Thought I'd link to my old Modelview mod, which allows darkplaces developers to use the engine as a modelviewer. Sources tell me it's been popular and useful, and should be advertised. Seeing as it's more than five years old, it's awfully behind in supported features, but it's still pretty good to pose models based on animation frame, plus checking that attachments work as they should, perhaps more. Enjoy! PS: Make sure to read the included Readme, or you'll have a hard time using it! It uses say commands, no GUI.
Twig Physics Library for DarkPlaces by Urre & LordHavoc
Thanks to: Electro for the awesome logo!
tZork for debugging and helping find what should have been an obvious bug
frank for support, discussion and ideas
Ender for Scratch tutorials
div0 for the automatic DP SVN build script
scar3crow for help with the readme
Spike for FTEQCC
Description: QuakeC physics-library for use in DarkPlaces powered mods and games. Currently capable of creating simple rigid objects, such as crates, barrels, hanging/dangling objects. NOTE: the readme gives a more in-depth description, and documentation to some extent, how to use the editor for example.
Q: Why? Why not make it a proper addition written in C for the DarkPlaces engine?
A: Dunno. Seriously though, there are many reasons. One is, I simply wanted to see if it's possible to do it. Another is that it's nice to have the control provided by the fact that you can access all the physics-related stuff from the gamecode directly, without having to rely on builtins which might be too limited for the purpose you're after. The more major reason is because when I started working on it, I didn't know C at all, and the description I read on these kinds of physics sounded like it'd work just fine within the limits of QC, and I've always wanted a physics-engine for DP, so I just went and did it.
Q: Can I make vehicles with this?
A: Not really, yet. It's a planned feature for future releases.
Q: Can this be made into a sort of Garrys mod?
A: Sure! The amount of work depends on the amount of features you want to support.
Q: Can this do real ragdolls?
A: Planned feature :)
Q: What about Sagdoll? Can it align corpses to slopes?
A: Twig is very modular. It doesn't have an understanding of "corpses" per se, it's just physics. You can make a corpse have physics, which would already do more than you're asking for. The short answer is no, because aligning corpses, or the more advanced kind of alignment that Sagdoll does, is more like gamecode than physics code.
Q: Does it support Gyro/does it do stuff Gyro does?
A: Supporting, maybe. You could make particles Gyro-objects, and it should work, might even be an interesting combo. About doing the things Gyro does... Gyro does stuff which is closer to gamecode rather than physics, but more modular than say Sagdoll, so it's sort of in-between. Twig will do many of the things Gyro does, just differently. Gyro is mostly about the interaction between objects, whereas Twig is more about the single object. Interaction between objects is much closer to gamecode-related things, and thus not as interesting for the purpose of Twig. Twig will handle the more physics-heavy things such as collisions between the objects, but things like explosions pushing stuff is up for the user to code.
Q: Can you make it read .obj's for physics-object info
A: For future releases, if so.
Q: Can I use this in Nexuiz?
A: Certainly! Nexuiz' gamecode is written in QC, just like this lib.
Q: Can I use this with Frikbot?
A: Should be entirely possible, but will probably require a lot of reworking of the bots AI, to understand the objects and their properties. If you don't care about the Frikbots interacting with the objects besides perhaps colliding with them, it would work without modifying the bot.
Q: Can stick-physics be used for clients and/or monsters?
A: Theoretically, sure. Currently things like hinge-constraints and motors aren't supported, so it'd be very hard or hacky. But even if those were supported, the amount of AI-work it'd take to do it is insane, totally major graduate level AI stuff. I can totally understand the fascination about this. See Euphoria for this theory in action, and Sumotori Dreams.
Q: Can this be used clientside?
A: Surely! Some future release will be made specificly with this in mind, but if you're CSQC proficient, it's not hard to port.
Q: What's the framerate impact of a typical 'stick'?
A: Well, a single stick will probably have no impact at all, atleast very hard to measure. An easier way to see it is this: In loose terms, the constraints are the most taxing part of the operation. For every particle you add to a physics-object, you have to add sticks between all the other particles, which means more constraints to solve to keep the shape of the object ingame. Two particles means one stick, three particles means three sticks, four particles means six sticks, five particles means ten sticks, and so forth. A very simple box is, like mentioned before, eight particles, and twenty-eight sticks.