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.
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?
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.
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).
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.
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.
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!).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.
Yes i realized i was overanxious about duplication, they won't affect run time efficiency as i thought, thx.
