Blocks

Would it make sense to pre-calculate a collision shape for each Page before the application is launched?

Thanks for the info!

I never encountered this issue in the small examples I used. The bullet collision mesh creation must be heavy for large or detailed chunks. Glad you got it solved!

Edit: if your physics are running in another thread then your physics pager should probably run on that thread. Or enqueue the modifying operations on the physicsspace if you run the pager from another thread then the physics thread (I don’t know if this is thread safe in bullet, so maybe not necessary).

@remy_vd The only code I am running on a background thread is the call I outlined above:
PhysicsRigidBody physicsRigidBody = new PhysicsRigidBody(new MeshCollisionShape(chunk.getCollisionMesh()), 0);
Everything else still runs on the jMe3 main thread, as before. The actual call to PhysicsSpace.addCollisionObject is still done on the main thread.

I am not sure if I have large or detailed chunks (how do you measure that?). The chunk size is 32x32x64h. It is Minecraft style (mountainous) terrain. One thing I should note is that my chunks are ‘hollow’. i.e. the soil is only 3 Blocks deep; below that is empty space.

I just ran some timings and most Chunks are taking 100-150 ms to create the MeshCollisionShape. With a 3x3x3 grid, I have to calculate 9 chunks when changing page. So you are looking at around 1 second of computation time each time it changes page. The pauses I was seeing weren’t that bad; perhaps 500ms max; but certainly enough to interrupt the smooth flow of a game.

In my case, the world is around 1000x1000 chunks. So that would be 1 million collision shapes to calculate. And the terrain data is downloaded on-the-fly while the application is running.

Alternatively, you might have a procedurally generated (infinite) world, e.g. like Minecraft. In which case you couldn’t know which areas to precalculate.

Hi @remy_vd

It will be nice to add a foam effect like this to FluidFilter. :slightly_smiling_face:

Implementation details:

Regards

2 Likes

that looks nice indeed. There is already (albeit rather basic) foam effect in the Fluid filter.

You see the effect at the edges and where the spheres are above the water.

Yes, I know. Mostly I am talking about these randomly generated bubble things on the water surface

Screenshot_2020-12-08_15-27-48

1 Like

I don’t mean to interrupt the main conversation, but I have a quick question. How can I freeze the player or prevent them from falling infinitely when they jump into a location where the chunk is in the progress of generating? Ex: when I start my game, the chunk below the player isn’t instantly loaded so they fall forever.

1 Like

hi, i belive you are the person from discord. there can be many solutions:

  1. If chunk physics is not generated, create invisible collisionBox for all chunk so player is unable to enter there.
  2. when chunk physics is not generated, teleport player to highest position when possible.

etc.

  1. But generally you should never allow that situation to exist, so for example you can make loading screen(when game start or player teleport somewhere) before chunks are generated and freeze physics and unfreeze when all near chunks are loaded.

you mean you merge two same edges? I mean are those quads/square separate quads? I borrow the Blender term for edge. in blender two edges can have same translation, location and rotation.

No, a quad/square is a mesh object. Blocks creates 1 mesh for an entire chunk.
If you have multiple squares next to each other, blocks will create 1 mesh object of those squares. The ‘joined’ line between two squares is not merged.

for example, picture the following 2 quads:

A ... B ... E
.  \  .  \  .
C ... D ... F

Blocks will create 4 triangles (ACD, ADB, BDF, BFE) for this mesh.

1 Like

Is it how jME do? What I know is more polygons are heavy. what I think is double polygons might slows down the performance. For example triangles ADB and BDF have DB and BD as two edges with the same size, place, and angel. if we can merge them, that might speed up the load.

Edit: probably my theory is not correct. Note blocks still great though. the game using block i am working on it is not that big and still load nicely so far.

I don’t think your reasoning is correct, a vertex is not the same as a mesh. There are no duplicate meshes (or polygons) in Blocks as you explain. The fact that the 2 vertices are not shared in the example above (B and D) is really negligible. This would also make the mesh algorithm extremely difficult if you don’t want to duplicate these coordinates. Don’t forget that a vertex also has a normal, uv coordinate, tangents, …

The above example is 1 mesh of 12 vertices and 4 triangles.

Because i am thinking like using Blender. In blender a single vertex is possible without creating an edge. and an edge by connecting two vertices is possible, without creating a face. and we make a face by connecting three vertices in minimum. however it’s just a thought. maybe not a big deal.

remember that Blender technical vertex can be something else. You dont know how technically it looks like in Blender. (thye dont even need merge edges since it looks same)

for example in software, you can make vertex to be visible as “point” or “sphere”, but technically its “nothing”. They just show it since its Modelling tool so you need see it.

IMO you should read about OpenGL VertexBuffer here and read about drawTechnique/etc - generally OpenGL here.

however, then I realize this. I’ve seen hair or maybe grass made of edges. If so, edge without face can’t be nothing. not ever try to export it to jME though.

Probably not. OpenGL can render lines but they are ugly and inefficient. They would make the ugliest hair or grass… always 1 pixel wide no matter the distance, etc…

You should take the advice and learn about OpenGL mesh information rather than taking your direction from a tool that can make feature films.

understood. i was just getting confused with those vertices i guess.

Are there any plans to move Blocks to mavencentral now that jcenter is closing? It looks like existing libraries on jcenter will still be downloadable for another 12 months so there is perhaps no immediate urgency. On the other hand it would be good to have jmonkeyengine and Blocks hosted at the same place.

1 Like

Yes, I’ll move it to another cdn and post an update here. Just have not got to it yet.

2 Likes