Boundings refactor

archive development-discussion-jme2
1

Hey folks,



So a few days ago I’d suggested I would take on refactoring BoundingVolumes to remove the overhead of extending Trimesh. Before I launch into designing that change, a few questions…


  1. Does anyone have an objection to turning BoundingVolume into an abstract class (it’s currently an interface.) This way we can move some code up into that rather than repeating it in each bounding. Originally it was an abstract class (before boundings could be visualized)


  2. I’m planning on adding a Trimesh field to BoundingVolume that would be lazily set on the first call to draw bounds on a given item. Not having to update certain things each frame in Trimesh should make life better for anyone not visualizing bounds. Any differing views on that?


  3. I’m going to look at either adding in the suggestions made on plane checks or optimizing what we have.


  4. Any other optimization ideas out there?



    I’ll start in on this probably Monday afternoon, so give me your thoughts by then. Once I’ve got the design together from your comments, I’ll post on the Code Review forum. Thanks!
2

Your ideas sound fine. Clone should return a BoundingVolume not an Object. It would also look nice if mergeLocal worked the same way that intersection did. IE w/o the instanceof chaining. Remove initCheckPlane (or make it part of the abstract class) Also with your changes, we can merge OBB2 and OrientedBoundingBox.

3
"renanse" wrote:
2. I'm planning on adding a Trimesh field to BoundingVolume that would be lazily set on the first call to draw bounds on a given item. Not having to update certain things each frame in Trimesh should make life better for anyone not visualizing bounds. Any differing views on that?
You can probably try having a static Trimesh for every child of BoundingVolume and rotate/scale it. If you do this then the most Trimesh you would need is three.