root material is not saved

[demostenes]

Sometimes we have 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 is happening. 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 (still not solves the issue, we have to exit the engine and manually add root material to the world file).

 

There are also others, who are experiencing same problem:

 

https://developer.unigine.com/forum/topic/2581-material-library-dependencies/#entry14249

[silent]

Hi,

 

If I understand you correctly, some times root material disappears from *.world file from the <materials> section? Could you please tell us if the other material libraries are still listed in the *.world file?

 

Also, could you please check the Node materials option state (Tools -> Common) on all of the computers where you perform save world operation? Node materials should be disabled to write all the materials directly into the world file (otherwise materials will be written to the node file).

 

Thanks!

[demostenes]

Hi,

 

If I understand you correctly, some times root material disappears from *.world file from the <materials> section? Could you please tell us if the other material libraries are still listed in the *.world file?

 

Also, could you please check the Node materials option state (Tools -> Common) on all of the computers where you perform save world operation?  should be disabled to write all the materials directly into the world file (otherwise materials will be written to the node file).

 

Thanks!

 

Yes, exactly. Root (first) material disappears from *.world file from the <materials> section and other libraries are still listed in the *.world file.

 

Well, we have Node materials enabled, but it works OK (as we want). Material properties are written into mat libraries and names of materials into node files. Only problem is that random disappearing of root material from world file (cca 1x per 20 world saves), everything else works as expected.

[silent]

Hi,

 

Thank you for this information. We are trying to reproduce such behavior right now, but with no luck.

 

Couple of questions left:

• How large is saving world should be(1Mb, 100Kb or doesn't matter)?
• How many objects in this world (100, 1000 or doesn't matter)?
• On what OS you get such behavior?

Also, could you please provide your Unigine editor config and a world file where this behavior was discovered? I believe with this files and additional info we can find what happening faster.

 

Thanks!

[demostenes]

It is usually very small 50-400KB. Anyway it does not seem that size matter.

It was happening from the beginning, so object count does not seem to matter too. We are using layer nodes, with content of layers nodes it is going above 1000.

Windows 7 64bit.

 

I ve sent you both files to engine-support@unigine.com

 

Thanks!

[silent]

Thanks! We will chek them too :)

[silent]

Hi,

 

Unfortunately, still can't reproduce this behavior. How often does it happen?

We will continue our investigation, so if you will have more information about this issue, please post it here or write directly to engine-support@unigine.com.

 

Thanks!

[demostenes]

Last days this is happening almost each save. Because root mateial library is not saved (first material library in the list of materials in the world file), next time all children libraries are saved as empty. Very anoying, I am returning content of these libraries 10x per hour.

 

Even more annoying is, that after world save such unloaded materials are removed from all nodes in scene containining these materials. So I have to fix 70+ nodes to be able to continue. And worst case is, if I notice this after several commits and hours of work, I have to figure our where is the problem and what return, what merge...I think automatical removing of not existing material from nodes (surfaces) should be disabled, or at least it should be posible to turn off this behaviour by some parameter in editor). Even if referenced material does not exist, name should stay there.

[silent]

Hi,
 
Unfortunately, we never met such issue with our internal projects. Also, we failed to reproduce this behavior with your .world file. Are you using latest SDK 2.0?
 

automatical removing of not existing material from nodes (surfaces) should be disabled, or at least it should be posible to turn off this behaviour by some parameter in editor). Even if referenced material does not exist, name should stay there.

We are totally agree with this part. I will pass this information to the developers.

Sorry for the inconvenice caused.

[demostenes]

Hi,

 

Unfortunately, we never met such issue with our internal projects. Also, we failed to reproduce this behavior with your .world file. Are you using latest SDK 2.0?

 

We are totally agree with this part. I will pass this information to the developers.

 

Sorry for the inconvenice caused.

 

Yes, latest version. I really dont know what is causing that, I have feeling, that more heavier the world is (more objects, nodes...), more often it happens. We have now 12*12km terrain with full vegetation (like Valley demo) + 10k mesh objects (cca 1500 unique).

 

This will help a lot. Thanks!

[demostenes]

This problem is still present. It is absolutelly random and happens only in heavier scenes.

[silent]

Hi Jirka,

 

Are you using some kind of antivirus of VCS that can can possibly affect on read/write access for the files on your hard drive? We tried hundreds of times to reproduce this behavior on our test stand, but with no luck.

[demostenes]

Hi Jirka,

 

Are you using some kind of antivirus of VCS that can can possibly affect on read/write access for the files on your hard drive? We tried hundreds of times to reproduce this behavior on our test stand, but with no luck.

 

No, it did even before antivirus. This is how usually look "problematic" worldfile:

 

<?xml version="1.0" encoding="utf-8"?>

<world version="2.1">

<budget>60</budget>

<materials>

<library>esq.mat</library>

<library>birches_leafandstem.mat</library>

<library>medieval_village</library>

<library>market_town.mat</library>

<library>marketplace.mat</library>

<library>slums.mat</library>

etc

</materials>

 

And sometimes root library (esq.mat), is not saved during save, so it disappears from the list. I never expected it in simple world, only in world with 3000+ nodes. But as I said, it happenes once per 20-30 saves. I will run always in debug mode and I will check log, when this happens.

[demostenes]

Now it is happening almost in 100% of cases. Probably because complexity of world increased even more. Nothing in debug log.

[demostenes]

It definitelly depends on the number of nodes (unique objects and textures) in the scene and probably low framerate. With these two combinations it is happening in almost 100% cases.

[demostenes]

I ve created new scene, added several thousands od nodes and it started to do this sometimes. And frequency increases with number of nodes. With 10000 thousand od nodes, it happens quite often.

[demostenes]

For simulation of this bug you can use esqworld.world (any project chagest, lets use 43). Open world, pretend some activity, add node, edit node etc...save. Sooner or later you will find esq.mat missing in materials section of world file, my frequency is now cca 20%:   

 <materials>
        <library>esq.mat</library>
        <library>tropical_dexoft.mat</library>
        <library>medieval_construction_kit.mat</library>
        <library>medieval_addons.mat</library>

......

 </materials>

Edited October 1, 2017 by demostenes

[silent]

Hi Jirka,

Thx, will try to reproduce again.

In 2.6 we removed material libraries, so this bug will be gone. The only concern here is the migration process, that (due to old system imperfection) can cause various unexpected results.

Thanks!

[demostenes]

Ok, if there are no material libraries anymore, no reason to solve this...