Page 1 of 1

[Submitted] Texture Atlas Support

Posted: Fri Mar 16, 2007 7:51 pm
by ShingoHill
Hi all,

I wanted to present my main idea here to know what you think about this before applying it to SoC. I would like to have as much feedback as possible to refine the idea before submitting.

The idea:
What I'm looking for is to implement texture atlas facilities in OGRE. This would consist in both an API and stand-alone tool(s) (as requested here), that allow an easy step from models and materials that doesn't use texture atlases to others that do, so that artists don't need to explicitely use them, being that one of the most important drawbacks when using this technique.
The benefits of using texture atlases is well-known, meaning in an increasing performance and better batching.

Some key features would be:
  • Update existing models to use TA.
  • Baking multiple textures into a single one. Materials baking would be an interesting feature related to this.
  • Supporting scripts to automate this process along various textures, materials and models.
Developpment process:
The development process would be obviously iterative, following the Scrum methodology. Sprints 7-15 days long.
Test-driven development, to ensure the quality of the delivered code.
Intensively documented, following the OGRE tradition, incuding as well project planning documents, bug and tasks tracking documents and per-iteration evaluations as Scrum suggests.
Key parts will be modelled previously using UML.
Use of repositories to keep the codebase safe and updated (either CVS or Subversion).

Any suggestions, improvements or opinions are very welcome.

Posted: Fri Mar 16, 2007 8:08 pm
by xavier
Some of the drawbacks? For instance, you can't really use mipmapping with them directly; do you have a solution for the mipping issue? Same for any filtering techniques.

Posted: Sat Mar 17, 2007 2:10 pm
by ShingoHill
About mipmapping, the solution I have in mind is to generate custom mipmaps instead of letting automatically generated ones. The best solution for this would be to save the image in DDS or any other format that allows to store mipmaps. Then, mipmap them individually in sub-maps, skipping the averaging process between neighbour subtextures.

About filtering, nearest filter shouldn't be a problem, though linear filtering would require adding a bleeding edge around the subtextures to minimise the impact. This bleeding edge would be generated depending on the texture addressing mode if possible (it would be a different edge if it uses clamping than if it uses wrapping).

These are still ideas though. I would need to do some prototyping and tests, but I think they would be quite interesting solutions.

Posted: Sat Mar 17, 2007 2:23 pm
by tuan kuranes
What texture packer algo are planned, one or more ?
Some "border" option ?
Some could be used real-time ?
Some other texture tools may be useful too, like adding DXT/3DC/Etc... as just texture atlas may not be a subject of its onw for a whole gSoc.

Posted: Sat Mar 17, 2007 3:31 pm
by Kencho
tuan kuranes wrote:Some "border" option ?
I think that's what he meant with "bleeding edge", as has mentioned linear filtering.

Maybe would be a good addition to include texture compression and packing algorithm options. There's plenty of info in internet about this. Do you think you could handle these additions as well?

By the way tuan, what exactly do you mean with using it "real-time"? If you mean run-time, I think that would be possible, but I don't have any faith on very large texture manipulation in true real-time; I think that wouldn't be fair to ask for something that can't be accomplished in a practical way, don't you think?

Posted: Sat Mar 17, 2007 4:47 pm
by tuan kuranes
@kencho : In my real-time impostoring code of unique entity, each entity is rendered into a part of RTT. Allocating the space in that RTT, and making optimal when rendering a lots of entity into impostor needs a Real-time packing algorithm... I did use a quadtree packing algo (fast to code) which is obviously non optimal in terms of texture space.

Posted: Sat Mar 17, 2007 5:05 pm
by Kencho
Yes, but think that here we're talking about very large textures, and specially about mipmap generation through software. That's a lot of memory to play with in a pixel-by-pixel way. Here, hardware acceleration has too few (if something) to see, unfortunately. Not the same about dealing with the models themselves, that could be done in real time.

In any case, the existing texture atlas tools that I've read about are run off-line, so I don't really see real-time a matter in this case.

