I’m not working on another minecraft, but yes, I’m creating the scenario in a similar way
I had a couple of idea (but I’m still doing some tests):
dynamically apply batch grouping
divide my sectors in smaller area, like invisible cubes/zones (containing several blocks), and checking area visibility using rays on area vertex and area center:
[java]
x
x
| |
| x |
| |
x
x
[/java]
I will send a raycast between the player and the "x". I know this method is not perfect, I think it could be a good solution (I still need to check it). I need to check overall performances and visibility problems (in some conditions the objects inside the zone could be visible but the "x" are not, so the zone could become invisible).
The zone will be applied to a node in the sceneGraph, and I will simply attach/detach the node to the rootNode.
Since i’m just beggining to use JMe3, i may be totally wrong. However i’m trying to develop a system with a lot of “boxes” (lego), and had the same problem
if you got so much boxes, you should bot put them directly under root. Each box has to be checked for culling.
What you can do is to create a set of “grouping” boxes under the root, and put your boxes under thoses grouping boxes. The bounding boxes of each grouping will be tested, and if out of sight, the whole grouping content (ie all the box under it) will be culled without checking each node of the content.
I have a 10010010 world, and approx 12000 geometry. I’ve created grouping for blocs of 10102. Instead of checking the 12000 geometry, the system check the 500 grouping boxes, and remove most of them. (this may depend of the view angle, of course)
ahoehma said:
Currently we have the same problem to resolve ... how can we implement an "open world" with caves etc. in JME3.
I think these guys solved the problem : http://ardorlabs.se/ArdorCraft/ -- but how? :D
Interesting find.
Can you confirm that ArdorCraft is a JME3 game?
No, not rays, thats exactly what I was saying, for lots of boxes (think Minecraft) the logic which box can be seen can be determined pretty easily w/o any ray checks (say you are on field 0/0/0 and on 0/0/1 theres a box then you wont see boxes 0/0/2 to 0/0/infinity and you can just cull those. So think about how that applies to your game or w/e (e.g. when you are in room1 you know one cannot see anything from room2).
I understand this approach ... but in details ... how can I implements such culling?
I implemented a simple open-world-manager, the world is separated in chunks, each chunk have a center (Vector3f) and contains N TerrainElements, during rendering I ask the openworldmanager for TerrainElements at players location, for now I return only those elements from chunks around this location (27 chunks around a player) ... that's working nice ... each chunk us 8x8x8 units big and contains 64 TerrainElements (a flat plane in the middle of each chunk) ... so the scene contains always about 700 elements (boxes) ... the fps are "good" ... but the visibility range is quite short ... 16 units in each direction ...
I would like to know how can I improve the visibility range with culling ... what are good parameters for a "nice" visibility range, where should the fog starts, what's with physics-space (are culled elements in the physics-space or not) ...
ahoehma said:
I would like to know how can I improve the visibility range with culling ... what are good parameters for a "nice" visibility range, where should the fog starts, what's with physics-space (are culled elements in the physics-space or not) ...
42
baxxo said:
Can someone more expert than me test that class (GeometryBatchFactory)
It works fine for me, are you sure you use it correctly? The "normal" batching takes materials into account and does not merge Geometry with different material.
The way it works right now isn’t ideal. It doesn’t actually check material equality parameter-by-parameter, but by reference, so it might miss perfectly equal materials just due to that.
In most cases such as models imported from OgreXML or OBJ however make proper use of material sharing so you should get the best optimization using it on those models.
I used combined geometry in other engines also and, when you combine geometry, you get another Spatial which is independent from the original meshes. It means, after you grouped meshes, you need to eliminate the original ones, and will use the combined one:
create 3 cubes
combine cubes (1+2+3) → CUBE_COMBINED
Now I add my CUBE_COMBINED to my scene (sceneGraph node)
another idea come to my mind … is it useful to remove “invisible” geometries and call GeometryBatchFactory with a list of “visible” geometries?
I think this “invisible check” need a lot of CPU power…
A simple check to do is on the model (ie not on the display element) : for a given voxel, check if the 6-neighbours voxels exist and are opaque. In this case, your voxel can not be seen and you can forget to add the corresponding geometry to the scene.
in a fully filled 8*8*8 zone, this would remove 6*6*6 geometry.
Also, i'm playing with the geometrybatch factory. What i'm doing (and that may or may not be useful to you) is the following :
all visible vertex node are grouped into groupnode (chunk of 10*10*2 node) so that culling may be faster.
for each displayed groupnode, except the one the pklayer is on, i'm generating the geometrybatch, and using it.
for the groupnode the player is on, i use a node for each vertex.
when the user change of group, i'm re-generating the geometrybatch for the group i'm leaving (and removing the independant nodes), deleting the batchgeomtry for the group I'm leaving, and recreating all node or this group.
If some effect occurs on a node, a function allow to recreate the node neighbours (ie i'm changing the model, re-cheking visibility for all neighbours, recreating the nodes for each neighbours is if does not exists, and recreating the batch from this if needed)
this work only for terrain, as some objects may span multiples groups.
