Performance question - one large (mesh & texture) vs. many small

I'm creating a game board using hexagons, like the attachment.  Each hex is made of 24 triangles from 19 vertices.  Somewhere in the forums, I found a thread about the GeometryBatch class that said a single large mesh would give better performance than multiple smaller meshes.  Therefore I implemented GeometryBatch to stitch together all the individual meshes into one large TriMesh, attach that to a TerrainNode which is attached to the RootNode, and off I go.  This mesh then uses a single texture that I'm creating dynamically before attaching it to the TerrainNode.  However, I want to create a map that is 29 rows by 43 columns, and I run out of memory trying to create the texture that wants to be more than 2000 pixels per side.  I'm thinking that maybe there has to be a better way than the direction I'm going in now.

A map of 29x43 means 1247 meshes, and a total of 29928 triangles from 23693 vertices.

In terms of performance (speed of rendering) and memory usage, for a straight-forward brute-force implementation, what will give the highest speed and least memory required:

  1. a single mesh of approximately 30K triangles with a single texture approximately 2000 pixels per side attached to a single node
  2. 1247 nodes attached to the root, each with a single 64x64 texture and a 24 triangle mesh
  3. some other option that works smarter rather than harder


Large number of meshes drop performance drastically.

check out this.

It all depends on your requirements I suppose.

To me, using a huge texture map and using a mesh which represents every hex would pretty much be alternatives.

If you're going to use a huge texture map, why not just bake the hexes and map it onto a plane (or terrain if it isn't flat)?

If you are going to use a model where every hex is a node, then why not use individual texture maps and share them? That way you can get a map of any size out of a fairly small set of textures. You will get repetition, but then you get that on most traditional map boards. There's various things to reduce it too. Extra details can be multitextured on.

You could consider zoning the board and rendering distant sections to texture.

youcould increase your java heap memory.

What about shared node? One geometry, one texture, shared (minimal memory footprint) and then use locks (for high performance). Then you just have to worry about putting the numerical text on each one, either with a decal or attaching a Text2D. Just some thoughts.