Well . . . it's still a work-in-progress, but I guess I could put up a single-level demo. I'll try to make something available before July 4th.

Actually, using some information here, I put together an implementation of the oriented bounding box collision algorithm that handles both dynamic and static collisions. I use the spherical collision detection method in jPCT to eliminate trivial cases, and then switch to my algorithm when there's a potential collision. I haven't tested it exhaustively, but it seems to work pretty well in my game.

Basically, each Object3D is associated with a corresponding OBB object, which consists of three axes and extents along them. Transforms applied to the Object3D are also applied to the OBB's axes and center. When a potential collision occurs, the target's bounding box checks for intersection with the source's bounding box. The velocity vector of the source is also taken into account.

The actual collision algorithm, which consists of a gauntlet of tests for potential separating axes, isn't terribly difficult to understand (although I'd never be able to derive it), but it is kind of tedious to implement. If you're thinking about adding this kind of functionality to jPCT, feel free to use as much of my code as you'd like: [link removed] (that link should only be good for a day or so).

Okay, thanks. I think I can fix this by simply spawning the projectile closer to the emitter, but it's useful to know exactly how the algorithm works.

One final question about collision: I was using the ellipsoid method to collide my cars against objects in the scene (terrain is not taken into account during these kinds of collisions). I wasn't sure initially if the ellipsoid used in the Object3D.checkForCollisionEllipsoid() method was object-oriented, but my latest tests have indicated that it is not. The trouble is that the car is a lot longer than it is wide, so sphere or shortened ellipsoid collision detection are both going to cause problems when collisions occur against the car's front or rear (objects will appear to pass through the car shortly before the collision is registered).

I'm planning on calculating the OOBB for each object and running this sort of collision algorithm on my own, but it might be useful to contain this functionality in the engine itself. Would you be willing to add an Object3D.checkForCollisionOOBB() method to the next release? Or is there a way to approximate this with existing methods?

Thanks again, and sorry to be such a continual pest.

Quote from: "EgonOlsen"Does it work now?

Yeah, it works very well. Thanks a lot. There are still some problems when projectiles are fired at an object from close range, but I suspect the problem is that I'm spawning the projectiles inside of said object. A collision won't be registered if the ray starts inside of an object's bounding-box, right?

Here's what I've been working on, by the way. It's playable right now, but I wouldn't want to show it to the public. I'll post it up in the Projects area as soon as we put together a Web Start-able demo.

Hey,

First of all, thanks a ton for adding that PolygonManager class in the latest release. That was a huge help.

On to the next problem, unfortunately: it seems that the ray/polygon collision methods (Object3D.checkForCollision(SimpleVector, float)) work very inconsistently. Collisions occur very rarely, and there doesn't seem to be any way of predicting when the method will work.

For instance, I can fire a projectile at a wall, calling checkForCollision each frame with the projectile's direction vector and the amount by which it moves during that frame. However, the collision is hardly ever registered. The sphere and ellipse collision methods work perfectly, but clearly I don't want to be doing full ellipsoid collision detection for a hundred small projectiles flying around the screen. Do you have any suggestions?

Thanks,

-Nick

Ah, okay, that makes sense. Thanks.

I've been implementing picking in my jPCT application, and I've come across the following problem: a ray created with reproject2D3D(...) from X and Y screen coordinates chosen by the mouse does not take into account the camera's transform. I have to manually multiply the ray by the camera's front matrix like so:

Camera cam;
FrameBuffer buffer;

.
.
.

SimpleVector rayTemp = Interact2D.reproject2D3D(cam, buffer, mX, mY);
rayTemp.normalize();
Matrix orient = cam.getFront();
float[] dump = orient.getDump();
SimpleVector ray = new SimpleVector();
ray.x = dump[0]*rayTemp.x + dump[1]*rayTemp.y + dump[2]*rayTemp.z + dump[3]*1;
ray.y = dump[4]*rayTemp.x + dump[5]*rayTemp.y + dump[6]*rayTemp.z + dump[7]*1;
ray.z = dump[8]*rayTemp.x + dump[9]*rayTemp.y + dump[10]*rayTemp.z + dump[11]*1;


If I don't do this, the ray has entirely the wrong orientation. Is this intentional behavior, or am I just doing something wrong?

Thanks,

-Nick

Quote from: "EgonOlsen"i mentioned the possibility of a TriangleController to access face normals and some other properties of a polygon but i'm not sure if i really should do that.
I've just implemented the effect you want to achieve in a new example (will be included in the next release (i hope)...have a look at the news-section for a screenshot of it). In this example, i'm using calcMinDistance on all four wheels of my "car" and calculate the rotation angles using these values (Math.atan() is your friend here).

Actually, that seems like a much better solution. I don't think I'll have any trouble working out the math on my own, but would you mind posting  the source for that example if the next release isn't going to be forthcoming for a while?

If I might add my two cents, though, I think that the ability to retrieve polygon information from a mesh might be invaluable in other ways. For example, if you were bouncing a ball on a jagged surface, and you wanted to figure out the direction in which the ball would rebound after impact, you'd definitely need to figure out the polygon normal quickly. Some sort of "TriangleController" would definitely be a welcome addition.

Anyway, thanks for the prompt reply.

Hey,

I just started using jPCT last week, and I'm really impressed with it. Have you ever worked with the (now defunct) Spacecrafter 3D API? jPCT seems very similar to it, albeit far more powerful.

There are a couple features, however, that I'd like to add to my project, and I wasn't sure how to go about implementing them.

3D points/lines:
I'd like to be able to draw single-pixel points or lines in world-space for particle effects and such. I could just convert 3D points to screen space and draw them directly using the Graphics structure, but then they wouldn't take the Z-buffer into account and wouldn't be occluded by other objects. If there's no clever way to do this, would you be willing to add simple point/line drawing methods to the next release?

Polygon normals:
My game uses terrain generated from image-based heightmaps, and I'm using calcMinDistance() to find an object's height from its 2D position on the grid. However, I'd also like to change the object's orientation based on the contours of the terrain. I could call calcMinDistance() a couple more times from different points on the object to recalculate the normal, but this seems wasteful. I suppose I could also misuse the pickPolygon() method and a VertexController, but the polygon in question won't necessarily be visible to the camera. Would it be possible to add a method similiar to calcMinDistance() that returns information about the polygon struck by the ray and its normal?

Thanks in advance,

Nick