Irrlicht with cubemap support

Discuss about anything related to the Irrlicht Engine, or read announcements about any significant features or usage changes.
Joe_R
Posts: 10
Joined: Wed Aug 10, 2016 10:38 am

Re: Irrlicht with cubemap support

Post by Joe_R »

Hello!

I'm using a recent trunk version of Irrlicht (Direct3D 9 driver) with the cubemap support. In my case the display window can be closed and reopened by the application, so the irrlicht device can be opened/closed multiple times. If I'm using cubemaps, a strange memory leak appears. I create the cubemap the following way:

Code: Select all

 
irr::video::IImage* cubeImages[6];
 
cubeImages[0] = driver->createImageFromFile("cube/pos-x.png");
cubeImages[1] = driver->createImageFromFile("cube/neg-x.png"),
cubeImages[2] = driver->createImageFromFile("cube/pos-y.png"),
cubeImages[3] = driver->createImageFromFile("cube/neg-y.png"),
cubeImages[4] = driver->createImageFromFile("cube/neg-z.png"),
cubeImages[5] = driver->createImageFromFile("cube/pos-z.png");
 
cubemapTexture = driver->addTextureCubemap("environmentMap", cubeImages[0], cubeImages[1], cubeImages[2], cubeImages[3], cubeImages[4], cubeImages[5]);
 
for (int i = 0; i < 6; i++)
        cubeImages[i]->drop();
 
So far so good, the leak only appears if I try to assign it to a material:

Code: Select all

 
node->setMaterialTexture(4, cubemapTexture);
 
If I comment this out the leak disappears. The size of the leak seams to be equal to the size of the 6 textures (1024*1024*4*6=~25MB) according to Visual Studio memory snapshots. I tried to look at the code of the Direct3D driver, but I can't find any apperent reason for this phenomenon. Could it be a bug in Irrlicht, or am I doing something wrong?
devsh
Competition winner
Posts: 2057
Joined: Tue Dec 09, 2008 6:00 pm
Location: UK
Contact:

Re: Irrlicht with cubemap support

Post by devsh »

its because irrlicht uses reference counting on textures
Joe_R
Posts: 10
Joined: Wed Aug 10, 2016 10:38 am

Re: Irrlicht with cubemap support

Post by Joe_R »

Yes, I know that, however setMaterialTexture doesn't increase the reference count. The reference count of cubemapTexture is set to 1 when I call driver->addTextureCubemap and decreased to 0 when the driver is destructed. The IImage instances I use to load the 6 textures are dropped after creating the cubemap, so I think there should be no leak. When I'm debugging I also load the .pdb for Irrlicht, so I should see the exact Irrlicht type that causes the leak in the memory snapshots, however it's not the case, it only sais "External frame". I will try to write a minimum code that produces this behaviour.
Post Reply