removeTexture crasher

MolokoTheMole · Post by **MolokoTheMole** » Mon Mar 07, 2011 3:25 pm

removeTexture causes havoc with impossible to find memory bugs. Irrlicht seems to keep the removed texture in cache. I made a temporary solution by cleaning the last material state, by making a wrapper function:

Code: Select all

void SafeRemoveTexture( ITexture *texture )
{
	if (texture && video && driver)
	{
		video->removeTexture( texture );

		SMaterial clean;
		clean.TextureLayer[0].Texture = NULL;
		clean.TextureLayer[1].Texture = NULL;
		clean.TextureLayer[2].Texture = NULL;
		clean.TextureLayer[3].Texture = NULL;
		video->setMaterial( clean );
	}
}

However this needs to be placed in removeTexture( ); itself.

hybrid · Post by **hybrid** » Mon Mar 07, 2011 10:04 pm

Well, since we don't keep track of the texture usage for now it's better to fix the render state changes to properly clean out the textures. If the texture is still used even when no mesh or cache holds any reference to it there's something wrong in the state handling. Would need to debug the wrong setup phases, though. Any code?

ChaiRuiPeng · Post by **ChaiRuiPeng** » Mon Mar 07, 2011 10:53 pm

hybrid wrote:Well, since we don't keep track of the texture usage for now it's better to fix the render state changes to properly clean out the textures. If the texture is still used even when no mesh or cache holds any reference to it there's something wrong in the state handling. Would need to debug the wrong setup phases, though. Any code?

wait is this what you uppers were talking about? i think i saw a thred somewhere takling about "better texture reference counting"?

i have not had any problems so far but just asking

hybrid · Post by **hybrid** » Tue Mar 08, 2011 8:36 am

If you use a texture in a certain material, and drop the only mesh that is using the material, it could be worth removing the texture as well. This would only be possible by using reference counting on textures, which is not yet done. But it would also change the way textures are handled, change SMaterial completely, and other things.

agamemnus · Post by **agamemnus** » Fri Mar 11, 2011 8:13 am

Well, there are many cases where you don't want to remove the texture when the mesh is removed. This should not be the graphics engine's call. A specific call to remove the texture from memory should be allowed though...

Not sure what Moloko means with "removeTexture causes havoc with impossible to find memory bugs.", however...

"Irrlicht seems to keep the removed texture in cache." <-- that'd be a significant bug if it were the case...

hybrid · Post by **hybrid** » Fri Mar 11, 2011 2:36 pm

Unless there's a bug in reference counting in the texture cache, textures will be deleted after clearing the cache. At that point, also removal on the GPU happens. Otherwise it'd be indeed a bug. One bug that we have had in the past was that the texture was still bound in some variable (and thus also on the GPU) which caused crashes in the drawAll call. But that should be fixed for some time already.

MolokoTheMole · Post by **MolokoTheMole** » Tue Mar 15, 2011 8:27 am

The program crashes when you start rendering after you removed the texture. It is nearly impossible to find this bug if you don't have the Irrlicht source code or don't know its inner working.

There was a thread here with a possible solution. I can't find it of course because of bad luck now. Maybe you remember, the guy simply suggested to clear the material cache on beginScene().

hybrid · Post by **hybrid** » Tue Mar 15, 2011 8:29 am

I use valgrind, gDebugger and MSVC memory debugger and cannot reproduce such problems. Please post code which shows off the error so I can trace it down.