textures from jpg and png

Anything and everything that's related to OGRE or the wider graphics field that doesn't fit into the other forums.
Post Reply
curantil
Halfling
Posts: 70
Joined: Wed Dec 11, 2002 10:00 pm
Location: Belgium
Contact:

textures from jpg and png

Post by curantil » Fri Apr 01, 2005 12:03 pm

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?
0 x

User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
Contact:

Post by tuan kuranes » Fri Apr 01, 2005 12:38 pm

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
0 x

curantil
Halfling
Posts: 70
Joined: Wed Dec 11, 2002 10:00 pm
Location: Belgium
Contact:

Post by curantil » Fri Apr 01, 2005 1:27 pm

tuan kuranes wrote: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)
tuan kuranes wrote: 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)
tuan kuranes wrote: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.
tuan kuranes wrote:
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.
0 x

User avatar
:wumpus:
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 3067
Joined: Tue Feb 10, 2004 12:53 pm
Location: The Netherlands

Post by :wumpus: » Fri Apr 01, 2005 1:41 pm

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.
0 x

User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
Contact:

Post by tuan kuranes » Fri Apr 01, 2005 1:50 pm

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...
   }
}
0 x

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19261
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
Contact:

Post by sinbad » Fri Apr 01, 2005 2:08 pm

(The texture is 2048x12288 btw)
:shock:

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

User avatar
DWORD
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 1365
Joined: Tue Sep 07, 2004 12:43 pm
Location: Aalborg, Denmark
Contact:

Post by DWORD » Fri Apr 01, 2005 2:13 pm

tuan kuranes wrote: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.
0 x

User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
Contact:

Post by tuan kuranes » Fri Apr 01, 2005 2:35 pm

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...
0 x

curantil
Halfling
Posts: 70
Joined: Wed Dec 11, 2002 10:00 pm
Location: Belgium
Contact:

Post by curantil » Fri Apr 01, 2005 2:53 pm

sinbad wrote:
(The texture is 2048x12288 btw)
:shock:

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?
0 x

User avatar
DWORD
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 1365
Joined: Tue Sep 07, 2004 12:43 pm
Location: Aalborg, Denmark
Contact:

Post by DWORD » Fri Apr 01, 2005 3:13 pm

tuan kuranes wrote: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):

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

Sorry for being off topic.
0 x

User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
Contact:

Post by tuan kuranes » Fri Apr 01, 2005 4:58 pm

:oops:
Thanks a lot for clarifiying that for me.
0 x

Post Reply