getD3d11Texture crashed when called ferquently in unigine 2.0 RC

[ianyyin]

Hi,

 

We are using getD3d11Texture () very frequently, it was very stable in unigine 1.0.

 

When we migrate our code from unigine 1.0 to unigine 2.0 RC, the function does not always return the valid pointer, it started to return some meaningless pointer which exceeds the memory limit.

Also, it is causing the memory violation crash in our solution.

 

Could you check what has been done in the recent release in the rendering pipeline which could result in this problem?

 

Thanks,

Ian

[silent]

Hi Ian,

 

We will surely try to reproduce this issue.

 

Could you please also provide a small test scene that causes this crash so we can check it on our test stand?

Thank you!

[ianyyin]

I reproduced it in unigine 1.0 if I turned off the flag render_manager_create_textures to 0.   It will crash too.

When we set it to render_manager_create_textures to 1. When we are frequently accessing the getD3d11Texture function, and when the texture is out of the current frustum, and back to the current frustum. It will always give us a valid pointer for the texture memory.

 

It looks like the mechanism in rendering engine to manage the memory/textures changed from unigine 1.0 to 2.0.

We have tried both of render_manager_create_textures 0/1, both of them will cause the crash/invalid pointer returned by getD3d11Texture while the texture is out of current frustum (our of the current camera viewport) and back to the frustum.

 

I believe the render_manager_create_textures = 1 no longer forced the texture is preloaded? and it is dellocated when the texture is out of the frustum?

Please help us to check how to avoid the invalid pointer of the texture, if the texture is out of frustum and back to the frustum very often.

[ianyyin]

Hi silent,

 

I cannot provide a c++ source code or scene, because it is deeply integrated into our project.

However, based on the above observation of the behavior, I think it is related to the memory management in new Unigine 2.0 version.

When the texture is out of the current frustum, the pointer is delocated somehow. Even, we set up the flag and force "render_manager_create_textures" = 1 to preload all textures in the beginning.

 

Is there any way for us to avoid this problem?

 

Thank you!

[silent]

Hi Ian,

Thank you for the additional information.

RIght now we are still investigating this issue, so if you can provide us:

1. Engine log file at the moment when you get crash;
2. Visual studio callstack from debug engine build (how to get a callstack)
3. Engine version that worked before (e.g. 2014-07-07);

All this information will surely help us to better understanding what can cause such behavior.

 

Once we can reproduce this behavior we will surely fix it.

Thank you for your patience.

[ianyyin]

Hi silent,

 

I checked the 2.0 console migration guide, it showed render_manager_create_textures console variable is removed in 2.0.

 

In 1.0, we forced that variable to be 1 for our usage. to force preload the textures for the scene instead of dynamically allocate and dellocate the texture memory.

If it is no longer supported in 2.0,  which could cause our problem.

 

In this case, anything you can suggest? or will such a console variable/functionality be supported?

[silent]

Hi Ian,

 

Without a stable reproduction we can't suggest you a proper solution, sorry. We are still trying to reproduce this behavior. Log files and other information that I mentioned in the previous post will be very useful to us.

 

Thanks!