Posted: Sun Mar 18, 2007 4:02 pm
by stoneCold
[Jumping in]:
The last days did some research on the topic myself (Atlas Packing + finally using the Atlas in Ogre)... ---> (because I'd like to use Atlases in ogreSwf)
I already did some experiments regarding the "Cross-Talking" / "Edge Bleeding" / *however* :) that happens between Atlas parts, just to recognise another problem that hasn't been mentioned yet in this thread (if I read correctly).

What if the mesh, that the atlas sub texture will be applied to, has texture coordinates out of the range [0.0 , 1.0] ?!
It might result in a mapping of the whole atlas to the mesh.
To solve the issue I just wrote a shader yesterday.
(maybe I'm completely missing the obvious, but there is no other solution for there?)

Some screens...

Standalone texture that is contained in the atlas as well:

The atlas:
(with the above texture contained, right between others and sized 64x64 to have the effect of the mip-mapping issue, etc. present)

An ogrehead with a usual material applied:
The material:

Code: Select all

material NormMaterial
				texture 1.png
The ogrehead with shader and the atlas texture assigned:
(the debug text shows the shader inputs used, ie. the first two values describe the width and height of the atlas patch,
the third and fourth are left and top values....these describe the region of the atlas texture that has to be used)
The material:

Code: Select all

material AtlasMaterialScene
			vertex_program_ref atlas_scene_vs
				param_named_auto wvp worldviewproj_matrix
				param_named_auto coords custom 1

			fragment_program_ref atlas_ps
				param_named_auto coords custom 1

				texture atlas.png
Here the other atlas patches beeing displayed:
(same material and same atlas texture, just the shader parameters are changed,
see the debug text for the input coordinates)

In the images you might see the well known "cross talking" caused by the technique as well as some artifacts that are caused by the shader
(I guess that happens because my clamping to int values in the shader code.....
you will see what I mean later, though this should be solvable, maybe even alltogether with filtering the "cross-talking" away)

Here a screen to see it better:
(cross-talking + artifacts)

As said, I just want to ask if there might be anything obvious that I'm missing completely? or is such a shader the (only) way to go?

[FINALLY]: my shader code
(It's not at all optimised = there are a lot of mathematical improvements possible,
though I leave it like that during experimenting, because else not even I might know what is happening in there :wink: )

As said, please comment/correct/etc.


Posted: Sun Mar 18, 2007 4:20 pm
by Kencho
An extract from Ivan-Assen Ivanov's feature in Gamasutra:
[quote="Ivan-Assen Ivanov"]For example, texture tiling is impossible, and all texture coordinates should fall within the unit square (0,0) – (1,1); this requires some retraining for artists who are used to the “freeâ€

Posted: Sun Mar 18, 2007 4:37 pm
by stoneCold
Kencho wrote:Plus, in my opinion a shader can't do what has been talked here. For instance, you can't create the atlas or the mipmaps through a shader in an efficient way. Or simply, you would have to re-write all your shaders if you plan to use an atlas in a material that already uses shaders.
(my above experiment was just thought to handle the texture wrapping, not cared about custom mip-map generation yet)

Ivan-Assen Ivanov wrote:...this requires some retraining for artists who are used to the “freeâ€

Posted: Mon Mar 19, 2007 8:15 pm
by ShingoHill
These are the features this project would have so far (the number between brackets is its priority as development order; same number means parallel development):

[1] Adapt existing meshes to make use of a certain texture in an atlas.
[1] Create a texture atlas from a set of textures. This would allow to pack non-power-of-two sized textures in a power-of-two size one.
[1] Provide an API to do these operations in run-time, as well as separate tool(s).
[2] Merge materials with identical features that used only textures now batched in an atlas, if possible.
[2] Texture packing algorithms support. At least one, with extensible design that allows further addition of algorithms. More will be added if there's enough time.
[3] Manual mipmaps generation (possibly multiple methods depending on the kind of textures that are being batched, as described here, for instance)
[3] Borders to solve the linear filtering problem. If enough information is available, these borders should be compatible with the different addressing modes (clamp, wrap, mirror).
[4] Scripting for batch operations through a single call. Same with the separate tools.
[5] Support for texture compression, if possible specialised for the target textures (3Dc if only normal maps, etc.)

Regarding the texture packing algorithms, I plan to do some research before starting the SoC program though I still don't have any candidates. However, the texture packing framework should allow easy addition of algorithms, so that shouldn't be an actual problem.
As much options as possible will be added in this time frame, though development will continue further. Any additions or suggestions? Would this be ready for an official submission?

Thanks a lot for your suggestions so far! :)

