Working with a tile-map--is there a better way?

In a side-project that I’m working on, the world is much like those in certain old first-person RPGs: a grid of simple flat tiles, with the floor and ceiling each lying on a single plane.

Thus far I’ve been constructing my floors and ceilings from quads, generated by CardMaker and positioned as appropriate. The game flattens this assemblage for the sake of performance, while the associated tile-editor does not, for the sake of allowing changes to tiles.

For the most part, this works. There are occasional glimmers between tiles, but it otherwise looks as intended and performs reasonably well.

With a small tile-map, that is.

When the tile-map is, say, 20x20, all is well, on my system at least. However, if the tile-map becomes too much larger, then performance in the editor drops–I think that I had a situation in which a ~500x500 tile-map resulted in a frame-rate of ~2-4fps.

I daresay that the problem here is simply the number of nodes: 50 000 nodes is probably a bit much to ask of the poor computer. ^^;

So, I’m looking into a new way of constructing my environment.

What I have in mind at the moment is to build my tiles procedurally within one or a few GeomNodes (perhaps one per floor-tile texture), and then add and remove primitives as called for. In addition to dramatically reducing the node-count, I think that this should also allow me to alter tiles during gameplay, an action that isn’t available under the current method.

However, before I dive into building my geometry from scratch, I want to check: is there an easier way that I’ve missed?

I think that sounds like the way I would go. You also want to keep the number of GeomPrimitives down, but that’s OK, because you only need one GeomTriangles containing two triangles per tile.

If you packed the tile textures together into a bigger atlas texture (or even a 3-D texture), you could even generate tiles with different textures together into the same Geom, by varying the UVs per tile to point into the part of the texture atlas that contains the desired tile texture.

Fair enough; I think that that’s what I’ll do, then!

Ah, fair enough, and noted! Thank you for mentioning that! :slight_smile:

I’ve considered that, but that runs into the problem of bleeding at the edges of tiles, if I’m not much mistaken. I daresay that it’s not an insurmountable obstacle, but it’s one that I’d rather not deal with if there’s an easier way…

(However, if I decide to have things like border- or corner- tiles, then it might be called for–such tiles and the like can significantly increase the number of images used, I do think.)

Thank you for all that advice! :slight_smile:

Just to clarify, since I realise I worded this ambiguously: you don’t want one GeomTriangles per tile, but only one GeomTriangles object that contains many triangles, two per tile.

That’s true, depending on your filtering setting; this issue is solved if you use an array texture instead, which is a single texture object containing equal-sized images that don’t interact with each other filtering-wise. Note that sampling an array texture requires a shader (or the shader generator). You might be able to get the same effect with a 3-D texture that has filtering in the W direction disabled, but I’ve not tried.

Either way, this might be premature optimisation. :slight_smile:

Thank you for the clarification. :slight_smile:

Hmm… Good ideas both, I imagine. I’m not familiar with array-textures, but they might be worth looking into if called for.

But as you say, such optimisations might be premature–I’ll try the basic one-image-per-file, one-geom-per-image approach first, I think!