New Indigo material (.igm) format

[Big Fan]

my feeling is that although .pigs may be useful for archiving and transport having zipped materials for daily use seems to present a few practical issues - I wonder if this is really such a good strategy?

[dougal2]

Actually, thinking about it I think it's a really good idea - so long as the spec for it stays very simple, as Ono has given.

As soon as you start piling up multiple materials in a single file there comes a need to de-compile that file in order to dig around and find stuff in it.

If it's just one material, end users have no need whatsoever to even know what's inside it, only that when used in rendering it gives them the material they want.

As a side note, I'm not sure if Ono is planning this, but using .pigms directly in <include> statements would be a wonderul thing

Code: Select all

<include>
 <pathname>../materials/Flooring_planks2.pigm</pathname>
</include>

Keep it very simple, I think is a good idea.

[Big Fan]

well I am not so concerned about the spec I am thinking of the practical aspects of handling them and what people would then want to do with them
I would rather just 'include' them than actually load them into the exporter for modification rename previews etc whether it be as materials or zipped ones
so either offer an 'include' of demo materials in the download or have a user library of .pigm to 'include' as you have started - or both
if people want to modify the provided materials directly they can use a material editor otherwise they just pack one they have set up in their exporter..
perhaps if there was a unified soln with all our tools in one application it would work better -at the moment I think it is in danger of becoming too complex for simple scripting to handle

[dougal2]

I don't think exporters (by definition) should do anything with the igm/pigm files other than build <include> tags.

However, if people want to be able to edit these materials, perhaps an effort could be started on importer scripts.

Having done it in PHP (where you can do pretty much anything) and seen what a PITA it can be, I'm certainly not interested in starting an import script.

[Big Fan]

yes I think thats what puts me off really
the prospect of the basic exporter turning into an importer/swiss army knife modifier/exporter tool..
this might be disappointing to people who would like to do all manner of things but I am kind of in favour of putting this in the too hard basket ATM
'includes" I would go with..

[xrok1]

maybe we should just set a standard for sharing mats and be done with it.

(1 igm file +1ipg texture(if needed) +1jpg 200*200 preview).ZIP done with the descussion, anyone strays from the guidelines thats up to them.

[dougal2]

Ono already set a standard, I think he got it right first time

[dougal2]

A thought on loading materials from the database to edit- "importing":

I can get the database to directly generate scripts for 3D apps
For instance, I can very easily export the material parameters as a Maya MEL preset script, which will set up a Maya shader for me.

That's much much easier than writing an XML -> MEL translator. It's almost trivial.

(this is actually one reason why I wrote the database the way I did - it allows outputs other than XML/IGM etc).

Question is, is this possible (thinks to self - "it must be") with other apps? is it feasible to generate a .py script for blender? maxscript for Max? Can other programs setup materials and shaders in this way?

[Whaat]

Maxigo and SkIndigo can already import IGM for editing. IMO, all exporters should have this feature (I think Ono mentioned this as well) I don't think your proposed method would work for SkIndigo anyway but it might be worth looking into for other apps.

If anyone is interested, I created my own XML parser to load IGMs. It is based entirely around the Ruby 'split' method which splits a string into an array using an arbitrary delimeter. As long as there is a similiar method in MEL, Python, etc. it would be simple to translate my IGM import method for use in other apps. Simply using exporters to generate an 'include' tag seems rather silly.

[Wedge]

I started to write IGM support awhile ago and had a somewhat working version but it was a disaster of code and was later removed. Probably my fault because I wrote it a certain way but regardless, I am keeping the classic Blender exporter very simple now days. I will not be doing anything with importing materials and other than exporting them as normal that will be as far as that goes.

But as for using include to bring in a package of materials from Indigo or some other place I am fine with that. That will only take about 15 minutes to write for code. Create a button in the GUI, provide a box or two or three or provide a way to include multiple files if the need be, or separate multiple files by ; character or something and be done with it. Simple and doesn't take me a week to write.

I am a few days away from my 1 year mark on maintaining the classic exporter and I am not up for going too deep inside the code anymore. From now on I am sticking to my idea of what I think a exporter should do and what I think a separate program needs to do.

[Big Fan]

@whaat
I still prefer not to do this 'importer' feature over a simple 'include' ATM
really its up to each applications export writers whether they use stuff or not and whatever onon's opinion is
if you have this for skindigo good for you
I guess it comes down to asking blender users how much need they have to modify a material from the library - if they are happy using it as supplied well an 'include' is fine - if they want to mess with it we will have to do more..
ATM I am not fussed about doing this and I see wedge and dougal2 aren't either
however...after poking around a bit it seems a python install is able to do quite a lot with xml with the provided modules..it would be possible ( I think) to link to a library on the web, choose and download a pigm, unzip, and then load material parameters into blendigo...and I guess the reverse...
this would be new territory for me though and take a while to get my head around doing it - I think we could run this as another script from inside the existing ones
- possibly someone out there is familiar with python/xml already?
perhaps this is what zeugs alluded to before when he spoke of rewriting for xml
as far as I can tell trying to do anything without xml approach would be more work than anyone wants to put in

[Whaat]

@Onosendai,

So...should we expect any changes to the above specification now that you have received some feedback? I would like to start implementing the new IGM spec but I was going to wait until it was 'official'.

Question:
How should nkdata be handled? I think the nkdata should be included with the IGM to allow for custom nkdata files. (Maxigo and SkIndigo currently export IGMs this way)

Where should the textures and nkdata be located? What should be the relative path? Is there supposed to be a 'textures' folder and an 'nkdata' folder included with the IGM?

[dougal2]

Whaat:
for the nkdata stuff I really think Ono should change the nkdata code so that paths are relative to the scene, and not the indigo directory.
As it is, the nkdata folder lives in the indigo directory ... not very "portable"

For textures, it doesn't really matter what the folders are called, as long as the paths relative to the scene file are correct.

FWIW, for the DB I have chosen
textures/Albedo/
textures/Bump/
textures/Exponent/
textures/Blend/
for the various types.

[Whaat]

For textures, it doesn't really matter what the folders are called, as long as the paths relative to the scene file are correct.

OK...so if you 'include' an IGM file in your scene, and the IGM file is not in the same folder as your IGS file, will the IGM textures load properly? Has anyone tried this? Basically I am wondering if all paths must be relative the root scene file or relative to the file that they are in (for example, an included file)

FWIW, for the DB I have chosen
textures/Albedo/
textures/Bump/
textures/Exponent/
textures/Blend/
for the various types.

I have no problem with that but I will probably use a different convention unless instructed otherwise by Ono.

[dougal2]

I would test it, but I'm too busy making changes to the DB right now.