Just wanna ask if there any plans for implementing BoundingPolytope, BoundingSphere, BoundingBox and BoundingLeaf .
BoundingSphere is already implemented. As for the rest, AFAIK engine currently depends on everything being BoundingSphere.
Real question is if all this functionality is really needed ? Bounding sphere has a benefit of being very fast to check, and what even more important, to transform, because it is not oriented. BoundedBox would be nice in case of AABB, but after transforming to world space, it will be not so clean. As for the BoundingPolytope, only benefit for it I can see is to have a good shape for picking - kind of simplified mesh. For FOV checks it is probably an overkill.
BoundingLeaf - no idea, AFAIK there is no scoping implemented currently.
every time I ask about something answer is …well is it really needed? …ok I shall stop asking then and go for a while to jogl and see what is there next spring 
Please remember that I’m not a xith3d developer, so my opinions are in no way official.
So what do you need them for?
If you present a good use case for needing them, I’m sure they’ll get added to the todo list.
Quite possibly the reason you are being asked if it’s needed is because you are the first to need it 
Will.
Hey Daath, do I detect some anger there? We havea huge list of stuff to do, so the question was certainly directed at helping us determine priorities.
Currently there are 3 bounding types supported. Frustum, BoundingSphere and BoundingBox. Internally we convert bounding boxes into bounding spheres when we compute the virtual to world bounds, but you can certainly supply bounding boxes as your shape bounds if you want.
Are you interested in :
-
Using non-spherical bounds for FOV culling?
-
Using them for some sort of internal computations, like constraining a particle system to a non box, non sphere shape?
-
Using them for geometry clipping? (whihc BTW we do not support yet)
-
Some other use?
Dave …anger that’s not me …rather everyday summarization of my luck
Ok then, why would I then care about this …well I just happened to use BoundingPolytope for frustum cullling in my previous code ( plus BoudingSphere) - set planes to it and ask if intersect is in or out - I know there are other ways to achieve same goal, but I just asked, that’s all…if it is not there I shall adapt.
Interesting point Daath,
Isn’t a frustrum culling a given in Xith?
Kev
yes you ask it nicely please cull this quadtree for me every frame ;D and it would do it
but surely it can be done with (at least I hope I have not tried it yet)
.
.
view.extractFrustum( frustum, canvas3d );
Classifier.Classification classify = frustum.classify( boundsSphere );
if ( ( classify == Classifier.OUTSIDE ) ) {
.
.
.
.
in j3d one couldnt use built in FC since TG from which you we re trying to extract planes was not in sync so I use that method and eventuallly run into even simpler way looking in to j3d.org source code . I am just lazy programmer and didnt wanna change much of the existing code that’s all. 
But obviously that is special case and in 99.9% you can leave that activity to xith3d inner working
ok that worked but now I need to exctract “eye” vector components from it - any ideas how?
in another words how should I modify my code to get equivalent of j3d code :
universe.getViewingPlatform().getViewPlatformTransform().getTransform(transform3D);
update 3 ;D
got this one as well. No more questions – for now
Just to let you know, I have started to play with BoundingBox, trying to make it usable. Currently it is broken in many places - interesections, classifications working wrong, data duplicated, new objects allocated everywhere, a lot of methods unimplemented. I’m at the same time doing some corrections in Sphere/BoundingSphere.
BTW, are BoundingBox/BoundingSphere from com.xith3d.spatial.bounds package needed for anything ? They are sure way for introducing some errors when mistaken with com.xith3d.scenegraph versions… They should be at least renamed, preferably removed (after merging).
Agree with abies. They make some confusion.
Yuri
agree as well, the only question is which ones should get removed. I am only guessing that bounding objects will eventually get used for colision detection and if that is a case then I would rather use(leave) those in spacial.bounds package. But that might be just matter of taste.
I plan to make spatial package Box/Sphere objects very smart - containing almost all logic. Then BoundingBox/BoundingSphere from scenegraph package would be just a subclass which would dispatch Bounds interface calls to correct supercalls. With almost all the logic moved to Box/Sphere, there would be no reason to have BoundingBox/BoundingSphere inside spatial package.