View previous topic :: View next topic |
Author |
Message |
Error Inside3D Staff

Joined: 05 Nov 2004 Posts: 558 Location: VA, USA
|
|
Back to top |
|
 |
Urre

Joined: 05 Nov 2004 Posts: 1073 Location: Sweden
|
Posted: Thu Aug 05, 2010 7:17 am Post subject: |
|
|
It can do per-poly collisions on all solids which tracelines can hit, IE not SOLID_NOT and SOLID_TRIGGER. If you're using this, I'd recommend having a separate entity representing the agent model, with a larger bounding-box than the physical agent and something like SOLID_CORPSE on so you can't run into it, which follows the agent around using MOVETYPE_FOLLOW or whatever you feel like using. This is because limbs and such often poke outside the regular bounding-box which is used for world-collisions and such, meaning those limbs won't be hit with your per-poly tracelines. DP uses the entitys bounding-box as a way to cull the collisions. Might not be noticeable in most cases, but is important if you're doing something like Dead Space where you shoot off limbs and such. _________________ Look out for Twigboy |
|
Back to top |
|
 |
GiffE
Joined: 08 Oct 2006 Posts: 141 Location: USA, CT
|
Posted: Thu Aug 05, 2010 12:19 pm Post subject: |
|
|
Urre, so if I got this clear, when using SOLID_CORPSE (as I use this for my players) tracelines will collide per-poly? And the bbox is only used for world collisions? _________________ http://www.giffe-bin.net/ |
|
Back to top |
|
 |
Spike
Joined: 05 Nov 2004 Posts: 944 Location: UK
|
Posted: Thu Aug 05, 2010 4:53 pm Post subject: |
|
|
There's a MOVE_HITMODEL flag on traceline/tracebox. Its that that will make it per-poly.
However it'll only collide against polys within the normal bounding box (so MOVE_HITMODEL will _always_ hit less often).
If you have a limb sticking out of the regular bounding box, and you 'hit' that limb, if you didn't also hit the bounding box it won't even check the limb, it'll just assume a miss. _that_ is what the solid_corpse is for - to allow a bigger bounding box on ents without breaking regular movement physics. _________________ What's a signature? |
|
Back to top |
|
 |
Urre

Joined: 05 Nov 2004 Posts: 1073 Location: Sweden
|
Posted: Fri Aug 06, 2010 5:51 am Post subject: |
|
|
Yes, I sometimes suck at explaining, atleast in hastily written forum posts... Note that you'll still need a separate entity in order to have this bigger SOLID_CORPSE action going on, unless someone knows another clever trick. You'd also require separate entities per limb if you want to do different amounts of damage based on which limb was hit, as far as I know there's no mesh name checking or anything like that. That'd be great though... _________________ Look out for Twigboy |
|
Back to top |
|
 |
frag.machine

Joined: 25 Nov 2006 Posts: 728
|
Posted: Fri Aug 06, 2010 12:21 pm Post subject: |
|
|
One could add engine side support to update a vector field holding the last collision coordinates relative to entity origin, allowing the proper treatment from QuakeC side. But of course that would be useful only for single point-sized or hitscan projectiles. _________________ frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/ |
|
Back to top |
|
 |
Spike
Joined: 05 Nov 2004 Posts: 944 Location: UK
|
Posted: Fri Aug 06, 2010 1:54 pm Post subject: |
|
|
frag.machine wrote: | One could add engine side support to update a vector field holding the last collision coordinates relative to entity origin, allowing the proper treatment from QuakeC side. But of course that would be useful only for single point-sized or hitscan projectiles. |
you mean: impact = (trace_endpos - trace_entity.origin)
you can then use impact_z, and you have what orion described (hint: don't forget mins/max sizes...). _________________ What's a signature? |
|
Back to top |
|
 |
frag.machine

Joined: 25 Nov 2006 Posts: 728
|
Posted: Fri Aug 06, 2010 4:51 pm Post subject: |
|
|
Spike wrote: | frag.machine wrote: | One could add engine side support to update a vector field holding the last collision coordinates relative to entity origin, allowing the proper treatment from QuakeC side. But of course that would be useful only for single point-sized or hitscan projectiles. |
you mean: impact = (trace_endpos - trace_entity.origin)
you can then use impact_z, and you have what orion described (hint: don't forget mins/max sizes...). |
Calculating on the engine side could be precise at polygon level, avoiding the false positives the formula above can lead. _________________ frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/ |
|
Back to top |
|
 |
GiffE
Joined: 08 Oct 2006 Posts: 141 Location: USA, CT
|
Posted: Fri Aug 06, 2010 11:17 pm Post subject: |
|
|
Would it also be possible to just check which tag the trace_endpos is closest too? _________________ http://www.giffe-bin.net/ |
|
Back to top |
|
 |
Urre

Joined: 05 Nov 2004 Posts: 1073 Location: Sweden
|
Posted: Mon Aug 09, 2010 6:37 pm Post subject: |
|
|
GiffE wrote: | Would it also be possible to just check which tag the trace_endpos is closest too? |
That's a clever trick which should work in most cases yeah. Neat! You might run into problems such as a fat part close to a thin part, where you actually hit the fat part, but the thin parts tag is still closer. _________________ Look out for Twigboy |
|
Back to top |
|
 |
|