Indigo Renderer Forum

------------Current Specification-----------

IGM specification

* An IGM file must be a (well formed) XML document with extension .igm
The root element of the XML document should be called scenedata.

* There may be multiple materials, media, etc.. defined in the XML document. (This is required for blend materials and specular materials respectively)

* There should be exactly one 'root material' defined in the XML document.
It may have any name, but a good default name is the name of the IGM file without an .igm extension.
A 'root material' is a material that is not referenced by any blend materials in the IGM file.

* Custom NK data files are not allowed, just use the ones in the Indigo distribution.

* All materials using maps of any kind should use the uv set with name 'default', e.g.
Packed Indigo Material (PIGM) specification

* A PIGM file must be a valid Zip (e.g. Pk-zip / winzip compatible) file.

* A PIGM file must have the extension .pigm

* A PIGM file may contain any number of textures.

* All textures required by the material must be included in the PIGM archive.

* A PIGM file should contain exactly one IGM file.
The contained IGM file may have any name

* All .igs or IGM files contained in the PIGM file should only use relative paths to any referenced resources (textures). This guarantees the 'relocatibility' of the PIGM file.


------------End Current Specification-----------


Hi all,
for various reasons, I think it's time to update the Indigo material file format (which has extension .igm)

One of the reasons is that I have added scene packing functionality into Indigo, and noticed that it should be easy to pack material files as well.

Some info on scene packing:
Packing a scene involves parsing the scene file, finding all referenced resources, such as textures, IES files, included .igs files etc.., and copying these resources into a zip file. The scene file is then updated to make sure all paths are relative, so that when the zip is unzipped, all paths will be valid.

So packed Indigo scenes are just zip files, with the extension '.pigs'.

And of course, .igm files could be packed the same way
However, some conventions will be needed to be codified.

So on that note, I'd like to propose an new .igm format, and get feedback on it from people, especially exporter writers.

IGM / PIGM requirements

* pigm's shoud be the type of file that is downloaded from the Indigo material website, when/if it is ever created

* pigm's. or igms, could be included in a 'materials' directory with the main Indigo distribution. Still thinking about this one.

* igm's should be able to be loaded by plugins, and the xml should be parsed if possible, so that the user can tweak colours, parameters etc..

pigm loading by plugins is desirable, but it may not be possible/easy to unzip files with the scripting languages. (Actually now that I think about it, Indigo could easily unpack the files for the plugin)

* igm's should be able to be saved by plugins ( and pigms if possible), in order to facilitate sharing of materials, and uploading to the material database etc...








So exporter writers, material database writers etc..., let me know what you think, in particular if this format can meet the requirements I listed.






------------Old Specification-----------


* REMOVED: The PIGM file should contain exactly one PNG file containing a render of the standard material test scene (ok this doesn't exist yet ), with the material applied.
the PNG file should be called preview_0.png, and should be in the root of the PIGM archive. (i.e. not in a subdirectory)
The PNG file should have dimensions of 500 by 500, and be in 24 bit RGB colour.



OLD IGM specification

An IGM file must be a (well formed) XML document with extension .igm
The root element should be called scenedata.

There may be multiple materials, media, etc.. defined in the file. (This is required for blend materials and specular materials respectively)

There should be exactly one material defined, that has the same name as the IGM file, but without the 'igm' extension.
For example, glossy_wood.igs should contain a material called 'glossy_wood'.
This convention allows exporter writers to find the correct 'root' material in the IGM file.

OLDPacked Indigo Material (PIGM) specification

a PIGM file must be a valid Zip (e.g. Pk-zip / winzip compatible) file.

A PIGM file may contain any number of textures.

A PIGM file should contain exactly one IGM file with the name of the PIGM file, except with an .igm extension instead of a .pigm extension.
For example, the file glossy_wood.pigm should contain a file called glossy_wood.igm.

All igi or IGM files contained in the PIGM file should only use relative paths to any referenced resources (textures). This guarantees the 'relocatibility' of the PIGM file.


So exporter writers, material database writers etc..., let me know what you think, in particular if this format can meet the requirements I listed.

Can Indigo pack a scene from a simple command line and die ? The exporter could send only specified materials to Indigo and generate a igm file, or the whole scene and pack a pigm. Could that be ?

CTZn wrote:Can Indigo pack a scene from a simple command line and die ? The exporter could send only specified materials to Indigo and generate a igm file, or the whole scene and pack a pigm. Could that be ?

Yup.

./indigo_console.exe --pack scene.igs output.pigs

or

./indigo_console.exe --pack mat.igm mat.pigm

Note that Indigo will automatically pack all textures and other resources referenced in the .igs / .igm into the .pigs/.pigm

Well.. it's pretty much the same as it is now. Only currently the root element of igm is <materialdata> and not <scenedata> (yeah, scenedata would be much more logical). Also paths in igm are relative already, cause the textures/nk's are included with the igm.

Only thing that i personally don't like is the requirement, that the igm name must be the same as a root material inside. Currently the user can export an igm file from max and save it under any name he wants or finds apropriate. The material name in Max can be different than the igm name. So this new requirement would force the user to export either under the same name as a material in Max or the Max name will change (after importing) to the name of the igm file.
I think it's not hard for exporter writers to determine the root material (it already works fine..at least in SU and Max scripts). I think the most complex is blend material, but that is also easily solved by checking if blend is inside other blends. If not, then it's root mat. But correct me if i'm missing something.

What's about complex Blend materials?
That wouldn't make too much sense in my eyes...

OK, I think that this is basically a good idea.

However, I would like to ask you again Ono to make the material relative paths all consistant - ie, all relative to the scene file location, because for now NK data is relative to the indigo folder, not the scene.

This might be a minor point, but I know that some people here have created their own NKs, and I don't see why everyone should be forced just to use the ones that you have supplied inthe indigo package anyway.

@dougal2
You can read nk data from anywhere you like. Include it with your igm (like a texture) and done.

@Kram
The count of blends inside blend is not limited and they may not be in perfect order inside the file.

[edit]
@dougal2
Ok. That's probably not what you meant.

The paths are inconsistent for a reason - which is that camera response functions, and nk data files, I considered to be a fixed set of data that is not really added to, and data that is included in the Indigo distribution. But I guess people do want to use their own nk files, and perhaps camera response functions as well.

Perhaps I could use a special 'environment' variable that could be inserted into path names, e.g.
or

for backwards compatibility

suvakas wrote:@dougal2
You can read nk data from anywhere you like. Include it with your igm (like a texture) and done.

@Kram
The count of blends inside blend is not limited and they may not be in perfect order inside the file.

[edit]
@dougal2
Ok. That's probably not what you meant.

Suv: you can currently use a .nk located anywhere, by specifying an absolute path, but once you use absolute paths then the resulting .igs file isn't relocatable.

well, I certainly use different camera responses.

Are you going to include the whole set in the next release? if so, my point becomes a little less important.

I have a question about sharing textured materials....

.. what should be given in the <uv_set> tag ?

Users will need to edit this for their models. This makes the whole sharing of materials a little less trivial than simply including a file and launching the render.

Also, if I were to be providing a web materials generator/database what should I put in there as a default?

Goog idea, i think. And Blendigo will support it for sure!

dougal2 wrote:I have a question about sharing textured materials....

.. what should be given in the <uv_set> tag ?

Users will need to edit this for their models. This makes the whole sharing of materials a little less trivial than simply including a file and launching the render.

Also, if I were to be providing a web materials generator/database what should I put in there as a default?

Just use "default" as the default

will do... that's what MtI exports for .obj files. It'll work fine for me

very good! cindigo will support it for sure!