memory reduction....

skumar · Post by **skumar** » Mon Jan 26, 2009 6:08 pm

hi,
I have asked similar questions before but this is a final one...i am doing a virtual walkthrough and i use lightmaps. What im facing is the huge memory needs of my app..

I am disabling mipmaps....for gettting some relief..

My question is if i use jpeg or such 24bit formats...will the texture made will also be 24 bit....or they reserve something for alpha??

hybrid · Post by **hybrid** » Mon Jan 26, 2009 7:29 pm

It can happen that 24bit images turn into 32bit textures. You can check the color format. You can enforce 16bit textures with the texture creation parameters, but it's also not necessarily created as 16bit then - depends on the driver and hardware.

Nox · Post by **Nox** » Mon Jan 26, 2009 11:04 pm

Maybe removing the texture using removeTexture could help you. But in fact a "clearup" methode which removes unused meshes, materials and textures would be really nice

. May be something for the requesttracker?

hybrid · Post by **hybrid** » Mon Jan 26, 2009 11:39 pm

Not possible, because materials are vital part of meshes, and textures are not reference counted.

Nox · Post by **Nox** » Tue Jan 27, 2009 1:11 am

And why are not they refcounted? Is there a good reason? Or just because? (Should not be respectless or an attack. It is just a question).

skumar · Post by **skumar** » Tue Jan 27, 2009 4:49 am

Thanx for the help....

I am using Lightmaps....i dont need any alpha information in that anyway.So if i can represent it as 24bit information i can save a lot of memory. One arch model may contain more than 10 1024x1024 textures...

16bits will surely degrade the quality...so what i want is ...i want my tex to represented as RGB and no A

skumar · Post by **skumar** » Tue Jan 27, 2009 6:52 am

I have done a small test ....

I made a simple plane(2 triangle) textured it using a 104*1024 tex(jpg) and loaded into the mesh viewer....

Empty meshviewer meme = 4520k
Untexture plane loaded = 4568k
Textured plane = 13256k
****************************

On paper the 1024 x 1024 tex need 4 MB and after mipmapping....

~5.33MB

What is this 8716k footprint....???

Or im i doing a bad experiment....?????

hybrid · Post by **hybrid** » Tue Jan 27, 2009 8:35 am

Depends on the driver and the way you check for free memory. But it's mostly due to the video mem being mapped into the application, hence you get almost double the amount of mem. But you should notice that it's not all CPU memory.

skumar · Post by **skumar** » Tue Jan 27, 2009 9:45 am

So my tests were a bit wrong....

thanx hybrid...

can you suggest a way i can test how much mem my app occupies in runtime...with precision.

hybrid · Post by **hybrid** » Tue Jan 27, 2009 1:12 pm

You can use a memory profiler or memory debugger. I guess once you track all allocations you can easily get the maount of memory allocated and deallocated, and then check for maximum values. But I never did this.

Nox · Post by **Nox** » Tue Jan 27, 2009 2:10 pm

Hmm what is about deactiveting mipmapping and using the software renderer? Should be more accurate.

But why are the Textures not refcounted?

hybrid · Post by **hybrid** » Tue Jan 27, 2009 2:47 pm

The software renderer has completely different memory usage than the other drivers. And I don't think that it will work without GPU mem.
Textures are not refcounted because you can assign them manually to the materials (using assignment to the pointer member). So you'd have to do the refcounting on your own. Which makes it somewhat absurd.

Nox · Post by **Nox** » Tue Jan 27, 2009 2:55 pm

Hmm you are right but ressourcemanagment is a important for apps which change their drawn content permanently. Killing everything results often in crashes and/or long reloadtimes. May be the materials could be changed to class (or a struct with private ITexture) using a set for textures? Or do you have a good idea how to deal with unused ressources?

bitplane · Post by **bitplane** » Tue Jan 27, 2009 9:44 pm

We could add a setTexture method to SMaterial struct, but we'd also have to eliminate any material copying within the engine.

Thinking about it, we could use a setTexture method to abstract away the stage numbers and replace them with an enumeration. This may increase the size of material struct but it would allow Irrlicht to understand the meaning of a texture slot and choose from a number of internal renderers.

Nox · Post by **Nox** » Tue Jan 27, 2009 10:40 pm

We could add a setTexture method to SMaterial struct, but we'd also have to eliminate any material copying within the engine.

May be copyc'tor+ = operator overloading is an other solution?