I am trying to make a voxel engine in JME3 and it is going well but I would like to improve FPS since I am only reaching 18FPS with rendering distances that are far smaller than Mythruna or Minecraft. Even after I disable post processing such as water, the FPS remains the same. Looking up at the sky, which has less geometry, does not improve the FPS either. The only way I see an FPS improvement is if I lower the draw distance (which means less chunks are attached to the scene at any given time.)
I use GeometryBatchFactory to compress chunks together and all of the geometry uses a since material generated from a single texture, passed by reference. Here are stats:
I noticed that the vertices are at 500,000 in the first shot and it is recommended to only have 50,000 vertices at any given time. However, you will see that in the second screenshot, the vertice count is very low but I still only achieve 18 FPS. (Like I said, lag is COMPLETELY dependant, both ways, on how many chunks, or geometry, are attached to rootNode.)
After testing my code, the only lines of code that significantly lag are rootNode.updateGeometricState() and rootNode.updateLogicalState(tpf) and they are causing this 18FPS since together they take over 35ms. They seem to be scanning all of the objects that are attached to my scene (which is a lot of objects) and this is completely unnecessary!
How do I approach this and get around the limitations of updateGeometricState ? I cant seem to flag rootNode to do less junk calculations on the voxels. I thought about only calling updateGeometricState on the voxel node right after the voxels are edited, but you cant uGS different parts of a scene at different times.
My cullmode is indeed set to dynamic. I do not know what you mean when you ask if my geometries have bounds generated. I do GeometryBatchFactory each chunk which bumps me from 1/10 a FPS to about 20 FPS
I disabled some post processing to get my stats to look nicer. Compare my stats in the first image with the stats of somebody elses JME3 voxel engine… All of my stats are lower or very close to his, but I get 17 fps while thy get 500fps. How is this even possible? I have a very modern new GPU and CPU.
Hm are you 100% sure that the actual rendering is causing teh slowdown not any other code like a controller update stuff or similar? Cause from the first impression I would say you avoided most of the d3efault errors on block terrains.
Empire Phoenix, yes I am 100% sure that some other code is not slowing down the game. When I reduce the number of chunks attached to the scene from ~70 to ~10, my FPS skyrockets up to 150FPS and I have code in the update loop that reports how many nanoseconds it took from the beginning of the loop to get there.
Check this out: The last 2 lines of my update loop are rootNode.updateGeometricState() and rootNode.updateLogicalState(tpf). The update loop makes it up to those two lines in 3ms. Then, it takes the update loop 40ms to execute those two lines of code, (about 20ms each! )
@admazzola said:
Check this out: The last 2 lines of my update loop are rootNode.updateGeometricState() and rootNode.updateLogicalState(tpf). The update loop makes it up to those two lines in 3ms. Then, it takes the update loop 40ms to execute those two lines of code, (about 20ms each! )
He was also rendering a scene with many objects and his updateGeometricState was taking forever too. I am not sure what was done to remedy the issue.
The reason those methods will take a lot of time is if you are moving children every frame or have a lot of controls attached to your spatials that are doing work. updateLogicalState() calls all of the controls of every object. updateGeometricState() makes sure that all of the transforms are up to date. It there is nothing to do then these are nothing more than a scene graph traversal. Though depending on how your doing your timing (manually versus in profiler) the results at 20 ms could be completely erroneous.
pspeed, I think you may be right in saying that my manual timing results are erroneous because in the Profiler, it is saying that 20% of time is being wasted on Node.collideWith. I will look into this further and report back.
@admazzola said:
pspeed, I think you may be right in saying that my manual timing results are erroneous because in the Profiler, it is saying that 20% of time is being wasted on Node.collideWith. I will look into this further and report back.
Is your world made up of boxes just batched together? Or is it made up of only the visible quads? The first way will never get you very far as you’ll often be rendering and managing 4-5x as many quads as required (or more).
Interestingly, JVisualVM is now saying that most of the lag is caused by RenderManager.renderShadow() even though I tried the most I could to remove all shadow code. Maybe some is there by default? I disabled all lights in my code and set shadowmode to none. What else can I try?
<cite>@pspeed said:</cite>
Is your world made up of boxes just batched together? Or is it made up of only the visible quads? The first way will never get you very far as you'll often be rendering and managing 4-5x as many quads as required (or more).
While you are in generally right, the posted case should work fine if its not doing anytihng really strange, as the counts are quite low actually.
Why do you do updateGeometricSTate and logicstate? are you extending Application or simplepaplication? If application show the update loop.
I am extending Application. It is just a bunch of calls to functions and then rootNode.updateGeometricState(); . Like I said, it takes about 3 ms to get to uGS and then that call takes 20ms which lags my game. I would be happy to bring it down below 10ms so then I could actually get 60fps. In debug mode, I stepped through the lines of code and it seems like uGS is just checking all of the ancestors (and ancestors ancestors… etc…) of rootNode to see if they have to be updated. Since there are TONS of Spatials (being a voxel engine), this is taking forever. If my game was no voxel based and just had a few hundred models, this would be a different story. I just wish I could combine all those spatials together into one big spatial so uGS wouldnt have to loop as much. Is there a way to do that? I thought GeometryBatchFactory would do that but it seems like it isn’t.
Since there are TONS of Spatials (being a voxel engine), this is taking forever.
Wrong. In a voxel engine, you have to put all of the quads into one big mesh - You don't have each quad as an own spatial.
You create one big mesh out of your chunkdata and put it in one geometry.
@admazzola said:
I am extending Application. It is just a bunch of calls to functions and then rootNode.updateGeometricState(); . Like I said, it takes about 3 ms to get to uGS and then that call takes 20ms which lags my game. I would be happy to bring it down below 10ms so then I could actually get 60fps. In debug mode, I stepped through the lines of code and it seems like uGS is just checking all of the ancestors (and ancestors ancestors.... etc...) of rootNode to see if they have to be updated. Since there are TONS of Spatials (being a voxel engine), this is taking forever. If my game was no voxel based and just had a few hundred models, this would be a different story. I just wish I could combine all those spatials together into one big spatial so uGS wouldnt have to loop as much. Is there a way to do that? I thought GeometryBatchFactory would do that but it seems like it isn't.
Andy
If there are tons of spatials then you are doing something wrong. You said you were batching so I took your word for it… and thought your stats indicated that also.
…but since you are extending application directly instead of extending SimpleApplication (the recommended way) it is hard to tell what other odd things might be happening.
So, how exactly are you batching them? If you batch all of your quads then you should end up with just one spatial of the batched objects.
Actually, now these stats seem a little troubling:
You said you had one material with one texture… how does that simple view end up with 15 textures and 203 visible objects?
And 268k triangles for those 203 objects seems high also if you are really removing the hidden faces. That’s about 1320 triangles per object… 660 quads. Something is getting batched, I guess. But I cannot figure out how there is possible 134k quads in this simple scene: http://i.imgur.com/aaRx8Gx.png
How are you measuring the time spent in updateLogicalState and updateGeometricState? If you are using currentTimeMillis() then subtract 15 ms since that’s sometimes the minimum resolution… or use nanoTime().
Also, you shouldn’t have to “remove shadow code”… if you don’t add the shadow stuff then you shouldn’t have shadows. I think we will need to know a lot more about how you are doing things to understand why your results are so strange.
@admazzola said:
How would I go about doing that? I hoped that GeometryBatchFactory.optimize would do the heavy lifting for me : /
Well, one thing you could do is traverse your scene graph and count the spatials (all nodes and geoemtries)… I suspect the count is not so high. If it is then you have something to look into.
Also, we have asked this before without a clear answer… what controls have you attached to your spatials? Also, what app states are you running? Do you have physics running? How is performance if you turn physics off? How is performance if you don’t add any controls, etc.?
