While I’ve been sick, I’ve been keeping myself busy with playing around with techniques for batching meshes. Honestly, I’m getting some results that I just wasn’t expecting.
Here are the things I have been playing with and the results I have seen so far:
I threw together a random dungeon generator to test with.
It’s tile based and each tile is about 50-100 verts.
I’ve tried multiple methods of batching them, from custom code to using a BatchNode… and for the sake of this explanation, I’ll use the BatchNode example.
After batching the tiles, I extract the Geometry from the batch node and add it to a regular node and GC the original BatchNode. I don’t need the references to the individual objects, so no need to keep the extra info.
With the way things are put together using texture atlasing, I’m able to narrow down the entire scene into a single mesh. Yay! This is a good thing… right?
Um… not so much. I’m not entirely sure why, but I’m getting some pretty crappy frame rates. Here are some stats so maybe someone can help me figure out what the issue is:
1 Mesh for all visuals… LOTS of verts… let’s see… about 4 million verts and 3 million tringles.
A single 2048x2048 texture.
Now, I get that this is not an ideal situation… this was a test mind you! But, I wasn’t expecting a frame rate as low as 35-40 FPS. I’ve been hearing for a very long time now that JME handles low object count, high vert count much better than the reverse.
For the hell of it, here are some screen caps showing what I was working on. I didn’t write it for any particular reason… though, I think it looks cool enough to consider writing a single player game around for fun. Buuuut… the frame rate issue has got me a bit puzzled… thoughts?
First off, I’m glad you are feeling well enough to be back with us =)
About the batching, I think you need to make a few smaller batches instead of one extremely large since with one large batch you are missing out on frustum culling optimization.
There is a sweatspot between object count and batch size somewhere between rendering one huge batch and a single batch for every object.
The game/map and the high quality assets looks really nice!
lol your “tests” could make nice looking games really
As @kwando said, it’s better to subdivide the scene in several chunks so you can have some frustum culling. 3 to 4 million triangles is a bit hardcore.
I guess your maps are grid based so it should be pretty simple to “cut” the area in sub areas.
Then some LOD could help too…
In short I wouldn’t recommend using brute force batching for this kind of scene
I love how this looks so far.
I am working on an android game and I have the same issue with batching. So I would love to hear more on this topic.
What I currently do is to not batch at all and let frustum culling do its trick.
Obviously this can have its downside as well, especially if you have lots of controls in the scene.
how do u ppl do such nice scenes? all i have done is squares and circles my game looks like this, go chop some cylinder trees, build box houses and slay sphere mobs
Yeah, I’d also say since you don’t cull anymore you go to the other extreme, in effect you probably render 4-6 times as many polys as before and the switching time for the geometries becomes negligible. As nehon hinted, keep a few single geometries, best dividing by areas that are being looked at.
can you show us the statistics of that scnee? Also what kind of hardware are you running?
(Here it gets funny, intel hd cards & amd fusion chips can usually go up to several times the object count than a normal pxie card can (due to less overhead for draw calls). At the same time they entirly suck at more complex scenes as the simply have not enough power to do several million polygons…
<cite>@eraslt said:</cite>
how do u ppl do such nice scenes? all i have done is squares and circles :( my game looks like this, go chop some cylinder trees, build box houses and slay sphere mobs :D
@monkeychops, if I remember correctly the SSAO filter needs to render all visible objects at least one extra time, maybe two times. This is because the SSAO algorithm needs boh a depth map and a normal map in order to make it’s magic.
@monkeychops
Heh… nice call on the use of SSAO. Yes, the scene is using SSAO, though it is not the standard JME SSAO filter and only requires one extra pass as I believe that the depth map is being rendered in all cases. This has minimal performance increase if I disable it.
@kwando
Dividing the scene up did the trick… I completely spaced frustum culling while I was barreling through the idea.
I haven’t spent any time optimizing the models yet, so this will probably help as well. I think the tiles sets require a total of 18 models… and a LOT of rotation lol… so optimizing shouldn’t take much time. I’ll try that out next to see what kind of help it is.
@EmpirePhoenix
I’m running this on an older gforce card… this is definitely playing into the lack of performance, I just wasn’t expecting the results I was getting (mostly due to not considering culling).
Oddly enough… the test wasn’t really for the sake of playing around with batching. I did the whole thing to test out the particle emitter being used to generate all torches as a single emitter. And then the OCD kicked in >.<
This worked out pretty well. To generate about 150+ torches, it required a single emitter with about 3000 particles to keep the dispersion/effect looking nice.
<cite>@abies said:</cite>
Any chance of sharing the piece of code responsible for generating wall geometry? They look really cool...
Regarding torches - I think that deferred lights would be a real killer on top of that
The tiles were put together in Blender… they could be generated via code easily enough, I would imagine though. If you’re referring the to code for laying out the tiles… generating halls, rooms, etc, etc… I’d be more than happy to put together the project into a zip file and share it with others. It still needs a little bit of cleanup, as I threw it together in like a day or two and it still has some leftover code from first attempts.
I’ll put together a thread for generating the tiles in Blender as well… as it takes no time what so ever to make a tile set that way.
For generating the tiles via code… here is how I would go about it:
Assuming the the tiles are in a 2x2x2 unit cube. You can use scaling past this…
You’ll want to start with a grid that sub-divides into 8x8 squares at -1,-1,-1 to 1,-1,1
Each wall is one square in from the edge… so a single wall would take the verts from z1 through z7 and raising them to +1 on the y axis (doubling up on the verts along position z1).
Now create the verts along the y axis at z1 to create the wall.
Decide on z offests for the wall varts along the side so they always match up
Randomly offset all the other wall verts along the z axis.
Now you’ll want to minimize the number of verts/faces along the floor and ceiling. Don’t worry about connecting all verts when doing this, just get the furthest x, z verts in the area you want to create the faces over and ignore the others.
Anyways… this is how I would generate the tiles programatically… though, this will only work simple tile sets, like caves, castle walls… anything basically squarish… ish…
Couple notes…
Generate 1 wall mesh… clone it and rotate 90, 180, 270… will make things go a lot faster than generating each wall separably (I know… obvious… but… eh… whatever)
Assume the wall verts along the sides have a normal that is pointing directly out along the z axis. Will make generating the normals a heck of a lot simpler
<cite>@zarch said:</cite>
Did you try geometry batch factory? I believe it does directly what you were doing by copying the mesh out of the batch node?
For the torches I’d batch them up as well - then sections can be culled if not needed.
@abies - my first thought was “deferred rendering lighting needed!” as well
I’ve had some odd results with GeometryBatchFactory… though, I’ll give it a go again and see how it does.
I’ll also give the multiple-emitter thing a go and see if there is a difference in performance.
I’m anxious for deferred lighting as well. Lighting makes a world of difference for sure. For now, I think I’ll work with a set number of point lights and move them to new locations based on the camera. At least I can get some idea of what the lighting would look like this way.
my game looks like this, go chop some cylinder trees, build box houses and slay sphere mobs 
