Sign in to follow this  

which way is more efficient to implementing texture atlas

This topic is 675 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Currently i am implementing texture atlas, while i cannot make a choice between two options:

1 Use multi call of glteximage2d to combine texture in gpu. or

2 Combine textures in cpu and call glteximage2d  once.

I am not sure which way is more efficient, thanks. 

Share this post


Link to post
Share on other sites

Can you do #3 -- make a tool that combines all the textures ahead of time, so that you don't have to do #1/#2 at runtime at all?

I want to make texture atlas for game scenes,because the same texture can be used in multiple scenes,if i make texture atlas for every scene ahead of time,there will be many texture duplication, so i think i have to combine at run time. 

Edited by PolarWolf

Share this post


Link to post
Share on other sites

 

Can you do #3 -- make a tool that combines all the textures ahead of time, so that you don't have to do #1/#2 at runtime at all?

I want to make texture atlas for game scenes,because the same texture can be used in multiple scenes,if i make texture atlas for every scene ahead of time,there will be many texture duplication, so i think i have to combine at run time. 

 

I just do it at pre-process time and have the artist specify which images go in which atlas such that they are drawn around the same time. I also made it very easy to tweak which images go in which atlas. The atlas itself is I think 1024x1024 so it can hold a lot of information. I also implemented an LRU cache to hold atlases in memory, and if I ever see excessive swapping at run-time I'll know there's a problem to fix (but I doubt this will ever happen).

Share this post


Link to post
Share on other sites

 

 

I just do it at pre-process time and have the artist specify which images go in which atlas such that they are drawn around the same time. I also made it very easy to tweak which images go in which atlas. The atlas itself is I think 1024x1024 so it can hold a lot of information. I also implemented an LRU cache to hold atlases in memory, and if I ever see excessive swapping at run-time I'll know there's a problem to fix (but I doubt this will ever happen).

 

Let artists combine atlas and pre-process is simple and usually has better combine results, texture duplication is really per game dependent.I came up with a new idea,textures are separate(or seems) in installation package,be they in separate image files or in the same one, or in one resource file,they are treated as independent resources,the program combines atlas at run time(combine rule can be specified by artists), and save those atlases to disk for later use.

Edited by PolarWolf

Share this post


Link to post
Share on other sites

Yeah I can see the sense in that. I'll describe what I did in a little more detail and maybe it will help your ideas:

 

So during development I have all the images stored separately, along with .PSD files if necessary, and these can be stored in the version control -- just like your idea. I'm just using hg but larger game studios seem to like perforce. When new images are made and the game is started up the atlases are compiled (only the ones that have been changed).

 

Outside of development builds the function for compiling atlases can just simply be not run, and so no run-time overhead is incurred involving atlas creation. The separate images are not shipped, just the final compiled atlases. The game has no knowledge of the separate images on-disk.

 

The hard part might be how do you refer to different images in-code and in the editor tools? By string, or some kind of integer ID? The solution I chose was to refer to all resources (including images) by hashed filepath, so the run-time never actually uses strings when dealing with any resources. The development build stores a large table of ID->strings so that editors and debug tools can see human-readable names. This table is not used by the game itself (outside of debugging and logging), and disappears for shipping. When the code refers to an image by ID it finds both the owning atlas and UV coordinates.

Edited by Randy Gaul

Share this post


Link to post
Share on other sites

because the same texture can be used in multiple scenes,if i make texture atlas for every scene ahead of time,there will be many texture duplication

This isn't necessarily a problem. It only affects the size of your game on disc, and how long it takes to download (and this can be almost entirely fixed by using good compression that takes advantage of the duplication!).
On PS3 it was actually common to deliberately duplicate assets on the game disc, as seeking a BluRay is very slow, so it's better to make sure that every scene is saved in a contiguous blob on the disc.

Share this post


Link to post
Share on other sites
This isn't necessarily a problem. It only affects the size of your game on disc, and how long it takes to download (and this can be almost entirely fixed by using good compression that takes advantage of the duplication!).
On PS3 it was actually common to deliberately duplicate assets on the game disc, as seeking a BluRay is very slow, so it's better to make sure that every scene is saved in a contiguous blob on the disc.

 

Yes i realized i was overanxious about duplication, they won't affect run time efficiency as i thought, thx.

Share this post


Link to post
Share on other sites

This topic is 675 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this