1.11.2 Cubemap cleanup crash Topic is solved

Problems building or running the engine, queries about how to use features etc.
Post Reply
rpgplayerrobin
Gremlin
Posts: 151
Joined: Wed Mar 18, 2009 3:03 am
x 16

1.11.2 Cubemap cleanup crash

Post by rpgplayerrobin » Sat Nov 17, 2018 8:27 pm

Ogre Version:: 1.11.2
Operating System:: Windows 10
Render System:: Direct3D11

Hello!

I have an assert crash when exiting my application when using Direct3D11 with a cubemap texture (with RTT), but I think it might be a bug.

Everything works on OpenGL, Direct3D9 and Direct3D11 with the cubemap texture, but it only crashes on exit when using Direct3D11.
Normal render target textures (with only one face) works properly, it is only the 6 face render target texture of cubemaps that crashes.

I create the cubemap texture like this:

Code: Select all

TexturePtr cubemapTexture = TextureManager::getSingleton().createManual("testCubemapTexture",
		ResourceGroupManager::DEFAULT_RESOURCE_GROUP_NAME, TEX_TYPE_CUBE_MAP,
		512,
		512,
		0, PF_R8G8B8, TU_RENDERTARGET);
That in turn goes into D3D11HardwarePixelBuffer::D3D11HardwarePixelBuffer 6 times (one per face of the cubemap):

Code: Select all

RenderTexture *trt = new D3D11RenderTexture(name, this, zoffset, mDevice);
mSliceTRT.push_back(trt);
Root::getSingleton().getRenderSystem()->attachRenderTarget(*trt);
On the "new D3D11RenderTexture", it gets added to "D3D11DeviceResourceManager::mResources", which then adds 6 RenderTextures to mResources in the end.

The thing in here is that "attachRenderTarget" only adds the RenderTexture if it has a unique name, which is true for the first time it comes into that, but for all 5 other faces nothing happens in that function because the RenderTarget name is not unique.
Is this a bug? Should it not also add "mFace" to the name in D3D11HardwarePixelBuffer::D3D11HardwarePixelBuffer?

After this is done, the texture can be rendered and everything in the application works with the cubemap.
But, when exiting the application and removing the texture, it comes into D3D11Texture::freeInternalResourcesImpl, which calls "mSurfaceList.clear()".
mSurfaceList has 6 objects in it, which is correct, and when clearing it the code jumps automatically 6 times to D3D11HardwarePixelBuffer::~D3D11HardwarePixelBuffer:

Code: Select all

if(!mSliceTRT.empty())
{   
	// Delete all render targets that are not yet deleted via _clearSliceRTT
	for(size_t zoffset=0; zoffset<mDepth; ++zoffset)
	{
		if(mSliceTRT[zoffset])
			Root::getSingleton().getRenderSystem()->destroyRenderTarget(mSliceTRT[zoffset]->getName());
	}
}
As you may understand here, destroyRenderTarget is called for the mSliceTRT, but as I mentioned before, that name is not unique.
This only destroys the first render target of the 6 created.

Later it comes to D3D11DeviceResourceManager::~D3D11DeviceResourceManager, which uses "assert(mResources.empty())" and crashes because there are still 5 objects in it (the last 5 of the 6 render targets to be exact).

Anyone know what is happening here?
Am I doing something wrong?
Is this a bug?

Thanks in advance! :D

Cheers,

Robin
0 x

paroj
OGRE Team Member
OGRE Team Member
Posts: 878
Joined: Sun Mar 30, 2014 2:51 pm
x 177
Contact:

Re: 1.11.2 Cubemap cleanup crash

Post by paroj » Sun Nov 18, 2018 12:02 pm

if you blame the "name" line you get this commit: https://github.com/OGRECave/ogre/commit ... 5397c763f8

so, yes this is a bug ;)
0 x

rpgplayerrobin
Gremlin
Posts: 151
Joined: Wed Mar 18, 2009 3:03 am
x 16

Re: 1.11.2 Cubemap cleanup crash

Post by rpgplayerrobin » Sun Nov 18, 2018 6:54 pm

I don't understand. :o

Is that bug solved with that commit? It seems to use the same code as my code uses:

Code: Select all

name = "rtt/"+StringConverter::toString((size_t)mParentTexture) + "/" + StringConverter::toString(mMipLevel) + "/" + parentTexture->getName();
What is the correct way to solve this bug? How do I solve it?
0 x

paroj
OGRE Team Member
OGRE Team Member
Posts: 878
Joined: Sun Mar 30, 2014 2:51 pm
x 177
Contact:

Re: 1.11.2 Cubemap cleanup crash

Post by paroj » Sun Nov 18, 2018 10:31 pm

no this is the commit that last touched the line. As you can tell from the commit message the author already expected bugs there.

this should be the fix: https://github.com/OGRECave/ogre/commit ... 6c6d6aebad
1 x

rpgplayerrobin
Gremlin
Posts: 151
Joined: Wed Mar 18, 2009 3:03 am
x 16

Re: 1.11.2 Cubemap cleanup crash

Post by rpgplayerrobin » Mon Nov 19, 2018 6:33 am

I was not sure if that was the way to solve it, so thank you! It works now! :D
0 x

Post Reply