Set the ShapeRegistry on the BlocksConfig:
BlocksConfig.getInstance().setShapeRegistry(myCustomShapeRegistry);
Use the constructor if you don’t like to use the builder:
Block block = new Block(name, shape, type, false, false, true);
No, a key is used to link a block with a shape. The ShapeRegistry is used to retrieve shapes from a key.
Thanks for all the help so far. In a previous post, I talked about a helper method someone had made that took a JME mesh and put it into a ChunkMesh, so that your shapes could be modeled in programs like Blender. How would one go about making such a helper method? I’ve figured out how to get the obvious stuff like verts, uvs, and indices into the chunk mesh, but I can’t get the normals and tangents to load in.
To clarify on the confusion before, my code to generate mesh shapes is really complex, so I decided to write it in general JME terms so it could be re-purposed in other parts of the program. That’s why I have a JME mesh that I need to add to the chunk mesh.
This is how I am doing
public static void fillFromMesh(Mesh mesh, Vec3i location, ChunkMesh chunkMesh, float blockScale) {
// calculate index offset, we setUsing this to connect the triangles
int offset = chunkMesh.getPositions().size();
// vertices
int numVertices = mesh.getVertexCount();
for (int vertexI = 0; vertexI < numVertices; ++vertexI) {
chunkMesh.getPositions().add(Shape.createVertex(vertexVector3f(mesh, VertexBuffer.Type.Position, vertexI), location, blockScale));
}
// indices
IndexBuffer indexBuffer = mesh.getIndexBuffer();
for (int ibPos = 0; ibPos < indexBuffer.size(); ++ibPos) {
int index = indexBuffer.get(ibPos);
chunkMesh.getIndices().add(index + offset);
}
if (!chunkMesh.isCollisionMesh()) {
// normals, tangents and uvs
for (int vertexI = 0; vertexI < numVertices; ++vertexI) {
chunkMesh.getNormals().add(vertexVector3f(mesh, VertexBuffer.Type.Normal, vertexI));
chunkMesh.getTangents().add(vertexVector4f(mesh, VertexBuffer.Type.Tangent, vertexI));
chunkMesh.getUvs().add(vertexVector2f(mesh, VertexBuffer.Type.TexCoord, vertexI));
}
}
}
private static Vector2f vertexVector2f(Mesh mesh, VertexBuffer.Type bufferType, int vertexIndex) {
Vector2f vertex = new Vector2f();
FloatBuffer floatBuffer = mesh.getFloatBuffer(bufferType);
int floatIndex = 2 * vertexIndex;
vertex.x = floatBuffer.get(floatIndex);
vertex.y = floatBuffer.get(floatIndex + 1);
return vertex;
}
private static Vector3f vertexVector3f(Mesh mesh, VertexBuffer.Type bufferType, int vertexIndex) {
Vector3f vertex = new Vector3f();
FloatBuffer floatBuffer = mesh.getFloatBuffer(bufferType);
int floatIndex = 3 * vertexIndex;
vertex.x = floatBuffer.get(floatIndex);
vertex.y = floatBuffer.get(floatIndex + 1);
vertex.z = floatBuffer.get(floatIndex + 2);
return vertex;
}
private static Vector4f vertexVector4f(Mesh mesh, VertexBuffer.Type bufferType, int vertexIndex) {
Vector4f vertex = new Vector4f();
FloatBuffer floatBuffer = mesh.getFloatBuffer(bufferType);
int floatIndex = 4 * vertexIndex;
vertex.x = floatBuffer.get(floatIndex);
vertex.y = floatBuffer.get(floatIndex + 1);
vertex.z = floatBuffer.get(floatIndex + 2);
vertex.w = floatBuffer.get(floatIndex + 3);
return vertex;
}
Note, some of the code above copied from Heart library’s MyMesh class:
@Ali_RS Thanks so much. That code worked.
Is there something you need to do to mark a shape as “solid”? Whenever I’m using my custom shape, blocks around it aren’t culled properly, even if the block is marked as solid (using ShapeIds.Cube on the block fixed the issue).
Marking a block as “solid” has nothing to do with culling, it is only for the physics, for indicating if the block will be part of the collision mesh of the chunk.
I guess what you are talking about is the face visibility function.
You need to provide your own function that supports your custom shapes and set them on each and every chunk.
Indeed, as @Ali_RS mentioned solid and culling are two different concepts.
Marking a block as solid, only adds this block to the ‘physical’ mesh, the mesh used for physics simulation.
If you want your custom block to cull faces of the blocks around it, you should adapt the faceVisibleFunction on the Chunk: Chunk#setFaceVisibleFunction.
The default behaviour of the function is written in the javadoc.
Is there a use case where one chunk might want to have a different face visibility function?
What about making it a global config by moving the method into BlocksConfig? (Just like what you have done for ChunkMeshGenerator.)
Rather than setting the same function on each and every Chunk, it can just take it from BlocksConfig.
No. It is an obvious error/oversight on my part. Reading your comment that you need to set it on every chunk surprised me 
I’ll create a patch for it on the latest release, changing it to a static parameter.
edit: I released a new version of Blocks v1.6.2 with this fix.
I think I see an issue with the way the the different Pagers call chunkManager.removeChunk() in the Pager.detachPageAtLocation() method. The issue occurs when you have 2 Pagers with different grid sizes sharing the same ChunkManager e.g. a ChunkPager and a PhysicsChunkPager. In my case the PhysicsChunkPager has a significantly smaller grid than the ChunkPager.
When a chunk in the PhysicsChunkPager is no longer inside the PhysicsChunkPager grid, it gets put on the pagesToDetachQueue and subseqently sent to the detachPageAtLocation() method. In Pager line 223, there is a call to chunkManager.removeChunk(pageLocation);
The issue is that the chunk in question may still be inside the ChunkPager grid (if the ChunkPager has a larger grid size), even though it is no longer in the PhysicsChunkPager grid. In that case it shouldn’t be removed from the ChunkManager until it is outside both Pager grids.
That’s indeed correct.
The thing is, I actually created the pager implementation to help with all the examples I released to demonstrate Blocks. It was never meant as a fully tested game-ready implementation. But it somehow ended up in the main module and not in the examples module.
I should think a bit more on this subject, if I want Pagers to be part of Blocks or not.
If not, it will be moved to the examples module and stay there. Otherwise they should be adapted and tested for different uses.
Do you have a plan any further with water? For example foam and water flow. Or how do we do that, in simple explanation? if see this discussion River using the PostProcessWater(ocean/lake) - #20 by shamanDevel , looks like somewhat difficult or impossible.
I don’t really understand how does it work. Is it possible to do WaterFilter or SimpleWaterProcessor on a Chunk?
There is a FluidFilter that has foam, mirror and distortion effects. There is an example for it:
What is unclear for you? The jme built-in waterfilters render a plane at a certain height and add some effects to simulate water, if I’m not mistaken.
You can use these in Blocks without any issues instead of ‘water blocks’.
I have tried that water example actually. I just didn’t take a look any closer. The waterFilter too. sorry about that. let me try those again.
sorry if a bit off topic. About WaterFilter. it’s a plane right? if I want under water building, like lab or something, the character from above sea level can go there with elevator or something. if I use sea monkey for the ocean, i can’t make the room of under water building clear from water, right? I need to consider other water system right?
I think they do some under water effect yes. So if your lab is below the water surface, you will have this effect even if you are indoors.
Can’t you disable the filter when you enter the lab?
You can, but if you have a window or something it will be apparent that you’ve done that. Water physics is what you want. I don’t know if blocks supports water propagation or not.
I understand. maybe I can disable the water filter. of course I want window, that’s the idea why I put the building under the sea. now, let me learn more about that. thanks.
Edit: I just want to add this really quick. Including like when in a boat. been never tried this. even in a small boat, some part of the boat must under the sea level right? must be weird if inside boat filled with water.
I am porting my Blocks application to Android. It is working well so far.
One thing I found was that out of the box, Blocks requires at minimum Android API 26. The requirement for API 26 was solely due to a couple of (trivial) uses of the java.nio.file.Paths class in the TypeRegistry class.
By changing these 2 lines of code in TypeRegistry.java to not use the Paths class, I was then able to run Blocks on Android API 24.
FWIW, according to Googles collected stats, API 24 is supported by 73.7% of devices, whereas API 26 is supported by 60.8% of devices.
@remy_vd
I realise the Pagers aren’t necessarily maintained / supported as part of core Blocks. Nevertheless, I thought I would pass on details of an issue in the PhysicsChunkPager in case others using the PhysicsChunkPager are encountering the same problem.
The symptom I was encountering was regular, very noticeable ‘pauses’ in the UI and drops in frame rate in my application. I noticed that these pauses happened after crossing into a new Page (and so triggering new Page loads) and the pauses also went away completely if I turned off the Physics pager.
After attaching a profiler I worked out the source of the issue.
Line 40 in PhysicsChunkPager
PhysicsRigidBody physicsRigidBody = new PhysicsRigidBody(new MeshCollisionShape(chunk.getCollisionMesh()), 0);
The call to the MeshCollisionShape constructor is very expensive and is happening on the jMe3 main thread. This is the cause of the UI pauses.
This operation should instead be done in a background thread.
I ended up writing my own Physics pager, creating the PhysicsRigidBody objects in a background thread, to fix this. The UI is now smooth with all pauses gone.