Thank you! Unfortunately, Bullet doesn’t handle empty mesh shapes.
For Minie v2, I’ll add argument validation to catch this condition before it causes an access violation.
2 Likes
@sgold Here is the stack trace with the ACCESS_VIOLATION
--------------- T H R E A D ---------------
Current thread (0x000000c39f9f1800): JavaThread “jME3 Main” [_thread_in_native, id=9352, stack(0x000000c3a5e30000,0x000000c3a5f30000)]
Stack: [0x000000c3a5e30000,0x000000c3a5f30000], sp=0x000000c3a5f2e910, free space=1018k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [bulletjme.dll+0x16372d]
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j com.jme3.bullet.collision.shapes.MeshCollisionShape.createShape(ZZJ)J+0
j com.jme3.bullet.collision.shapes.MeshCollisionShape.createShape([B)V+30
j com.jme3.bullet.collision.shapes.MeshCollisionShape.<init>([Lcom/jme3/scene/Mesh;)V+35
j com.rvandoosselaer.blocks.PhysicsChunkPager.createPage(Lcom/rvandoosselaer/blocks/Chunk;)Lcom/jme3/bullet/objects/PhysicsRigidBody;+39
j com.rvandoosselaer.blocks.PhysicsChunkPager.createPage(Lcom/rvandoosselaer/blocks/Chunk;)Ljava/lang/Object;+2
J 6893 c1 com.rvandoosselaer.blocks.Pager.attachPageAtLocation(Lcom/simsilica/mathd/Vec3i;)V (74 bytes) @ 0x000000c3899fe3ec [0x000000c3899fdac0+0x000000000000092c]
J 6049 c1 com.rvandoosselaer.blocks.Pager.update()V (25 bytes) @ 0x000000c3897fc654 [0x000000c3897fc3c0+0x0000000000000294]
j com.rvandoosselaer.blocks.PhysicsChunkPagerState.update(F)V+4
J 6823 c2 com.jme3.app.state.AppStateManager.update(F)V (101 bytes) @ 0x000000c39043031c [0x000000c3904300c0+0x000000000000025c]
j com.jme3.app.SimpleApplication.update()V+77
j com.jme3.system.lwjgl.LwjglAbstractDisplay.runLoop()V+22
j com.jme3.system.lwjgl.LwjglCanvas.runLoop()V+222
j com.jme3.system.lwjgl.LwjglAbstractDisplay.run()V+136
j java.lang.Thread.run()V+11 java.base@11.0.7
v ~StubRoutines::call_stub
siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), writing address 0x0000000000000000
1 Like
I can’t find much documentation about how to implement multiple texture support. One of the main features in the format I’m trying to implement is the ability to specify different textures for use on different faces of the block. Where should I start to implement this?
Textures are ‘positioned’ with uv coordinates in the mesh. Each vertex has one uv coordinate.
In blocks you can find all this code in the Shape implementations. By default Blocks support a single texture (same image on all sides) or 3 textures (different images for up, down and side faces).
If you want to have custom uv textures, you will need to create your own shape.
If you just want to have a cube shape with 6 different images, you can copy the Cube shape and adapt only the code that sets the uv textures. The change is really only a couple lines of code.
Just try it out and post your issues here. In the end I might include it as an example as it is a ‘common’ use case.
1 Like
You should use
ChunkManager#addBlockandChunkManager#removeBlockto place and remove blocks
I am confused now. My code is structured very similar to the ProceduralTerrain.java example. I provide my own implementation of ChunkGenerator. Here I implement generate(Vec3i location) method. This creates a new Chunk and adds blocks to the Chunk.
Am I using the wrong approach?
This would be OK, if empty chunks didn’t use the same amount of memory as half filled chunks.
These are some stats from my own application.
Total chunks: 1000 Air chunks: 269 Underground Chunks: 430 Crust chunks: 300
So the chunks I care about (Crust chunks) are only using 30% of the memory. The other 70% of memory is essentially being wasted.
Is it possible to only initialise the Block when you are actually adding a Block to a chunk? (or allow ChunkGenerator to return null)
I have question. I use better character. when I walked my character a bit faster it’s jumping a lot. Seems it’s hitting the edge of the quads, because the quads are separated. beside that, if shot a ball to ground made of blocks, some times it goes trough between quads, or jump to another direction. It must be a big feature request to make those quads not separated. It can be a bug. maybe depends to the game. Or maybe I can configure the physics, I still can figure out. Advice? edit: My question is, is my conclusion correct, about that separated quads? Can I do something? Wait… maybe I set the gravity too low. Sorry. Let me try it again. However, that shooting ball can go trough, that can make a bug, right?
1 Like
Sounds like physics issues to me. Have you tried increasing the accuracy (shortening the physics timestep)? Have you enabled continuous collision detection?
Perhaps a new topic would be in order.
I don’t understand this part. All quads should align perfectly. With a default block scale of 1, all quads should be 1x1 wu and are an appropriate size for collision meshes.
When the quads are very large you might get weird results like falling through the ground etc.
You can counter this behavior by setting ccd. Check the wiki for it.
I’m on my phone now, I’ll update my post later.
no, I didn’t. I am a bit busy to understand PBR too. I am just using the example provided. I modify it by adding character with better character control. I tried adding 8 more chunks around original with the same size, the perfomance fine to me.
Well, I must misunderstood then. I was just guessing. I am just do bulletAppState.setDebugEnabled(true); to see what happens. I think the ball sometimes go trough when hitting a line. The character shaking too when hitting the lines. when I attach a camera to character, the camera shaking when walking.
let me try something again.
edit. Maybe I missed something when creating the blocks. IDK. Like I said, I am just using the example. I removed the bricks and water for space the character to walk.
This can also occur if the velocity of the ball is fast or the size is too small.
For example you have a ball with a diameter of 0.1f going 100m/s - bullet checks every 1/60th of a second. So in one tick the ball is “behind” the surface and in the next tick is is past it - so a collision never occurs.
Continuous collision detection (if enabled) will detect the collision between the ball and the surface, no matter how fast it goes.
1 Like
This is ‘normal’ physics behavior. You can create a mean for the y value to try to decrease the jitter effect.
Or take a look at the chasecamera in jme and see how they handle the smooth motion effect.
The goal is to not directly set the camera location from the physics location.
Also note that many of the character control examples are broken with respect to camera following and will create the look of “jitter” even if physics is perfect.
@remy_vd
re: adding Chunks that are closer before Chunks that are further away.
Perhaps the Pager is a good place to add this logic?
I made this 2 line change to Pager.updateQueues()
protected void updateQueues() {
List<Vec3i> newPages = new ArrayList<>(getPages());
newPages.sort(Comparator.comparingInt(vec -> vec.getDistanceSq(centerPage)));
This will request chunks in order of distance from the player.
I found this small change made a big difference to the perceived performance.
…you guys should consider a PriorityQueue instead of making so many copies.
1 Like
Indeed. The ChunkManager already works with queue’s under the hood. Changing this to a priority queue where the user can set an optional comparator during construction is a small change.
I would not add this logic to the pager, but to the ChunkManager itself.
I’ll make an issue for it on GitHub and see if I can add this to 1.6-beta.
Just keep in mind… with any sorted collection, you don’t want to change the conditions of the sort while the object is in the collection. So, for example, if you use distance as your sort metric then you want to lock that value in when you add it to the queue so that it doesn’t change later. Else the priority queue (or any sorted collection) logic can get all messed up because one time a < b and later b > a.
1 Like
@pspeed Yes that’s exactly why I ended up doing the sort in the Pager rather than the ChunkManager. The sort order will change as the player’s location changes. AFAICT there is no API in java.util.PriorityQueue to “refresh” the sorting of existing elements after they have been added to the queue.
@remy_vd Adding chunks in order of proximity to the player is a more useful default than the current behaviour, which adds the chunks in x,y,z order (essentially arbitrary). Could Blocks provide this functionality out of the box?
In my pager stuff, when crossing a ‘chunk’ boundary, I pause the pager, rebuild the queue, then resume the pager again.
3 Likes