Vanishing/Broken Meshes

[sebastian.vesenmayer]

Hi,

 

we updated our project to 2.8 version of the engine.

We have issues with vanishing and broken meshes when starting our application again.

There is no way to reproduce this problem properly, but we think it is on Unigine side.

We observed this with generated meshes during runtime and loaded node files from the hdd.

 

We first observed this in the 2.7 version of the engine. Back then we fixed it when calling this console command:

render_manager_reload

But it was removed from the engine in 2.8.

 

We are using opengl, reproduced it on 1070/1080TI graphic cards with also newest driver version of nvidia.

VRAM usage is about 25 %

 

Thank you for your help

 

 

[silent]

Hi Sebastian,

This command was renamed to render_streaming_reload. All the changes you can find in migration guide: https://developer.unigine.com/en/docs/2.8/migration/migration_console

If this will not help - could you please prepare a test scene so we can check this on our side as well?

Thanks!

[sebastian.vesenmayer]

This happens very unpredictable, so i guess i cannot give you a simple test scene on this, it will take some time to reproduce it. But we observe it often.

I will try that command when i see it again.

[sebastian.vesenmayer]

Hi, i had the same issue today again. The command resulted in an ogl out of memory error but the mesh was repositioned to the right place i hope. Graphics card 1080 Ti, vram usage about 5 gb of 11 gb. Only application running on the pc. 

Pictures will follow 

Edited September 26, 2019 by sebastian.vesenmayer

[sebastian.vesenmayer]

And here again on another run are missing wheel parts

Edited September 27, 2019 by sebastian.vesenmayer

[sebastian.vesenmayer]

What we are doing is very simple.

We are saving the mesh file on the drive:

    mesh->save(meshName.get());

And create an ObjectMeshStatic:

   auto node = Unigine::ObjectMeshStatic::create(mesh_name);

That is all we do. I guess when i call render_streaming_reload mesh, and the mesh gets visible then, then you have a bug in the engine.

The file is not touched anymore by us after it gets saved.

[silent]

Hi Sebastian,

If you add new files at run time, the Engine won't know anything about such files. To add the files to the virtual file system, use addVirtualFile(). Maybe that will somehow help.

It's hard to say what is going on without seeing the whole scene or at least a small test application.

[sebastian.vesenmayer]

Well when the Engine won't know anything about such files, than it would render nothing, am I correct?

So why do I see my scene and an incomplete vehicle when the engine won't know about anything of these meshes? They are all created the same way.

And why is render_streaming_reload help to load it correctly even if addVirtualFile() is never called?

Why do I need addVirtualFile()?

Is static ObjectMeshStaticPtr create ( const char * path, int unique = 0 ) function not able to load meshes from a mount point with the path correctly?

m_fsTemp = Unigine::FileSystem::get()->createMount(getTempPath().c_str(), getTempPath().c_str(), Unigine::FileSystemMount::ACCESS_READWRITE);

We have a mount point, and every node, mesh, texture is located there when we save it over the node/mesh/image.

The only thing that could cause this, is when the engine is saving files threaded and a race condition occurs when trying to load it, and garbage data is produced. But i hope you are not doing it. And we did also see this with not producing data during runtime.

 

Like I said, it is not very easy to reproduce and it is going to be even harder to create a reproducer.

It also depends on viewpoint and view direction of the Player.

 

You can be lucky and everything is alright and you can be unlucky and it breaks, that is what we are observing.

 

[silent]

Sebastian,

Quote

Well when the Engine won't know anything about such files, than it would render nothing, am I correct?

So why do I see my scene and an incomplete vehicle when the engine won't know about anything of these meshes? They are all created the same way.

My first assumption was that this exact node is only created from code, but if other nodes are also created and displayed correctly, it should be something else.

 

Quote

You can be lucky and everything is alright and you can be unlucky and it breaks, that is what we are observing.

I understand that it might be very tricky to create a scene or provide a project, but in order to fix this we need to at least reproduce this behavior couple of times.

We will continue our attempts, but if you already have some kind of reproduction (at least if you have this issue 1 out of 5 times - it's already a good result, we can work with this) it would be very helpful.

Thanks!

[sebastian.vesenmayer]

Hello again,

 

just wanted to let you know that we may found the issue.

We did observe NVIDIA driver crashes and side effects (default framebuffer is extremly malformed and stretched in QOpenGLWidget) when using

Unigine::Render::get()->compressImage(image, 1, Unigine::Image::FORMAT_DXT5, 1);

The crash and side effect appears a few frames later, so we think that stack or heap gets corrupted.

We checked the framebuffer texture which looks ok when the widget output is malformed.

We have deleted that line of code and since then it did never happen again.

We also did not see any missing or broken meshes since then.

So that is maybe a hint for you to fix it.

[silent]

Hi Sebastian,

Thank you for the additional information.

We use GPU compression heavily for importing textures inside Editor, but never saw any artifacts. It would be great to see the whole code that leads to this behavior. Did you call this method from the main thread only?

[sebastian.vesenmayer]

Hi silent,

We are calling this from the thread where unigine engine has been initialized.

We are mainly using opengl and I am not sure if we ever saw this with directx.

[silent]

I'm afraid the only symptom was cured (by removing the call to compressImage), but without any reproduction it's really impossible to say. So far I believe it's a good sign if you can run your application without any strange rendering artifacts.

We will also try to check the compressImage implementation in combination with OpenGL, maybe some unnoticed issues will arise.