This is a question about the usage of TextureAtlas. Writing myself a block world. Currently, each of my “chunks” of terrain consist of a set of 16x16x16 blocks. I use GeometryBatchOptimizer to merge those blocks/faces into Geometry(s) for each chunk. When I wrote the code TextureAtlas wasn’t available – now that I see it being available I thought …to myself…“cool… I can get get those down to 1 material, and thus a single geometry per chunk”…
but… I don’t get it… . 
I see how I can use TextureAtlas on an entire node… to merge the geometries and create a single material with one invocation… but that would end up creating a TextureAtlas for each of my chunks…(several hundred)… and use up tons of memory.
I can’t work out a sequence of calls to TextureAtlas to get what I want… my brain keeps thinking I want to do something like:
ta = new TextureAtlas(whatever, whatever);
for( each of my textures ) {
ta.add(texture, uniquename);
}
Then later for each of my chunks:
TextureAtlas.makeAtlasBatch(myChunk, mgr, ta);
Thus I’d be re-using the same TextureAtlas for each of my chunks…
I see how I could just merge all of my chunks into one single large mesh – but, I assume, would make the mesh expensive to change…
Do I just need to write my own version of makeAtlasBatch that uses a TextureAtlas from a parameter rather then create a new one with each invocation? is it that simple? I really didn’t think of that until I wrote this… and now I think I should have done that before I wasted anyones time with posting this… but … I’ll click post anyway…
Thanks!
Inevitably with a block world you end up writing everything custom. This is why I say it’s the hardest kind of engine to write.
This case is no different. You will probably have to write a custom texture atlas and incorporate it into your chunk generation. In fact, you may even have to create your texture atlas offline for a variety of reasons but at minimum you will have one texture atlas for all of your block “materials”.
Eventually you will probably want to replace your Quad → Optimize stuff, too, because that’s a really inefficient way to manage a block world… but that will last you much longer.
Yeah I don’t think that idea of mine would work… okay back to the “old” plan that I had been putting off doing for awhile. Creating my own Atlas and simply changing the texture coordinates of the mesh to point at the right place within the Atlas. My strengths aren’t with custom meshes so I had been putting it off…
When you say that doing my Quad–>Optimization would need to be addressed in the future – was there a specific aspect of it that would be slow? Currently it is simply taking a bunch of quad geometries for the various exposed faces and batching them into a single mesh for each material. The next level of optimization I had in mind was to simply create the mesh from scratch from the start rather then relying on GeometryBatchDoohicky to merge it all for me.
Chunk/Mesh generation is almost completely outside of the update calls in another thread – only swapping in the updated/new mesh into the scene graph is being done within update… so far chunk generation has been able to keep up with player movements without a problem.
I don’t do anything like finding adjacent exposed faces with the same material and attempt to simply repeat the texture. That was my “next next” level of optimization and only if I really needed to do it.
BTW – thanks for the reply! `tis appreciated.
Yeah, I meant eventually you’ll probably just go straight from data → mesh without all of the intermediate “create 5000 things just to turn them back into 1” work.
@ehubbard said:
I don't do anything like finding adjacent exposed faces with the same material and attempt to simply repeat the texture. That was my "next next" level of optimization and only if I really needed to do it. :)
I don't do it either. It has its own downsides, also... and plenty of the Mythruna faces are not solid squares anyway.