2.0 Progress Update

News about Box2D
Erin Catto
Site Admin
Posts: 2948
Joined: Thu Sep 06, 2007 12:34 am

Re: 2.0 Progress Update

Postby Erin Catto » Fri Jan 25, 2008 12:39 pm

I'll add a callback for sensors. Keep in mind that sensors won't use continuous collision. So a fast moving object can move across a sensor undetected.

kdmiller3
Posts: 100
Joined: Sun Dec 02, 2007 6:29 pm

Re: 2.0 Progress Update

Postby kdmiller3 » Fri Jan 25, 2008 1:35 pm

Hmm. Sensor-based mines ignore bullets in my particular case, so it won't be an issue for me in the short run. However, I could see that inconsistency coming up as a "gotcha" if it's going to be the permanent state of affairs going forward. I'd obviously prefer it if sensor shapes were consistent with solid shapes (generating the same events, handling continuous collision detection) except for applying impulses on contact. Just saying'... :D

brainclog
Posts: 185
Joined: Mon Dec 17, 2007 10:11 pm
Contact:

Re: 2.0 Progress Update

Postby brainclog » Fri Jan 25, 2008 2:44 pm

I second that! I don't understand why sensors wouldn't be treated just like any other shape, except that they don't generate collision responses. I understand it could be a performance problem because sensors can have a ton of contacts because well, they just sit there and don't try to resolve the contact situation. Is there some technical reason why sensors can't have CCD?

Erin Catto
Site Admin
Posts: 2948
Joined: Thu Sep 06, 2007 12:34 am

Re: 2.0 Progress Update

Postby Erin Catto » Fri Jan 25, 2008 4:53 pm

What would a sensor report for CCD? There are an infinite number of contact points as the shapes sweep across each other.

Keep in mind that with solid objects I compute the time of impact and then apply an impulse. I'm not sure what algorithm I would use for sensors.

Normally in games if you need a sensor to do CCD it is very restrictive. The sensor will be static and you will use simple raycasts to detect when a point enters and exits the sensor region.

Sensors as they are going to be implemented are best at applying force fields or some AI.

If you have some fixed region in space that kills the character when they cross it, then it will be faster for you to use raycasts. In other words, sensor can solve some problems, but not all problems.

kdmiller3
Posts: 100
Joined: Sun Dec 02, 2007 6:29 pm

Re: 2.0 Progress Update

Postby kdmiller3 » Fri Jan 25, 2008 5:25 pm

What would a sensor report for CCD? There are an infinite number of contact points as the shapes sweep across each other.

True. I figured the sensor would generate a b2ContactListener Add event at the moment the shapes first touch and a Remove event at the moment the shapes last touch. At those moments, the contact point and normal have meaning even if they don't during the interval in between. The continuous contact between the shapes would be implied by the time interval between the Add and Remove events, so it wouldn't need to report anything else; if you haven't gotten a Remove event yet, then the shapes are still overlapping. A Persist event would have undefined contact point and normal, so I don't see it as being all that useful.

Keep in mind that with solid objects I compute the time of impact and then apply an impulse. I'm not sure what algorithm I would use for sensors.

It would be the same except for applying the impulse, though there is the complication of computing the time of separation. I would imagine it being a TOI with time and velocity negated, but I don't know that for sure.

Normally in games if you need a sensor to do CCD it is very restrictive. The sensor will be static and you will use simple raycasts to detect when a point enters and exits the sensor region.

True enough, though the existing TOI code would allow non-point shapes. That'd be a very powerful feature.

Sensors as they are going to be implemented are best at applying force fields or some AI.

That's sort of how I was using sensors (mine trigger region), but I can also see the value of catching transient contacts with fast-moving non-point shapes without affecting their motion.

If you have some fixed region in space that kills the character when they cross it, then it will be faster for you to use raycasts. In other words, sensor can solve some problems, but not all problems.

That's always an option, of course. If there's a tradeoff between speed (raycast) and accuracy (CCD), maybe the sensor could have a flag indicating whether it should react to CCD?
Last edited by kdmiller3 on Fri Jan 25, 2008 6:51 pm, edited 1 time in total.

brainclog
Posts: 185
Joined: Mon Dec 17, 2007 10:11 pm
Contact:

