Cleaning up Renderer Interface

archive development-discussion-jme2
21
  1. Remove the Clone stuff.



    Done.


  2. Switch to UIText (some profiling will need to be done to make sure there is not any performance issues here).



    Further discussion needed.


  3. Remove Tint (this can be handled with the RenderQueue now)



    Done.


  4. Remove the get*State()



    Done.


  5. Remove the old Model loading code so it only uses cep’s.



    Working on it.


  6. Move intersections into BoundingVolume and subclasses.



    Haven’t started yet.

After looking over UIText, it doesn't look like it was designed to do quickly changing text (FPS display, etc). If Guurk is around, let me know if that is accurate. If so, I'd like to move the font class into the ui package and clean up the rendering of it some.
22

Model loading has been cleaned up.

23

Starting on the intersection revamp, then that will be the last of my changes I wanted to make. I’m then going to do a quick and dirty “clean up”, mostly formatting, and check in. We’ll then start with a more formalized method of contribution.

24

Ok, well, actually, I’d like to talk about the bounding stuff a little more. You suggest adding a generic intersect method to BoundingVolume for example:



public boolean intersect(BoundingVolume bv){
  return bv.intersectSphere(this);
}



But because bv is a BoundingVolume as well, that means intersectSphere is part of the interface, as well as intersectAABB, intersectOBB, etc.

The interface now has to know about every implementation to add the method signature. This doesn't feel right.

Any suggestions, should I just push ahead and do it anyways? Comments?
25

Every bounding volume needs to know how to intersect an AABB right? Otherwise jME won’t work right for collision detection. Well if it’s a function that every bounding volume needs to know, then why not put it in BoundingVolume? This also makes adding another bounding volume more obvious. If I want to createa BoundingKTop class, it’s easy to tell I need an intersectKTop and such for everything. The way it is now, I need to dig through various classes to find out where exactly the intersection is, where the ray testing is, where the area testing is, and so forth.



This is much like the post

http://www.javagaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=Tuning;action=display;num=1090878716

there by princec.

26

Fine by me, just thought it odd that an interface should have explicit knowledge of it’s implementers. So, I thought I’d bring it up for discussion.

27

Ok, another interesting thing I have forgotten… intersections are only supported for like bounding volumes.



Sphere vs. Spheres, box vs box etc

28

Ok, I’m just going to implement as discussed before and for now if it’s two different volumes false will be returned. We can implement them later. I just want to get this done to move on to the clean up so I can focus on the Policy system.



So,



BoundingSphere.intersectsBox(BoundingBox) {

return false;

}



etc.

29

That’s fine. Later, the interfaceing can be easily added to make intersection testing more complete. I’ld also like to impliment the mergeLocal code the same way (it as well is a series of instanceof statements). I can do that myself in the future, after the OBBTree is complete.

30

Ok, one last question.



IntersectionOBB contains the OBB to OBB collision test. So, OrientedBoundingBox if working fine. When I went to add the methods into OBB2 I’m having problem with:


Vector3f akA[] = new Vector3f[]{
            getxAxis(),
            getyAxis(),
            getzAxis()
        };
        Vector3f[] akB = new Vector3f[]{
            obb.getxAxis(),
            obb.getyAxis(),
            obb.getzAxis()
        };
        Vector3f afEA = getExtent();
        Vector3f afEB = obb.getExtent();

        // compute difference of box centers, D = C1-C0
        Vector3f kD = obb.getCenter().subtract(getCenter(), tempVa);



get*Axis and the getExtents do not exist for OBB2, is there an equivalent?
31

just .extent or .xaxis and so on should work. If not, make them public :slight_smile:

32

Got the intersection calls in bounding volumes. Implemented the OBBTree calls into the existing CollisionDetection algorithm. So, now you can through a scene at a trimesh, it will check all elements of the scene (based on bounding volumes) if it reaches a leaf that is colliding it then does the OBBTree check. So we have full integration. I’m in the process of cleaning up CollisionDetection and Picking, should be done fairly soon, and then we will be able to look at the current system and discuss how to improve it. The only improvement I was going to make is have CollisionDetection and Pickings calls contained within TriMesh rather than the static classes (same improvement to the Intersection class).

33

Ok, clean up is checked in. This will be my last direct check in without using the policy (except for formatting and misc clean ups). Take a look at how I cleaned it up (I didn’t mess with picking in this pass), and we can talk about how to improve it in the tasks. I’d like to take on the task of making the improvements to the collision/intersection/picking stuff as it’s quite fresh. While I know Renanse was interested in the Bounding improvements.