Posted: Mon Mar 19, 2007 11:42 pm
by Kencho
[quote="stoneCold"][edit]: [quote="Ivan-Assen Ivanov"]...this requires some retraining for artists who are used to the “freeâ€

Posted: Wed Mar 21, 2007 5:30 am
by ShingoHill

Material switching, and specially texture switching, is one of the most expensive operations in terms of performance in graphics applications. Today is usual to find an increasing number of textures in applications, specially because of their added versatility thanks to the pixel shaders (normal maps, specularity maps...).

As a solution to the large number of texture switches appear the texture atlas concept, packing in a single texture a number of subtextures. This lets minimizing the number of switches, being only one where there were many before. nVidia already offers tools for building texture atlases, though their functionality is limited as it's not oriented to a particular application.

As a direct application to OGRE, it's intended to develop a number of functionalities to allow the OGRE engine support texture atlas features directly. This will allow OGRE users to benefit from the use of texture atlases through a custom solution, letting, for example, merging materials or adapt meshes directly.

Detailed Description

The main goal of this project is to give every OGRE user the chance to benefit from the use of texture atlases. To do this, both an API and a tool that makes use of this API offline will be delivered. To simplfy its usage and let batched workflows, an scripting facility will be added as well.
Thanks to the use of texture atlases, OGRE users will be able to enhance their applications' performance, thanks to the decrease of texture switching in the graphics card, solving many of the inherent problems, providing, at least, the features that offer the nVidia tools.

In this case, OGRE will receive some extra advantages as this project is targetted to this particular engine. As an API is provided, will be possible to access all the features in run time.
Additionally, this project wouldn't be limited to the atlas construction itself, but adapting existing meshes so that they can make use of them directly, or even merging materials in certain cases. This makes it the perfect partner of OGRE's static geometries.
In this case, other existing tools are many steps behind when OGRE is the chosen graphics engine.

Will be possible to use different texture packing algorithms in a flexible and extensible way that opens a point to add new algorithms in an easy way, plus specialised mipmap generation, as well as specialised texture compression (ie, use of 3Dc for normal maps only atlases). Also will be studied the possibility of reaching a compromise solution between mesh tesellation and texture wrapping.

As a side goal, this is a great chance to help the open-source community, contributing a whole project, and an opportunity to learn how a real-life development process is.

[Development methodology]

The chosen development methodologies are Scrum and Test-driven development. The development cycle will be divided in 14 days sprints as suggested by Scrum. At the end of each sprint a report will be released with the analysis of the ending sprint, so that the next can solve the found cons, as well as empowering the pros.
Regarding TDD, unit tests will be done when possible, to ensure the design by contract. Before finally closing a task, regression tests will be run to ensure the developed code isn't harmful for the existing codebase.
Tasks and defects tracking will be used to know the development and stability status at every moment.
Source Configuration Management is also important to keep the project codebase as well, using an open-source tool for this task (such as Subversion or CVS).
Following OGRE's directives, this project will be intensively documented, both its source and other important elements such as technology, project planning, reports and tools user manuals.
OGRE's coding style is also a key part of the development.
Will be fully multiplatform (at least Linux and Windows), and the tools used will be open-source or at least free.
Before implementing a feature, a previous UML design using patterns will be done to study the best suited approach for it.

