Cooool...i'll have a look at your code for sure. The funny things is, that jPCT already has an OBB (i.e. the tranformed AABB) for each object. It's just not public. Maybe it should be...

Currently, it's used for collision detection in a way that rays/spheres/ellipsoids are checked against it before work starts on the polygon level (if it has to, i.e. if there is an intersection).

Anyway, i got the oriented ellipsoid stuff working too. At least i think i did...it requires some more testing. However, i think that your OBB-approach is very well suited for cars, because they are just boxes...basically... :wink:

Fine, but i'll look into this 120-issue...i don't see a reason for this behaviour. If nothing has been selected, null should be returned. Not an array containing nonsense values.

Edit: Please let me know if an object with ID=120 really exists (even if you haven't created it yourself). Try to get the actual object with this ID from World by calling getObject(int id). If such object exists, please tell be the name of it (getName()). Or does getObject() returns null and prints out an error?

Have you implemented a KeyListener together with the MouseListener?

You are right: The ellipsoid doesn't get transformed like the object. It always remains "axis aligned". It's on my to-do list to see, if i can do something about it. Currently, the algorithm basically works like this:

The camera/object that should be checked for a collision is transformed into the collider's (the "target" of the collision) object space. The collision detection itself is taking place in ellipsoid space, which is a scaled variant of the collider's object space in which the ellipsoid is a unit sphere.
This translation from object into ellipsoid space is the problem. It happens for a lot of vertices of the collider multiple times (depending on the recursion depth of the collision) and therefor, it has to be fast. With the "axis aligned" ellipsoid, this is easy. It requires 3 divisions/vertex. If the ellipsoid should be tranformed too, it's no longer that simple.

However, i'll look into it and see what i can do. For the time being, can't you simply use some smaller spheres placed at the car's front and back (like one left and one right) to approximate it? I'm not sure how well this will work though...

I've uploaded a fixed version here: *Link removed*
It's only the API-jar, not a complete distribution. Please compile the examples from the regular distribution with this jar and tell me, if the textures are looking fine now.

Edit: The fix is now included in the release version of jPCT

The code of the OpenGL renderer includes a comment: "Will this work on Mac? (byte order)"...well, obviously it doesn't... :wink: Should be an easy fix in this case, albeit i'm not sure that it's the only place where little endian vs. big endian matters.
Anyway, i'll upload a version for you to test on monday.
About the input problem: I don't know. Seems to be a LWJGL problem then. You mean that you can't move around in the fps example, i assume!?

What is mouseClick()? I suggest to overwrite

protected void processMouseEvent(MouseEvent e)

in the applet with something like:


protected void processMouseEvent(MouseEvent e) {
   super.processMouseEvent(e);
   if (e.getID()==MouseEvent.MOUSE_CLICKED) {
      wire=!wire;
   }
}


That should work. You shouldn't abuse processKey() for mouse events, because it was meant to handle events from the keyboard, not from the mouse.