I can use models I guess. But why should that be a work around? Is every terrain considered a block of memory that cant be fully recovered?

After doing this test: I can create an .mdl file using ent_create, then ent_purge and remove, and i can regain that memory the entity used up. But if I ent_create a terrain, and ent_purge and ent_remove, the texture memory is never fully recovered.

A workaround here is just to have all your terrain placed within WED and never created.

UPDATE:

reloading a level (level_load), over and over again, with or without terrains is causing me to run out of memory

reloading the level is increasing my shadow map video memory consumption, the sha in the statistics panel.

Does this memory stat (sha) relfect the baked shadows in level geometry, or PSSM shadows?

I believe it's baked shadows.
"Amount of video memory currently used for wmb shadow maps." from manual

I am facing similar issues. It seems to be my "d3d_texbmaps" and d3d_texskins" that are stacking up with each level load.

I've created a smaller game which emulates the functions of my game in a hope to find out where the leak is coming from. So far no luck...

Each time I add a function to the smaller game to see how the memory gets handled, and so far the memory is reset on each level load. There is no stacking. However, if I keep adding functionality similar to my (big) game, eventually I'll either have a working game, or I'll discover exactly what's causing the problem.

Level_Load is "supposed" to clear out the memory, but there must be some limitation, or some loophole that allows memory to build up between loads. I will definitely follow up if I find the source of my leak.

UPDATE:
Actually, I can reproduce this memory drain by loading a .wmb file into my level. It increases the overall RAM usage each time I load it, even if I purge and remove it from the level, and even after I load a new level.

Hey Dooley!

I did the same thing. In my main level, I deleted more and more objects, and spammed the level_load on the same level. If i deleted everything except the bare minimum to run my level, no memory was being stacked. After narrowing it down, i found out it was map entities causing the problem!!!!

These map entities (.wmb) are placed in the level to prevent certain nodes from seeing each other. If i had none of these map entities in the level, memory isnt stacked/leaked. But once i placed these .wmbs in the level and reloaded constantly, the memory would stack. After going into the .wmb file itself in WED, i recompiled with no shadows, along with a few other options I dont remember off hand and resaved the .wmb.

Loading the new compiled .wmb into my main level, I was able to reload constnatly without memory stacking.

Question: Why would baked shadows in a map entity (.wmb) cause memory to be unreleased in level_load??

, wouldn't suprise me if it was a bug. But aren't map entities fairly slow compared to models? (I think Sivan tested this once with this map builder) Perhaps its better to just switch to models completely or perhaps bake in lower resolution shadows so the crash is more rare as a (crappy) quick fix for now .

I didnt know they were slower, though it does make sense that they are, being that they have bsp/collision/texture/shadow stuff in them.

Is there a way to see how much total memory an entity takes up? Outside of taking a before and after of the sys memory stat when its created?

Level_Load should be removing any extra memory used by these .wmb files. Is it possible for you to restart/reload the level on some occasions?

I was able to reload/restart the level. But the map_entities definitely stacked, in the shd column!! Which meant something was going on with the shadows. And once I changed the settings of the wmb file individually, the shd never stacked in level reload. I have no idea why

UPDATE:

spoke too soon. WMB map entities placed in the level are not really freed from memory when level_load is performed.

I have found another thing that seems to help. Instead of loading a level directly, and worrying about purging different entities with ent_purge, I've found that loading a blank level seems to clear the entities automatically. Then you can load the level you need next.

Something like this:



On my smaller game, this is not necessary. The engine seems to handle purging memory very well. I'm sure there is something in my code (on the bigger game) that is causing these problems, but I have yet to find it. In the meantime, these techniques seem to keep the memory from stacking...