Texture atlas extension to the RTSS

Discussion area about developing or extending OGRE, adding plugins for it or building applications on it. No newbie questions please, use the Help forum for that.

Texture atlas extension to the RTSS

Postby Assaf Raman » Mon Nov 22, 2010 12:34 pm

Texture atlases are useful in cases you want to merge batches of static geometry that have different textures and you don't have texture array support.
A texture atlas is basically one big texture that includes all textures of all the batches.

I has just committed a patch from Mattan Furst of a texture atlas extension to the RTSS.
I helped by adding geometry to demonstrate this new feature to the RTSS sample.

Mattan based his work on the well known NVIDIA texture atlas tools.

I created a sample texture atlas using the tool that looks like this:
TextureAtlasSampleOrg0.jpg


The first problem we saw immediately was a texture bleed issue when using wrap addressing mode as you can see from this screen shot (on the left side are the original textures and the right side are the textures from the texture atlas):
org.jpg


The solution was lowering the textures quality by half in the texture atlas and have a frame of the texture wrapped, so when it bleeds – it bleeds into the appropriate texture, this modified image demonstrate the idea:
TextureAtlasSampleWrap0.jpg


And here is a screen shot of the result with the modified texture atlas:
wrap.jpg


Here is the code for the modified texture atlas tool that support wrap
AtlasCreationToolWithWrap.zip
(687.45 KiB) Downloaded 3386 times

and here is a modified exe:
AtlasCreationToolWithWrap_exe.zip
(43.19 KiB) Downloaded 12438 times


Note - you only need the tool to create texture atlas textures - not to use them - a parser to the tool output is included in Mattan's patch.



