Jump to content
Sign in to follow this  
jostapo

Creating models that detect collisions

Recommended Posts

Hi. Dinger and I have been working on a mine pack for Chain of Command. So far we have claymores working as well as we'd like (nicely), and have some bouncing betty mines (they jump into the air and detonate).

I was wondering if it's possibly to make an object that is hyper sensitive to anything bumbing into it. Specifically, if a person steps on the mine.

So far, with the cpp and model combination we have, the models detonate appropriately when a heavy tracked vehicle or they are shot. However, they do not detonate when some steps on them. For this we are having to use a trigger for each and every bouncing betty (it works but it's not as polished as we'd like).

I've tried numerous combinations of cpp tweaks, and model tweaks in an effort to make the mines hyper sensitive. Basically, i'd like a strong breeze, let alone someone stepping on them to detonate the mine.

What am I missing? I've noticed that various objects, all have differing sensitivity as to what actions cause them damage and how much damage is given. For instance, some objects will only register a hit when rammed by a fast moving tank, while others will register a slow moving jeep.

Is this a CPP issue? a model issue? a combination of both? and can an object be made so sensitive that it detects footfalls?

If any of the guys from BIS happen to see this post i'd sure like your input. In fact, i'd be equally happy if you said "It's not presently possible." At least I could put this to rest.

Thanks,

Jostapo,CoC

Share this post


Link to post
Share on other sites

In other words, we're looking for an object that when tapped by someone's foot, registers measurable damage, no matter how slight.  A good way to visualize our mine problem is think of a tripwire.  All the LODs are going to be very simple, but when something touches it with 1kg of force (and not 1000), it needs to record damage.  What needs to be done to make it work in these circumstances?

We've got all the other problems solved (submunitions, mp sound effects, banking the spray for elevation changes), it's just this guy that's holding us up.

Share this post


Link to post
Share on other sites

It is possible... well... I'm working on it, but it takes forever to get things right.

The question is, for your application, do you want the object itself (the claymore) to be the "sensing" object, or can you use another object setPos'ed over/around it as the sensor?

Prospero

Share this post


Link to post
Share on other sites

Hi prospero.

The ideal solution is of course to make the object itself the sensor. Barring that, we could "live with" a prosphere-type sensor createvehicled via init and positioned on top of the mine; At that point, we'd either have to use the "Hit" EH (Which would mean that crawling into it would cause at least 5% damage per collision) or if that causes MP problems (and this is really ugly) add it to the list of units to poll on all clients (<10 Hz) for damage.

Making the object itself trigger is cool because then we don't double the number of objects, and for MP reasons, we need to be polling those objects anyway. Additional objects would be nice for later improvements (like editor- and player-placeable tripwires).

Dinger

Share this post


Link to post
Share on other sites
Guest BratZ

Only thing offhand I can think is why not do it the old fashioned way just using a trigger

Share this post


Link to post
Share on other sites

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (BratZ @ Nov. 18 2002,21:55)</td></tr><tr><td id="QUOTE">Only thing offhand I can think is why not do it the old fashioned way just using a trigger<span id='postcolor'>

The answer to your think is above biggrin.gif

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">For this we are having to use a trigger for each and every bouncing betty (it works but it's not as polished as we'd like).<span id='postcolor'>

Share this post


Link to post
Share on other sites

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (Dinger @ Nov. 18 2002,19:42)</td></tr><tr><td id="QUOTE">Hi prospero.

The ideal solution is of course to make the object itself the sensor.  Barring that, we could "live with" a prosphere-type sensor createvehicled via init and positioned on top of the mine; At that point, we'd either have to use the "Hit" EH (Which would mean that crawling into it would cause at least 5% damage per collision) or if that causes MP problems (and this is really ugly) add it to the list of units to poll on all clients (<10 Hz) for damage.

Making the object itself trigger is cool because then we don't double the number of objects, and for MP reasons, we need to be polling those objects anyway.  Additional objects would be nice for later improvements (like editor- and player-placeable tripwires).

Dinger<span id='postcolor'>

Yup, it's a tricky one. Most of the stuff I do is for single-player. I don't have broadband out here. So, polling is good for me.

Some kind of specific collision detection event handler would be good - sensing intrusion of one object's volume on another - that sort of thing.

Prospero

Share this post


Link to post
Share on other sites

Polling is a problem in MP. We are doing some presently (and I hate the fact).

Here's my reasoning for having asked the question in the first place.

If you build a model, you create your GEO and fire lods TYPICALLY to match the shape of the detail lod. When a collision occurs between something HEAVY and something light, the ONHIT and ONKILLED event handlers are triggered. So the object is actually detecting collision dammage.

I've noticed there are varying degrees of this collision detection in the BIS object collection. For instance, shooting a mine barricade with an m16 will not register a hit... but shooting a grave does.

Armed with that bit of knowledge, it would only make sense that some combination of CPP setting and model setting, could make a super sensitive model that will detect a player colliding with it.

You could then exagerate the geometry lod for your objects, and thus make a mine easy engouh for a player to step on, (say a 1 m disc for the geo lod), while not requiring a trigger.

That and it'd be very likely to work well in MP with no polling or monitoring at all.

-Joel/jostapo

Share this post


Link to post
Share on other sites

Hit EH fires at .05 damage.

The big deal is that with some collision detection we can significantly reduce the polling that placing triggers for mines requires, and that means a heck of a lot less CPU overhead in missions.

And without triggers, we can have scatterable mines.

Share this post


Link to post
Share on other sites

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (jostapo @ Nov. 23 2002,16:47)</td></tr><tr><td id="QUOTE">Armed with that bit of knowledge, it would only make sense that some combination of CPP setting and model setting, could make a super sensitive model that will detect a player colliding with it.<span id='postcolor'>

As Dinger knows, I have been using invisible spheres to sense collisions (and also as 3D triggers). The spheres are sim-type "motorcycle", side gamelogic, and have a mass of 1 gram. They vary in size from a few centimetres in diameter, to several meters.

I typically poll them either for damage sustained, a change in direction, a change of position, or a change in velocity. Often it depends if one wants them to be "reusable" like a trigger which has been set to be activated repeatedly.

I have yet to check how "sensitive" they are - i.e. whether I can trigger the Hit eventhandler reliably upon the slightest brush contact (having setPos'ed the sphere once and once only - not in a loop).

Prospero

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×