I like the idea of packing igs and igm files. Here are my thoughts:
OnoSendai wrote:
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