I have read some posts about memory management, and am still left with a few questions - maybe someone can help. Currently, I am aiming at higher-end harware that supports pixel shaders, and a world created from high-poly count models.

Models:

When a model leaves the clip distance, is it still loaded in memory? Would you need to purge it to free that memory again? If the model is purged when it is outside of the clip distance, and you move so that it is once again in the clip distance, is it reloaded?

If a model is reduced in polycount at a certain LOD distance, is the older higher count model purged?

What are the limitations on level size in this scenario. If you move in one direction, and the models are purged from memory as they leave the clip distance, would you theoretically be able to continue forever?

Textures, Video Memory, System Memory:

What is the relationship? Is there a limit to the number of textures you can use, and if so how is this determined. If a texture associated with a model is purged, are all of these resouces available again?

I guess what I am getting at is... I have a room built with high res textures, and detailed models, with shaders and the works. It is an indoor scenario, so the clip distance is not too distant, as I build this out to a large level, what limitations will I run into in terms of memory. I would rather avoid going back and reducing texture sizes, and/or reworking models to have a lower poly count.

I understand LOD, and plan on implemeting this. I also have read alot of posts about optimal texture resolution, and I understand the concept that you make every attempt to conserve on poly count and texture sizes.

As things progress, I am sure I will learn alot about this, and I will be conducting some tests, but I was curious if other users had any insight that might help me on my quest.

Quote:

---

When a model leaves the clip distance, is it still loaded in memory? Would you need to purge it to free that memory again?

---

Yes, and yes.

Quote:

---

If a model is reduced in polycount at a certain LOD distance, is the older higher count model purged?

---

I would think not, however I may be wrong. Mipmaps and distance textures are generally there not to free texture memory, but just make things look better.

Quote:

---

What is the relationship? Is there a limit to the number of textures you can use, and if so how is this determined. If a texture associated with a model is purged, are all of these resouces available again?

---

Video memory is what your textures use up. So let's say for an instance, your level is made out of high res textures. If you consume too much video memory, then your computer will end up using it's system memory. If it does this, then everything will become very slow. I believe the system memory is called "virtual memory" in your pc.

This is why video cards as time has gone on, increased there memory(8MB, 32MB, 64MB, 128MB, 256MB, 512MB). Since games need more memory as time goes on due to not only high res textures, but all the textures invovled with shaders too. Normal map textures are particularily notorious for this, since they tend to be higher res to keep the detail.

If you find that your going over your memory limit, and need to keep the same textures, you can purge entities or bmaps to free up memory. I'm going to explain how purging works in A6 now...

When you load an entity into A6 for the very first time, you'll notice a bit of a stutter or delay before it's loaded. This is partly due to it allocating its memory. Now, even if you delete this entity, it will still be using up texture memory. It will not be purged until you purge it, clipping ect. will not purge it. The reason for this is that let's say your in a fast paced action game, and every model you delete you purge upon doing so. Now everytime you load this model up again, there will be a delay. Such as a rapid fire laser weapon and the such.

So what i'm saying is, in the case of models, purge only when your very sure you won't be needing this model again anytime soon. It's also a good idea to load up all your models into the texture memory before you even need them. That way you wont have to deal with the delay.

In the case of bmaps, such as panels. It's a good idea to purge all the panels that you don't need anymore. For example, if you load up a menu screen, when you get rid of it purge the bmaps. I noticed that panels can consume a fair amount of texture memory, no need having them consume this memory in-game when you dont need them for a while.

I should note that the information above is just what i've gathered through the years. I could be getting a couple things wrong here, but hopefully it'll help clear up a few things for you.

btw - A6 supports dds textures now. It would be a good idea to develop your game using these, as there are many choices within dds to really save texture memory.

Thanks for the info! The manual states, that after an ent_purge, the video memory will be assigned again on seeing the entity, which is good. And that video memory is allocated at game start for loaded entites.

If you wanted to do dynamic loading, say by setting triggers, you would first need to purge entities that are not in the current zone, it seems.. You could hide the load with an info panel or something.

But dynamic loading aside, is a workable formula to take the size of textures in MB, the model sizs in MB, add that up, and that is the amount of physical memory you would need on a system? I wonder how much memory is needed for engine overhead.

How much faster is video memory than physical memory (virtual memory is obviously really slow?)

Each model vertex takes 12 bytes. Each model triangle takes 6 bytes. The memory usage for textures is the width, times the height, times (the color depth divided by 8). Animation frames vary more. Vertex animation stores each vertex's positions for every frame so for 1000 vertices and 2000 faces, you'd be using 12000+12000 or 24000 bytes. If you had 100 frames, this becomes 2.4 million bytes. For bones animation, the positions and angles of each bone are stored, 24 bytes per bone.

thanks uli - that is very helpful.

Oh, I forgot to mention that each skin map vertex uses 8 bytes and each skin map face uses 6 bytes. Because textures aren't animated with animated models, this only gets processed once instead. Each position on each of 3 axes (2 for skin vertices) uses 4 bytes (a 32-bit float). Each vertex is assigned a value from 0 to 65,535 (a 16-bit variable) and faces are built based on a choice of 3 such 16-bit positions which is where the 6 comes from.

If you have multiple instances of the same model, are they loaded only once into memory for both geo data and textures?

For exanmple, if I have a soldier with 20 anim frames and three skins, and have ten instances of it in my game, is the memory footprint the same as one instance, actions not withstanding?