Hi all,
I’m working on an open world almost end-less. It’s divided in chunks. I’ve designed a simple manager so that the player can walk in any direction for a long period of time. It’s the classic “scroller”, here is a diagram to help you understand
-------------------------
| | | |
| | | |
|-------+-------+-------|
| | | |
| | x | |
|-------+-------+-------|
| | | |
| | | |
|-----------------------|
Internally I manage a grid of 3*3 chunks. The player is always in the same chunk : the one at 1,1. If he enters the chunk on the left, the grid shifts to the right and 3 new chunks are created, and attached to the scene ; the other 3 are cleaned up.
This systems works quite well but some chunks have more “content”. And when the engine adds too much stuff at once, we experience an FPS drop.
My question is : with JME, what would be the best strategy to handle this ?
The chunks are composed exclusively of com.jme3.scene.shape.Box
; some have a lot ! Also there’s a directional light. LOD is not possible.
Maybe I could design a system that adds x number of Boxes, wait for next tick, then add another x number of Boxes until all is added ? Also, every time the grid shifts, it’s 3 chunks : maybe this could be parallelized, but I read somewhere that doing that is a big no-no in JME…
Also, what causes this FPS drop ? Is it the fact that Nodes are added, or the render of the Nodes ? Thus, would a fog fixes this ?
All feedback appreciated
Updates :
- I was talking about Minecraft chunks, not the voxels per se :
A chunk in Minecraft is a procedurally generated 16 x 16 segment of the world that extends all the way down to the bedrock up to a height of 256 blocks . In other words, a chunk is simply a small portion of your game world that consists of a maximum of 65,536 blocks.
- I’m already using
GeometryBatchFactory.optimize