Quote:> i'm trying! ;)
> ..i wasn't trying to be critical -- the demo's quite impressive.
> it's just that i've found (with my very simple 2D attempts) that
and I wasnt challenging you : )
> (a) the normals are well-behaved and you can never get a decent
> sharp/hard corner.
> (b) the normals jump around the surface of the shape, but the edges of
> things no longer have to be rounded.
> > The normal produced by any ( free )
> > package Ive found up to now is jumping discretely from
> > place to place with large displacements ( closest feature )
> > or changes with the motion of the objects.
> i'm trying to solve things based purely on the configuration of the
> objects, but i have a feeling i may have to take their movement into
> account -- i really don't want to though, because in the past
> everytime i attempted something like this, it broke previously
> well-behaved behaviours and in general seemed like a big hack.
Actually, I do have a nice 2d version running with one minor
problem, when a stack of objects fall down and two objects
touch slightly at a corner in their fall, the higher object gets a bit
'blocked' in the direction of the collision normal, whereas only
the colliding part(icles) of the objects should be blocked.
Unfortunately, this engine is not public, but I can tell you this
much, as you already suggested: you will have to revert to
frame-coherency at some point if you want to get 'sharp' normals,
because there's no way to tell from a static configuration where
one object entered the other.
> the problem is (as far as i can tell), you can ALWAYS pick an
> arbitrarily large displacement that will break things. how are you
> handling this?
I dont, seems like we're trying exactly the same thing, I've already
made the choice of having too smooth collision-normals rather than
frame-coherency and its problems of degenerate normals, having to
find the time of collision, etc.
> > described. So it actually costs money. It seems that finding a less
> > perfect, yet robust and generic method for them is very valuable.
> these are my goals exactly -- make it impossible to blow the sim up.
> at the same time, i _really_ need stacking to work -- for instance,
> most urban scenes have sharp corners/etc. (for instance, building
> tops) that really do need to feel "flat".
At the moment, I feel 'true' stacking of say 10 identical cubes just
wont work if you dont support the structure by additional constraints
when using the Jakobsen method. There's one stupidly fundamental problem
with our approach: since we try to be frame-incoherent, we dont know if
a particle of an object is coming to a halt or speeding up. It would be nice
to stop an object by clamping its particles when it has hit the floor
(or an underlying object ) and comes to a halt due to friction, but that
will prevent it from speeding up again too, when it is hit by another
moved by the user, moved due to a change in direction of gravity, blown
away by wind, etc. Once you try to mix the two approaches ( put additional
constraints on slowing down and speeding up particles ) all hell breaks
in terms of complexity, everything starts to influence every other thing,
things pop up with close-to-zero motion etc.etc, I think exactly like you
Quote:> ..i just reread your ealier post, and i wanted to ask: how are you
> simulating the rigid-body dynamics? i.e vanilla jakobsen, or did you
> homebrew something?
I once called my engine the 'emergent rotation engine'. It's based on the
Jakobsen paper, so no force, velocity, etc. just displacements with, of
as he says: "Naturally, a lot of additional tweaking was necessary to get
result just right. " and this lot he talkes about is the secret stuff. Its a
for instance how to get a proper matrix out of the configuration of the
particles that make up a body, when to update that matrix, when to update
the boundingboxes, etc. etc.
Quote:> i'm not sure if you've read it already, but the phd thesis of jeroen
> wagenaar presents an alternate approach to the one jakobsen described
> -- still based on "dynamic-model-rigidly-embedded-in-collision-shape",
> but handling forces and collision resolution differently. apparently
> they worked together on this stuff -- wagenaar's now working at ioi.
strangely enough, I dont find the paper online. c'd you send it to me ?
Quote:> anyway, i've found it pretty useful, since it covers many topics much
> more thoroughly. what i'm using right now is kind of a mixture of
> their ideas, plus a few of my own...
feels a lot like cooking, doesnt it - Potter style though ; )
c'd you tell me a bit more about your project, why, how and where ?
I think we should get off the newsgroup now, so feel free to reply to my
own eddress ( remember to tear off the *sticker* )