Material Library Dependencies.

[danni.coy]

I have just been talking through some issues we are having in the office with losing materials.

 

The problem occurs when for some reason a material library doesn't load that another material library depends on. This results in the materials from the dependent material library being wiped on closing - If we weren't using a versioning system this would be a disaster for us. (occasionally it is when the material library hasn't been checked in).

What I think would be useful is to be able to define the material libraries that a material library depends on (similar to the way a node file can contain a list of material libraries). And perhaps not load a world if those files cannot be found.

[nat.harrold]

Importantly, please don't wipe node and material file definitions if engine can't find materials or material libraries without asking yes or no.

 

Perhaps more elegant solution is to use a fall back material that can be substituted temporarily by the engine with a descriptive texture. Do not discard original definition without a prompt.

Eg, if material was killed because it was an orphan, then perhaps temporarily substitute materials texture is red with the word 'orphan' on it.

Eg, if material was killed because it was not defined in a library, then temporary substitute material texture could say undefined

 

In these cases, it would be a relief to be able to load the material library if that was the cause or reset the parent without loading a library only to have it destroyed by the engine.

 

Further to this, it would be good if it was possible to:

1. be able re parent materials from within engine, (rather than text edits requiring a shutdown). Is this possible? If so, engine could print warning of incompatible parameters and let user cancel or force reparenting and engine removes unused or incompatible data.

 

2. (Mildy unrelated), be able to collapse or simplify the selected material's family tree. (Your great great grandparent is now your parent without changing the original result). This could be done by presenting user with dialog that displays linear family tree and allows choice of new parent from direct lineage.

 

Thoughts or questions?

[ulf.schroeter]

Nat, fully agree with your comments on graceful loading of incomplete material libraries including error visualization.

 

Nevertheless your last 2 feature requests for easy material re-parenting appear somehow 'wrong' to me (both conceptually and implementation efforts wise)

[demostenes]

I agree with comments above, it is pretty anoying and without having versioning system it would be disaster.

 

Also we have sometimes issue, that first material library (root one) is not saved to the world file, it is skipped. So next engine start no other library loads on start (they are dependent). We were not able to determine condition, when this happens. It seems random. Interesting is, that it is enough to load world for the second time after start and material libraries are loaded, even without having root library.

[nat.harrold]

Nevertheless your last 2 feature requests for easy material re-parenting appear somehow 'wrong' to me (both conceptually and implementation efforts wise)

Reparenting materials within the engine, I understand.. I'm also aware that I would much rather some amazing new rendering features than these tools.

 

However, the second point about simplification of the selected materials tree is not hard for unigine. It is just collapsing the stack. The engine already uses the final result of the parameters, but there is no way for the user to bake or absorb relevant and discard redundant parents parameters, the use case is for cleaning up deep hierarchies.

 

The request evolves from running many large projects from the same build and using extensive common material libraries for years. It is a simple, convenient cleanup tool request. Doing this manually in a text editor is difficult.

 

Hope this explains more.

[nat.harrold]

Also we have sometimes issue, that first material library (root one) is not saved to the world file, it is skipped. So next engine start no other library loads on start (they are dependent). We were not able to determine condition, when this happens. It seems random.

We have repeatedly encountered this one, and it is seemingly random. I have noticed that on save it can at random times remove some of the first libraries loaded in the world file, and when you open it world next time, many things are invisible due to dependancies. We quit, and manually add the missing libraries in text and it is ok.

 

Better post this to bugs.

[ulf.schroeter]

Hope this explains more.

Yep, thanks, now I got the idea. Indeed this should be quite easy to implement.