Using only collision detection + resonse
MrCoder
(penetration depth/normal etc)? I need to handle the body simulation
manually.
Morten Silcowitz
> (penetration depth/normal etc)?
Yes I think that is perfectly possible. However, the collision
response is based on the motion integration method, or the body
simulation, so you would be pretty much confined to computing the same
body motion as would be computed by Jinngine. If not, the collision
response computed will be wrong/inaccurate.
The part of jinngine that does this computation is really simple, and
you could easily do it in your own code. I did a little comment in the
code to help:
Alternatively, you could just copy the transforms that are to be
handled by Jinngine, like a controller for each such body. But I guess
you have a good reason for not doing that.
Can you tell me more about your project? Maybe I can be of more help :)
MrCoder
I'm gonna add some moving objects, that have to interact with the
character AABB. Basically it doesnt have to be more than AABB-OBB
collisions (all boxes thank god *s*). I'd prefer to still do the
character motion myself, and the collision against the static world,
since it's so simple (easy case to just raycast).
To be honest, having collision of the moving objects against the
boxgrid world would be awesome too, but I might manage to do that
myself as well.
I'll take a look at the provided code, thanks a lot for that!
If you have any other ideas, I'll be more than happy to hear them :)
Andy Shaules
events system too.
I figure it should be easy to add if it is not there yet, but I will like to
broadcast those events over the flv stream as well as the positional and
orientational data.
Andy
mo
> I'm gonna add some moving objects, that have to interact with the
> character AABB. Basically it doesnt have to be more than AABB-OBB
> collisions (all boxes thank god *s*).
can provide you with contact points, normals, depths etc. At present
that would give you capsules, convex hulls, spheres and boxes.
> I'd prefer to still do the
> character motion myself, and the collision against the static world,
> since it's so simple (easy case to just raycast).
there. I do have some simple ideas to how an animated character could
be made to interact with objects animated by Jinngine, though.
Combining character animation with the dynamics of physics is
something that occupies many people, recently I saw a number of talks
on the subject at SCA-2010. Maybe you could enlighten me a little on
how you did that, maybe in some previous projects?
> To be honest, having collision of the moving objects against the
> boxgrid world would be awesome too, but I might manage to do that
> myself as well.
course, since your wold is vast and unbounded, it requires some
handling in inserting and deleting the static environment boxes into
jinngine. But since you presumably already have some BVH going at this
point, it should be easy to do such lookups fast.
MrCoder
How hard do you think it would be to create a boxgrid geometry object?
Implement the SupportMap3 methods by dynamically raycasting into the
current grid etc.
If I could manage to move over all physics to Jinngine that would
remove a lot of problems offcourse. I've done lots of hybrid
simulations before (own+ODE, own+Bullet etc) and it's always
painful :)
mo
> Implement the SupportMap3 methods by dynamically raycasting into the
> current grid etc.
the grid of boxes is non-convex. Jinngine works with convex objects,
so non-convex objects are compositions of convex ones. This has to do
with the fact that contact point generation for general non-convex
objects is hard to do right. When Jinngine compute contact points etc,
it uses the SupportMap3 methods extensively, so they should be as fast
as possible.
However, the way you could model the box grid, was to create a single
static body, and simply add/remove box geometries to it. Then, all
those boxes will be handled by the broad-phase system (which is SAP),
and all overlapping pairs (of overlaps with dynamic bodies) will be
handled individually. Although it would seem expensive, SAP is so
efficient, that in cases where AABB's makes good approximations of the
actual objects (which is evidently does for boxes:), it is likely to
be much faster than handling the box grid as one big non-convex
object.
I guess, SAP and AABBs is a simple form of a BVH, that a linear
running time in the number of AABBs, but with very small constants. As
I recall, Bullet uses a kind of BVH for their broad-phase system as
default though. Of course there is a turning point somewhere,
depending on the number of objects and their sizes/properties.
Especially if you restrict the representation in the physics to be in
a neighborhood of your dynamic objects, I speculate that SAP and
AABB's will outperform a BVH on a non-convex structure. But thats just
speculation though :)
> If I could manage to move over all physics to Jinngine that would
> remove a lot of problems offcourse. I've done lots of hybrid
> simulations before (own+ODE, own+Bullet etc) and it's always
> painful :)
can. I'll start by committing some geometry branch updates into trunk.
MrCoder
boxes, do setLocalTransform and add to the scene alt remove from
scene, as the character(or object) moves around? Any other update
operation that needs to be run for things to work after that?
Seems to be a whole lot of Vector3 and Matrix creation. Ever thought
about adding in additional methods to the math classes to either do
local operations or take a store paramter so it's possible to reuse
objects from outside? (See our Ardor3D math lib for example).
Awesome that you are able to reply as quickly, thanks again :)
Morten Silcowitz
> Right, that's worth a try. So I would just have a growable pool of
> boxes, do setLocalTransform and add to the scene alt remove from
> scene, as the character(or object) moves around? Any other update
> operation that needs to be run for things to work after that?
Actually this talk got me thinking, and right now i'm working on some
changes that would make this sort of thing as painless as possible. I
will commit those change as fast as I can. Until now, I would
recommend the following way:
- for each box, create both a body and a box:
Body newbox = new Body( "newbox", new Box(1,1,1));
newbox.setPosition( pos);
newbox.setFixed(true);
scene.addBody(newbox);
- then for deletion, just do
scene.removeBody(newbox);
This will require one body pr box, which is kind of a waste, but it
will not affect the performance much. It spares you from working with
the geometries directly in a single body, because its a bit of a mess
as it is right now. I'm working on fixing that right now.
> Seems to be a whole lot of Vector3 and Matrix creation. Ever thought
> about adding in additional methods to the math classes to either do
> local operations or take a store paramter so it's possible to reuse
> objects from outside? (See our Ardor3D math lib for example).
Yes, this is an issue. There are some methods that starts with
"assign..." that works locally on the same instance. There are also
static instances that work directly on a specified instance. In the
beginning, i never really noticed the flood of objects, until one
day... :) It should definitely be fixed. I think I should start by
doing some profiling, and cure the most work intensive parts. If you
have any input on this, its very welcome :)