textures from jpg and png

[curantil]

When (manualy, not in a .materialfile) loading images fot textures I have the impression that an jpg takes less space in video memory as a png. That is, for loading the png I have to close some applications else my program would crash. Are these images still compressed in their own format on the graphics-card? Or what is the cause of this?

What exactly do these mipmaps that generated do? I mean is that sufficient for lod-managment of the texture or should I implement lod for it of my own?
For the moment I have to load 1 huge texture for my terrain (a custom planet-scene-manager). So I guess it would be better if I did some lod on the texture as well. What is the best way to manually create (combine) a texture?

[tuan kuranes]

For Motherboard memory, only if png has an alpha channel, png is to be loaded in 32bits instead of 24 bits, jpg is 24bits. (Compression-format is only on disk.).

Gpu memory is under internal GPU control, but consider it as 32bits by default.

Mipmaps is used to educe memory usage when objects are far from camera by using smaller texture.
Usually gives a 33% main memory increase, but can decrease GPU memory and GPU texture upload by huge factors. (if objects are not always near cam.)

Mipmaps is sufficient for single texture material.

Ogre texture Lod gives you a way to have simpler material (ie less pass, less texture units, less shaders) when far from camera.

If you have one huge texture, use max mipmaps possible (all power of 2 size under til size of 1.) and/or try DXT compressed textures, that divides texture size by some factors.

What is the best way to manually create (combine) a texture?

you mean pre-create mipmaps texture ?
Have look at nvidia texture tools

[curantil]

For Motherboard memory, only if png has an alpha channel, png is to be loaded in 32bits instead of 24 bits, jpg is 24bits. (Compression-format is only on disk.).

The properties of the png show 24bit as bit per depth. Could it maybe be that the decompression algorithm of the png takes more memory? (The texture is 2048x12288 btw)

Mipmaps is used to educe memory usage when objects are far from camera by using smaller texture.
Usually gives a 33% main memory increase, but can decrease GPU memory and GPU texture upload by huge factors. (if objects are not always near cam.)

Mipmaps is sufficient for single texture material.

Does this also work for landscapes? (So the object is part close and part far)

Ogre texture Lod gives you a way to have simpler material (ie less pass, less texture units, less shaders) when far from camera.

Isn't that for the whole material at once? Because I need the texture-lod for my terrain.

What is the best way to manually create (combine) a texture?

you mean pre-create mipmaps texture ?
Have look at nvidia texture tools

No I mean if I want to implement my own texture-lod algorithm. How can I create a material and fill the texture with the relevant pieces of the orignal texture.

[:wumpus:]

See the Dyntex demo on how to manually paste data into a texture or even specific mipmaps.

Also, it doesn't matter wether you load an texture from jpg or png, both require the same storage in texture memory, generally width*height*4 bytes. (assuming no mipmaps)

I recommend using texture compression (dds textures with DXT1/3/5 compression) if you're low on texture ram.

[tuan kuranes]

2048x12288 is not supported by GPU ? Last time I check biggest was 4096x4096 for the best video cards.
It's unlikely the algorithms take more... but who knows what DevIl does ?

Mipmap affects whole texture, so if you use on big texture on a single whole mesh, so no, unless you're far from the whole object. (But you should split mesh in smaller part, an split texture in smaller part, and then you would gain use of mipmaping.)

My sentence wasn't correct, it's:
Ogre texture Lod gives you a way to have simpler technique.
It only affects the renderable that select a lower Lod of the material

Look manual for material scripts, like this :

Code: Select all

material BaseMaterial
{
    lod_distances 280000
    technique
    {
        lod_index 0
        ... passes texture_units...
      
    }
    technique
    {
        lod_index 1
        ... passes texture_units...
   }
}

[sinbad]

(The texture is 2048x12288 btw)

Even if cards supported textures of that resolution (they don't), that would be 96Mb on the GPU, before you even started adding mipmaps.

[DWORD]

Mipmap affects whole texture, so if you use on big texture on a single whole mesh, so no, unless you're far from the whole object. (But you should split mesh in smaller part, an split texture in smaller part, and then you would gain use of mipmaping.)

What do you mean by this? I probably misread this, but you don't have to use multiple meshes to take advantage of mipmaps. You can use one texture (w/ mipmaps) on one mesh and use get mipmaps where applicable.

[tuan kuranes]

I mean : You cannot have different mipmap level on same object at same time, but you can have multiple mipmap per object/texture.

If you have an enormous plane (single object) with a single texture, if camera is near a corner of the plan, plane would have the best mipmap possible as texture because you're near the plane.

Other plane corners cannot have a different mipmap, even if they're very far from the camer, because it's same object 'instance' and same texture 'instance' at this frame.

hope I made my self clearer...

[curantil]

(The texture is 2048x12288 btw)

Even if cards supported textures of that resolution (they don't), that would be 96Mb on the GPU, before you even started adding mipmaps.

Well, that's why I want to do lod on it myself
I know it is incredibly huge. But I haven't had time to implement the lod for textures yet. And it worked for mee until now.

But the 2048x2048 limit could cause some problems. I don't think there is a way to put multiple textures on 1 renderable? So I'll better splitup my different lod-levels of my mesh in different renderables?

[DWORD]

I mean : You cannot have different mipmap level on same object at same time, but you can have multiple mipmap per object/texture.

If you have an enormous plane (single object) with a single texture, if camera is near a corner of the plan, plane would have the best mipmap possible as texture because you're near the plane.

Other plane corners cannot have a different mipmap, even if they're very far from the camer, because it's same object 'instance' and same texture 'instance' at this frame.

hope I made my self clearer...

I think you're wrong here. (Unless you are talking about some 'manual' mipmaps which you switch per renderable.) The mipmap that the graphics card uses depends on the texel to pixel ratio.

Here's a modified shadows demo (switched rockwall.tga with this rockwall.tga). Here you can clearly see that at least three different mipmaps are used on the same plane (red arrows):


(This is with bilinear filtering; trilinear or anisotropic filtering of course improves the image quality.)

Sorry for being off topic.

[tuan kuranes]

Thanks a lot for clarifiying that for me.