Dynamic bounding-box collision in Q1

Discuss programming topics for the various GPL'd game engine sources.
Post Reply
JasonX
Posts: 422
Joined: Tue Apr 21, 2009 2:08 pm

Dynamic bounding-box collision in Q1

Post by JasonX »

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?
frag.machine
Posts: 2126
Joined: Sat Nov 25, 2006 1:49 pm

Re: Dynamic bounding-box collision in Q1

Post by frag.machine »

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)
Cobalt
Posts: 445
Joined: Wed Jun 10, 2009 2:58 am
Location: New England, USA
Contact:

Re: Dynamic bounding-box collision in Q1

Post by Cobalt »

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 :)
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: Dynamic bounding-box collision in Q1

Post by Spike »

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.
frag.machine
Posts: 2126
Joined: Sat Nov 25, 2006 1:49 pm

Re: Dynamic bounding-box collision in Q1

Post by frag.machine »

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)
Post Reply