New Indigo material (.igm) format

[suvakas]

Any thoughts about the naming issue i talked about?
Should i really have to start re-writing my working igm import/export?
Doesn't sound fun at all.

[fused]

i think the igm/pigm should have the name of the root material. of course this might be a huge soure of problems, since many users dont know/care about this convention and will probably change the name of the igm/pigm to whatever they think fits better, but its sure is the easiest solution (especially when it comes to importing igm's).

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 dont know how max script or your plugin works, but mybe it is possible to let the user just specify the dir where the igm is exported to. the user would not even get in touch with the naming.

but maybe we (or you, ono ^^) can find another, more foolproof solution. maybe im talking nonsense, but what if the name of the root material name is stored in an extra text- or xml file (suffix could maybe be .rmn for "root material name"), or just an extra xml tag in the beginning of the .igm file (wich sure is easy to read out for both, indigo and the exporters)?

what do you think?

[suvakas]

Can you or someone else make an example situation, when it's so hard to find the root material, that we need to know the name of it?
What if there are 2 roots? 1st is "main root" and 2nd is a root of a 2nd blend material (blends inside blends). What happens then? You still need to figure out the "2nd root" via your exporter script, don't you? That means, that you still have to have this logic build into your exporter and not rely on igm name. Sounds logical or are my thoughts confusing?

Ok. I admit, that I'm fighting because i'm lazy and i'm not into rewriting Maxigo script, but I'd also like to hear a good reason why i should do this.

[edit]
No, no extra text files please.

[fused]

2 roots? i dont get what you mean. if its a blend the blend is the root?

sry...

edit: nevermind...

[suvakas]

Made a small tree..
How do you find those other blend roots if you only rely on the naming of the igm? You have to have the logic of "finding roots" ("roots - blody roots".. good song ) in your exporter. Get what i mean?

[dougal2]

no, you don't need to know anything at all about the blend dependancies.

reference the main root and move on...


edit: HAHA nice avatar!

[suvakas]

no, you don't need to know anything at all about the blend dependancies.

reference the main root and move on...

How do you show the imported igm in your 3d app if you don't know the dependancies?

edit: HAHA nice avatar!

lol
Thanks, and Merry Christmas !

[dougal2]

erm.. let me think about that - I've got my head deep in web coding at present.

[Whaat]

I like the idea of packing igs and igm files. Here are my thoughts:

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.

Sounds good. However, I like the current method of having all resource files stored in the same directory as the IGM file. For example, I don't think textures should be stored in a 'textures' folder and nkdata stored in an 'nkdata' folder (once the packed igm is unpacked). Maybe this makes sense for a packed IGS file but I don't like it for a packed IGM file.

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

You're kidding right? Why not use the extension .ips (indigo packed scene) or .ipm (indigo packed material) to avoid the inevitable mockery?

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

This might work fine. However, only basic beginner materials should be included and additional igm libraries could be downloaded from the website a la Kerkythea. Otherwise, the indigo download becomes too heavy and users end up getting a bunch of materials that they may never use.

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)

Indigo should unpack the pigms. This is not easy for me to do.

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

Yes, the exporters should save igms but saving pigms will not be easy. I like the idea of saving the igm and then calling indigo to pack the igm and then close itself. I think Indigo should be able to handle any errors that occur during the packing process (throw messages when resources are not found or XML is broken, or deprecated)

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.

I disagree 100% for the same reasons as suvakas. What if the user renames the igm file or edits the names in the XML?
I don't understand this discussion about finding the 'root' material. The root material should always be the LAST material defined in the IGM file. It doesn't make sense any other way. Indigo won't let you define a blend material without defining material A and B first. So why would you not structure the IGM file the same way? (Maybe I'm missing something here.) This is how it works in SkIndigo for importing multiple blended materials (probably the same in Maxigo)

One last thought. Does it really matter what we use inside the uv_set tag for IGM files? IMO, the exporters should all ignore this tag anyway when importing igm files. The uv requirements for the material would be chosen after importing the material anyway. However, i suppose the uv set should be standardized for igm files simply for consistency. Any further thoughts on this?

