Dynamic bounding-box collision in Q1
Moderator: InsideQC Admins
5 posts
• Page 1 of 1
Dynamic bounding-box collision in Q1
This is something that i've been always curious, but never really understood in Q1: how does collision really work? Is it related to the BSP format? Isn't it easier, today, to just calculate the bounding box of all models (grunts, player, dogs, etc.) and detect if they are colliding with the BSP geometry?
- JasonX
- Posts: 411
- Joined: Tue Apr 21, 2009 2:08 pm
Re: Dynamic bounding-box collision in Q1
JasonX wrote:Isn't it easier, today, to just calculate the bounding box of all models (grunts, player, dogs, etc.) and detect if they are colliding with the BSP geometry?
That's exactly the problem: as Spike already explained in other threads, you don't have the complete map geometry stored in the BSP tree, only planes.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC
(LordHavoc)
-

frag.machine - Posts: 2090
- Joined: Sat Nov 25, 2006 1:49 pm
Re: Dynamic bounding-box collision in Q1
Right as Frag Machine says, its dependent on the BSP structure q1bsp uses in regard to entity collision on BSP. Entity on entity collisions seems that it can be done by checkind the mins and maxs of each entity to see if they overlap each others bounds, but Im not sure if thats exactly how the engine does it.
I always pondered that it ought to be possible to do collisions model to model without "hitboxes" if you mapped each pixel out with a center reference says its origin point with regard to the model, then you should be able to calculate collision by comparing each specific coordinate to detect a collision, and map out each frame of the moel the same way - thus overcoming the concept of a hitbox completely. Would be time consuming and resource heavy yea, but on the newer technology cpu's out there might not be as demanding if its coded right.
As with the way it is now, the issue becomes more complex with moving entities and I suppose would be very demanding when detecting if a point sized entity collided with another point size entity. In actuality you ought to be able to see rocket to rocket mid air collisions in vanilla Quake but in all the years I have been playing have not see any and by now ought to have seen at least one
I always pondered that it ought to be possible to do collisions model to model without "hitboxes" if you mapped each pixel out with a center reference says its origin point with regard to the model, then you should be able to calculate collision by comparing each specific coordinate to detect a collision, and map out each frame of the moel the same way - thus overcoming the concept of a hitbox completely. Would be time consuming and resource heavy yea, but on the newer technology cpu's out there might not be as demanding if its coded right.
As with the way it is now, the issue becomes more complex with moving entities and I suppose would be very demanding when detecting if a point sized entity collided with another point size entity. In actuality you ought to be able to see rocket to rocket mid air collisions in vanilla Quake but in all the years I have been playing have not see any and by now ought to have seen at least one
-

Cobalt - Posts: 445
- Joined: Wed Jun 10, 2009 2:58 am
- Location: New England, USA
Re: Dynamic bounding-box collision in Q1
box vs box is easy.
point vs triangle is straight forward, but non-commutative.
box vs triangle is still supportable, but non-commutative
triangle vs triangle is an absolute nightmare.
things get much more complex if any of these objects is rotated.
point vs triangle is straight forward, but non-commutative.
box vs triangle is still supportable, but non-commutative
triangle vs triangle is an absolute nightmare.
things get much more complex if any of these objects is rotated.
- Spike
- Posts: 2892
- Joined: Fri Nov 05, 2004 3:12 am
- Location: UK
Re: Dynamic bounding-box collision in Q1
Spike wrote:box vs box is easy.
point vs triangle is straight forward, but non-commutative.
box vs triangle is still supportable, but non-commutative
triangle vs triangle is an absolute nightmare.
things get much more complex if any of these objects is rotated.
And that's why even today the Source engine sticks with box collisions for models (obviously with far more flexible and accurated version than Quake, but boxes in the end)
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC
(LordHavoc)
-

frag.machine - Posts: 2090
- Joined: Sat Nov 25, 2006 1:49 pm
5 posts
• Page 1 of 1
Who is online
Users browsing this forum: No registered users and 1 guest