cstatz
commented
3 years ago This could also easily be extended into a cellinoid [Cellino et al., 1989], where you have 6 radii spanning 8 octants. I would add, that I'd prefer separate primitives, since the added shape complexity yield more computational effort, which in turn reduces traversal-time for the simple shapes (sphere).
Is your feature request related to a problem? Please describe. Switching from a sphere primitive to an ellipsoid would greatly improve flexibility of the framework. Should be useful for scientific applications, because spherical bodies are usually only approximations.
Describe a possible solution. An ellipsoid can be transformed to a sphere such that the existing intersection algorithms and so are still useful. The only thing that would need to be changed is a coordinate transformation before the intersection algorithm and the inverse transformation before setting the intersection points and normals.
Furhtermore, the test cases would need to be adapted due to an API change for the sphere. Alternatively, there could be a overload/type alias/... of some kind to provide a sphere with radius R in terms of an ellipsoid. C
Describe alternatives you've considered Leave the Sphere primitive exactly the way it is and create a new primitive.
We should discuss which approach we are going to use.
The first approach would be API breaking, which in my opinion is ok at this stage of the project. The second approach would not be API breaking but would already clutter the code base with unnecessary duplication or similar issues.