For my grid like terrain i decided to copy the mesh data (trianglebatches) into 1 big mesh, to avoid having many many trianglemeshes and thus dropping my framerate to a slide show.
Since the terrain is generated up front nothing really changes as far as the renderer is concerned. I have been able to copy the meshdata from 1 batch into another but somehow i cannot get the texture to show up on my target batch. I copied the renderstates cloning from sharedbatch, but i guess i am missing something else.
Below is the code i use to copy information from 1 batch to another.
/**
* Appends all the vertex, index and normal information from the source to the destination after applying the specified
* scaling, rotation and translation. RenderStates are also coppied. Destination is required to have sufficient space to store
* all the information from the source.
*
* @param source
* @param destination
* @param rotationAndTranslation optional matrix for rotation and translation
* @param scale the scale for the new coordiantes on all axis
* @param indexOffset offset is added to indices of the source TriangleBatch to form the new indices in the destination
*
You are probably onto something. Indeed i create the target batch with a new texturebuffer at 0. and my guess is now instead of updating that buffer i append a new buffer which never gets used.
I'll modify the code to update the existing buffer like i do with indices and get back to you.
SharedBatch is like sharedMesh in that it is a reference to another batch/mesh. you still need to obtain a shared instance for every location you want to place it.
Copying batches is taking all the info from 1 batch and placing it inside another batch. for every location you want to place this batch in your world you copy the information into 1 and the destination batch (taking care of transaltion issues and all) and then place only 1 batch (the 1 were everything was copied into) in the scene.
So if i wanted to place 1 mesh (of say 100 vertices) 50000 times in the scene. The shared approach would give me 50000 sharedmeshes and 5000000 vertices in the scene. Whereas the copy approach would give me 1 mesh with 5000000 vertices in the scene.
Although the copy approach should render a lot faster as the shared approach it also has its drawbacks, boundingvolumes just to name one.
I totally aggree with you about the clipping. Like i said there are drawbacks. However in my situation this is not yet a problem because the triangle count per mesh is not that high. And most of the time the user will have a top down view of the entire board. If and when this becomes a problem for me i'll deal with it.
In the mean time it might be interesting to compare notes on this subject.
Although my implementation is geared verry much towards my personal needs for my game, i can tell you briefly what happens.
I have a Board (node) which gets its data from a map this map contains several grids (Object[][]) containing information about the items to display.
For instance i have a grid of the floor, the walls and soon will need another one for stuff like tables and chairs. Each of these grids or levels as i call them maps to a trianglebatch on a trimesh in my board. each item in the grid knows its vertices and indices and textures and stuff. Some of them use 3d models for this others i just hardcoded.
When the board is constructed it iterates over all the objects and lets them update the trianglebatches.
When i decide to knock over a few walls in my world i then only need to rebuild the right trianglebatch to show the changes.
Cuurently with a topdown view of the entire world (30x20 grid with the floor plan, traps and walls) i get about 150 fps. when i drop down the camera to simulate walking in the corridors i get about 300 fps.
Well i did some prelimanary testing with plain boxes that came in (20x20) at about 60 fps. But i don't feel that is a fair comparisson to what i have now. I'll see if i can build something and let you know.
For a grid of 26x19 using basically quads and box shapes for a total of 4192 triangles and 4204 vertices
The copy everything to trianglebatches approach yields 123 fps showing all the meshes completely from a topdown view (2 meshes total)
The sharedmesh approach yields for the same view 69 fps with 738 meshes total.
Going for a more closeup shot the copy approach ranges from 100-400 fps depending on where i look and the shared approach a constant 66 fps although that might be increased by using some culling. (too tired to try that now though)
Running on a Acer travelmate 800, 1gb ram and an ati mobility radeon 9000 at a windowed screen of 640x480
cool! would like to encourage people to make optimizations like this as pluggable as possible, so that you can easily switch between multiple implementations(go OOP ), similar to the vegetation challenge…it'll make you a happier person in the end…
