See if I can repair 3D Quadric Quadric intersection #5
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Wow, there already is code to do the intersection between two QuadricObjects that both happen to be from 3D circles. But it seems to behave strangely, the points keep hiding, sometimes become undefined, and sometimes seem to hit the spurious apparent intersections. But on the other hand, the bulk of the time they seem to be something reasonable. See if it’s possible to work with them and get them more solid like other intersections. This would greatly decrease the importance of doing something like #4.
A subissue or sideissue of this is that right now the code is assuming that any quadric through 3D points is actually a 3D circle, which may not be valid: a user could define a quadric on any five 3D points, violating that assumption. It would be better to have a definitive marker that this is the case; I think the ideal would be to fix #4.
However, in the interest of muddling through to attachable dodecahedra without doing too much at the moment on this project, perhaps we can just get things working better under the present assumptions.
OK, so the two intersections are definitely there, and in a reasonably large portion of perspectives, they are actually correct. Other times they have incorrect coordinates, as far as I can see always the incorrect Z coordinate (but that may be an artifact of the example I am using having the intersection of the two planes of the circles being perpendicular to the XY plane). And essentially all of the time after any move or update they are hidden, which is not too surprising as there is only code to hide them, never any code to show them.
Also, as far as I can tell, the code at the beginning of the block in QuadricQuadricIntersection once it has detected an intersection of two 3D circles is just some kind of back-lifting of the 2D intersection points into 3D, which I think makes it completely useless and deletable.
I think the toggling of non-validity of the 3D intersections has to do with the “Rank” (bad choice of word for what I think is just the disambiguating selector) of the intersection and it hopping around between the spurious apparent intersections and the “actual” ones. So I think a good first step would be to get a handle on that, perhaps by actually un-hiding the intersections when all goes well.
Another point is that it seems to me that this whole computation is being re-done on every rotation, whereas the intersection really only changes when the underlying 3D points change their 3D coordinates. Therefore, the intersection should cache the underlying circles and only redo the computation when those coordinates change.
If we do that, then it won’t matter if there are potentially expensive function calls in the computation, we will be doing it more rarely.
If we get to the point of trying to debug the computations of the intersection points, see if it’s possible to access the javafx.geometry.Point3D class and use that for the 3D computations (for sanity’s sake!)
Eh, the code is confused because it thinks there should be four intersections between two quadrics, but if they are really 3D circles, there can only be two. This is where the fact that 3D circles are misclassified as quadrics is really biting us. So maybe it is better to implement as a new sort of circle object (#4).
Plus there is some kind of funky code in the intersection operation in rene/zirkel/construction/Interpreter.java that appears to actually tweak one of the operands in an intersection, apparently to work around some kind of bug in the intersection code? OK, I think it will be easier to do #4 rather than this, closing.