A sort of memory leak

Tuan,

This is a continuation from the topic:
http://www.ogre3d.org/phpBB2/viewtopic.php?t=16153

Using BoundsChecker (which I just got yesterday), I think I've identified where the leak is coming from. I placed a "memory mark" just before opening the dialog box, let the box stay open for a bit, then closed the box and did a "compare memory since last mark". This is after allowing the app to settle for a couple of minutes, to avoid new pages being loaded by PLSM2.

I find a LOT (1053) of allocations made by PagingLandScapeRenderableManager::_addBatch(), all 696 bytes in size at the line:
PagingLandScapeRenderable* rend = new PagingLandScapeRenderable();

The stack looks like this for all the instances:

PagingLandScapeTile::_Notify()
PagingLandScapeTile::load()
PagingLandScapeRenderableManager::getRenderable()
PagingLandScapeRenderableManager::_addBatch()

These allocations are apparently not getting freed while the dialog box is displayed.

Does this tell you anything? Any clue what's going on? Am I barking up the wrong tree?

Renderables are pooled to speed up and so that memory isn't too much fragmented and become slow upon time.
But once allocated, they'll be free only at end of plsm2.

(if using stl + vc2005 there's a memory leak in its STL that should be fixed in Dagon)

Renderables are pooled to speed up and so that memory isn't too much fragmented and become slow upon time.
But once allocated, they'll be free only at end of plsm2.
So that explains what I'm seeing, and why it's not reported at the end of the run as a leak.

(if using stl + vc2005 there's a memory leak in its STL that should be fixed in Dagon)
I've already applied the fix that Sinbad provided, so that's not a problem.

As discussed in another thread, my RTT cameras aren't even rendering the terrain.
I turn it off like this in the dialog's preRenderTargetUpdate function:

sceneMgr->addSpecialCaseRenderQueue(RENDER_QUEUE_MAIN);
sceneMgr->setSpecialCaseRenderQueueMode(SceneManager::SCRQM_INCLUDE);

So how do I fix this situation? What's causing the renderable pool to grow out of hand?

Thanks

Each camera update its paging each frame pooling renderable to be shown.

Solution is to add a test in pagemanager::updatepaging to check if RENDER_QUEUE_WORLD_GEOMETRY is to be rendered with this camera ?

fixed in CVS.

I think eventually it'd be nice to add a mechanism to unload renderables after they are a large distance from the camera or haven't been used for a while.

I would like my players to be able to move around on the terrain for hours across a vast landscape (eventually) and that would probably be something that would be needed in my case.

What kind of challenges would be involved in doing that?

That's how that works actually (large distance and time), but renderables are unloaded, but no deleted, to be reused. (same for tiles, page and textures actually.)

Those memory pools only pre-allocates on max need at a frame, but never deallocate, staying at the maximum "needed at once" objects reached during a session.

Perhaps it can be reduced to last maximum needed renderables needed at once upon 1000 frame or something ?

That sounds like it'll fix the problem for this situation.

However (just to be a pain in the ass), what if the terrain was rendered in the RTT cameras?
Would the pool still grow out of hand?

No, if they render same terrain as main camera.
Yes, if they render terrain other camera don't look at, and therefore need more total renderables to draw.
(just to be sure, even if it's not the question, no more since cvs fix, if they don't render terrains by excluding world geometry render queue.)

I tested your changes in CVS, and verified that the leak is indeed fixed, if the terrain is not shown in the RTT cameras.
However, it does still leak if the terrain is shown.

However, it does still leak if the terrain is shown.
by leak, do you mean never end growing, used memory or not released at application end ?

And yes I'm interested by source or wiki on rtt-based dialog (did you try alpha on RTT background ?

Sorry, by leak I mean the pool growing continously. Not really a leak, but I don't know what else to call it.

I've not played with alpha yet. I haven't done much with it because of the memory issues until now. This coming up week I'll spend more time making it more useful/pretty.

Thanks for all your support!

I should have fixed it.
If you cannot re-check it using boundschecker, I'll be interested by results.
(still have to wait til anonymous CVS is updated.)
Thanks.

Just checked your fixes, looks good. I can't make the memory "explode".

Many thanks, Tuan!