Some questions: Who should handle compatibility issues? For example, will indigo validate the igm file and make sure it is consistent with the particular version of indigo being used? Will indigo up-convert older igm files when unpacking if (and when) the xml changes in the material definitions? I suppose indigo could handle this for pigm files but what if the user is loading an unpacked igm file? I guess this would have to be handled by the plugin (this is already being done in SkIndigo)

How will thumbnails be handled with the new igm specification? Are they optional? They would be difficult to load if they are inside a packed igm file. I like the idea of browsing a material library within the plugin by paging through thumbnails. This might not be possible using pigms. I suppose that is what the material database is for.

Cheers,
Whaat

[suvakas]

I don't understand this discussion about finding the 'root' material. The root material should always be the LAST material defined in the IGM file. It doesn't make sense any other way. Indigo won't let you define a blend material without defining material A and B first.

Good point !

One last thought. Does it really matter what we use inside the uv_set tag for IGM files? IMO, the exporters should all ignore this tag anyway when importing igm files.

Yes, exporters should ignore it, but if someone would like to just <inglude> the igm file, then using UVset 'default' would work with both - 3ds and obj format. It will not work with xml though, but it's still better, than exporting no UVset at all.

[Big Fan]

ok there's always one right...

I am struggling to understand why you would want to do this - pack them that is
is this actually an issue for people presently?
are people passing massive files around? short of disk space? or something?
I don't really see why this needs to happen as part of indigo ATM..
I know there is a download size paranoia in the Blender HQ too but it is ridiculous to think people cant handle a few mb
As we speak I am downloading SAGE maths - 720 mb..
The Solidworks service packs are hundreds of mb every 2 months..
even something as common as Quicktime,Adobe reader or Skype is ~20-22mb
Nvidia Gelato is 67mb, Java 66mb...
I think ono should concentrate on adding render functionality - people aren't going to be put off by a few extra mb to download
just zip and unzip them yourself if need be or have I missed something vital?
how big can one material file be?

ok there you go controversy again

[Wedge]

I would really like to know if we could set a standard for uv set names. Or are they variables? How can they be standard, there can be more than one on each mesh? Can we number them? uvset1....uvset2.....uvset3?

In Blender exporter they have a name but I don't remember it at the moment and I'm too lazy to look.

[dougal2]

Big fan: packing materials is a good idea so that any albedo/bump/blend/exponent maps are included along with the material definitions.

This way the user gets single Carpet_material_5.pigm (or whatever) all with correct relative paths and textures self-contained, and doesn't have to een worry about which images it's using for what purpose or even what they're called.

It's massivley simplifying sharing materials. Download 1 file, plug it into your exporter, and away you go.

[Big Fan]

ok thanks @dougal2 I guess I was missing something then

so I will need to unzip these via python (I think there is a module) to access the tex images to give appropriate UV co-ordinates.. and change uv set names.. and allow people to tweak the materials if they want...

.. and I will need to then rezip them via python for indigo to use ( unzip) for the render? - or at least save over the unpacked one.. perhaps I want to keep the original too..
EDIT: well actually if you unpack something you will actually have to delete either the packed or the unpacked file afterward else you will have 2 material files available to be read in the folder..or.. rename them..

and everything ( all the little .piglets - packed and unpacked) will live happily in a 'materials' folder adjacent to indigo - ie stripped of its old file locations when packed.. is that it?

if I choose another texture than the supplied one while tweaking I will need to repack the .piglet so that the textures are all in and referenced together?...
EDIT: ie you would not want to / could not mix and match types and locations

how does this scene packing work if I already am using 'includes'? - and I might be doing this because I want to limit the size of files and just chain them together - I dont want to end up with one massive mesh file .bosshog and a materials etc file .mamasow

[xrok1]

I definatly think the pigm format should include a preview render, at a predefined resolution so nobody gets carried away. lets say 200x200.

I also have a thought, what will happen when your exporter creates a pigm from a material ie: mat name-floor ;texture name-oak; pigm name-floor boards_oak.

maybe the exporter would need to rename all the included files to the same name as the pigm, both when compressing and also check and rename again when extracting in case the user changed the pigm file name before using it.

Also maybe indigo should render a preview of the mat. at say 200x200 while creating the pigm, this way the previews could be consistent with camera; lighting; geometry etc.. settings the same for all previews and keep users from getting caried away and including 1200x1200 previews or whatever and bloating file sizes.

quite the bag of worms we have here!