New Indigo material (.igm) format

A forum for exporter development discussion.
User avatar
OnoSendai
Developer
Posts: 6241
Joined: Sat May 20, 2006 6:16 pm
Location: Wellington, NZ
Contact:

New Indigo material (.igm) format

Post by OnoSendai » Sun Dec 23, 2007 9:56 pm

------------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.

Code: Select all

<albedo_texture>
	<uv_set>default</uv_set>
	<path>textures\tex.jpg</path>
	<exponent>2.2</exponent>
</albedo_texture>

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.
Last edited by OnoSendai on Mon Jun 09, 2008 7:52 pm, edited 7 times in total.

User avatar
CTZn
Posts: 7240
Joined: Thu Nov 16, 2006 4:34 pm
Location: Paris, France

Post by CTZn » Sun Dec 23, 2007 10:08 pm

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 ?
obsolete asset

User avatar
OnoSendai
Developer
Posts: 6241
Joined: Sat May 20, 2006 6:16 pm
Location: Wellington, NZ
Contact:

Post by OnoSendai » Sun Dec 23, 2007 10:12 pm

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

User avatar
suvakas
3rd Place Winner
Posts: 2613
Joined: Mon Sep 04, 2006 11:08 pm
Location: Estonia
Contact:

Post by suvakas » Sun Dec 23, 2007 10:59 pm

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.

User avatar
Kram1032
Posts: 6649
Joined: Tue Jan 23, 2007 3:55 am
Location: Austria near Vienna

Post by Kram1032 » Sun Dec 23, 2007 11:22 pm

What's about complex Blend materials?

Code: Select all

Material_Name

Blend_A

Material_Name_A
Material_Name_B

Blend_B

Material_Name_C
Material_Name_D
:?:
That wouldn't make too much sense in my eyes...

User avatar
dougal2
Developer
Posts: 2532
Joined: Wed Nov 15, 2006 8:17 am
Location: South London

Post by dougal2 » Sun Dec 23, 2007 11:32 pm

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.

User avatar
suvakas
3rd Place Winner
Posts: 2613
Joined: Mon Sep 04, 2006 11:08 pm
Location: Estonia
Contact:

Post by suvakas » Sun Dec 23, 2007 11:37 pm

@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. :)

User avatar
OnoSendai
Developer
Posts: 6241
Joined: Sat May 20, 2006 6:16 pm
Location: Wellington, NZ
Contact:

Post by OnoSendai » Sun Dec 23, 2007 11:45 pm

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.

Code: Select all

		<phong>
			<nk_data>$(INIDIGO_BASE_PATH)/nkdata/ag.nk</nk_data>
			<exponent>1000</exponent>
		</phong>
or

Code: Select all

		<phong>
			<nk_data>$(SCENE_BASE_PATH)/nkdata/ag.nk</nk_data>
			<exponent>1000</exponent>
		</phong>
for backwards compatibility

User avatar
OnoSendai
Developer
Posts: 6241
Joined: Sat May 20, 2006 6:16 pm
Location: Wellington, NZ
Contact:

Post by OnoSendai » Sun Dec 23, 2007 11:46 pm

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.

User avatar
dougal2
Developer
Posts: 2532
Joined: Wed Nov 15, 2006 8:17 am
Location: South London

Post by dougal2 » Sun Dec 23, 2007 11:50 pm

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.

User avatar
dougal2
Developer
Posts: 2532
Joined: Wed Nov 15, 2006 8:17 am
Location: South London

Post by dougal2 » Mon Dec 24, 2007 2:37 am

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?

User avatar
SmartDen
Developer
Posts: 999
Joined: Fri Oct 13, 2006 10:58 pm
Location: Canary Islands
Contact:

Post by SmartDen » Mon Dec 24, 2007 3:55 am

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

User avatar
OnoSendai
Developer
Posts: 6241
Joined: Sat May 20, 2006 6:16 pm
Location: Wellington, NZ
Contact:

Post by OnoSendai » Mon Dec 24, 2007 4:25 am

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 :)

User avatar
dougal2
Developer
Posts: 2532
Joined: Wed Nov 15, 2006 8:17 am
Location: South London

Post by dougal2 » Mon Dec 24, 2007 5:04 am

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

User avatar
fused
Developer
Posts: 3648
Joined: Fri Sep 22, 2006 7:19 am
Location: Berlin, Germany
3D Software: Cinema 4D

Post by fused » Tue Dec 25, 2007 12:41 am

very good! cindigo will support it for sure!

Post Reply
60 posts

Who is online

Users browsing this forum: No registered users and 5 guests