@remy_vd Thanks. FYI there is a dependency on com.simsilica:sim-math which I understand is pspeed’s. That is hosted on jcenter and not on mavencentral at the moment (at least I couldn’t find it).
I have a year to get it over to maven central. I’m working on other things right now.
In the mean time, it does absolutely no harm (and is a VERY GOOD IDEA) to put both jcenter() and mavenCentral() in your list of repositories in your build.gradle file. (mavenCentral() first).
1 Like
Regarding the use of a PhysicalChunkPager, am I supposed to use the same ChunkManager than the one used for the ChunkPager ?
If yes, there seems to exist race conditions between the pagers working on the same chunk.
If not, some work is duplicated (e.g. mesh generation), no ?
What are your thoughts about that ?
Yes, you should only have 1 ChunkManager in your application. The Pagers use the ChunkManager to retrieve chunks.
What do you mean by race conditions? The pager just tries to attach or detach the geometry of a chunk to the node, in case of the ChunkPager. When the pager tries to attach a chunk that isn’t available yet (the ChunkManager is still generating the mesh for instance) it will skip this chunk and try again at a later stage.
Please note that I wrote those pagers with the simple example applications for Blocks in mind. It might be a good idea to create your own pagers (maybe based on the ones in Blocks) for your game. As the ‘example’ pagers will probably only get you so far.
1 Like
Thanks for your reply.
Indeed, after hunting and solving the multiple origins of NPE, it seems to work fine now with a single ChunkManager.
I have run into an exception with the physics engine while using Blocks. I think it was caused by having a Chunk where every Block had Block.solid==false. (This has happened because the chunk is composed entirely of Water blocks)
I am using the latest Minie (4.2.0) for the physics engine.
java.lang.IllegalArgumentException: Must have at least one triangle.
at jme3utilities.Validate.require(Validate.java:923)
at com.jme3.bullet.collision.shapes.MeshCollisionShape.<init>(MeshCollisionShape.java:175)
This is the line in my code where the exception happens (I am using my own custom Physics pager)
meshCollisionShape = new MeshCollisionShape(chunk.getCollisionMesh());
My current workaround is to catch the exception and ignore it.
In the past there was a similar issue when a Chunk had no blocks at all. I think that issue was fixed.
1 Like
As the exception message indicates, Minie does not allow a MeshCollisionShape with no triangles. This is a limitation of the underlying Bullet code and something the Blocks library will have to deal with, perhaps by not creating a collision object for such chunks.
Are you using the latest version of blocks? I remember this issue and I think it was fixed. I’ll have a look at it on sunday when I have some spare time.
Edit: I check for an empty mesh in the pager itself. As you are using your own pager, you just need to check the mesh and skip it if necessary.
2 Likes
Thank you both for the prompt reply. I’ve added that check to my pager code and it’s working correctly now.
2 Likes
I have added water / sea to my application. It works great, but it has these very obvious “grid” patterns, at the edges of each Chunk. (see screenshot)
Can anyone suggest a way to remove this “grid” pattern from the water, and so make it look better?
I am using the standard Water block from Blocks (BlockIds.WATER).
Something is wrong if it’s trying to draw the surfaces between chunks… that’s going to be a LOT of wasted quads.
indeed, looks like it remove unseen quads within chunk, but not between chunks.
@remy_vd wasnt it also removing quads between chunks?
Is this anything to do with ChunkManager.triggerAdjacentChunkUpdates ? Because I have that currently set to false.
could be
Correct. Blocks also removes quads between chunks. More precisely put, when looping over the blocks in a chunk to generate the mesh, it actually loops over the blocks + 1 block of each adjacent chunk.
There is however a catch. When the adjacent chunk of the chunk currently having its mesh generated isn’t available yet (eg. it is still in the queue for generation), the side quads are indeed rendered as at this point in time Blocks doesn’t know if there ever will be an adjacent chunk or not.
That is what the flag triggerAdjacentChunkUpdates does. When a chunk is rendered, it notifies the 6 surrounding chunks. These 6 chunks then check if their mesh should be regenerated or not.
So either you use the flag and the chunk will be regenerated. Or you should make sure that all chunks are available before starting the mesh generation.
edit: if I ever should write a v2 of Blocks, I would probably make a chunk hold one row of blocks more then the actual size. So a chunk of 32x32x32 would actually hold 34x34x34 blocks just to facilitate this looking-over-the-border issue.
3 Likes
This is what it looks after setting triggerAdjacentChunkUpdates to true. (for some reason there is one Chunk that is out of whack. Ignore that).
The main issue for me is that it then takes much longer to generate the scene, as it has to regenerate a lot of chunks, possibly multiple times. This was the reason I turned triggerAdjacentChunkUpdates off in the first place. It would be great if I could get this behaviour but still only having to generate each chunk once.
As you hinted, maybe this requires a new architecture (Blocks 2.0).
It is good to know more about how Blocks works. Thank you all for the answers.
How do I do this?
Make sure the ChunkManager has all the chunks in the cache that the pager needs for rendering the scene.
If you are rendering a scene of 9x9x9 chunks, the ChunkManager should have those 729 chunks in the cache.
There is no way around re-rendering chunks if half of them are missing when you start. A new version will not fix this.
1 Like
A new architecture could generate the chunks on demand where “on demand” includes “when the geometry generator needs a neighbor”. Two layers.
Mythruna/MOSS goes one step further and bakes the visible side information into the chunk data… which still requires neighbor chunks to calculate so there are two phases: raw chunk generated and chunk masked. But upon subsequent edits, you only have to adjust the mask for the block neighborhood being edited.
Making chunks +2 all around turns out to be a lot of data, by the way. (Tried that in the Mythruna early days.)
Hopefully someday soon I will get the MOSS block world stuff ready to release publically. May not happen until June, though, the way my schedule keeps slipping.
2 Likes
Thanks for the tip. I haven’t tried it yet, but it seemed like a good idea in my head 