Atlas Textures

I’d like jme to have support for atlas textures.


As GPUs continue to follow Moore’s Law squared [Wloka2003] and get
comparatively faster than CPUs, it is important for game developers to aggressively
reduce batches. The fewer batches a game uses the higher its frame-rate, or rather
the more eye-candy, physics, or AI computations are available to the game. Texture
atlases promise to be one tool that allows reduced batch-counts.


http://http.download.nvidia.com/developer/NVTextureSuite/Atlas_Tools/Texture_Atlas_Whitepaper.pdf

While texture atlases have a perceived stigma of producing lower image quality, the
Atlas Comparison Viewer demonstrates this to be a misconception. This paper
explains how to use texture atlases and how to avoid common pitfalls. Since the
Atlas Comparison Viewer and the Atlas Creation Tool come with source code, we
hope that game developers take a second look at texture atlases as a technique to be
integrated into their tool chains.

http://hub.jmonkeyengine.org/gsoc-2011/ideas-page/#Texture-Atlas-Auto-Generation



:slight_smile:



Thanks for the extra info, I’ve linked to it in the idea entry.

moonkey said:
I'd like jme to have support for atlas textures.

Us too! :)

but don’t you guys have the know-how on how to do this, I mean you are the gurus :slight_smile: or perhaps atlast textures ain’t that easy to implement?

@moonkey In spite of their godlike qualities, even the jME developers are held captive by the cruel laws of time.



Every new feature comes with preliminary research, several iterations and post-stable maintenance and support. Whenever there’s a chance we might spark the interest of a new developer, that’s usually our best bet.

Having an easy to use texture atlas would be great. Unfortunately, doing it right is not exactly easy. If I recall correctly, there are two big issues:

  1. mipmapping - copies of your texture rendered at a lower resolution. You have to make sure that you don’t combine adjacent textures when the mipmaps are calculated.
  2. Clamping the texture at the edges of your triangles. You can get some ugly artifacts at the edges of your triangles from neighboring textures. To prevent this, you have to clamp the texture at the edges. I’m pretty sure this needs to be done in the shader.



    So, on the surface, a texture atlas seems easy to implement. But there are (at least) the above two issues to deal with. I don’t think these problems are enough to make it hard, but it does mean that whoever implements them needs to know some pretty low-level opengl stuff. That restricts the number of people that can tackle the problem. I wish I knew a bit more about this, because even though I know what the issues are (at least, I think I do), I don’t know how to address them. I’d definitely take a stab at implementing texture atlases if I wasn’t so mystified by glsl. Maybe I’ll get brave and dive into it someday. If any experts have some advice on where to start, I’d appreciate a few pointers.

hi codeviking



you can start here, investigate if texturepacker is something we can use and perhaps incorporate in jME



http://code.google.com/p/libgdx/wiki/TexturePacker



http://code.google.com/p/libgdx/source/browse/wiki/TexturePacker.wiki



continue with learning glsl by following these great tutorials at swiftless:

GLSL – Swiftless Tutorials - OpenGL, GLSL & WebGL Tutorials for the computer graphics beginner



suprise us in month or two! :))

1 Like

Ardor3D has the TextureAtlas.

I was porting it to jme3.

It is discontinued because I don’t know how to handle sub images to make one big atlas.

If you want, I’ll share it.



can you explain the problem about sub-images that you run into?



is this working tool or is it not working because of this problem?

The packing algorithm works well.

The problem I have is creating one Big Texture Atlas by reading subimages. Image IO.

Actually I’m currently In the progress of writing a Texture Atlas tool for Jme3 as a resarch project for my University (Mainly as a tool to optimize the use of Batching for Objects that share the same relative coordiante space) Using a few ideas I got while looking at MegaTexture techniques. Also planned is the support for repeating Textures.



Internally it is in fact using the already mentiond texturepacker for the atlascreation. However that is only a small part.



Basic idea is:

Drop in a folder with models and the materials+ textures (Glow,Specular,Normal,Depth,Diffuse,Detail supportet)

get out a folder with j3o modelfiles a few dds textures and j3m materialdescriptions.



Planed schedule is to finish a working project around easter.

Good news!

Then I’ll just wait for it. :slight_smile:

What if you just have folder with textures and not models, I hope models are not required to get something out?

You can’t just point the tool at textures. You need to adjust the texture coordinates of all models effected so they point to the coordinates in the new texture.



You could however create some kind of intermediate format that describes new mappings for textures, e.g.



[xml]<atlas path=“result_0.png”>

<texture path=“tex123.png” x=“10” y=“50” width=“123” height=“321”/>

<texture path="…"/>



<!-- … etc … -->



</atlas>[/xml]



Then you can use this data to apply the new coordinates by matching the material’s texture path to the atlas its referenced at.

Something very similar is the result of the TexturePacker. However there are only few needs for textureatlases if you don’t apply the changed texturecoordinates to models.

If you gonna have a complete solution that has hope of being integrated in jMP I think you gonna have to cover for case where model is procedurally crated from the engine/game/whatever and where uw map is assigned there as well to the model. To then be able to get the texture you want and correct uw position for that texture is important. If you can do that then you got complete atlas tool, if you got something that is automated withouth much flexibility that I mentioned that it will fit in very special cases. I hope whatever you are cooking it will be able to use it in more then “export the model from 3d application with assigned uw map and import the model dont care about it” case.

I will donate to you if whatever you end up making is able to give me uw coordinates of a special texture in a texture atlas. I can assign the materials etc my self. Can you explain littebit more how you inted it to work so I am not missunderstanding you :slight_smile:

No need for that :wink: The actual atlas creation is only a import. The main focus is on combining the stuff to efficiently batch for my case. (Bring dynamically combined geometry like spaceshipparts that are assembled to a spaceship) to one big geometry with only one large Material that has all needed textures. Also another target is to release the burdon on artists to create complex uvmaps for each model. Instead they can use various textures per model. (and they are later combined automatically)



http://code.google.com/p/libgdx/wiki/TexturePacker

Not sure I understand the case you are talking about, I wonder if will there will be support to find out uw position of texture that is inside atlas texture? If you got that covered then you have real atlas tool.

If you only need that low level atlas functionality there is no need to use my system. As you can see in the link there is already a solution for that.



The System has a more or less specific case, in the meaning that it can only do one thing, but one thing that most persons using jme with models might benefit from.