Experimenting more with the interesting class HelloIntersection, I’ve discovered what seems to be a bug relating to bounds:
As you can see, the bounds around the small green “bullet” are too big. It seems jme doesn’t like bounds smaller than 1 in radius. Also, there is a weird bound between the bullet and the target (red sphere) that grows as the distance between the two increases, and vice versa.
Also, there is a weird bound between the bullet and the target (red sphere) that grows as the distance between the two increases, and vice versa.
This is the bounding that contains both spheres, i.e. the parent Node's world bound.
We'll test a bounds for values less than 1.
"mojomonk" wrote:
Also, there is a weird bound between the bullet and the target (red sphere) that grows as the distance between the two increases, and vice versa.
This is the bounding that contains both spheres, i.e. the parent Node's world bound.
Hmmm I misunderstood, I thought you were talking about a bigger sphere containing everything, I guess it’s that middle one in your pic. Very odd, I’ll take a look. Is this the normal HelloIntersection? I.e. no modifications from you?
Ok, ran the test, definately a bug in the test. Will look at this over the weekend, but right now I’m off to do some baby shopping. Thanks for catching this.
Man, what is up with BoundingSphere… I think we should rewrite that class for .9 and maybe add a few other bounds types while we are at it.
As a side note, I think the enclosing bounds problem is a relatively new thing (I remember when it properly enclosed the two), but the improper bounding size (less than 1) bug has been there since I started using jME (several months ago).
The bug wasn’t there when I wrote the class. I looked into it, and saw that renase made some changes to the class. I rolled back to 1.23 and the boundingspheres of hellointersection worked as expected. Renase, what were you trying to fix?
Yep… it was a divide by zero issue in the welzl code you copied from the flipcode forums… certain combinations of points can do that in the method. David Eberly even logged in and commented on it later. If you go to: http://www.flipcode.com/cgi-bin/msg.cgi?showThread=COTD-SmallestEnclosingSpheres&forum=cotd&id=-1 and scroll down, he posts a 7 point info list on it.
Not to say my fix was good, but it fixes the divide by zero that was keeping us from showing at GDC. Rollback is not the answer, but maybe a tighter fix from eberly’s suggestions would help.
Why did you change case b=0? I think that’s where the problem’s coming from.
hmm, not sure (3 months of fading memories), but reverting only radius to 0 and leaving the other changes seems to work well. (committed) The real test is to shove a few odd models through it and see if the code breaks again.