sorry but this is not newsworthy at all (well, other than providing LordHavoc with a shoutout, which he most certainly deserves).
this physics engine is not the piece you're looking for. from the looks of it this was pretty much only ever a proof of concept and as it stands it would only be useful for minor effects. first off it's written in quakec, which is a very bad idea for something as computationally intensive as a physics engine like this. as for the engine itself, it's very limited. it's particle based and i believe only does collision detection at each particle, so the edges of a box made out of particles will just pass though level and other object geometry (meaning anything other than small objects isn't going to work right). object stacking is out of the question with something like this, if you tried it out i'm sure you'd have a very hard time getting just one object to stay on top of another, and you probably couldn't for more than a few seconds. ragdolls would be possible to add but are very awkward to make and difficult to tune properly using an engine like this.Originally Posted by reader quoted on article
this really can't compare at all to the physics engine used in hl2, which itself barely supported even small amounts of (stable) object stacking (at the time of initial release anyway, i would imagine they've probably released updates to the physics engine since then).
anyway things have come a long way since the methods used by this engine were first developed. while it may not be of much practical use today, it could still useful as a learning aid for those who would like to get an idea of how this sort of stuff works. it being written in quakec may actually be an advantage in this area, as i would imagine it would make it easier to experiment with.
TECHNICAL DESCRIPTION: the engine looks like it was based off the methods presented by Thomas Jakobsen years ago at one of the gdc events. it's a verlet particle based method supporting only stick/distant constraints between pairs of particles, which is then solved by what essentially amounts to a (hacky) newton/non-linear gauss-seidel type solver. if implemented properly (and carefully) this could actually deliver some decent results without a lot of additional work, particularly since the quake engines were built with point/ray based collision dection in mind.


Reply With Quote