I have a question; why would it be necessary to define materials in the IGS file before outputting the meshes? Could this restriction be relaxed to allow late binding of materials to meshes?
Why I ask is that for the exporter I've been writing (for Houdini) it's more convenient to output geometry all the while collecting all bound materials, and then exporting the relevant materials. It would save traversing the geometry twice or save me making the redundant assumption that *every* material in the Houdini scene should appear in the IGS file.
Thanks!
Jason
IGS export question: why materials first?
You can <include> your materials igs file before the geometry definitions in your main Indigo scene file.
When you do your actual material export (before or after outputing the geometry) is up to you. Having materials in a separate file would also make it possible to update materials without exporting the geometry at all.
Makes sence?
When you do your actual material export (before or after outputing the geometry) is up to you. Having materials in a separate file would also make it possible to update materials without exporting the geometry at all.
Makes sence?
There's no particular reason, apart from that it was easiest to code the scene loader that way.
However it does have the nice side-effect that a given material (name) can be redefined, which allows varying materials to be applied to instances of the same model. (Although this could be achieved in other ways)
However it does have the nice side-effect that a given material (name) can be redefined, which allows varying materials to be applied to instances of the same model. (Although this could be achieved in other ways)
Hi Ono,
Thanks for the explanation. Could put in a request to relax this restriction?
In Houdini you can apply different shaders to each polygon and it'd be most convenient to be able to gather all shaders while writing the mesh and then spit out the associated shaders. It'd also help with the "archiving" portion of Indigo4Houdini (ie, the <include> stuff) where I could inject scene data into the include file in whatever order is most simple/convenient/elegant for the exporter.
I hear what suvakas is saying about dropping in an <include> and doing it in my own reverse order but my goal is really to keep everything in one file as much as I possibly can; holding out hope that one day I'll be able to pipe directly into Indigo in the same manner as PrMan, Mantra or mental ray (which is another request of mine:)).
Thanks,
Jason
Thanks for the explanation. Could put in a request to relax this restriction?
In Houdini you can apply different shaders to each polygon and it'd be most convenient to be able to gather all shaders while writing the mesh and then spit out the associated shaders. It'd also help with the "archiving" portion of Indigo4Houdini (ie, the <include> stuff) where I could inject scene data into the include file in whatever order is most simple/convenient/elegant for the exporter.
I hear what suvakas is saying about dropping in an <include> and doing it in my own reverse order but my goal is really to keep everything in one file as much as I possibly can; holding out hope that one day I'll be able to pipe directly into Indigo in the same manner as PrMan, Mantra or mental ray (which is another request of mine:)).
Thanks,
Jason
Well..I don't know anything about any pipes and stuff, but why do you want to keep everything in one file? Let's say you have your 1 million poly scene exported and then you want to change your red material to lets say green. If everything is in one file, then well.. you either have to seek through that file and replace the red material or export the entire scene again. With includes you would have to only re-export the file containing materials.
You're absolutely right, the external archive (ReadArchives in Renderman speak) can be very useful with large scenes, especially because ASCII geometry definitions can be painfully slow - but for 95% of scenes it is only a matter of seconds to export all your geometry.
The standard Houdini way is to default to embedded all geometry in the stream, but offer "Archiving/AutoArchiving" functionality to allow artists to parcel off geometry into separate files for inclusion in the scene stream.
The standard Houdini way is to default to embedded all geometry in the stream, but offer "Archiving/AutoArchiving" functionality to allow artists to parcel off geometry into separate files for inclusion in the scene stream.
Who is online
Users browsing this forum: No registered users and 39 guests