Re: 2.0 Progress Update

Postby brainclog » Fri Jan 25, 2008 6:12 pm

I was previewing my post when I noticed that kdmiller3 just said basically the exact same thing I was going to say... He said it better too, so I'm left with "I second that" yet again. :(

Erin Catto
Site Admin
Posts: 2948
Joined: Thu Sep 06, 2007 12:34 am

Re: 2.0 Progress Update

Postby Erin Catto » Fri Jan 25, 2008 6:30 pm

I figured the sensor would generate a b2ContactListener Add event at the moment the shapes first touch and a Remove event at the moment the shapes last touch.


This sounds simple, but it is a very complex problem.

First the sensor would generate a TOI event when the shapes first touch. I can do that. But then I would need to provide some mechanism where the sensor stops generating the TOI event so the shapes can pass through. This is very complex when there are long skinny rotating shapes. Also there is no existing mechanism for TOI remove events. The current remove event doesn't give the time of last touch, it just notifies you when a contact point has been removed. The system doesn't know when the contact point became invalid, even for CCD contacts. Usually contact remove events occur at the beginning of a time step when all the contacts are re-evaluated.

I guess the best I could do is allow each sensor contact one TOI event per time step. At the TOI event I could re-evaluate the sensor contact and send a message if a point is added, persisted, or removed. You would also get messages during the normal contact processing.

All this seems to be solved better with ray casts. So I wonder if it is worth it.

kdmiller3
Posts: 100
Joined: Sun Dec 02, 2007 6:29 pm

Re: 2.0 Progress Update

Postby kdmiller3 » Fri Jan 25, 2008 6:48 pm

This sounds simple, but it is a very complex problem.

I don't doubt that. :D

First the sensor would generate a TOI event when the shapes first touch. I can do that.

That alone would be immensely helpful, and is pretty much all I need.

But then I would need to provide some mechanism where the sensor stops generating the TOI event so the shapes can pass through. This is very complex when there are long skinny rotating shapes.

Hmm. I think I could see how that would be tough.

Also there is no existing mechanism for TOI remove events. The current remove event doesn't give the time of last touch, it just notifies you when a contact point has been removed.

Ah. Since I don't even need the exact time of last touch, doing a whole lot of work to get it is not worth your time and effort. I was just sort of thinking out loud...

The system doesn't know when the contact point became invalid, even for CCD contacts. Usually contact remove events occur at the beginning of a time step when all the contacts are re-evaluated.

Fair enough. The CCD collision already works great, so there's no sense in adding something complicated and difficult for a case that most people don't care much about.

I guess the best I could do is allow each sensor contact one TOI event per time step. At the TOI event I could re-evaluate the sensor contact and send a message if a point is added, persisted, or removed. You would also get messages during the normal contact processing.

That'd be enough for me. The exact time of contact is usually much more important than the exact time of not-contact, and would make my sensor triggers work correctly. My contact listener only responds to Add events, as bullet impacts and sensor triggers can evaluate fully right then. I don't have any plans for anything involving the exact duration of overlap, so the Remove event doesn't have to be precise.

All this seems to be solved better with ray casts. So I wonder if it is worth it.

It's a consistency thing for me, so my application's event-driven collision response doesn't have to perform special checks for intersections with sensor shapes.

Seligman
Posts: 4
Joined: Fri Jan 25, 2008 8:44 pm

Re: 2.0 Progress Update

Postby Seligman » Fri Feb 01, 2008 9:50 am

How is b2Body::Destroy(b2Shape* s) supposed to be used? If I pass it a shape that's already in the body, it's almost guaranteed to raise an the b2Assert(s->m_body == NULL) assert.

Or, put another way, I'm trying to remove a shape from a body long after the body has been created and interacted with other bodies in the world. Is this not the expected usage scenario?

Erin Catto
Site Admin
Posts: 2948
Joined: Thu Sep 06, 2007 12:34 am

Re: 2.0 Progress Update

Postby Erin Catto » Fri Feb 01, 2008 10:31 am

That's a bug (obviously I haven't tested that function yet).

Try changing NULL to this.


Return to “News”



Who is online

Users browsing this forum: No registered users and 2 guests