I noticed this bit of code around line 101:
[java]if (tracer.isRayPerpendicularToGrid()) {
// no intersection
return null;
}[/java]
That was causing issues for me because I wanted to intersect a ray being cast directly downwards towards the terrain, so I commented it out, it should probably be done in the live source too, since I don’t think it makes any sense.
Also, when the Collision result is created, the terrain patch should be passed in, since it inherits from geometry it will allow users to check if the geometry is an instanceof TerrainPatch to detect collisions with terrain.
Also the debug system.out.println lines should probably be removed as well.
Also Distance calculations make more sense to me like this:
[java]float distance = intersection.distance(worldPick.origin);[/java]
But maybe my needs are different than the jme vision… I just don’t understand the value of the previous results…
Hi monkeys, I bring this topic up because I encountered the same problem.
Also, when the Collision result is created, the terrain patch should be passed in, since it inherits from geometry it will allow users to check if the geometry is an instanceof TerrainPatch to detect collisions with terrain.
The CollisionResult gets returned with the correct ContactPoint but yields no pointer to the geometry in the terrain case.
[java]CollisionResult r = results.getClosestCollision();
r.getContactPoint(); <-- Works fine
r.getGeometry(); <-- NullPointerException[/java]
Cheers
Hey
Sorry for the late reply. Make sure to post terrain-specific questions and problems to the TerraMonkey group and I will get notified of them automatically.
I just committed a patch to allow for vertical/perpendicular picking. I forgot to implement that piece when I moved it over from jme2. I also added in the terrain patch to the geometry in the collision result.
The distanceSquared value is stored so a square root operation doesn’t have to be computed, which is slow. However the CollisionResults object doesn’t specify that it is distance squared, so it should just be distance. I made that change and committed it too.
Let me know if it is working for you.
Maybe there are meaningless clone() and multLocal() calls.
[patch]
Index: src/terrain/com/jme3/terrain/geomipmap/picking/BresenhamTerrainPicker.java
===================================================================
— src/terrain/com/jme3/terrain/geomipmap/picking/BresenhamTerrainPicker.java (revision 6813)
+++ src/terrain/com/jme3/terrain/geomipmap/picking/BresenhamTerrainPicker.java (working copy)
@@ -87,10 +87,10 @@
TerrainPatch patch = pd.targetPatch;
-
tracer.getGridSpacing().set(Vector3f.UNIT_XYZ).multLocal(patch.getWorldScale().clone());<br />
-
tracer.getGridSpacing().set(patch.getWorldScale());<br />
tracer.setGridOrigin(patch.getWorldTranslation());
-
workRay.getOrigin().set(worldPick.getDirection().clone()).multLocal(pd.cr.getDistance()-.1f).addLocal(worldPick.getOrigin().clone());<br />
-
workRay.getOrigin().set(worldPick.getDirection()).multLocal(pd.cr.getDistance()-.1f).addLocal(worldPick.getOrigin());<br />
tracer.startWalk(workRay);
[/patch]
yep, seems to be that there are. Thanks for the patch mulova, appreciated.
Hi Sploreg,
thanks for the commit. But strangely enough, I don’t always get the geometry pointer. I click on the terrain multiple times at random places and sometimes, even if it’s just some vertices away from the old click, I get the geometry back and sometimes null.
hmm, ok I will look into it.
Thanks for being on the bleeding edge Dodikles 
ok give it a try now; I missed one place in the picker where I had to add the terrain patch.
Yay, that did the trick!
I’m using your terrain class heavily at the moment, so the thanks go out to you! 
Woohoo, glad it’s working now