I named the texture atlas with the original tool TextureAtlasSampleOrg.tai and the modified one TextureAtlasSampleWrap.tai.
Here they are (for non-ogre forum members that don't want to search for them in the OGRE code):
TextureAtlasSampleOrg.zip
(818 Bytes) Downloaded 7409 times

TextureAtlasSampleWrap.zip
(847 Bytes) Downloaded 1007 times


Here is the command I used to create the atlas:
Code: Select all
"C:\Program Files\NVIDIA Corporation\Texture Atlas Tools\DEMOS\Direct3D9\bin\release\AtlasCreationTool.exe"   -width 2048 -height 2048  -o TextureAtlasSample 1d_debug.png 1d_SPIRAL.png checker.png img1.png img2.png LowRes.png radial.png SmallLeaf_BP.png spotlight_image.png Dirt.jpg flare.png nm_bk.png rockwall.tga steelhead.png dirt01.jpg ogrelogo-small.jpg RustyBarrel.png NMBalls.png scr-up-p.png terr_dirt-grass.jpg tusk.jpg


And here are the textures I used (once more for ppl that don't want to download all of OGRE code just for this...):
textures.zip
(806.14 KiB) Downloaded 644 times


I committed the patch to the trunk.
Watch out for my OGRE related tweets here.

For this message the author Assaf Raman has received kudos
User avatar
Assaf Raman
OGRE Team Member
OGRE Team Member
 
Posts: 3092
Kudos: 78
Joined: 11 Apr 2006
Location: TLV, Israel

Re: Texture atlas extension to the RTSS.

Postby betajaen » Mon Nov 22, 2010 1:10 pm

A real big thumbs up from me. :D
User avatar
betajaen
OGRE Moderator
OGRE Moderator
 
Posts: 3446
Kudos: 57
Joined: 18 Jul 2005
Location: Wales, UK

Re: Texture atlas extension to the RTSS.

Postby Jabberwocky » Mon Nov 22, 2010 1:21 pm

Thanks to both Mattan and Assaf for this change.

I do have one critique though:

Assaf Raman wrote:The solution was lowering the textures quality by half in the texture atlas and have a frame of the texture wrapped, so when it bleeds – it bleeds into the appropriate texture, this modified image demonstrate the idea:
TextureAtlasSampleWrap0.jpg



For most video game projects, reducing your textures to 1/4 area would never be acceptable. That's a huge loss in texture quality, and would almost certainly not be worth the performance gain. Would it be possible for the atlas tool to instead add a 1-2 pixel wide border around the outside of the image, which copies the colour of the texture edge?

Perhaps one possible implementation would be to do something like this:
- original texture to place in texture atlas: size 256x256
- atlas tool places texture to atlas at position (0,0) size (256x256)
- atlas tool recopies texture to atlas at position (1,1) size (254x254)

Now, you've got a 254x254 sized image with a 1 pixel wide border. You could even repeat this process one more time for a 252x252 sized image with a 2 pixel wide border, if needed. Either is much better than the current atlas tool, which would only give you 128x128 sized image.

[edit: maybe the size of the pixel border could be an argument to the atlas tool]
Last edited by Jabberwocky on Mon Nov 22, 2010 1:32 pm, edited 1 time in total.
Image
User avatar
Jabberwocky
OGRE Moderator
OGRE Moderator
 
Posts: 2818
Kudos: 213
Joined: 05 Mar 2007
Location: Canada

Re: Texture atlas extension to the RTSS.

Postby Assaf Raman » Mon Nov 22, 2010 1:27 pm

@Jabberwocky: Well - you can also have texture that is 4 times bigger with this solution.
Regarding your smaller pixel border idea - the problem I see are the mipmaps. Using your idea will mean using less mipmaps.
I provided the modified tool code, you can pickup where I left off if you want to try out your idea.
Watch out for my OGRE related tweets here.
User avatar
Assaf Raman
OGRE Team Member
OGRE Team Member
 
Posts: 3092
Kudos: 78
Joined: 11 Apr 2006
Location: TLV, Israel

Re: Texture atlas extension to the RTSS.

Postby Jabberwocky » Mon Nov 22, 2010 1:39 pm

Ok thanks, I'll look into it at whatever point I switch over to RTSS (probably not until my next project).

I'm not sure I understand the mipmap problem. Actually I could see a potential issue due to the textures not being a power of 2. Is that the issue you're talking about, or is it something different?
Image
User avatar
Jabberwocky
OGRE Moderator
OGRE Moderator
 
Posts: 2818
Kudos: 213
Joined: 05 Mar 2007
Location: Canada

Re: Texture atlas extension to the RTSS.

Postby Assaf Raman » Mon Nov 22, 2010 1:56 pm

@Jabberwocky:
This thread talks about a tool that may solve the issue of bleeding in a different way - you may want to have a look: viewtopic.php?f=8&t=47644&start=0

Regarding the mipmaps - well - each mipmap is a quoter in size of the previous mipmap - meaning 6 pixels in top mip map are 3 in the next, 1.5 in the next, 0.75 in the next - meaning you will start to bleed from the 4rth mipmap. The only way I can see to overcome this for all mipmap - is the way I did it. I will be happy to find our that my math is off.

Regarding the RTSS - yes - wait for the trunk version to come out as an official version.
Watch out for my OGRE related tweets here.
User avatar
Assaf Raman
OGRE Team Member
OGRE Team Member
 
Posts: 3092
Kudos: 78
Joined: 11 Apr 2006
Location: TLV, Israel

Re: Texture atlas extension to the RTSS.

Postby betajaen » Mon Nov 22, 2010 2:10 pm

Few questions;

Could this be used in Gorilla? I am playing with the idea of a new file-format for "Gorilla 2.0" which uses Texture Atlases (like Gorilla 1 does). I'm concerned with texture packing and declaring the areas correctly the most. The quality does not bother me to much as it will be only rendered in one detail and thus does not need mip-mapping.

Also; I noticed that the image you used isn't square. I thought that was frown upon and made it quite inefficient for the GPU?
User avatar
betajaen
OGRE Moderator
OGRE Moderator
 
Posts: 3446
Kudos: 57
Joined: 18 Jul 2005
Location: Wales, UK

Re: Texture atlas extension to the RTSS.

Postby Jabberwocky » Mon Nov 22, 2010 2:26 pm

@Assaf
Gotcha. I understand the math you're using. But in practice, I don't think it would be a problem. Look at textures for uv-unwrapped models, for example. They rarely show any kind of mipmap problem due to bleeding with the background texture colour (the unmapped portion). And these textures don't need to provide a huge border around the seams of the image, usually a couple pixels is fine. I think textures in the atlas would behave similarly.
Image
User avatar
Jabberwocky
OGRE Moderator
OGRE Moderator
 
Posts: 2818
Kudos: 213
Joined: 05 Mar 2007
Location: Canada

Re: Texture atlas extension to the RTSS.

Postby Assaf Raman » Mon Nov 22, 2010 2:35 pm

betajaen wrote:...Could this be used in Gorilla? ...

I think so. But - better use texture array if available - and use a texture atlas only as a fallback.

betajaen wrote:... the image you used isn't square. I thought that was frown upon and made it quite inefficient for the GPU?

No - it is still a power of two in each direction - and that is the important part.
The reason power of two has better performance - is mipmaps - you can divide the number by 2 until you get to 1 and have integer numbers. BTW: I think that if you don't use mipmap with the image - none-power of two images will not be less inefficient.
I will be happy to get corrected on this also (With a link to a benchmark or the sort).
BTW: The image I have here is the result of the NVIDIA tool - I don't think they would have created none-square images if it was inefficient - so that gives me the feel I am right.
Watch out for my OGRE related tweets here.
User avatar
Assaf Raman
OGRE Team Member
OGRE Team Member
 
Posts: 3092
Kudos: 78
Joined: 11 Apr 2006
Location: TLV, Israel

Re: Texture atlas extension to the RTSS

Postby pratty70 » Mon Nov 22, 2010 4:09 pm

I recently wrote a simple atlas config parser that internally generated a series of Ogre Materials - pointing to the same texture, using setTextureScroll and setTextureScale of the texure unit. I can't say I'm seeing a huge difference in performance when converting my whole project to using 3 large (1024x1024) textures. I would expect to as there should only be 3 texture changes during rendering. Is it sensible to assume that this method will appropriately order objects associated with the single texture and render them together?

Any thoughts??

Cheers
pratty70
Gnome
 
Posts: 394
Kudos: 0
Joined: 13 May 2004
Location: Wales - UK

Re: Texture atlas extension to the RTSS

Postby Assaf Raman » Mon Nov 22, 2010 4:28 pm

@pratty70: Well - if you have less textures but the same batch count - your performance will not improve.
You need to merge the batches.
Watch out for my OGRE related tweets here.
User avatar
Assaf Raman
OGRE Team Member
OGRE Team Member
 
Posts: 3092
Kudos: 78
Joined: 11 Apr 2006
Location: TLV, Israel

Re: Texture atlas extension to the RTSS

Postby pratty70 » Tue Nov 23, 2010 9:12 am

hmm, so texture atlasing to reduce texture switching per frame will not improve performance - I must also batch geometry too?
pratty70
Gnome
 
Posts: 394
Kudos: 0
Joined: 13 May 2004
Location: Wales - UK

Re: Texture atlas extension to the RTSS

Postby Assaf Raman » Tue Nov 23, 2010 9:32 am

Yes.
Here is why - a GPU is basically a special parallel computer - it has lots of cores that are good in very specific tasks.
The way it works - you setup the state (what triangles are going to be drawn, what texture will color them and other such parameters) - then give the GPU the "go" command - then it draws the triangles with the properties, then it returns to you, you re-setup the next state and the cycle of rendering continues.
Each time you stop to re-set the state - the parallel computer stop working, moreover - if you have small batches - not all of the GPU cores are used when it does work - meaning a waste.
It doesn't really matter if you change the texture or not - the main thing with modern GPUs is the batch count. (triangle count and memory are the next big bottlenecks).
Watch out for my OGRE related tweets here.
User avatar
Assaf Raman
OGRE Team Member
OGRE Team Member
 
Posts: 3092
Kudos: 78
Joined: 11 Apr 2006
Location: TLV, Israel

Re: Texture atlas extension to the RTSS

Postby pratty70 » Tue Nov 23, 2010 10:10 am

I understand all that, thanks though for the info. Articles I've read have stated that a texture state change between two "objects" or "geometries" is "one of the worst offenders" for poor performance, regardless of the number of objects in the scene.

One such article: http://www.gamasutra.com/view/feature/2530/practical_texture_atlases.php?print=1

I was told at some point in the past that Ogre actively orders objects according to the texture used to minimise this texture state change.

Maybe I'm wrong.....
pratty70
Gnome
 
Posts: 394
Kudos: 0
Joined: 13 May 2004
Location: Wales - UK

Re: Texture atlas extension to the RTSS

Postby Mattan Furst » Tue Nov 23, 2010 7:55 pm

@pratty70

I was told at some point in the past that Ogre actively orders objects according to the texture used to minimise this texture state change

It does, but this isn't the same as having less batches. Ordering the object according to their materials saves Ogre from calling the directX with some render state changes. However, as long as you have 2 separate objects (different vertex and index buffers) they are considered as different batches. This is because the graphic card needs to render them separately, one after the other, not in parallel. The switch between the different objects creates the performance drain.
it's turtles all the way down
User avatar
Mattan Furst
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 260
Kudos: 32
Joined: 01 Jan 2008
Location: Israel

Re: Texture atlas extension to the RTSS

Postby pratty70 » Tue Nov 23, 2010 11:06 pm

Many thanks.

This does however still contradict things I'm reading.

The Nvidia white paper "improve batching using texture atlases" http://http.download.nvidia.com/developer/NVTextureSuite/Atlas_Tools/Texture_Atlas_Whitepaper.pdf
refers specifically to
Code: Select all
setTexture()
DrawPrimitive()
setTexture()
DrawPrimitive()


becoming:
Code: Select all
setTexture()
DrawPrimitive()
DrawPrimitive()


when using an atlas - hence reducing texture switching, and hence improving performance when drawing two separate "objects".
Am I mis-understanding this?
pratty70
Gnome
 
Posts: 394
Kudos: 0
Joined: 13 May 2004
Location: Wales - UK

Re: Texture atlas extension to the RTSS

Postby pratty70 » Tue Nov 23, 2010 11:14 pm

I think I may have mis-read it. It does suggest that by doing this - the two batches are able to be combined.
Does this mean texture atlasing on it's own provides no improvement in performance and must be combined with staticGeometry - I can't use static geometry as nearly all of my elements move around within the environment! - but does it mean that any that don't require to move - just to have their textures changed could just have their texture coordinates manipulated within the staticgeometry to map a new texture from the atlas on?? (If that makes any sense)
pratty70
Gnome
 
Posts: 394
Kudos: 0
Joined: 13 May 2004
Location: Wales - UK

Re: Texture atlas extension to the RTSS

Postby Assaf Raman » Tue Nov 23, 2010 11:28 pm

Yes.
Watch out for my OGRE related tweets here.
User avatar
Assaf Raman
OGRE Team Member
OGRE Team Member
 
Posts: 3092
Kudos: 78
Joined: 11 Apr 2006
Location: TLV, Israel

Re: Texture atlas extension to the RTSS

Postby pratty70 » Wed Nov 24, 2010 1:07 am

;-)
pratty70
Gnome
 
Posts: 394
Kudos: 0
Joined: 13 May 2004
Location: Wales - UK

Re: Texture atlas extension to the RTSS

Postby pratty70 » Wed Nov 24, 2010 8:54 am

OK, decision made to make anything that doesn't move, or get hidden, part of a static geometry.

Am I correct in assuming that using setTextureScroll and setTextureScale in manually created materials will have the same effect as directly modifying the UV coordinates within the staticgeometry?
pratty70
Gnome
 
Posts: 394
Kudos: 0
Joined: 13 May 2004
Location: Wales - UK

Re: Texture atlas extension to the RTSS

Postby Mattan Furst » Mon Nov 29, 2010 8:46 am

@pratty70

Again Yes.
In fact modifying the UV instead of using setTextureScroll and setTextureScale creates slightly better performance (very slightly), at least in the RTShader system.This is because it means that the RTShader doesn't have to add a step in the shader which multiplies the texture matrix with the UVs.
it's turtles all the way down
User avatar
Mattan Furst
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 260
Kudos: 32
Joined: 01 Jan 2008
Location: Israel

Re: Texture atlas extension to the RTSS

Postby pratty70 » Wed Dec 01, 2010 9:04 am

Many thanks....
pratty70
Gnome
 
Posts: 394
Kudos: 0
Joined: 13 May 2004
Location: Wales - UK

Re: Texture atlas extension to the RTSS

Postby Mattan Furst » Sun May 29, 2011 10:43 am

I have just made an update to the texture atlas RTSS. The shader for the texture atlas no longer shows a border containing pixels from neighboring images. It does so by picking pixels only from the center of the image relative to the displayed LOD.

On another note,

If you are using the texture atlas tool from NVidia to create the images and script files for the shader system, please note that this tool has a bug. If you have dds images from 2 different formats (e.g. DXT1 and DXT5), The texture atlas files from one format will override the other format.

Attached is a compiled version that has this bug fixed. Plus, it contains a feature to allow you to limit the amount of textures per texture atlas texture.
Attachments
AtlasCreationTool.zip
Fixed NVidia texture atlas creation tool
(45.32 KiB) Downloaded 139 times
it's turtles all the way down

For this message the author Mattan Furst has received kudos
User avatar
Mattan Furst
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 260
Kudos: 32
Joined: 01 Jan 2008
Location: Israel

Re: Texture atlas extension to the RTSS

Postby Mattan Furst » Thu Aug 11, 2011 1:37 pm

Just added a new feature to texture atlas which may be important for people using texture atlas. ability to turn of automatic border sampling.

The following is an exert from the new code documentation
There is an inherit problem in texture atlases. This issue occurs because individual textures within the atlas texture are adjacent to one another. when sampling the color of a texture near the texture's edges, especially in lower mipmaps pixel color from other images may be mixed in with the result.
There are 3 ways to handle this issue, each with it's own limitations:
  • Ignore the problem - bad for repetitive images in which the border color may be quite apparent.
  • Auto adjust the sampling position - This the default implementation of the TextureAtlasSampler SRS. Auto adjust the polling position in the shader according the mipmap level in use. This means that a different (smaller) section of an image may be polled instead of the original section (especially with in mipmaps). Bad for non repetitive accurate images.
  • Generate a texture atlas where each image will contain around it a wrapped version of itself. This solves all visual problems but is wasteful in gpu memory (up to 3 times the size of the original image)

As silly is it may sound until now only the second option was available.

The problem and solutions can be viewed in the shader system sample. Check the "atlas auto border" checkbox to move between auto adjustment and no adjustment option.
it's turtles all the way down

For this message the author Mattan Furst has received kudos
User avatar
Mattan Furst
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 260
Kudos: 32
Joined: 01 Jan 2008
Location: Israel


Return to Developer talk

Who is online

Users browsing this forum: No registered users and 2 guests