I've decided to add multiple data set capability to my planetary voxel library.  This is a smooth voxel system using extended marching algorithms. It will allow for up to 8 different data sets using the same set of voxels. This is so I can support things like trees and buildings more easily using voxels+morphing+functions, instead of having to construct and load discrete assets, with their own LOD and so forth.

As it stands I have chunks of voxels and each chunk typically generates a border and a center mesh so that the border can change to match neighboring chunks if they change.  However now since I will support 8 data sets, It could generate a maximum of 16 meshes per voxel chunk. What I'm wondering is if there is a maximum optimal mesh size. I read years ago in some book that terrain mesh sizes should be a about 6K triangles max, but I'm sure things have changed since then.  What I was thinking of doing is sill having just 2 meshes per chunk, and then adding an extra vertex parameter that tells the shaders which data set a vertex belongs to, so the right shader routine can be selected.  This seems like it would generate a lot less draw calls at the expense of possibly very large meshes.  Do large meshes really matter any more?  I'm guessing having less calls is more important.

Of course batching meshes to one big vertex mesh is the way to work out rendering. 6K triangles max is I gess related to 16bit indicies limit per vertex stream in a draw call that allowed only like 64000 verticiesi in an indexed stream, things changed since then.

1 hour ago, JohnnyCode said:

6K triangles max is I gess related to 16bit indicies limit per vertex stream in a draw call that allowed only like 64000 verticiesi in an indexed stream, things changed since then. 

Note that it is still an optimization to only batch up to 65k tris and use 16bit indices, as this saves half the bandwidth required for the index buffer.

34 minutes ago, Juliean said:

Note that it is still an optimization to only batch up to 65k tris and use 16bit indices, as this saves half the bandwidth required for the index buffer.

That may be true if it outperforms vertex stream swithings, depends on character of draw calls and sumary amount of verticies to render. I myself did not go for this kind of optimization since my draw calls were quite abundant as for verticies. Cannot say if I would recommend it.

20 hours ago, Juliean said:

Note that it is still an optimization to only batch up to 65k tris and use 16bit indices, as this saves half the bandwidth required for the index buffer.

Yes, I looked into that myself and decided to stick to full sized indexes.  The problem is the meshes are based on 3D chunks. The chunks are constantly resized since voxels constantly subdivide and re-merge, so the voxel library tries to keep a very roughly constant number of voxels per chunk. In common usage I should be able to set the chunk size  such that 16 bit indices would work. However for odd cases with a lot of vertical geometry I could easily over break 65536 indexes, which means I'd have to support more meshes per chunk. Sticking with 32 bit indexes just seemed easier.

I guess what I'm asking is, are there any in-obvious yet known downsides to having large mesh sizes.  I'm aware of things like frustum culling and sorting of meshes from front to back to minimize wasted calls to the shaders.   However that should by taken care of by the current chunks system.  But is there anything else I should worry about, when generating large meshes?  Like would there be anything inherently wrong with having a 200K vertexes in a mesh?

2 hours ago, Gnollrunner said:

But is there anything else I should worry about, when generating large meshes?  Like would there be anything inherently wrong with having a 200K vertexes in a mesh?

In case your count of draw calls is high and they utilize small amount of processed verticies, 16 bit indicies with few vertex buffer swithces might outperform one big buffer of 32bit indicies... but only very slightly. You should profile both cases.