Texture Atlas

Troubleshooting graphics
1

In the search for more performance I’m left with the question if JME3 has support for Texture Atlases, or if i have to build that myself.

Any ideas?

2

Empire Phoenix made some texture atlas creator few month ago

http://hub.jmonkeyengine.org/groups/user-code-projects/forum/topic/ogre-textureatlas-creatorremapper-materialfilecreator/



The engine does not really have “support” for texture atlas, but we use it for particles, you should look how it’s done. You’ll probably have to implement your own shader in the process.

3

argh… another shader…



Thanks, I’ll have a looksee.

4

Some unexpected good came out of this for me though. For some reason you triggered a thought in my tiny brain about how I was handling some animated textures and I think I’ll give it a try tonight and see if it works a little better. Not exactly a texture atlas, but not as barbaric/stone age as the way I’m currently doing things =p



Thanks all the same! =p

~FlaH

5

Hey tehflah, care to give some feedback (bit of code would be nice) if you get that working? Thats also on my wishlist :slight_smile:

6

Yeah, I’ll try to if it doesn’t look as barbaric as most of my code tends to be (refactoring? WTF is refactoring?). :smiley: I already have a shader in place (well, sorta… It’s not ideal for sure), but what I was getting at was right now I’ve got… a really nasty way of handling a sheet of texture animations. You got me thinking about just storing the individual frame data into an xml and just reference it by frame number/frame name (structure to do this of course). Right now I’m slinging uv coords all over the place like a madman. But pairing the texture with the mapping data makes way more sense than pairing the model with the mapping data, no idea why I did it the way I did.



I’m still figuring most of this stuff out the hard way… ;p



~FlaH

7

I changed the server so the above link will not work anymore, I will look though my svn and hdd however to see if i still have a version.



I can shortly explain what it does however, as there is no difficult code in it:



It loads a ogrexml, search for all used textures, combines them with the help of a nvidia tool, then reads the output of that, and applies the changes to the texture coordiantes and material file.



Basically it only helps you to reduce several textures into one (per mesh)

8
You got me thinking about just storing the individual frame data into an xml and just reference it by frame number/frame name (structure to do this of course).

Well, since it's basically the same problem for statics textures as for texture animations where you don't want to keep binding new textures to the gfx card but in stead would want to give them one large texture with all the subtextures in it (just like they are doing in Slick2D), why not extend the Texture class to be able give subTextures (getSubTexture(row,col))? Then you could still load it with the asset manager and can use one of the many tools to combine your textures into one image (Also see the Slick2D's site). That would basically be a Texture Atlas and would be usable for animation too with some auto-increment of the 'default' subtexture. Easy enough i think.
The hard part would (for me at least) be to bind the TextureAtlas to the card and changing the shaders to use the subtexture.

Not too far beyond the limit of possibilities, unless you plan to stream live video on a geometry, i think.