[Project schedule]
  • Sprint 1:
    Project planning
    Research on fields such as algorithms, approaches...
    Prepare the workspace
    Do the first designs for the next sprint

    Sprint 2:
    Develop the base framework to start implementing
    Performance tests for the packing algorithms: Mainly determining how much wasted space they produce
    Texture packing algorithms: A functional simple algorithm first. More will be developed later.
    Texture packing implementation
    Meshes updating

    Sprint 3:
    Borders to reduce linear filtering bleeding
    Mipmap generation
    Combine materials with same features that are sharing an atlas
    First, basic version of the standalone tool

    * At this point, first pack of code will be submitted to Google.

    Sprint 4:
    Scripts support
    Texture compression support

    Sprint 5:
    Second version of the standalone tool
    Add more texture packing algorithms
    Extra features identified during development

    Sprint 6:
    Pre-release bug fixing
    Final tests
    Closing documentation

    * At this point, the final version is submitted to Google

    Concurrently, these tasks will be performed during the whole development cycle:
    Technical documentation
    Code integration
    Scrum Daily meetings via IM
    Various (updating the forums and student-mentor communication)
    Research and prototyping
    Reports when closing a sprint and during evaluation periods
[About the student]

I've got my Bachelor's degree on Computer Science last year, and am currently studying for the Master's degree on Computer Science as well.

With good knowledge on project management and SCM, I've been lucky enough to learn from one of the founders of Codice software (Plastic SCM developers). I'm towards the use of agile methodologies for software development because of the great flexibility they have against changes over time (Scrum & XP are my personal favourites). I know UML quite fine and am a follower of "the three amigos" and "the gang of four".
Expert in automata and formal languages, I did my graduation project Thoth (a Java application for the finite automaton and formal grammar simulation), currently used as a teaching assistance tool that got a 9 over 10 points on the graduation evaluation. I've always been interested in the compilers and syntactic analysers fields that will undobtely be very helpful for this project's script implementation.

Unfortunately in my university I haven't had the chance to learn about this subject, and thus this is an unique chance to develop my first heavy project on graphics design. I have always been interested on game development and wish to work on that industry in the future. That's why I think being a developer of a Google project for OGRE can open many doors to me in the future. Have got a good C++ level, but have known about OGRE a bit late. Some months ago I received a small course on OGRE from a MVP (Jesús Alonso Abad), and thanks to that I could come into the OGRE world and along these last months I haven't stopped to learn a lot by asking for advice from him and reading from the forums and wiki.

I'm sure I'm capable to handle this an if it's finally chosen, I swear I'll spend as much time as required until it's perfect.

Posted: Thu Mar 22, 2007 12:40 am
by Hudson

Interesting topic.

Have you read about DirectX 10 texture arrays?
David Blythe, Microsoft Corporation wrote: Texture maps and render targets can be created as linear arrays (of up to 512 elements) of a homogenous resource and bound to the pipeline as a texture or a render target. Shader instructions used to address texture maps are extended to include a shader-computed array index. This alleviates some pressure for applica-tion developers to pack multiple images into a texture map and the extra computation to manipulate texture coordinates to retrieve the subimage.

Posted: Fri Mar 23, 2007 2:46 am
by ShingoHill
No, I haven't heard about that. Thanks for hilighting it.

But will wait until this project is finished and OGRE supports Dx10 (I've read another proposal posted here). Don't want to mix many things at this moment :)

Posted: Sun Jun 03, 2007 9:57 pm
by funshark
Just popping this thread up to have some news.

I'm very interested about Atlas implementation in Ogre.
Good luck!

Posted: Sun Jun 03, 2007 10:02 pm
by Kencho
The project was not picked for this year's SoC, so I wouldn't count with this before September at least.

Posted: Sat Jul 07, 2007 7:14 pm
by SiENcE
hi there,

i was also thinking about an texture atlas option for ogre, because,in our project, we have many small textures to load.
Pacific Storm, a Game from Lesta uses the Ogre3D Engine and has support of Texture Atlas.

They bind it to the Texture Unit...something like this:

Code: Select all

	filtering none
	tex_address_mode clamp
	tex_size 0.0 0.0 5.8125e-002 0.2953125 
	texture example.png
I hope there is an option in the next Ogre release.

so long.

Re: [Submitted] Texture Atlas Support

Posted: Mon Nov 22, 2010 1:47 pm
by Assaf Raman
Here is a thread that talk about a texture atlas extension to the RTSS: