Terrain Grid and Ray Casts

Summary of logic for the background:
I have a racing game and tried to create a beizer-curve and terrain quad based world. (JME 3.0 stable)

First a create the terrain using the diamond-square algorithm (working well).
Then i create randomly generated beizer curve nodes, if they are over the terrain move the node to the height of the terrain using terrain.getHeight(x,z).
Next step is generating the beizer curve roads which is basicly generate some quads and doesn’t need the terrain.

The last step is to move the terrain under the road to the height of the road quads (minus some) using a ray cast from height above the terrain looking for anything named “Quad”.

The questions are:
How do I make the ray casting work better so the terrain doesn’t comes through the road? (like at 0.08 sec)

How do i prevent the terrain from causing weird horizontal beams when the terrain is at a 45 angle to the road? (harder to explain)

Changing the terrain height near the edge and then casting a shadow over the edge causes an internal bullet error, does any one recognise this?

The result can be seen here:

Code can be seen here (and exclusively in this folder of the repo, yes its mostly copy paste for now)

Game can be played from here: (requires java 8) (and also has a lot of bugs)

Jake Murphy

Some other notes:
I have looked into ray casting in JME 3.0 and how it has some issues on points like 0,0 and exactly normal to the surface.
This suggests normalizing the ray: Need help with terrain and ray collision
And another suggests updating JME.

Yes, well, several bounding box collision related things were fixed at some point.

I did read a post about the bounding box collisions being fixed in an update.
I have now updated to 3.1-beta1 still have all the above problems.

For the third one the terrain looks like a bite was taken out and touching any point in that causes the error:

SEVERE: Uncaught exception thrown in Thread[jME3 Main,5,main]
java.lang.ArrayIndexOutOfBoundsException: -1 at com.bulletphysics.collision.shapes.TriangleShape.localGetSupportingVertexWithoutMargin(TriangleShape.java:98)
at com.bulletphysics.collision.narrowphase.GjkPairDetector.getClosestPoints(GjkPairDetector.java:141)
at com.bulletphysics.collision.narrowphase.DiscreteCollisionDetectorInterface.getClosestPoints(DiscreteCollisionDetectorInterface.java:69)
at com.bulletphysics.collision.dispatch.ConvexConvexAlgorithm.processCollision(ConvexConvexAlgorithm.java:127)
at com.bulletphysics.collision.dispatch.ConvexTriangleCallback.processTriangle(ConvexTriangleCallback.java:163)
at com.bulletphysics.dom.HeightfieldTerrainShape.processAllTriangles(HeightfieldTerrainShape.java:218)
at com.bulletphysics.collision.dispatch.ConvexConcaveCollisionAlgorithm.processCollision(ConvexConcaveCollisionAlgorithm.java:86)
at com.bulletphysics.collision.dispatch.CompoundCollisionAlgorithm.processCollision(CompoundCollisionAlgorithm.java:120)
at com.bulletphysics.collision.dispatch.CompoundCollisionAlgorithm.processCollision(CompoundCollisionAlgorithm.java:120)
at com.bulletphysics.collision.dispatch.DefaultNearCallback.handleCollision(DefaultNearCallback.java:55)
at com.bulletphysics.collision.dispatch.CollisionDispatcher$CollisionPairCallback.processOverlap(CollisionDispatcher.java:236)
at com.bulletphysics.collision.broadphase.HashedOverlappingPairCache.processAllOverlappingPairs(HashedOverlappingPairCache.java:190)
at com.bulletphysics.collision.dispatch.CollisionDispatcher.dispatchAllCollisionPairs(CollisionDispatcher.java:247)
at com.bulletphysics.collision.dispatch.CollisionWorld.performDiscreteCollisionDetection(CollisionWorld.java:150)
at com.bulletphysics.dynamics.DiscreteDynamicsWorld.internalSingleStepSimulation(DiscreteDynamicsWorld.java:378)
at com.bulletphysics.dynamics.DiscreteDynamicsWorld.stepSimulation(DiscreteDynamicsWorld.java:339)
at com.jme3.bullet.PhysicsSpace.update(PhysicsSpace.java:349)

It’s weird that bullet is involved in a ray cast at all. JME can answer that sort of question without involving bullet… likely more efficiently, also.

The exception above is related to the old jbullet.jar file that was included in 3.0 stable.
Does 3.1-beta1 have an equivalent? I tried using the one in /opt/native-bullet/ but it didn’t seem to have all the classes i use. (Edit: like RaycastVehicle)

The other problems are JME things im using Node.collideWith(Collidable, CollisionResults) (line 292~ of link file) to get the results of the ray casts.

Just for reference what the terrain looks like at the edge.
Now this is probably because i am just randomly calling terrain.adjustHeight(List{Vector2f}, List{Float}) on all the points under all of the road.

Just trying to add what ive tried to fix this with for context.

So after generating the ‘random’ terrain heights i flattened it to always be the height of 10. But for some reason the terrain had no collision, so changed it to “height = 10 + x / 10” which should make a slope up to positive x and fixed the physics collision.
But it made a stepped terrain that jumped up was flat except for a step every 10. So its being stored not as the float i give it. Which means its possible that the ray casts were fine but setting the height of the terrain wasn’t.

Is there any way around this?

Edit: It also seems that sometimes the terrainquad.getHeight method returns NaN if there is nothing there which may cause the weird edge bug seen in the previous picture.

Okay my bad, dividing by integers gets you integers not floats…
It also seems to have fixed the edges crashing, although im not really sure how.

Unless you care about the bug with the edges, you can consider this closed.