material uid problems

[FakeShamus]

ok, I had a feeling this might lead to some issues - I am getting materials mixed up in my scene because when created and saved out as igm files through indigo they have the same material uid. when I assign these as external materials in Blendigo my objects sometimes get the wrong material applied due to this double id. you can use the material picker in the Indigo gui while rendering and it correctly shows the material and its settings for each object, but in the render itself the object renders with the wrong material.

[FakeShamus]

maybe I should post this in the bugs forum, I'm having more trouble due to the material uid system and no responses here so far.

so, whenever I generate a new material from scratch in Indigo it assigns some random low number for the mat uid. when I assign those materials as external igm's in Blendigo they often come into conflict with other materials exported from my scene. so instead of rendering the material I've created, it renders as one of the other materials in my scene which happens to have the same material uid.

now, this gets even more complicated when creating nested blended materials, or, for example, the new double-sided materials. in order to solve the conflict you have to manually change all of the mat uid's in a text editor and make sure that all the references link up correctly in the blended material - if this is not done correctly Indigo crashes immediately when opening the scene that uses the blend material, with no explanation or error message.

I don't know what the solution is aside from going back to the regular naming convention that was used previously, it is really messing with my workflow. can someone respond with ideas for a fix?
thanks!

[CTZn]

Hi Fakeshamus, I'm answering by principle but in reality I haven't implemented the model2 yet; it's not documented afaik and the crashes aren't helping indeed. I think that UID may not coexist with named references.

Keep in mind that Indigo 3.6 is at a beta stage atm.

As for (p)igm files with UID, the fix should be easy, yet is it to come. Replacing an existing material by another one would be a good option if it wasn't happening at "random"

[OnoSendai]

Hi FakeShamus,
Materials saved out from the latest Indigo save out their UIDs, which they didn't in the past.
Exporters will need to take this into account from now on when importing materials or using external materials.

If that is too tricky I might revert the change that saves out UIDs.

nick

[CTZn]

Regardless of the implementation for exporters, this could be a nice option I think:

Upon importing a (P)IGM with an embedded UID clashing, ask the user wether it should update the material already defined with the same UID, or be a new material with an overriden UID. Users don't have a control on UID's anyways.

This could be declined into a File menu item: update selected material, in addition to import.

It's a feature

[FakeShamus]

I was thinking a quick fix for this could be to just assign some random, high uid number when creating materials from scratch in Indigo. as it is, they all seem to get "8" by default, which almost always conflicts with something. maybe reserve 4-digit uid's for newly created external materials, something like that.

[CTZn]

That would still mean exposing Indigo to eventual clashes, any thin the margin.

[FakeShamus]

right - eventually you would want some conflict-checking system built in, but I think for most cases this would avoid the problem. can I ask what the benefit is to the uid number system vs the old naming convention? if it has to be a number, could the uid be somehow determined by the material name? translate the name into a numerical code?