Page 2 of 3

Re: Is the cpSimpleMotor constraint stable?

PostPosted: Thu Nov 19, 2009 9:35 am
by slembcke
I guess you could do that. There is nothing special about those fields.

Re: Is the cpSimpleMotor constraint stable?

PostPosted: Thu Nov 19, 2009 1:37 pm
by Tam Toucan
Correct a and b are the two bodies. No swapping, just a,b as passed in to the cpxxxxInit function.

Re: Is the cpSimpleMotor constraint stable?

PostPosted: Thu Nov 19, 2009 5:12 pm
by Dave
ok, cool. thanks for all the help guys.

Re: Is the cpSimpleMotor constraint stable?

PostPosted: Sat Nov 21, 2009 6:48 pm
by Dave
Well, I've got the joint destruction management under control now. Keeping track of them through my struct isn't so bad after all. I have another question though, if you guys aren't tired of hearing from me yet j/k :p
Anyway, is it the case that if you don't add 2 shapes to the same group, whose bodies are attached with a joint, they will fight? I was hoping that I could just check my struct and see if they're in the same group, process the callback, then if they are, return 0, which will skip the collision. If this is incorrect, I'll go back to debugging, but I'm almost certain they are fighting in some sense.

Re: Is the cpSimpleMotor constraint stable?

PostPosted: Sat Nov 21, 2009 9:21 pm
by slembcke
That is correct, connecting to bodies together with at joint is not enough to prevent collisions between their shapes. There are valid reasons why you would want shapes linked by a joint to collide, so you have to filter them out some other way.

Re: Is the cpSimpleMotor constraint stable?

PostPosted: Sat Nov 21, 2009 9:25 pm
by Tam Toucan
I've had very little sleep so I'm not able to process your question properly :) But here's some info

There is an "early reject" check before the complex part of collisions is even tried. Its in the docs, but this is the code
Code: Select all
queryReject(cpShape *a, cpShape *b)
{
   return
      // BBoxes must overlap
      !cpBBintersects(a->bb, b->bb)
      // Don't collide shapes attached to the same body.
      || a->body == b->body
      // Don't collide objects in the same non-zero group
      || (a->group && b->group && a->group == b->group)
      // Don't collide objects that don't share at least on layer.
      || !(a->layers & b->layers);
So if you have two shapes on two different bodies and they don't have the same group value (or the group value is zero) and the layer masks overlap (default mask is 0xffffffff so unless you have changed it this will be true) then the shapes can collide. If not then your collision function will never be called for them. Joints don't come into collisions, they just affect the forces applied.

So you don't need to check if they are the same group, because if they are you will never get a collision. If they are different groups and different bodies then they will collide with each other so depending on the joint etc you could get "fighting".

Re: Is the cpSimpleMotor constraint stable?

PostPosted: Sat Nov 21, 2009 11:12 pm
by Dave
Well, what I'm really trying to do, is decide from the callback if two bodies should collide, even if they are connected by a joint. If I understand correctly though, this wont work because it affects the forces before the user callback is ever processed?

Re: Is the cpSimpleMotor constraint stable?

PostPosted: Sun Nov 22, 2009 1:23 pm
by Tam Toucan
I don't quite follow. The joints are always affecting the bodies. It doesn't mean they can't collide. What joint have you got and what are you trying to do?

Re: Is the cpSimpleMotor constraint stable?

PostPosted: Sun Nov 22, 2009 2:02 pm
by slembcke
The user callbacks are called before any of the collision response processing starts. That's why you are able to reject collisions using the callbacks. Does that clear things up?

Also, a slight warning is that by the time the collision callback is called, all of the collision detection work has already been done. If you are rejecting a lot of collisions from callbacks by running graph algorithms on the joint connectivity, you might find your performance is not so good. Usually processing the collision responses is far more expensive than the collision detection, so I wouldn't worry about it too much.

Re: Is the cpSimpleMotor constraint stable?

PostPosted: Sun Nov 22, 2009 3:58 pm
by Dave
slembcke wrote:The user callbacks are called before any of the collision response processing starts. That's why you are able to reject collisions using the callbacks. Does that clear things up?


Yeah, actually it does.

EDIT:
Well, I might as well show this video anyway, but I figured out the problem, right after I uploaded it. :lol: Those "lines" have their own callback, and when I was using separate groups, I never rejected the collision from the callback. I was only doing it for circle/line collisions. If I get a bit of a performance hit by doing it this way, it shouldn't be too bad because eventually there will be a limited area in which the players can create their machines. They wont be able to add thousands of bodies when the game is complete. Maybe when I've got a bit more experience with it I can bit-mask everything into collision layers properly as well. ;)
http://www.youtube.com/watch?v=jSugbZlVDV0

By the way, If I sound like I'm being mean or anything, I'm really not. I seem to have a strange way of wording things or something, and people tend to think I'm being a jerk. This is an awesome engine and I appreciate all the work you guys have done. If I can ever get my paypal crap working properly, I'll donate some funds. :)