Re: [osg-users] [osgPhysics] Project osgPhysics started!
Dear All, I used OpenTissue for some physics simulation application with osg for rendering. Vista.bibalex.org As i red the PAL will support OpenTissue sooner. I think the multi threading is a must, it is the future, because we must use all of our cores specialty in such heave application. My problem with the physics simulation is that the render time only take much time. So what about OpenTissue calculation. it is not a real time physics engine. I used an idea such as Sukender one but with out locking any thread. This because I have one thread(physics) put data in a shared memory and one thread (OSG) read this data. And because it is not necessary to draw all nodes of osg in the same time step of physics. I don't care, draw as much and as fast as you can,this is my case. And this help me a lot spatially in make the navigation in osg very fast. But what is the shared memory. It is of course the position of every node. So what we need to do,i think, is 1- a stander PositionAttitudeTransform like node. it is thread or not thread safe. 2- A traversal that read the scene graph in the first step only and fill the physics with its suitable form of node conversion. Of course with or without our hints. So we don't want to modifying the OSG code much. and use multi threading. of course if we can modified the osg nodes to handle the PAL. it will use much less memory and be more fast for one thread. But it will be much more difficult to make it multi threading. So overall speed will be less. I can work with you on osgPhysics if you want. I am in Egypt :) Thanks, Ahmed Nawar Software Engineer, ICT Department, Bibliotheca Alexandrina, P. O. Box 138, Shatby, Alexandria 21526, Egypt, Tel: +(203) 483 , Extension: 1463, Email: ahmed.na...@bibalex.org, Web Site: www.bibalex.org, From: osg-users-boun...@lists.openscenegraph.org [osg-users-boun...@lists.openscenegraph.org] On Behalf Of Paul Martz [pma...@skew-matrix.com] Sent: Thursday, January 15, 2009 1:18 AM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] [osgPhysics] Project osgPhysics started! Well, is it possible to run n times PUT, and then one time the standard frame (update/cull/draw)? If so, there should be no problem. It's possible to do it that way, but the display frame rate will suffer if the physics computation gets expensive. In my own work, I am stepping the physics simulation once, then calling osgViewer::Viewer::frame(), and I'm already seeing framerate issues when interactions get complex. If you want to step the physics simulation multiple times, it'll be even more of an issue. I think putting the physics simulation in a separate thread will make this less of a problem. It's also simpler, because it doesn't require osgPhysics to invade osgViewer, which I personally think is a bad idea. OSG has a lot of mechanisms that allow you to do physics without modifying the OSG code. I'm able to do a full Bullet physics simulation in my project, and haven't modified one line of OSG (just derived a few classes). Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPhysics] Project osgPhysics started!
Hi Sukender, On Wed, Jan 14, 2009 at 8:59 PM, Sukender suky0...@free.fr wrote: Well, multithreading *is* an issue, but we need to address the problem. I guess the order of steps would be: - When it is time to update the physics, run the physics update traversal (say PUT) in a physics thread - PUT - PUT - ... - When the times come to update the display, lock the physics thread so that no PUT runs - Run the display update traversal (DUT) in a display thread. During this, copy physics positions/orientations to transforms. - Unlock the physics. - PUT (physics thread), cull and draw (display thread) - and so on. Am I right? I'm not sure about threads because here the PUT cant run when DUT runs, so the interest is limited, even if cull and draw steps would be in parallel of a PUT. Maybe there could be improvements. Any idea? I would suggest supporting decoupling of the rendering and physics threads as much as possible, without either one blocking the other. The way I would tackle this would be via thread safe data buffers that can be read by the rendering thread, and written to by the physics thread, this buffer would typically be a matrix (or similar transform representation) with a time stamp, new entries would be push to the end of buffer, and then the rendering thread would pull at the time interval required - perhaps interpolating between two entries or even estimating the position beyond last entry if physics is lagging behind. This type of buffer need only have one mutex and would only be locked when the physics thread pushes data into it, and when the rendering thread pulls data from it. This way neither threads should be halted and will run happily decoupled. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPhysics] Project osgPhysics started!
(coninued...) I forgot to mention a thing about interpolating. Yes, this could be a nice idea to interpolate (or extrapolate) data, but I think this is a great risk for something that may not be very useful for common physics usage. I belive that realtime engines generally run at something like 50 or 100Hz (one can of course be much slower or much faster), so you may loose much time trying to interpolate; and moreover you may introduce inconstistencies (such as objects interpenetrating). So I guess simply reading the last matrix is enough. This is what I do in my engine (not multithreaded yet), and it works without lagging. I simply created a main loop that takes care of running physics or display when necesssary. Maybe you have a different point of view on that? I'd be happy to read! And what about other types of engines (non realtime)? I suppose interpolating could be possible, but I still think we introduce simulation errors. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 15 Jan 2009 11:48:48 +0100, Sukender suky0...@free.fr a écrit: Hi Robert, I like your idea. I'm not a threading expert, but won't this cost much? I mean locking/unlocking is quite expensive, as far as I know, and depending on the number of matrices to lock, this could cost much. Anyway much less that waiting for a complete traversal to end, of course! :) Maybe our implementation could be a ThreadSafeMatrixTransform... Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 15 Jan 2009 10:10:05 +0100, Robert Osfield robert.osfi...@gmail.com a écrit: Hi Sukender, On Wed, Jan 14, 2009 at 8:59 PM, Sukender suky0...@free.fr wrote: Well, multithreading *is* an issue, but we need to address the problem. I guess the order of steps would be: - When it is time to update the physics, run the physics update traversal (say PUT) in a physics thread - PUT - PUT - ... - When the times come to update the display, lock the physics thread so that no PUT runs - Run the display update traversal (DUT) in a display thread. During this, copy physics positions/orientations to transforms. - Unlock the physics. - PUT (physics thread), cull and draw (display thread) - and so on. Am I right? I'm not sure about threads because here the PUT cant run when DUT runs, so the interest is limited, even if cull and draw steps would be in parallel of a PUT. Maybe there could be improvements. Any idea? I would suggest supporting decoupling of the rendering and physics threads as much as possible, without either one blocking the other. The way I would tackle this would be via thread safe data buffers that can be read by the rendering thread, and written to by the physics thread, this buffer would typically be a matrix (or similar transform representation) with a time stamp, new entries would be push to the end of buffer, and then the rendering thread would pull at the time interval required - perhaps interpolating between two entries or even estimating the position beyond last entry if physics is lagging behind. This type of buffer need only have one mutex and would only be locked when the physics thread pushes data into it, and when the rendering thread pulls data from it. This way neither threads should be halted and will run happily decoupled. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPhysics] Project osgPhysics started!
Hi Paul, I'm not really sure the framerate would suffer. Actually this is what I do in my engine (I use ODE). There is absolutely no problem running 3 physics steps and then one display step. Of course this would depend on the complexity of the scene! Anyway, as explained in another post, I created a main loop that takes care of the framerate for each part (physics, display) and that fire off steps when necessary (without changing OSG code). Anyway, threading would of course be better... Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 15 Jan 2009 00:18:19 +0100, Paul Martz pma...@skew-matrix.com a écrit: Well, is it possible to run n times PUT, and then one time the standard frame (update/cull/draw)? If so, there should be no problem. It's possible to do it that way, but the display frame rate will suffer if the physics computation gets expensive. In my own work, I am stepping the physics simulation once, then calling osgViewer::Viewer::frame(), and I'm already seeing framerate issues when interactions get complex. If you want to step the physics simulation multiple times, it'll be even more of an issue. I think putting the physics simulation in a separate thread will make this less of a problem. It's also simpler, because it doesn't require osgPhysics to invade osgViewer, which I personally think is a bad idea. OSG has a lot of mechanisms that allow you to do physics without modifying the OSG code. I'm able to do a full Bullet physics simulation in my project, and haven't modified one line of OSG (just derived a few classes). Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPhysics] Project osgPhysics started!
(coninued again... sorry for posting multiple times!) I got a problem about using a kind of ThreadSafeMatrixTransform... What if object 1 is updated, but not object 2 when display update traversal (DUT) happens? Well we would see inconsistencies (like interpenetrations) too... So I'm wondering if DUT and PUT are mutually exclusive... What are your thoughts on this? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 15 Jan 2009 12:04:41 +0100, Sukender suky0...@free.fr a écrit: I forgot to mention a thing about interpolating. Yes, this could be a nice idea to interpolate (or extrapolate) data, but I think this is a great risk for something that may not be very useful for common physics usage. I belive that realtime engines generally run at something like 50 or 100Hz (one can of course be much slower or much faster), so you may loose much time trying to interpolate; and moreover you may introduce inconstistencies (such as objects interpenetrating). So I guess simply reading the last matrix is enough. This is what I do in my engine (not multithreaded yet), and it works without lagging. I simply created a main loop that takes care of running physics or display when necesssary. Maybe you have a different point of view on that? I'd be happy to read! And what about other types of engines (non realtime)? I suppose interpolating could be possible, but I still think we introduce simulation errors. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 15 Jan 2009 11:48:48 +0100, Sukender suky0...@free.fr a écrit: Hi Robert, I like your idea. I'm not a threading expert, but won't this cost much? I mean locking/unlocking is quite expensive, as far as I know, and depending on the number of matrices to lock, this could cost much. Anyway much less that waiting for a complete traversal to end, of course! :) Maybe our implementation could be a ThreadSafeMatrixTransform... Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 15 Jan 2009 10:10:05 +0100, Robert Osfield robert.osfi...@gmail.com a écrit: Hi Sukender, On Wed, Jan 14, 2009 at 8:59 PM, Sukender suky0...@free.fr wrote: Well, multithreading *is* an issue, but we need to address the problem. I guess the order of steps would be: - When it is time to update the physics, run the physics update traversal (say PUT) in a physics thread - PUT - PUT - ... - When the times come to update the display, lock the physics thread so that no PUT runs - Run the display update traversal (DUT) in a display thread. During this, copy physics positions/orientations to transforms. - Unlock the physics. - PUT (physics thread), cull and draw (display thread) - and so on. Am I right? I'm not sure about threads because here the PUT cant run when DUT runs, so the interest is limited, even if cull and draw steps would be in parallel of a PUT. Maybe there could be improvements. Any idea? I would suggest supporting decoupling of the rendering and physics threads as much as possible, without either one blocking the other. The way I would tackle this would be via thread safe data buffers that can be read by the rendering thread, and written to by the physics thread, this buffer would typically be a matrix (or similar transform representation) with a time stamp, new entries would be push to the end of buffer, and then the rendering thread would pull at the time interval required - perhaps interpolating between two entries or even estimating the position beyond last entry if physics is lagging behind. This type of buffer need only have one mutex and would only be locked when the physics thread pushes data into it, and when the rendering thread pulls data from it. This way neither threads should be halted and will run happily decoupled. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPhysics] Project osgPhysics started!
Hi Sukender, What happens if OSG updates the scene while the physics do the same??? In my case i will have some of the nodes with time t and some with t-1. but this will be fixed in almost the second osg frame ( osg is much more fast than physics) and because osg scene graph is separated from physics nodes. this will not Affect the result of physics. (Else we have to buffer values.) So what we need to do,i think, is 1- a stander PositionAttitudeTransform like node. it is thread or not thread safe. 2- A traversal that read the scene graph in the first step only and fill the physics with its suitable form of node conversion. Of course with or without our hints. I'm sorry but I don't understand what you mean. 1- PositionAttitudeTransform like node is your ThreadSafeMatrixTransform. In it we must make sure that when PUT change the data The DUT will not change any value in it while draw. 2- what we want is a conversion from OSG scene node to PAL. this conversion will be done in the first step only. we can add a abstract conversion method and all nodes must overwrite it. (it must handle complex scene and this was not in my case. my case was PositionAttitudeTransform for each graph boxes and spheres i want to simulate there behave) So I'm wondering if DUT and PUT are mutually exclusive I think it will be because DUT is much more faster than PUT. thanks, Ahmed Nawar From: osg-users-boun...@lists.openscenegraph.org [osg-users-boun...@lists.openscenegraph.org] On Behalf Of Sukender [suky0...@free.fr] Sent: Thursday, January 15, 2009 1:23 PM To: OpenSceneGraph Users Subject: Re: [osg-users] [osgPhysics] Project osgPhysics started! Hi Ahmed, I think the multi threading is a must [...] 100% agreed :) I used an idea such as Sukender one but with out locking any thread. This because I have one thread(physics) put data in a shared memory and one thread (OSG) read this data. Is it like a ThreadSafeMatrixTransform? What happens if OSG updates the scene while the physics do the same??? So what we need to do,i think, is 1- a stander PositionAttitudeTransform like node. it is thread or not thread safe. 2- A traversal that read the scene graph in the first step only and fill the physics with its suitable form of node conversion. Of course with or without our hints. I'm sorry but I don't understand what you mean. I can work with you on osgPhysics if you want. Well, that's if *you* want! :) Sice osgPhysics is opened to anyone. Feel free to discuss with us, or propose code changes. And if you want write access to the SVN repository, then you should give us your SF.net UNIX name. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPhysics] Project osgPhysics started!
Hi Robert, So, to avoid having two objects updated with 2 different time stamps, is it ok if I: - Fill matrix buffers with physics timestamped matrices (PUT - physics thread) - Update in a batch all the display matrices from the latest timestamp that is available over all buffers (display thread) - Remove data that is before that timestamp on all buffers. But then, does the batch be done before, or during the display update traversal? Does a kind of circular buffer that can grow as vector could be the best structure for the buffer (if we reserve enough at the begining)? Does that solution cost much RAM if we have a physics that run very frequently (Ex: 1kHz)? Or may we create a buffer that only stores 2 latest matrices since there is no reason for the physics to not update all objects? I suggest then our buffer to be a Thread safe structure with 2 matrices + 1 time stamp (latest one). Your thoughts? :) Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 15 Jan 2009 12:21:47 +0100, Robert Osfield robert.osfi...@gmail.com a écrit: Hi Sukender, On Thu, Jan 15, 2009 at 10:48 AM, Sukender suky0...@free.fr wrote: I like your idea. I'm not a threading expert, but won't this cost much? I mean locking/unlocking is quite expensive, as far as I know, and depending on the number of matrices to lock, this could cost much. Anyway much less that waiting for a complete traversal to end, of course! :) Maybe our implementation could be a ThreadSafeMatrixTransform... Perhaps a custom or user data callback would be sufficient for managing the common data buffer, this way you could adapt the buffer for different purposes. As for the cost of the locking and unlocking - this is actually pretty low, you don't want to be doing thousands of locks/unlocks per frame, so if you do have a scene with many separate entities that are being modelled then having composite buffers that have a single mutex between them, and do a sync data to and from this buffer on batch rather than each buffer individually would avoid making too many lock/unlock calls. As for the interpolation vs choosing the most value, this is something that could easily be done via an option on the reading side - or simply have two different update callbacks that read from the buffers in different ways. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPhysics] Project osgPhysics started!
Hi Ahmed, In my case i will have some of the nodes with time t and some with t-1. This may be not a problem with OpenTissue, but may be one for other engines. I think we should adress that problem. 2- what we want is a conversion from OSG scene node to PAL. this conversion will be done in the first step only. So you build your OSG scene and then create a PAL equivalent? I must say this is a suprising approach! I have the intention of manually creating the physics... because in many applications, physics objects are not exactly what you see (they are often simplified). I suggest that your OSG to physics conversion should be an additional (and separated) feature for those who want to use it. I think it will be because DUT is much more faster than PUT. This ay depend a lot on what you are simulating :) I personnaly won't made such an assertion for osgPhysics. Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 15 Jan 2009 12:51:02 +0100, Ahmed Nawar ahmed.na...@bibalex.org a écrit: Hi Sukender, What happens if OSG updates the scene while the physics do the same??? In my case i will have some of the nodes with time t and some with t-1. but this will be fixed in almost the second osg frame ( osg is much more fast than physics) and because osg scene graph is separated from physics nodes. this will not Affect the result of physics. (Else we have to buffer values.) So what we need to do,i think, is 1- a stander PositionAttitudeTransform like node. it is thread or not thread safe. 2- A traversal that read the scene graph in the first step only and fill the physics with its suitable form of node conversion. Of course with or without our hints. I'm sorry but I don't understand what you mean. 1- PositionAttitudeTransform like node is your ThreadSafeMatrixTransform. In it we must make sure that when PUT change the data The DUT will not change any value in it while draw. 2- what we want is a conversion from OSG scene node to PAL. this conversion will be done in the first step only. we can add a abstract conversion method and all nodes must overwrite it. (it must handle complex scene and this was not in my case. my case was PositionAttitudeTransform for each graph boxes and spheres i want to simulate there behave) So I'm wondering if DUT and PUT are mutually exclusive I think it will be because DUT is much more faster than PUT. thanks, Ahmed Nawar From: osg-users-boun...@lists.openscenegraph.org [osg-users-boun...@lists.openscenegraph.org] On Behalf Of Sukender [suky0...@free.fr] Sent: Thursday, January 15, 2009 1:23 PM To: OpenSceneGraph Users Subject: Re: [osg-users] [osgPhysics] Project osgPhysics started! Hi Ahmed, I think the multi threading is a must [...] 100% agreed :) I used an idea such as Sukender one but with out locking any thread. This because I have one thread(physics) put data in a shared memory and one thread (OSG) read this data. Is it like a ThreadSafeMatrixTransform? What happens if OSG updates the scene while the physics do the same??? So what we need to do,i think, is 1- a stander PositionAttitudeTransform like node. it is thread or not thread safe. 2- A traversal that read the scene graph in the first step only and fill the physics with its suitable form of node conversion. Of course with or without our hints. I'm sorry but I don't understand what you mean. I can work with you on osgPhysics if you want. Well, that's if *you* want! :) Sice osgPhysics is opened to anyone. Feel free to discuss with us, or propose code changes. And if you want write access to the SVN repository, then you should give us your SF.net UNIX name. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPhysics] Project osgPhysics started!
Hi Sukender, On Thu, Jan 15, 2009 at 12:06 PM, Sukender suky0...@free.fr wrote: So, to avoid having two objects updated with 2 different time stamps, is it ok if I: - Fill matrix buffers with physics timestamped matrices (PUT - physics thread) - Update in a batch all the display matrices from the latest timestamp that is available over all buffers (display thread) - Remove data that is before that timestamp on all buffers. I'd have one time stamp per matrix/value that is pushed in from the physics thread, and then the rendering thread pulls the appropriate matrix/maitrces/values according to the time stamp(s) that look most appropriate. One could also do a batch copy of from all the buffers to all the scene graph related values at one time. As for the data structure required, a custom ring buffer implemented on top of a std::vector would probably work just fine. However, I'm just waving my hands around, I haven't actually done much work with physics integration personally, others who've been there and done that would probably be best placed to give the low level recommondations. Does that solution cost much RAM if we have a physics that run very frequently (Ex: 1kHz)? Or may we create a buffer that only stores 2 latest matrices since there is no reason for the physics to not update all objects? If you running at really high frequences then one would need to take in account how big these buffers might get, in which case you'd want to cut down the number of matrices/values you store, perhaps not even record them every frame, all the rendering thread needs to one matrix/value per frame. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPhysics] Project osgPhysics started!
Hi Sukender, On Thu, Jan 15, 2009 at 10:48 AM, Sukender suky0...@free.fr wrote: I like your idea. I'm not a threading expert, but won't this cost much? I mean locking/unlocking is quite expensive, as far as I know, and depending on the number of matrices to lock, this could cost much. Anyway much less that waiting for a complete traversal to end, of course! :) Maybe our implementation could be a ThreadSafeMatrixTransform... Perhaps a custom or user data callback would be sufficient for managing the common data buffer, this way you could adapt the buffer for different purposes. As for the cost of the locking and unlocking - this is actually pretty low, you don't want to be doing thousands of locks/unlocks per frame, so if you do have a scene with many separate entities that are being modelled then having composite buffers that have a single mutex between them, and do a sync data to and from this buffer on batch rather than each buffer individually would avoid making too many lock/unlock calls. As for the interpolation vs choosing the most value, this is something that could easily be done via an option on the reading side - or simply have two different update callbacks that read from the buffers in different ways. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPhysics] Project osgPhysics started!
Hi Robert, hi all, Robert, I didn't say it before, but thanks for giving us your thoughts/ideas. So there is, IMO, 3 viable solutions: 1. A simple thread safe matrix transform. Benefits: Simple and fast. Drawbacks: You may have t and t-1 matrices. Can't do interpolations/extraploations. That may fits some needs (OpenTissue as Ahmed explained?), but not be the common solution I guess. 2. A full thread safe timestamped matrix buffer (your idea), with an option to record matrices once each n-th physics frame. Benefits: Can handle complex updates, like interpolations and such. Useable with any engine. Drawbacks: Complex, and may consume RAM and CPU (reallocations of buffers when there is a lag). 3. A thread safe structure with 2 matrices + 1 time stamp Benefits: Intermediate solution that fits most engines and usages. Drawbacks: Physics engine must update all matrices on each update. Can't do interpolations/extraploations. I suggest we provide the user multiple possible implementations (by the way of a pre-processor define?). Does that sounds good? About getting the best framestamp (for solution 2), I think it is far safer to do a batch update to avoid having t and t-1 matrices, as in solution 1. Or we may let the user do a custom processing by simply giving him/her the latest framestamp that is common to all buffers? I'm waiting for comments! :) Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 15 Jan 2009 13:42:54 +0100, Robert Osfield robert.osfi...@gmail.com a écrit: Hi Sukender, On Thu, Jan 15, 2009 at 12:06 PM, Sukender suky0...@free.fr wrote: So, to avoid having two objects updated with 2 different time stamps, is it ok if I: - Fill matrix buffers with physics timestamped matrices (PUT - physics thread) - Update in a batch all the display matrices from the latest timestamp that is available over all buffers (display thread) - Remove data that is before that timestamp on all buffers. I'd have one time stamp per matrix/value that is pushed in from the physics thread, and then the rendering thread pulls the appropriate matrix/maitrces/values according to the time stamp(s) that look most appropriate. One could also do a batch copy of from all the buffers to all the scene graph related values at one time. As for the data structure required, a custom ring buffer implemented on top of a std::vector would probably work just fine. However, I'm just waving my hands around, I haven't actually done much work with physics integration personally, others who've been there and done that would probably be best placed to give the low level recommondations. Does that solution cost much RAM if we have a physics that run very frequently (Ex: 1kHz)? Or may we create a buffer that only stores 2 latest matrices since there is no reason for the physics to not update all objects? If you running at really high frequences then one would need to take in account how big these buffers might get, in which case you'd want to cut down the number of matrices/values you store, perhaps not even record them every frame, all the rendering thread needs to one matrix/value per frame. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPhysics] Project osgPhysics started!
Hi Sukender, hi all, I would first introduce the implementation of osgPhysics at present: 1. Create a World (derived from Group) instance. 2. Create some RigidActor (derived from Transform) instances and add them as the World's children. 3. While the simulation running, the World will have a UpdateCallback to update itself and all its children RigidActors (calling their update() functions). 4. The matrix of each RigidActor will be got from computeLocalToWorldMatrix() funtion, which is automatically called during the culling traversal. And the object is rendered at specific position. And it works fine with few objects and a single world. You may have a look at the latest SVN version. If the physics simulation is put into another thread and thus have one or more PUTs parallel to the DUT, we may have to create a fix-sized queue for maintaining matrices of every RigidActor. In this case, I suggest we create a read callback and a write callback, to lock/unlock the queue during every DUT, and dispatch them to RigidActor nodes. And the FIFO (first-in, first-out) queue would have a *user-defined* size, and store framestamp-matrices data. I don't deeply read all the posts but think my thoughts a little samiliar with Robert's, but leave the decision to users. So customers may set size of buffer to 2, like Sukender suggests. This mechanism may only affect rigid actors and may be confusing if we have more than one world (it's possible in PhysX). Maybe we have to discuss it again and again and be coding again and again, to get the final result. I'd like to first try to realize soft bodies with geometry shader / VBO in these days. And Sukender and I would make an initial multi-threaded physics update traversal and see its effects ASAP. :) Cheers, Wang Rui ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPhysics] Project osgPhysics started!
Hi Robert, hi all, I got a question! Robert and I discussed the fact that the future osgAudio may have a specific update traversal. 1. Do you think it could be wise to do a similar physics update traversal for osgPhysics? 2. If so, is there a way to code things in OSG so that osgPhysics could benefit from it WITHOUT disturbing existing OSG apps? 3. And finally, is there be someone to code it, or could you send your thought/ideas? Thank you! Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPhysics] Project osgPhysics started!
Hi Sukender, Gratulations to the newly started project! I had created a subforum (osgPhysics) on our forum. I've also connected the [osgPhysics] tag with this forum. Hence we have a direct place where to post or where to read the related questions ;) Best regards, art -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=4570#4570 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPhysics] Project osgPhysics started!
Hi Art, I forgot to ask you about the tag on the forum, and you did it! Marvelous! :) Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Wed, 14 Jan 2009 15:59:08 +0100, Art Tevs stud_in...@yahoo.de a écrit: Hi Sukender, Gratulations to the newly started project! I had created a subforum (osgPhysics) on our forum. I've also connected the [osgPhysics] tag with this forum. Hence we have a direct place where to post or where to read the related questions ;) Best regards, art -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=4570#4570 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPhysics] Project osgPhysics started!
Well, the problem is that physics don't run at the same rate as display. For instance, we should run a physics update traversal at 100Hz, and the normal update traversal the fastest possible (well, limited by the VSYNC). Then the physics update would run in a separate thread, and you'd need some mechanism to pull the physics state into OSG during the update traversal. I guess I don't understand why this pull couldn't be done in the existing update traversal. You can always fire off custom traversals from the existing traversals. Hum... do we need to modify the viewer source? I guess so... I think what Robert is talking about is something like launching a physics simulation step from a root node update callback (for example). This doesn't require modifying osgViewer. But I don't think this would satisfies your requirement to run the physics simulation at a different rate from the display. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPhysics] Project osgPhysics started!
I'm using PAL for a physics integration with delta3d. I'm still confused about why people want to integrate things like physics and audio into a scene graph, but that aside, I am adding features and such to PAL since I have commit access. We should all work together implementing features in PAL so we don't duplicate effort. I'm going to be working on adding support for collision masks, then I'm going to look at doing a character model interface. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPhysics] Project osgPhysics started!
Hi Paul, Sukender et al, On Wed, Jan 14, 2009 at 5:01 PM, Paul Martz pma...@skew-matrix.com wrote: Then the physics update would run in a separate thread, and you'd need some mechanism to pull the physics state into OSG during the update traversal. I guess I don't understand why this pull couldn't be done in the existing update traversal. This is an important point - how to handle the concurrency, effectively we'd need to have parts of the scene graph cloned by the rendering scene graph and the physics scene graph, the rendering scene graph pulling values from the physics scene graph. The physics scene graph may well be identical, but have a thread just working on different elements that the rendering thread doesn't modify - such as a cached matrices or meshes. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPhysics] Project osgPhysics started!
Hi Paul,
Thanks for the answer... and thanks for improving osgPhysics by the way of
discussion.
Well, the problem is that physics don't run at the same rate as
display.
Then the physics update would run in a separate thread, and you'd need some
mechanism to pull the physics state into OSG during the update traversal.
I guess I don't understand why this pull couldn't be done in the existing
update traversal.
Well, multithreading *is* an issue, but we need to address the problem.
I guess the order of steps would be:
- When it is time to update the physics, run the physics update traversal
(say PUT) in a physics thread
- PUT
- PUT
- ...
- When the times come to update the display, lock the physics thread so that no
PUT runs
- Run the display update traversal (DUT) in a display thread. During this,
copy physics positions/orientations to transforms.
- Unlock the physics.
- PUT (physics thread), cull and draw (display thread)
- and so on.
Am I right? I'm not sure about threads because here the PUT cant run when DUT
runs, so the interest is limited, even if cull and draw steps would be in
parallel of a PUT. Maybe there could be improvements. Any idea?
You can always fire off custom traversals from the existing traversals.
Hum... do we need to modify the viewer source? I guess so...
I think what Robert is talking about is something like launching a physics
simulation step from a root node update callback (for example). This doesn't
require modifying osgViewer. But I don't think this would satisfies your
requirement to run the physics simulation at a different rate from the
display.
Well, is it possible to run n times PUT, and then one time the standard frame
(update/cull/draw)? If so, there should be no problem.
For now, physcs objects are updated manually, by calling something like for
each object { object-update(); } because all objects are known by a single
class (the World). The PUT could simply be that kind of loop (instead of a
full traversal)... what is the best design, according to you?
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPhysics] Project osgPhysics started!
Hi David, Thanks for the info. And yes, you're right about implementing features in PAL. About the integration of audio and physics, we aim at giving users an easier access to features often coupled with scene graphs. Doesn't it make sense for you? Or maybe we're not talking about the same thing!? I belive that providing a layer that facilitates the use of a physics engine would give users an additional reason to use OSG for any simulation. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ I'm using PAL for a physics integration with delta3d. I'm still confused about why people want to integrate things like physics and audio into a scene graph, but that aside, I am adding features and such to PAL since I have commit access. We should all work together implementing features in PAL so we don't duplicate effort. I'm going to be working on adding support for collision masks, then I'm going to look at doing a character model interface. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPhysics] Project osgPhysics started!
I guess I understand why people do it, but I would rather that OSG kept the limited scope of being a scene graph, that is with the features just of doing 3d rendering. I think a more limited scope makes it more useful as a drop in component of a game engine. physics and audio, while they are necessary in a game or simulation engine, they are not rendered, and I don't think they belong in a scene graph. In delta3d, we have, and are more and more trying to separate things such as drawing, physics, and audio from simulated objects (actors) so that actors can be composed of these features via componentization and messaging. We would eventually even like delta3d to have the ability to use different renderers. As technologies like raytracing become more prevalent, the scene graph may have change a fair bit, but that shouldn't affect the audio and physics systems. Originally we had wanted to work with Robert more closely to make delta3d have game engine features, and osg have the rendering features, but things didn't evolve that way. Either way, this is not a discussion for the osgPhysics list. I'm making dtPhysics, which appears to have nearly exactly the same goals as you have except that we intend to integrate with delta3d its component system. I email back and forth with Adrian Boeing a fair bit, and I have commit access to PAL, as I said before, so we would discuss the features and direction of PAL, as we see it. Perhaps PAL needs a mailing list, or maybe we need to do something more like a telecon to discuss things. I don't know where in the world you are. I'm on the east coast of the US. Adrian is, I think, in Australia. So, I'm not sure how practical that is. -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=4619#4619 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPhysics] Project osgPhysics started!
Sukender wrote: Hi David, Thanks for the info. And yes, you're right about implementing features in PAL. About the integration of audio and physics, we aim at giving users an easier access to features often coupled with scene graphs. Doesn't it make sense for you? Or maybe we're not talking about the same thing!? I belive that providing a layer that facilitates the use of a physics engine would give users an additional reason to use OSG for any simulation. when you talk about simulation, you do not mean http://caelinux.com and such with finite elements, non-linear thermo-mechanics, coupled fluid-structure dynamics, seismic / non-linear explicit dynamics, contacts, visco-plasticity, fluid dynamics, heat exchange, convection heat transfer and radiation, electro-magnetcis and such. if i understand pal right than it is a game physics layer and not a simulation physics layer. nothing bad about it, but i think it needs to be mentioned. would be great if osg would be used more also in the simulation field. best regards ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPhysics] Project osgPhysics started!
Hi David, Well, what we intend to do is simply provide a plug so that you can do what you want. Morover, the osgPhysics' aim is to drive nodes in the graph by the way of physics. We don't plan to make physic objects to be cullable, or things like that. Changeing the renderer (like raytracing) would not affect things handled by osgPhysics. I hope this is a bit clearer! :) About Adrian, I also discussed a few points with him, and I may contribute to PAL too. And yes, he's in Australia... Wang Rui (osgPhysics, osgNV) is in China, and I'm in France... well it may be difficult to be all online for a chat, but we still can work :) Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ I guess I understand why people do it, but I would rather that OSG kept the limited scope of being a scene graph, that is with the features just of doing 3d rendering. I think a more limited scope makes it more useful as a drop in component of a game engine. physics and audio, while they are necessary in a game or simulation engine, they are not rendered, and I don't think they belong in a scene graph. In delta3d, we have, and are more and more trying to separate things such as drawing, physics, and audio from simulated objects (actors) so that actors can be composed of these features via componentization and messaging. We would eventually even like delta3d to have the ability to use different renderers. As technologies like raytracing become more prevalent, the scene graph may have change a fair bit, but that shouldn't affect the audio and physics systems. Originally we had wanted to work with Robert more closely to make delta3d have game engine features, and osg have the rendering features, but things didn't evolve that way. Either way, this is not a discussion for the osgPhysics list. I'm making dtPhysics, which appears to have nearly exactly the same goals as you have except that we intend to integrate with delta3d its component system. I email back and forth with Adrian Boeing a fair bit, and I have commit access to PAL, as I said before, so we would discuss the features and direction of PAL, as we see it. Perhaps PAL needs a mailing list, or maybe we need to do something more like a telecon to discuss things. I don't know where in the world you are. I'm on the east coast of the US. Adrian is, I think, in Australia. So, I'm not sure how practical that is. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPhysics] Project osgPhysics started!
Hi Hannes(?) PAL is an abstraction layer for real-time simulation, such as games. However, there is nothing against adding support for complex physics to PAL or osgPhysics. This is true that it is not our first intention for osgPhysics but the project is a layer to whatever you need. So maybe you'll see (ona day) an OpenFOAM or Code_Saturne support... this is possible. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Wed, 14 Jan 2009 22:52:28 +0100, hanne...@gmx.at hanne...@gmx.at a écrit: Sukender wrote: Hi David, Thanks for the info. And yes, you're right about implementing features in PAL. About the integration of audio and physics, we aim at giving users an easier access to features often coupled with scene graphs. Doesn't it make sense for you? Or maybe we're not talking about the same thing!? I belive that providing a layer that facilitates the use of a physics engine would give users an additional reason to use OSG for any simulation. when you talk about simulation, you do not mean http://caelinux.com and such with finite elements, non-linear thermo-mechanics, coupled fluid-structure dynamics, seismic / non-linear explicit dynamics, contacts, visco-plasticity, fluid dynamics, heat exchange, convection heat transfer and radiation, electro-magnetcis and such. if i understand pal right than it is a game physics layer and not a simulation physics layer. nothing bad about it, but i think it needs to be mentioned. would be great if osg would be used more also in the simulation field. best regards ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPhysics] Project osgPhysics started!
My experience is admittedly limited here, but I think some of us are coming from the position that your physics graph is an entirely different thing than the render graph. The two are often completely orthogonal. In one case you may have physics body represented by something simple like a ball... where as for various implementation reasons your scene graph may need to be a whole pile of objects. Conversely, sometimes a whole mess of physics parts/bodies/bones/whatever may decompose into a single mesh and a custom shader to move the points around. While there may be parts similar between a physics node and a scene graph node, I'm not sure they are similar enough to justify being related in a class hierarchy. ...and maybe you are already taking all of that into consideration and I've misunderstood the conversation so far. It just sounds like you are trying to have the physics engine directly act on scene graph nodes versus transferring values transform information from the physics nodes to the scene graph nodes. I think you will pay dearly for the convenience. :) -Paul Sukender wrote: Hi David, Well, what we intend to do is simply provide a plug so that you can do what you want. Morover, the osgPhysics' aim is to drive nodes in the graph by the way of physics. We don't plan to make physic objects to be cullable, or things like that. Changeing the renderer (like raytracing) would not affect things handled by osgPhysics. I hope this is a bit clearer! :) About Adrian, I also discussed a few points with him, and I may contribute to PAL too. And yes, he's in Australia... Wang Rui (osgPhysics, osgNV) is in China, and I'm in France... well it may be difficult to be all online for a chat, but we still can work :) Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ I guess I understand why people do it, but I would rather that OSG kept the limited scope of being a scene graph, that is with the features just of doing 3d rendering. I think a more limited scope makes it more useful as a drop in component of a game engine. physics and audio, while they are necessary in a game or simulation engine, they are not rendered, and I don't think they belong in a scene graph. In delta3d, we have, and are more and more trying to separate things such as drawing, physics, and audio from simulated objects (actors) so that actors can be composed of these features via componentization and messaging. We would eventually even like delta3d to have the ability to use different renderers. As technologies like raytracing become more prevalent, the scene graph may have change a fair bit, but that shouldn't affect the audio and physics systems. Originally we had wanted to work with Robert more closely to make delta3d have game engine features, and osg have the rendering features, but things didn't evolve that way. Either way, this is not a discussion for the osgPhysics list. I'm making dtPhysics, which appears to have nearly exactly the same goals as you have except that we intend to integrate with delta3d its component system. I email back and forth with Adrian Boeing a fair bit, and I have commit access to PAL, as I said before, so we would discuss the features and direction of PAL, as we see it. Perhaps PAL needs a mailing list, or maybe we need to do something more like a telecon to discuss things. I don't know where in the world you are. I'm on the east coast of the US. Adrian is, I think, in Australia. So, I'm not sure how practical that is. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPhysics] Project osgPhysics started!
Well, is it possible to run n times PUT, and then one time the standard frame (update/cull/draw)? If so, there should be no problem. It's possible to do it that way, but the display frame rate will suffer if the physics computation gets expensive. In my own work, I am stepping the physics simulation once, then calling osgViewer::Viewer::frame(), and I'm already seeing framerate issues when interactions get complex. If you want to step the physics simulation multiple times, it'll be even more of an issue. I think putting the physics simulation in a separate thread will make this less of a problem. It's also simpler, because it doesn't require osgPhysics to invade osgViewer, which I personally think is a bad idea. OSG has a lot of mechanisms that allow you to do physics without modifying the OSG code. I'm able to do a full Bullet physics simulation in my project, and haven't modified one line of OSG (just derived a few classes). Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPhysics] Project osgPhysics started!
Ditto this post. In my Bullet work, the physics representation is based on, but separate from, the OSG visual representation. The two graphs are only tied together at Transform nodes that allow Bullet to drive the transformations of the visual representations of rigid bodies. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Paul Speed Sent: Wednesday, January 14, 2009 3:08 PM To: OpenSceneGraph Users Subject: Re: [osg-users] [osgPhysics] Project osgPhysics started! My experience is admittedly limited here, but I think some of us are coming from the position that your physics graph is an entirely different thing than the render graph. The two are often completely orthogonal. In one case you may have physics body represented by something simple like a ball... where as for various implementation reasons your scene graph may need to be a whole pile of objects. Conversely, sometimes a whole mess of physics parts/bodies/bones/whatever may decompose into a single mesh and a custom shader to move the points around. While there may be parts similar between a physics node and a scene graph node, I'm not sure they are similar enough to justify being related in a class hierarchy. ...and maybe you are already taking all of that into consideration and I've misunderstood the conversation so far. It just sounds like you are trying to have the physics engine directly act on scene graph nodes versus transferring values transform information from the physics nodes to the scene graph nodes. I think you will pay dearly for the convenience. :) -Paul Sukender wrote: Hi David, Well, what we intend to do is simply provide a plug so that you can do what you want. Morover, the osgPhysics' aim is to drive nodes in the graph by the way of physics. We don't plan to make physic objects to be cullable, or things like that. Changeing the renderer (like raytracing) would not affect things handled by osgPhysics. I hope this is a bit clearer! :) About Adrian, I also discussed a few points with him, and I may contribute to PAL too. And yes, he's in Australia... Wang Rui (osgPhysics, osgNV) is in China, and I'm in France... well it may be difficult to be all online for a chat, but we still can work :) Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ I guess I understand why people do it, but I would rather that OSG kept the limited scope of being a scene graph, that is with the features just of doing 3d rendering. I think a more limited scope makes it more useful as a drop in component of a game engine. physics and audio, while they are necessary in a game or simulation engine, they are not rendered, and I don't think they belong in a scene graph. In delta3d, we have, and are more and more trying to separate things such as drawing, physics, and audio from simulated objects (actors) so that actors can be composed of these features via componentization and messaging. We would eventually even like delta3d to have the ability to use different renderers. As technologies like raytracing become more prevalent, the scene graph may have change a fair bit, but that shouldn't affect the audio and physics systems. Originally we had wanted to work with Robert more closely to make delta3d have game engine features, and osg have the rendering features, but things didn't evolve that way. Either way, this is not a discussion for the osgPhysics list. I'm making dtPhysics, which appears to have nearly exactly the same goals as you have except that we intend to integrate with delta3d its component system. I email back and forth with Adrian Boeing a fair bit, and I have commit access to PAL, as I said before, so we would discuss the features and direction of PAL, as we see it. Perhaps PAL needs a mailing list, or maybe we need to do something more like a telecon to discuss things. I don't know where in the world you are. I'm on the east coast of the US. Adrian is, I think, in Australia. So, I'm not sure how practical that is. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
