R: [Plib-users] ssg physics
Brought to you by:
sjbaker
From: Paolo L. <p.l...@ci...> - 2004-04-22 15:01:39
|
Simon, It's a pity to have missed/underevaluated the topic in the list, infact this is a cool topic for me presently. I'm in the process of first-evaluating-then-start-designing an interface (of Plib-SSG) with OpenDE (formerly ODE) - Open Dynamics Engine. The idea is to introduce in my Plib-based viewer the ability to realisticly manipulate CAD originated geometries with a CyberGlove, which the viewer is already interfaced to. In this case gravitiy or spring-based action/reaction is not sufficient, so the choice of the "hard work" with OpenDE. In the rest of this talk I'll suppose you have a minimum SSG knowledge, otherwise I could have misunderstood the quest for the call. About the how-to, you can link whatever information to SSG nodes by set/getting the userdata: this is actually a pointer to a ssgEntity, so if you subclass from both ssgEntity and your nodedata class, you can pass it to those methods cleanly (no cast, please) and get ref counting. However the userdata is a way to make a node points to some information, so in this it's a "passive" mechanism. For getting something "active" consider using the node callbacks. Depending on the type of node there are pre/post draw, pre/post traversal, and, for state nodes there's just an apply-time callback. A limitation is that only one pre-somethig and one post-something callback per node can be set, so, for example in my application I have no callback slot free. We should extend this useful mechanism in 2.0 to multiple callbacks of the same type, isn't it? It shouldn't add performance penality. Regarding how to get the geometry off a ssgLeaf, proper get methods are available in the class for this. Usually collision detection is the only part of a physics engine where object geometry is taken into account, so, especially if you have complex geometries, an efficient way to pass scene graph meshes to the engine is key to memory consumption. Depending on how the geometry is collected by the physics engine, simple pointers to graphs' vertices/triangle indices structures could suffice (optimal case - no duplication), or an actual translation in engine's mesh format could require data duplication. If you are designing your own engine, of course consider not duplicating and complain to the low-level arrays format. For both the tasks a depth walk into a ssg will be needed in the pre-processing phase (once in the program execution) for establishing the needed cross-pointer network between the scene graph and the engine. A simple recursive function does acomplish the task - should you need one just ask it me. Finally there are methods in the ssgTransform nodes (the "father" of the array of leafs which contains the actual object geometry) to set transformation for the sub-graph nodes. So after your engine has determined the new position for an object you can set it by one of the multiple ways to set transformation data (position and/or orientation, the whole 4x4 matrix, and converting from/to quaternions through the SG library functions). Note that for data loaded by the 3DS loader, and most other ssg loader I think, the setName method does point to an ssgTransform, i.e. an object "starts" from the parent transformation node of its geometry. My opinion is that the physics engine *can* be "external" to the scene graph class, and some "wrapping" layer could put the engine in communication with the graph. But I could change opinion in the progress of my problem analysis. My last effort has been to make nvidia hardware shadow mapping to work with SSG, and, despite of thinking it could have a strict relation with ssgCullAndDraw internals, I call it but I didn't modified it or wrote my own. Nice to come back on this topic - Paolo -----Messaggio originale----- Da: pli...@li... [mailto:pli...@li...] Per conto di Simon Inviato: gioved=EC 22 aprile 2004 8.29 A: pli...@li... Oggetto: [Plib-users] ssg physics Hi, heres a summary of it all: I said - Hi, a while ago I posted about trying to hook up a physics engine to ssg. I don=92t recall getting any replies. I was wondering = if someone could give me an over view of how they go about adding things like gravity to each object. I have the feeling that I=92m missing something really basic. Wolfram said - Normally, you do something like this per iteration of the physics engine: calc forces=20 convert to accelaration speed =3D speed + accelaration * deltatime position =3D position + speed * deltatime In your case, accelaration is constant Then I said - Hi, thanks Wolfram its great to get a reply although I don=92t think I explained myself very well. The aim I=92m trying to = reach is to have a stack of blocks on top of each other. I then want to knock them down. I found this great physics example to do with dice falling down some stairs. I can get it to work with a non plib scene but I was trying to link it to an ssg tree. What I really want to know is how everyone goes about that. =20 In the non plib demo each object maintains a set of physics related properties. There is also a physics class that each inherits from. Basically the physics engine runs constantly and checks then updates each object in relation to each other object. I think in just writing this I am beginning to work the answer out myself. Isnt it funny how sometimes just writing or saying something out loud can make things so much clearer. So now I guess the question is should the physics engine class be added to the tree or left to run outside of it? It=92s a little difficult for me to recall everything as the project has been on hold until this bit gets worked out. For anyone interested; the demo that I=92m basing this on for now is from Chris Haag. I got it off his site originally but that seems to be down at the moment. Theres a copy of it on the NeHe site: http://nehe.gamedev.net/data/downloads/download.asp?letter=3DS It=92s called Stairs by Chris Haag. Thanks for the patience, if I get it to work then I could submit it as an ssg example. I=92m using the 3D Studio loader for the dice and the stairs so the example would incorporate that as well. At that point Adam said - (Feel free to correctme here guys.. ) My understanding is that with game design, the graphics engine (which=20 utilized the scene graph) and the physiscs engines are kept separate. An=20 object in question (say a car or a block in your example) has access to both=20 a physics model that represents it's behavior, as well as a pointer to it's=20 relevant information in the scene graph. That way, everytime you update an=20 object, it gathers information from it's current state and the physics=20 model, and then uses that information to manupulate it's characteristics within the scene graph. And that=92s when I sent the mail that you got and didn=92t know what it = was about. |