Re: [Plib-devel] Collision detection in PLIB/SSG

[Steve B. <sjb...@ai...>]

Sam Stickland wrote:

> Is there any support for any form of collision detection in PLIB?  I was
> thinking about maybe integrating it with one of the free ones (V-Collide,
> I-Collide, Rapid etc.).

SSG contains code to test all the polygons in the scene against either
a vector or a bounding sphere - and also a quick way to find polygons
vertically below a given 3D point.

This is a basis for doing efficient collision detection - but since the
needs of games vary greatly, I don't *directly* supply specific collision
detection.

> Does this seem a sensible thing to be doing - or are there any fundamental
> objects as to why this shouldn't be done?

Well, those other libraries won't know about SSG's scene graph structure
and are hence rather unlikely to be able to do as good a job as the
builtin routines.
 
> I also have code (from AMD's website) from 3DNow! acceleration (windows only
> unfortunately), that would be very easy to plug into SG (and I do mean very
> easy - it's just a bunch of function calls).  I'll add this next week some
> time.

Hmmm - be careful.

Taking a single 3D transform (say) and turning that into a 3DNow! instruction
sequence provides a disappointingly tiny speedup.

When Mesa added 3DNow! code like that, they got (barely) a 5% speedup.
Definitiely *NOT* worth the hassle of implementing and (especially)
supporting a machine code insert that can assemble on any machine but
which is only turned on on the right kinds of CPU.

The reason for that disappointing performance is that turning the
3DNow! engine on and off is horribly slow.

The way to get blazing speed out of 3DNow! is to queue up a large buffer
of vertices to be transformed - and to do them all in a batch without
having to turn it on and off again.  Mesa eventually needed significant
restructuring to make 3DNow! actually worthwhile.

However, something like SSG doesn't ever need to do large numbers of
consecutive transforms - most of what it's doing (that consumes
significant CPU time) is culling the database to the field of view
(or to the collision test vector/sphere).  By it's very nature,
this isn't something that is readily batch-able.

In any case, a typical SSG application on a PC without hardware T&L
spends a vast proportion of it's time inside the OpenGL library.
Hence, the only worthwhile place to look for optimisations is
either inside OpenGL - or in more subtle ways of reducing the
amount of stuff we send to OpenGL.

So, I don't think 3DNow is actually worth the maintenance hassle.
Bear in mind that it would have to compile under both Windoze and
Linux (and perhaps BSD UNIX) - that's no easy matter since the
Linux and Windoze assemblers accept different input syntax - and
even withing Windoze, some of the older MSVC versions don't know
about the 3DNow instruction mnemonics (ditto with Linux/gcc I
suspect).   Then you need runtime code to detect whether the code
is *running* on a 3DNow-capable machine.  That code has to work on
all 8086-family CPU's - but not on Alpha's and MIP's and such.

Altogether, it's a large maintenance pain with very little gain,
I think.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)