How is geometry stored in vram?

[Noiecity]

How is geometry stored in irrlicht? For example, if I load hundreds of models into ram, but don't render them, will they never be uploaded to vram? And if I render them all, do they stay permanently in vram until I manually clear them? Or does it only access ram every time it renders and then it no longer remains in vram? I'm not sure about this

[CuteAlien]

If you don't render they won't be uploaded. IMesh/IMeshBuffer have a function setHardwareMappingHint. When using EHM_NEVER it will send the data over the bus each frame. Which can make sense for animated meshes which are changed each frame on CPU or very small meshes. Which seems to be even default.. which is generally a bad idea. As nearly always you want EHM_STATIC - then it just stays on GPU. There's also dynamic and stream - but those are all really just hints for the hardware and it depends on the driver if it cares about those in any way.

Things always stay on GPU memory until it needs more memory and then decides what it kicks out (that's where those hints probably come into effect - but that's just me guessing).

So... generally - overload the default Irrlicht hint after loading static mesh. And yeah, I'm a bit surprised this is still default... now wondering if I should change that.

[Noiecity]

Thanks for the information, I intend to use static geometries to simulate the shadows, I'm just worried that the vram will overload or something, it's an isometric game with loading screens, and from what you said, now I intend to clean the vram when moving from one city to another or something like that.

Since it is an isometric game, I can simulate the shadow gaining transparency as the pointlight approaches...

[CuteAlien]

You can call void IVideoDriver::removeHardwareBuffer(const scene::IMeshBuffer* mb). Thought worth it doing a quick calculation how much memory geometry really needs, might be unnecessary. Mostly it's the textures which take up memory.

[Noiecity]

Thank you. Yes, the textures probably take up much more space, besides, I have noticed something spectacular, blender has a mode to render as if they were normalmaps... it is not the same as baking the normalmaps, they are different algorithms, and well... the geometry looks almost exactly like real geometry from a single angle...(in a quad mesh)
Well, thanks again anyway, since I noticed that many games did not clean the resources, and as time went by the games began to slow down











These kinds of normalmaps are useless if the angle is changed, but in an isometric game where the angle is always the same, it works perfectly. You can add a UV projection to a low poly model plus this and you would get a very realistic result...
Now, not only in isometric games, you get lor normalmaps from various angles and you add transition in these, uff, you would have the equivalent of seeing a high poly model, in a low poly model in real time.

I use this example for this:
https://irrlicht.sourceforge.io/docu/example011.html

And comment this:

Code: Select all

		/*if (normalMap)
			driver->makeNormalMapTexture(normalMap, 9.0f);
			*/