EDIT: PullRequest with possible fix
I’m using the JME3.1-alpha4 with native bullet (not jbullet). When using the rayTest it returns the results on a ordered linkedlist (order by collision with the ray) and sometimes it returns the same list but inverted.
The use:
List<PhysicsRayTestResult> results = physicsSpace.rayTest(start, end);
Possible results without any found pattern:
obj0, obj1, obj2, obj3
obj3, obj2, obj1, obj0
I tested it making many raytest from-to the exact same location on an unvarying scene. The results are the precedent. Is this a bug or an expected behavior that I don’t understand?
The results are passed verbatim in the order given by Bullet. I am guessing they do not enforce any ordering.
Should be possible to fix on the jME side by sorting on hitFraction. If you want, you can make a pull request on GitHub to do that.
Well, looking at the results I would say that they have an order, but sometimes just the inverted one (as it is a list it can be used backwards when the first element’s hitFraction is higher than the last).
I’m not sure how critical is the performance there, should it be reversed always? (having in mind it is a linkedlist it should be enough with changing the chaining when it is inverted), or should it be let to everyone the choice to sort it or iterate it in the given order?.
It also could be added another method rayTestPerf() that doesn’t order it and make the default rayTest be compatible with the jbullet code.
I was actually thinking we could add support for closest raytest method which only gives the closest result. In many cases you don’t care about any other result except the closest one and bullet probably has some optimizations when you do that kind of raytest.
As for sorting, I don’t see why we shouldn’t do it. Doing the actual collision detection consumes a lot more CPU time than sorting a small list.
1 Like
