Re: [osg-users] Looking towards 2.4, and what might go into it.
In the category of beyond 2.4, the community can look forward to an OpenFlight export plugin. Should be submitted to OSG sometime in the February-April '08 timeframe. So maybe it'll be in 2.6. Its capabilities are pretty limited at the moment, but what is working works well and looks promising. Perhaps I'll post a cow exported to FLT as a Christmas gift... If you've all been good. :-) Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com 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] Looking towards 2.4, and what might go into it.
Any volunteers, pretty please ;-) Ask you and shall receive! :) Hell, less than 24 hours is a pretty decent turnaround time... Beat me to it... thanks. I was going to ask the same questions I saw in your comments... should the interface restore the original display mode in the destructor or should that be left up to the application developer (which is what the others seemed to do). Also one more request that goes along with this... :) Can we add to the WindowingSystemInterface a way to get the available resolutions? It would be beneficial to all platforms as you could use it to display to the user a list of available resolutions (I imagine refresh rates may need to be queried as well). Lucas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Osfield wrote: Yep its working in 2.2, osgViewer is more rounded and complete in 2.2 than 2.0, and in SVN its a little bit further on still. Note quite viewer/windowing nirvana yet, but the closest the OSG has come in its history. Ah, cool! I will check it out, that should fix one long standing bug in our application :) Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFHaYm0n11XseNj94gRAvUtAKCjfAkbu5DoC61IbHM0JK8GQluEMACfcJ0m r7lwFvWXnQFBJej/5mTCeKU= =ImnG -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeremy Moles wrote: On Tue, 2007-12-18 at 20:35 +, Robert Osfield wrote: On Dec 18, 2007 7:47 PM, Jan Ciger [EMAIL PROTECTED] wrote: I guess RandR it is then, because some people voiced the support for changing the resolution on the fly. RandR is the only reasonable way how to do this on Unix at the moment. The older X extensions change resolution, but do not resize the root window, leaving you with a panning virtual desktop. Any volunteers, pretty please ;-) Ask you and shall receive! :) Hell, less than 24 hours is a pretty decent turnaround time... Forwarding my patches to Submissions. Wow, that's called - Lead with the code :)) BTW, I have noticed a comment in your diff whether or not the original resolution should be automatically restored. I would vote for yes, because otherwise I would have to query the original screen settings, store them somewhere and then pass them back to your code to restore the screen on exit. That sounds as bit dumb thing to do, because your code has all the information already. Furthermore, it enables the possibility of screwed up screen if the applications throws an exception that is not caught or some library just calls exit() (yes, some libs do that) and my cleanup code is not reached. I would have to wrap everything into a class with a catch-all exception handler around the code and deal with all this there. Quite a complication for a small program. How does this work for Windows? Are the settings restored automatically? One way or another, it would be good to be consistent across platforms. Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFHaYl9n11XseNj94gRAs9YAKDuoxpUOxxfu0UugqJq/Jzut8ss+gCcCxwU ZouHebbc3rqkGY19k3LkLWc= =xCNR -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
On Wed, 2007-12-19 at 22:13 +0100, Jan Ciger wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeremy Moles wrote: On Tue, 2007-12-18 at 20:35 +, Robert Osfield wrote: On Dec 18, 2007 7:47 PM, Jan Ciger [EMAIL PROTECTED] wrote: I guess RandR it is then, because some people voiced the support for changing the resolution on the fly. RandR is the only reasonable way how to do this on Unix at the moment. The older X extensions change resolution, but do not resize the root window, leaving you with a panning virtual desktop. Any volunteers, pretty please ;-) Ask you and shall receive! :) Hell, less than 24 hours is a pretty decent turnaround time... Forwarding my patches to Submissions. Wow, that's called - Lead with the code :)) BTW, I have noticed a comment in your diff whether or not the original resolution should be automatically restored. I would vote for yes, because otherwise I would have to query the original screen settings, store them somewhere and then pass them back to your code to restore the screen on exit. That sounds as bit dumb thing to do, because your code has all the information already. Furthermore, it enables the possibility of screwed up screen if the applications throws an exception that is not caught or some library just calls exit() (yes, some libs do that) and my cleanup code is not reached. I would have to wrap everything into a class with a catch-all exception handler around the code and deal with all this there. Quite a complication for a small program. How does this work for Windows? Are the settings restored automatically? One way or another, it would be good to be consistent across platforms. Yeah, I'm in total agreement here. It would be very easy to restore the settings in the destructor if other platforms do that kind of thing... Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFHaYl9n11XseNj94gRAs9YAKDuoxpUOxxfu0UugqJq/Jzut8ss+gCcCxwU ZouHebbc3rqkGY19k3LkLWc= =xCNR -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Robert, Robert Osfield wrote: An external script that invokes the 3D app only works when entering an application, not once its running, so it does have a bit of limited applicability. I understand that, however, how often do you need to change resolution once the application is running? If it is needed only once when starting it, then it is not a problem. You can always make the app called and the path application/user definable with a sensible default for each platform one doesn't need to hard wire it - if a platform doesn't have anything sensible then you'd just have a blank app string and would therefore not call the res changing app. That could work, but I am not sure whether it is actually worth the trouble - the original poster only wanted to change the resolution before starting the application, not during runtime, so this could be an overkill. Perhaps a poll to figure out whether this is a one-off request or a more general issue would be a good thing to do. BTW, I'm just trying to explore possible solutions here. I see. I would say that a most future-proof solution would be to implement support for the RandR extension (http://keithp.com/~keithp/talks/randr/). This is now supported by everything running X.Org X servers (Linux, various BSDs), however proprietary Unix doesn't support it (SGI, Sun, HP). I am not sure whether that would be a significant issue or not. However, it is not 100% foolproof solution, because not all drivers support it (ATI and nVidia do, though). Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFHZ8mAn11XseNj94gRAhHgAJ9/CrXu2NKFpUVHT/DRfM545Gc2oQCg7KA+ J/mRwxs5trWZaUFQIa9cHyc= =HOut -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
Hi Jan, On Dec 18, 2007 1:22 PM, Jan Ciger [EMAIL PROTECTED] wrote: An external script that invokes the 3D app only works when entering an application, not once its running, so it does have a bit of limited applicability. I understand that, however, how often do you need to change resolution once the application is running? If it is needed only once when starting it, then it is not a problem. The OSG is a general purpose graphics library so it needs to accommodate a wide range of application usage, and also try to make it seemless across platforms - this is the advantage with wrapping it up with existing OSG interfaces for it - ones that are only implemented for Win32 so far. You can always make the app called and the path application/user definable with a sensible default for each platform one doesn't need to hard wire it - if a platform doesn't have anything sensible then you'd just have a blank app string and would therefore not call the res changing app. That could work, but I am not sure whether it is actually worth the trouble - the original poster only wanted to change the resolution before starting the application, not during runtime, so this could be an overkill. Perhaps a poll to figure out whether this is a one-off request or a more general issue would be a good thing to do. BTW, I'm just trying to explore possible solutions here. I see. I would say that a most future-proof solution would be to implement support for the RandR extension (http://keithp.com/~keithp/talks/randr/). This is now supported by everything running X.Org X servers (Linux, various BSDs), however proprietary Unix doesn't support it (SGI, Sun, HP). I am not sure whether that would be a significant issue or not. However, it is not 100% foolproof solution, because not all drivers support it (ATI and nVidia do, though). RandR support would be a reasonable way forward. SGI and other older workstation class machines are not so prone to users wishing to change resolution - Once I had 1280x1024 on an SGI Indigo Elan back in 92 this didn't change till my final contact with SGI's with the Oynx IR2... If if users do wish support on these platforms they can step forward and implement it. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
That could work, but I am not sure whether it is actually worth the trouble - the original poster only wanted to change the resolution before starting the application, not during runtime, so this could be an overkill. Perhaps a poll to figure out whether this is a one-off request or a more general issue would be a good thing to do. Actually I want the resolution to be able to be changed anytime in the application. So the user starts the application, finds that the the application runs a little slow, changes some settings for detail and resolution, and now the application performs at a good rate. And a smart application would be even nicer where it tests the users machine and automatically configures this stuff for them (but still allows them to change it). I see. I would say that a most future-proof solution would be to implement support for the RandR extension (http://keithp.com/~keithp/talks/randr/). This is now supported by everything running X.Org X servers (Linux, various BSDs), however proprietary Unix doesn't support it (SGI, Sun, HP). I am not sure whether that would be a significant issue or not. However, it is not 100% foolproof solution, because not all drivers support it (ATI and nVidia do, though). RandR support would be a reasonable way forward. SGI and other older workstation class machines are not so prone to users wishing to change resolution - Once I had 1280x1024 on an SGI Indigo Elan back in 92 this didn't change till my final contact with SGI's with the Oynx IR2... If if users do wish support on these platforms they can step forward and implement it. That's what I was thinking as the solution is already not 100% foolproof. Because if you compile your code on Linux/BSD/Unix/etc. and expect it to work the same on every platform, it doesn't (works on Mac and Windows though). So at least including the Linux/BSD and others that support X.Org is a little better than not supporting any at all. Currently OSG just silently fails when making this call, which you could still do for those platforms that don't support the RandR extension. Lucas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
For many games (particular on Windows of yesteryears) and applications, I have changed resolutions and 3D effects once the application or game has started depending on the frame rate performance. Thus if possible it would be best to implement a feature into OSG to change resolution, though how this would be done internal can be very platform dependent, so more work would be needed to implement this feature. My 2c worth. Rizzen Lucas Goss wrote: That could work, but I am not sure whether it is actually worth the trouble - the original poster only wanted to change the resolution before starting the application, not during runtime, so this could be an overkill. Perhaps a poll to figure out whether this is a one-off request or a more general issue would be a good thing to do. Actually I want the resolution to be able to be changed anytime in the application. So the user starts the application, finds that the the application runs a little slow, changes some settings for detail and resolution, and now the application performs at a good rate. And a smart application would be even nicer where it tests the users machine and automatically configures this stuff for them (but still allows them to change it). I see. I would say that a most future-proof solution would be to implement support for the RandR extension (http://keithp.com/~keithp/talks/randr/). This is now supported by everything running X.Org X servers (Linux, various BSDs), however proprietary Unix doesn't support it (SGI, Sun, HP). I am not sure whether that would be a significant issue or not. However, it is not 100% foolproof solution, because not all drivers support it (ATI and nVidia do, though). RandR support would be a reasonable way forward. SGI and other older workstation class machines are not so prone to users wishing to change resolution - Once I had 1280x1024 on an SGI Indigo Elan back in 92 this didn't change till my final contact with SGI's with the Oynx IR2... If if users do wish support on these platforms they can step forward and implement it. That's what I was thinking as the solution is already not 100% foolproof. Because if you compile your code on Linux/BSD/Unix/etc. and expect it to work the same on every platform, it doesn't (works on Mac and Windows though). So at least including the Linux/BSD and others that support X.Org is a little better than not supporting any at all. Currently OSG just silently fails when making this call, which you could still do for those platforms that don't support the RandR extension. Lucas ___ 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] Looking towards 2.4, and what might go into it.
For many games (particular on Windows of yesteryears) and applications, I have changed resolutions and 3D effects once the application or game has started depending on the frame rate performance. Thus if possible it would be best to implement a feature into OSG to change resolution, though how this would be done internal can be very platform dependent, so more work would be needed to implement this feature. This feature is already in OSG and works already on Windows and Mac (the function in question is setScreenResolution in the osgViewer library). So it's already implemented on two platforms, but not on any *nix platform. Lucas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Osfield wrote: RandR support would be a reasonable way forward. SGI and other older workstation class machines are not so prone to users wishing to change resolution - Once I had 1280x1024 on an SGI Indigo Elan back in 92 this didn't change till my final contact with SGI's with the Oynx IR2... If if users do wish support on these platforms they can step forward and implement it. I guess RandR it is then, because some people voiced the support for changing the resolution on the fly. RandR is the only reasonable way how to do this on Unix at the moment. The older X extensions change resolution, but do not resize the root window, leaving you with a panning virtual desktop. BTW, when speaking about these features - is the setting of the window title working on Unix again? It used to work before 2.0, but then it was not implemented once the renderer was redone. Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFHaCPtn11XseNj94gRAovCAKCzhzfd6TAm+/b5lJehm/CEgz1AiACePfph xkvSoUdrhOp8Hz/TDfQtkZs= =9Yzx -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
On Dec 18, 2007 7:47 PM, Jan Ciger [EMAIL PROTECTED] wrote: I guess RandR it is then, because some people voiced the support for changing the resolution on the fly. RandR is the only reasonable way how to do this on Unix at the moment. The older X extensions change resolution, but do not resize the root window, leaving you with a panning virtual desktop. Any volunteers, pretty please ;-) BTW, when speaking about these features - is the setting of the window title working on Unix again? It used to work before 2.0, but then it was not implemented once the renderer was redone. Yep its working in 2.2, osgViewer is more rounded and complete in 2.2 than 2.0, and in SVN its a little bit further on still. Note quite viewer/windowing nirvana yet, but the closest the OSG has come in its history. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lucas Goss wrote: Hmm, that might be alright, though I don't really like writing shell scripts, haha. Of course if that is an advantage for some they can still do it that way, they don't have to use OSG's implementation. But it would be nice to have an implementation still, as OSG provides an interface for it and those that want a quick way of resolution changing without messing with shell scripts can get it there. The reason for SDL's craziness and why I have suggested a shell script is easy - you can make a some kind of X hack that works on your computer using one extension, but I compile the program on my computer and it is very likely that either the resolution is not available, the extension is not available/working with my X and driver or some other weird problem happens. In that case relying on external (and supposedly working) tools can save your bacon. I wouldn't like to have to implement resolution switching logic for X having to juggle X11 calls to the older extensions, newer RandR stuff (that is incompatible with them) and most recently the various OpenGL compositing managers like Compiz, where the situation is yet different (you could be running on a nested X server and your application calls are actually proxied). Are you ready to handle all of this? Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFHZsw2n11XseNj94gRAlE6AJ9GPz2UCa2Gf2ha2OALHCtj+RlLnACgiZNc 06tH32ylbosbDgEjuFsvwOw= =nZvm -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
Hi Jan, On Dec 17, 2007 7:21 PM, Jan Ciger [EMAIL PROTECTED] wrote: The reason for SDL's craziness and why I have suggested a shell script is easy - you can make a some kind of X hack that works on your computer using one extension, but I compile the program on my computer and it is very likely that either the resolution is not available, the extension is not available/working with my X and driver or some other weird problem happens. In that case relying on external (and supposedly working) tools can save your bacon. I wouldn't like to have to implement resolution switching logic for X having to juggle X11 calls to the older extensions, newer RandR stuff (that is incompatible with them) and most recently the various OpenGL compositing managers like Compiz, where the situation is yet different (you could be running on a nested X server and your application calls are actually proxied). Are you ready to handle all of this? I wonder about a compromise... call an external application to do the change of resolution for us from within osgViewer just by issuing a system call. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
Hi Jan, On Dec 17, 2007 8:21 PM, Jan Ciger [EMAIL PROTECTED] wrote: That would be quite a hackery, IMO. Are you going to handle all the issues with path, detection whether certain binaries are available or not and potentially which versions they are in the application code? An external script that invokes the 3D app only works when entering an application, not once its running, so it does have a bit of limited applicability. That is far easier and safer to do at the operating system level and it also leaves the door open for the potential packager to adapt the script to the conventions used by the particular distro. If it is part of the binary, one cannot do this unless the application is shipped with source. That could be an issue for commercial software vendors using OSG. You can always make the app called and the path application/user definable with a sensible default for each platform one doesn't need to hard wire it - if a platform doesn't have anything sensible then you'd just have a blank app string and would therefore not call the res changing app. BTW, I'm just trying to explore possible solutions here. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Osfield wrote: Hi Lucas, On Dec 14, 2007 9:46 PM, Lucas Goss [EMAIL PROTECTED] wrote: Would it be possible to implement setScreenResolution for X11? Was it left out because it requires an X11 extension? I have some linux machines that have older video cards that run the desktop ok at higher resolutions, but run 3D much faster if the resolution is scaled down. Setting screen resolution isn't straight forward with X11 unfornately, if it had been it'd already have been done. The generic interface for setting resolution is in place, and implementation is done for Win32, but on the X11 side we did a volunteer to go forth and implement it. Anyhow, I think that an easier and more unix-y way is to make a wrapper script calling xrandr or whatever your distro supports to change the resolution before starting your application and then change it back. That has also the advantage that should your app crash, it will not leave the screen in a messed up state - a way too common issue that could be a major problem if you are working on a system where the primary screen can deal only with certain resolutions/refresh rates (projectors, HMDs ...) Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFHZWqfn11XseNj94gRAlMyAJ4oD7iX6DVA5Wrk9bPD1SVEoJb3FgCgyNHP Sgrm2IXVsclNg7CIJZUrWXA= =a34K -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
Setting screen resolution isn't straight forward with X11 unfornately, if it had been it'd already have been done. The generic interface for setting resolution is in place, and implementation is done for Win32, but on the X11 side we did a volunteer to go forth and implement it. Hmm, I'll have to look into it. I've made my own XWindow wrappers with OpenGL before setting the screen resolution and never had a problem. I just looked at SDL's implementation and it's pretty crazy. I looked at OGRE's for comparison and it's much simpler. Maybe I can make the implementation, I'll look into it. Anyhow, I think that an easier and more unix-y way is to make a wrapper script calling xrandr or whatever your distro supports to change the resolution before starting your application and then change it back. That has also the advantage that should your app crash, it will not leave the screen in a messed up state - a way too common issue that could be a major problem if you are working on a system where the primary screen can deal only with certain resolutions/refresh rates (projectors, HMDs ...) Hmm, that might be alright, though I don't really like writing shell scripts, haha. Of course if that is an advantage for some they can still do it that way, they don't have to use OSG's implementation. But it would be nice to have an implementation still, as OSG provides an interface for it and those that want a quick way of resolution changing without messing with shell scripts can get it there. Lucas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
Hi Lucas, On Dec 14, 2007 9:46 PM, Lucas Goss [EMAIL PROTECTED] wrote: Would it be possible to implement setScreenResolution for X11? Was it left out because it requires an X11 extension? I have some linux machines that have older video cards that run the desktop ok at higher resolutions, but run 3D much faster if the resolution is scaled down. Setting screen resolution isn't straight forward with X11 unfornately, if it had been it'd already have been done. The generic interface for setting resolution is in place, and implementation is done for Win32, but on the X11 side we did a volunteer to go forth and implement it. As a guide SDL has code for changing screen resolution. I've reviewed this and came away with the conclusion that implementing it properly would take more time than I had the time. Alas time right now is no more abundant, so we do need an help on this one ;-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
Would it be possible to implement setScreenResolution for X11? Was it left out because it requires an X11 extension? I have some linux machines that have older video cards that run the desktop ok at higher resolutions, but run 3D much faster if the resolution is scaled down. Lucas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 James Halliday wrote: I've been using osgswig ( http://code.google.com/p/osgswig/ ) for a project on a cave-type system combining python, vrjuggler, and osg. osgswig supports python, ruby, java and lua, although I've only played with the python features. I had tried to use osgPython and pyosg before, but they only work with older versions of osg. Interesting, I didn't know about this project! Thanks for the pointer! / 2) Application is written in a high level language and calls into C/C++/ / code to run the performance critical stuff. I think that this is what/ / you want (... enable us to/ / develop applications purely from scripting languages, so developers in/ / this realm would just need the binaries to the OSG installed, and no/ / need for C++ dev environment). /The osgswig project seems to be primarily designed for scenario 2, although in my application I've been using osgswig as in scenario 1 by getting out a void pointer to the opaque values from the python api. I'm not sure how possible this approach is with other languages though. It usually works in the same way if you are using SWIG - you get a void pointer packaged into some opaque data structure (e.g. a SMOB for Guile) and you are passing that around. However, if the bindings are made using a different tool, this could be different. Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFHYFQOn11XseNj94gRAppsAJ9FKDi2zX4EGao8ftGEdfatY2pM7ACeIOzm rCZ1YXKvB0SzqoKqUM8LDL0= =2jic -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jason Daly wrote: osgCal/Replicant are great, provided that you want to use Cal3D characters only. Why? Where is a problem about taking a character/animation from Collada and creating the Cal3D skeleton structure from it on loading? That is what the Cal3D loaders do. Cal3D doesn't really expect anything exotic, so it should be very easy to do. I didn't do it for mesh, but I had a Cal3D character skeleton created and driven from outside before. Nothing crazy was required. The only exception are probably LOD levels in Cal that work in a bit unusual way - by collapsing mesh dynamically - instead of the more normal way of swapping around different meshes, but that is not really an issue, especially if the software skinning in Cal is not used. I don't think the idea behind osgSkeleton is limited to a transformation hierarchy. Most OSG users know we already have that functionality. My understanding is that osgSkeleton would provide the necessary infrastructure for skinning and character animation, and the required data could come from Collada, Cal3D, or whatever other plugin that can provide it. That is fine, but I do not see much point in it - it would be only re-implementation of what already exists in Cal3D. That's the main advantage I see in creating a new nodekit. It makes the rendering orthogonal to the data format. Is the current Cal3D situation different? Non-orthogonal? I understand that you are somehow implying that without using the Cal3D data formats you cannot use Cal3D library. That isn't the case, as outlined above. Cal doesn't care where the data come from once they are loaded. If you load them from Collada file, no problem. Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFHYFXzn11XseNj94gRAui8AJ9EjTvrnrAyHp/APfoCVvOdJBOjOgCgz1Gl I+MSnqL7/+eKRclYsvGBAKQ= =gfRw -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vladimir Shabanov wrote: Yes, it has different implementation. But what about skeletal character with morphing face and maybe some particles around his body (imagine a small devil). Different rendering methods are tightly coupled here. And their animations must be synchronized. So while the rendering implementation can be separated (not sure about morphs and skeleton) the animations must be ran from single place. You have a valid point here. However that doesn't require a huge, all-encompassing node kit for managing all kinds of animation, does it? If you want to have a character that is both skeletally animated and has morph targets for e.g. face, it could be a composite structure with two components - face and the rest. I would leave this to the user to implement a class managing a character like that and have OSG have two animation node kits - one for skeleton, deforming the mesh and then another one that will work on the pre-deformed mesh and fix the face or whatever. The morphing is useful even without the skeletal animation that brings a lot of extra baggage in and I wouldn't like it to be tightly tied together. However, this could be tricky to implement. Otherwise, then let's not talk about a general animation package but something specific to character animation. Then it would be OK to have a character class supporting both things out of the box, but we wouldn't be pretending that this is something more generic. Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFHYFgYn11XseNj94gRArtvAJ0aexy7mtZZiR2O+vlJVDBNgcJ1VwCdERc9 wZ84pXuBajnwdJCi2a4Ce7Q= =RYar -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Jeremy, Jeremy Moles wrote: Nothing more was ever implied given the code provided, so I'm not sure why you even brought this up? The example is clearly a purposefully succinct and shortened summation. What brings it up to speed is adding the mixing, interpolation, etc, which I also mentioned at the end of the paragraph. Yes, I agree, however, who is going to do it? Those parts are the least sexy and most difficult in the animation code. My answer wasn't so much targeted at you (you know what this stuff is about, I believe), as much as at the others who could get a false impression that once we have a skeleton support and skinning code, all is going to work by magic. Secondly, and I'm not speaking as a total foreigner here since I do have a lot of experience w/ Cal3D and a decent amount of affiliation with the project, when he can use osgCal or Replicant that work already is really the issue that is up for debate in my mind. My issue is more on the resource level - is there anybody willing to commit himself to redo this stuff that Cal3D provides? The animation parts are tricky, requiring good math skills and certain experience. I didn't see anybody stepping up and saying I will do this until now. Unless we have this, it would be rather unwise to make a half-cooked toolkit that is not practically usable. Vladimir has made many posts regarding his changes to osgCal2 today, and from the information I can gather he was required to basically re-implement portions of Cal3D in his plugin just to get acceptable performance and support for hardware skinning. It sounds like osgCal2 is really more of a hybrid Cal3D adaptation than just a simple Cal3D wrapper/plugin. While his changes my create the outward appearance of animation working already, as a developer it certainly doesn't qualify as such to me, though I often admittedly fall victim to putting too much emphasis on the wrong things. I think that this was answered elsewhere by him already. Perhaps Cal3D just isn't the tool for the job here. Or at least, it shouldn't (and perhaps I'm wrong for believing will become as much) be THE character animation solution for OSG, long term. I agree with this, however, there isn't anything better on the table at the moment. Unless somebody offers to replace Cal, I suggest an evolution rather than revolution. I gather that this is also what Robert wants, judging from one of his last emails on the topic. If we can eliminate the dependency on Cal long term, great. However, I would hesitate to remove it until we have a replacement, including the design pipeline. At any rate, unless I'm willing to step up and code to solve the problem, I probably shouldn't say too much more on the issue. Unless I'm able to provide real working code, it just looks like I'm forum trolling, which I'm not trying to do. :) :-)) Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFHYFzon11XseNj94gRAhPvAJ0YI+GqRuOuHwqxvLNaPR3lbwLQxACg1cd7 z/QGWZKaZ5KLoCTd+E5B4ac= =Yeu4 -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vladimir Shabanov wrote: As I said before cal3d meshes are not used by osgCal for performance and memory usage reasons. They are used at export stage to generate ready to direct load meshes file. For compability loading from cal3d .cmf-files is still here. The only things needed to be integrated in OSG to remove cal3d dependeny are skeleton support and skeleton animation support. OSG and osgCal have all other things. Skeleton animation is actually probably the trickiest part. Getting animations to blend right and to mix right, allowing procedural animation (bones driven by an algorithm, not just keyframe interpolation) and such are quite a big deal. That is why I am not so enthusiastic about ripping out Cal3D - nobody has so far offered to do this hard part. Rendering it is comparably easy. But skeleton animations is not enough, exporters to these animations are also needed. It is artist pipeline that need most work. Very important point! No. It's not linux only. osgCal2 works on windows also. There is no CMake files in osgCal2, it uses old OSG make files to make osgCal on unix systems and on mingw under windows. People have made Visual Studio project files and osgCal works ok on windows. I didn't try the hardware accelerated version, but the software skinned one used to work just fine on Windows, indeed. Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFHYFjvn11XseNj94gRAliKAJ92I/sQvTRduNCzMOkCT6PlJ1yPmQCgxTXB 4oGghkNNzCmVB1QdsnRfVyI= =GIwL -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
Robert Osfield wrote: On Dec 11, 2007 6:31 AM, J.P. Delport [EMAIL PROTECTED] wrote: could we get support for multiple render targets (MRT) integrated into 2.4? I know some people are using hacky patches for this. Some patches have been submitted, but they have to be reworked. I can help with this if needed. If we can get a clean set of patches to support MRT then I'm for reviewing/merging them :-) Mea culpa... I implemented JP's hack into my source and it worked for what I needed it for. Then I submitted a half-baked patch which Robert was right to refuse, but then I was dragged off to do other things. I'll have time to play around with it over chrimbo in my spare time, so if you're around between christmas day and new year JP, we could collaborate on a decent fix. We're most of the way there really. -JD __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
Hi, John Donovan wrote: Robert Osfield wrote: If we can get a clean set of patches to support MRT then I'm for reviewing/merging them :-) Mea culpa... I implemented JP's hack into my source and it worked for what I needed it for. Then I submitted a half-baked patch which Robert was right to refuse, but then I was dragged off to do other things. I'll have time to play around with it over chrimbo in my spare time, so if you're around between christmas day and new year JP, we could collaborate on a decent fix. We're most of the way there really. It'd be great if you can give it a bash before January. I think if you address the things we've talked about in the earlier discussion on osg-submissions, we can get it merged. I'll be away until 7th Jan, but will then have some time to look at/test it. regards jp -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
On Tue, 2007-12-11 at 09:18 +, Robert Osfield wrote: On Dec 10, 2007 8:27 PM, Jeremy Moles [EMAIL PROTECTED] wrote: One thing that should be kept in mind when using Cal3D is that in it's current state, Cal3D isn't a skeletal system alone--it's a skeletal animation system+mesh format, and one cannot be divorced from the other. Furthermore, there is a lot of data reproduction in Cal3D that already exists in OSG, and no way to easily (or cleanly) make changes therein. How big is Cal3D? I ask in terms how much effort would it be required to reimplement the unique parts not found in the core OSG? It's hard to say--there's a lot of code in Cal3D supporting the mesh format, XML loading, matrices, vectors, quaternions, etc. If I had to estimate, I'd guess OSG already contains 20-25% of what Cal3D has to implement itself to be graphics library/system agnostic, and another 20-25% or so is code relating to it's mesh format. So, you'd probably have to re-implement half of it... :( In the opinion of someone who is familiar with Cal3D, I'd say that we wait a bit on inclusion of this until someone has the time to cleanup the current plugin. Hardware skinning is a pretty common performance boost these days, and whatever solution arises for OSG, I'd personally look at support for this feature as the make-or-break aspect. I thought there was already hardware skinning support in place. So which versions which hardware skinning? Not in Cal3D itself. The software doesn't make any attempt to bind itself to any graphics API, so things like hardware skinning are left up to the user (though they do include examples using the old shader/assembly code or whatever it's called). Vladimir patched support for GLSL skinning into osgCal2, but it's currently Linux only... To be completely honest, character animation is such a huge issue unto itself that it probably deserves a lot of discussion and review before any steps are taken--but that's just my opinoin. Indeed - a good topic to break out into a separate thread... P. S. When I finish a release-candidate version of osgHUD (or whatever you want to change the name to), I'll be peddling that for inclusion as well. :) I've made a number of changes in the last few days if anyone is keeping up with SVN, and almost done with a decent implementation of a table layout, very similar to how HTML tables are done... however, no one posted any complaints to my first thread, so I'm just going to keep proceeding as normal, though I did remove the silly functional code that no one could have possibly understood but myself... it's a shame how difficult it is to do use something as [conceptually] easy as std::for_each()--it's a nightmare, when you can almost always achieve the same thing cleaner and with less code using for(iter;iter;++)... If you can get osgHUD ready for integration then I'm very open to reviewing it with a view to inclusion in 2.4/2.6. We do need to save people from the trials and tribulations of going with something like CEGUI. 2.6 is my goal... W.r.t awkwardness of some program concepts, C++ is the culprit here. My own feeling is that scripting languages shine for high level GUI work. One could use a scripting language for both the control and the layout setup. How to make this integration possible is another big topic... Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Osfield wrote: On Dec 10, 2007 8:27 PM, Jeremy Moles [EMAIL PROTECTED] wrote: One thing that should be kept in mind when using Cal3D is that in it's current state, Cal3D isn't a skeletal system alone--it's a skeletal animation system+mesh format, and one cannot be divorced from the other. Furthermore, there is a lot of data reproduction in Cal3D that already exists in OSG, and no way to easily (or cleanly) make changes therein. How big is Cal3D? I ask in terms how much effort would it be required to reimplement the unique parts not found in the core OSG? Cal3D implements basically these things: 1) Data loading (including exporters for popular modelling packages) - mesh, skeleton, animation files. Skeleton can be arbitrary - e.g. an octopus or even a car, it is not restricted to humanoid skeletons (important feature, IMO!). 2) Keyframe interpolation - you get two poses of the skeleton and you need to calculate the in-betweens smoothly. Basically quaternion slerping, but it can get hairy. 3) Animation blending/mixing. You want a guy to walk and e.g. wave his hand or fire a weapon at the same time - this is animation mixing. Switching between animations should be smooth, not abrupt - blending between poses of different animations over a given time. 4) A little bit of support for spring-mass systems, this was intended for cloth simulation. It doesn't work too well. 5) Software skinning - after calculating the final pose of the skeleton, the mesh is deformed to conform with it. This can be bypassed, if the renderer implements hardware skinning instead. 6) Support for attachments - e.g. a guy picking up a sword from the ground and the sword is then animated together with his hand. As such, the library is not really big. I would hesitate to go and re-implement it without reason, because lot of things you cannot do too differently than what Cal3D does already. If there are specific issues with the library, I would prefer to try to fix it first before throwing it away, together with the large amount of existing data for it and the set of working exporters. On the other hand, a person who knows what he is doing with regards to character animation could re-implement most of the Cal3D functionality easily. However, please, keep in mind that the animation stuff goes way beyond rendering a guy using a hardwired shader for skinning playing a single animation (that is what e.g. osgCharacter does). That is a toy that is not really usable. At least, the keyframe interpolation and animation blending/mixing are essential and need to be in place. Only then can a system such as ReplicantBody or even higher level be used to actually build a usable animation control system on top of it - with navigation, path finding, ground following, motion planning, etc. I do not see much issue with data duplication - the only thing that could be duplicated is the mesh geometry that OSG could potentially load from elsewhere. Skeletons and animations have no support in OSG at the moment. There is also no rendering code in Cal3D itself - all happens on abstract data structures, the library is completely independent on any renderer. It only provides data suitable for feeding into e.g. vertex arrays in OpenGL. However, there is no problem with adding an external loader for these data to Cal3D - everything can be built procedurally, bypassing the native data formats (XML-based, btw). Potential integration could be e.g. with Collada file format that seems to have some support for skeletal animation built-in. In the opinion of someone who is familiar with Cal3D, I'd say that we wait a bit on inclusion of this until someone has the time to cleanup the current plugin. Hardware skinning is a pretty common performance boost these days, and whatever solution arises for OSG, I'd personally look at support for this feature as the make-or-break aspect. I thought there was already hardware skinning support in place. So which versions which hardware skinning? The osgCal2 plugin has hardware skinning already, however the code needs a bit stabilization and cleanup, IMO. Also, it could use wider testing, specifically for the threading issues. To be completely honest, character animation is such a huge issue unto itself that it probably deserves a lot of discussion and review before any steps are taken--but that's just my opinoin. Indeed - a good topic to break out into a separate thread... True. However, Cal3D and osgCal2 are fairly mature libraries, being in development for many years (Cal3D at least). They provide at the very least the minimal support one needs to get skeletal animation running. Unless somebody sits down today and delivers a new library tomorrow, there is nothing else free (as in freedom) available on the table with comparable features. Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva
Re: [osg-users] Looking towards 2.4, and what might go into it.
2007/12/10, Jeremy Moles [EMAIL PROTECTED]: I noticed there was a lot of Cal3D discussion going on here so I'd figure I'd chime in and say a few things. I have write access to Cal3D SVN I obtained a year or so ago when Palle Raabjerg and myself rewrote the Cal3D Blender exporter, which we built by starting from the version in the Soya project; I've also fixed a few small bugs here and there in Cal3D proper. I'm pretty familiar with Cal3D in general, and with the various Cal3D OSG plugins that exist. As a matter of fact, I'm the one who made the Cal3D videos on the website, and I used OSG to do it. :) http://home.gna.org/cal3d/ For a bit of info (and some personal opinion): Firstly, there is the generally-referred-to osgCal (officially called osgCal2), which was originally made by Ruben Lopez and has had many additional edits since then. There is also a GPL version that is incredibly more sophisticated which was created by the people at Underware, but the license wouldn't not allow for wholesale inclusion into OSG. Vladimir Shabanov recently made some changes to osgCal2, and I believe he and Ruben coordinated so that his changes were committed upstream. However, as I mentioned back then and I believe Jan Ciger has alluded to earlier in this thread: the code will need a lot of love before it's ready for serious inclusion. For example, the last time I checked, the shaders were somehow parsed by sed before actually being written into a valid shader file, and there's simply no way I can see anyone in the Windows or Mac world willing to accept such a restriction. Shader files that are preprocessed by sed are also kept in SVN, so there is no need for windows/mac users to run sed. Preprocessing can be done using OpenGL driver but it compilcates shader debugging (it's easier to see final shader code than try to think what defines are processed and what are not). One thing that should be kept in mind when using Cal3D is that in it's current state, Cal3D isn't a skeletal system alone--it's a skeletal animation system+mesh format, and one cannot be divorced from the other. Furthermore, there is a lot of data reproduction in Cal3D that already exists in OSG, and no way to easily (or cleanly) make changes therein. BTW osgCal doesn't uses cal3d's mesh files (.cmf). There is a tool osgCalPreparer (not sure is it a good name) that prepares cal3d.cfg.meshes.cache file which contatins all the necessary data ready for fast loading (vertex, normal, texcoord, weight, matrix index, tangent and handedness buffers). If meshes cache file doesn't exists this data is created implicitly. Cal3d's meshes are not ready for hardware skinning. There is a separate CalHardwareModel class which fills vertex arrays with the necessary data (and it is lengthly operation for hi-poly models). Also cal3d incorrectly calculates tangent-binormal-normal basis for meshes with mirrored UV. So osgCal calculates TBN too. Also osgCal performs mesh deformation calculation itself, not using CalRenderer. So the only things osgCal currently uses from cal3d is material description loading plus skeleton and animation system. (And it uses CalHardwareModel but it is needed only at export stage). In the opinion of someone who is familiar with Cal3D, I'd say that we wait a bit on inclusion of this until someone has the time to cleanup the current plugin. Not sure that there is a need for some major clean up for osgCal. Many things was reworked in past few months and osgCal is not far from stable release. As far as ReplicantBody is concerned I'm unsure--I've never looked at it. To be completely honest, character animation is such a huge issue unto itself that it probably deserves a lot of discussion and review before any steps are taken--but that's just my opinoin. Every time I'm forced to put any thought into the issue, I just get sleepy. What we __really__ need is an osgSkeleton NodeKit, which can then be exercised/demonstrated in the Collada importer, but would be usable alone as well in true OSG style: osgSkeleton::Skeleton* skel = new osgSkeleton::Skeleton(); osgSkeleton::Bone* root = new osgSkeleton::Bone(); osgSkeleton::Bone* child = new osgSkeleton::Bone(); root-addChildBone(child); skel-setRootBone(root); I bet once a basic, simple system was released, people would go to town making the necessary changes to bring it up to speed with other kits. It wouldn't have to be perfect, but as long as it was adaptable and done in true OSG fashion, people could subcass things in osgSkeleton for their own uses or to inject their desired interpolation algorithms (which is a big area of interest for animations buffs)... osgSkeleton is a good idea. The cal3d dependency can be removed with it. But there can be much work to make osgSkeleton. ___ osg-users mailing list osg-users@lists.openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
2007/12/11, Jeremy Moles [EMAIL PROTECTED]: How big is Cal3D? I ask in terms how much effort would it be required to reimplement the unique parts not found in the core OSG? It's hard to say--there's a lot of code in Cal3D supporting the mesh format, XML loading, matrices, vectors, quaternions, etc. If I had to estimate, I'd guess OSG already contains 20-25% of what Cal3D has to implement itself to be graphics library/system agnostic, and another 20-25% or so is code relating to it's mesh format. So, you'd probably have to re-implement half of it... :( As I said before cal3d meshes are not used by osgCal for performance and memory usage reasons. They are used at export stage to generate ready to direct load meshes file. For compability loading from cal3d .cmf-files is still here. The only things needed to be integrated in OSG to remove cal3d dependeny are skeleton support and skeleton animation support. OSG and osgCal have all other things. But skeleton animations is not enough, exporters to these animations are also needed. It is artist pipeline that need most work. In the opinion of someone who is familiar with Cal3D, I'd say that we wait a bit on inclusion of this until someone has the time to cleanup the current plugin. Hardware skinning is a pretty common performance boost these days, and whatever solution arises for OSG, I'd personally look at support for this feature as the make-or-break aspect. I thought there was already hardware skinning support in place. So which versions which hardware skinning? Not in Cal3D itself. The software doesn't make any attempt to bind itself to any graphics API, so things like hardware skinning are left up to the user (though they do include examples using the old shader/assembly code or whatever it's called). Vladimir patched support for GLSL skinning into osgCal2, but it's currently Linux only... No. It's not linux only. osgCal2 works on windows also. There is no CMake files in osgCal2, it uses old OSG make files to make osgCal on unix systems and on mingw under windows. People have made Visual Studio project files and osgCal works ok on windows. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
2007/12/9, Jan Ciger [EMAIL PROTECTED]: I am not sure what are you referring to when speaking about keyframe animation, though. Do you mean 3D morphing of meshes? I would keep that separate, it is a completely different beast with different problems than skeletal animation. Animation of an inflating baloon is quite different issue than animation of a human or an octopus :) Yes, it has different implementation. But what about skeletal character with morphing face and maybe some particles around his body (imagine a small devil). Different rendering methods are tightly coupled here. And their animations must be synchronized. So while the rendering implementation can be separated (not sure about morphs and skeleton) the animations must be ran from single place. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
Jan Ciger wrote: However, it doesn't solve any of the animation and skinning issues and is completely useless by itself. I cannot imagine somebody bringing it up to speed with other kits from this alone, for that you need something actually usable to start from. This is why e.g. osgCharacter is a toy only - it does exactly this. You could display a stick-figure character, but that would be about it. I do not see why somebody would spend time on this when he can use osgCal or Replicant that work already? osgCal/Replicant are great, provided that you want to use Cal3D characters only. I don't think the idea behind osgSkeleton is limited to a transformation hierarchy. Most OSG users know we already have that functionality. My understanding is that osgSkeleton would provide the necessary infrastructure for skinning and character animation, and the required data could come from Collada, Cal3D, or whatever other plugin that can provide it. Or, as mentioned, the data could be created on the fly in code. That's the main advantage I see in creating a new nodekit. It makes the rendering orthogonal to the data format. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
Jan Ciger wrote: Actually, I think that the focus should be on providing a meaningful API to export to these languages. That could even mean a wrapper in order to eliminate/minimize usage of pointers and some C++ functionality that is difficult to translate (templates?). Once you have that, the language bindings could be done very quickly for almost any language, even in an automated way (e.g. using SWIG or something similar). Ideally, the wrappers should be made automatically from the current code. I've been using osgswig ( http://code.google.com/p/osgswig/ ) for a project on a cave-type system combining python, vrjuggler, and osg. osgswig supports python, ruby, java and lua, although I've only played with the python features. I had tried to use osgPython and pyosg before, but they only work with older versions of osg. Jan Ciger wrote: / 1) Application is written in C/C++ and calls embedded scripts. This is/ / fairly typical for game development - game is written in C/C++ and e.g./ / AI is scripted using a built-in scripting engine. Here Lua is great (it/ / was written for it), because it is fairly easy to maintain separation/ / between different scripts (exception/error in one script does not crash/ / the whole thing). Furthermore, Lua is really tiny, with negligible/ / overhead. Another contender is Javascript (e.g. VRML standard uses it/ / for exactly this purpose). I wouldn't target this case, because it is/ / very application-specific and there is little a generic scene graph/ / binding could provide to it. /// / 2) Application is written in a high level language and calls into C/C++/ / code to run the performance critical stuff. I think that this is what/ / you want (... enable us to/ / develop applications purely from scripting languages, so developers in/ / this realm would just need the binaries to the OSG installed, and no/ / need for C++ dev environment). /The osgswig project seems to be primarily designed for scenario 2, although in my application I've been using osgswig as in scenario 1 by getting out a void pointer to the opaque values from the python api. I'm not sure how possible this approach is with other languages though. ~ James ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
Just want to share my experience with using Lua for building applications. We have been using Lua fo building applications for quite some years now. THe binding is using tolua++ where we have exported most of osg, openal++, osgal, replicantbody, physics library etc... We took the path of exporting all functionality, so that there is nearly a 1-1 match of programming in c++ and lua. You can if you want derive from classes and get c++ to call overridden methods written in lua and vice versa. Really time critical things is written in C++ and exported as one or more classes to lua. THis means that one can build whole applications more or less using a viewer, which loads the appropriate configuration scripts+luascripts+plugins (written in c++). This is really great for flexibility, fast prototyping, productivity really. The BIIIG drawback is the type flexibility of lua. You dont really know you are using the right types in a call until you get to that exact point in the code. This is rather tiresome, as you might write nodee, instead of node, where lua interpretes nodee as a NIL value (which is a NULL pointer really). I think there are plugins for checking this, but it has nevertheless been a timeconsumer in some projects. Other things are fear of new/delete, as tolua++ really uses that quite a lot for methods like: Vec3 Matrix::getTrans(); It allocates a new Vec3(), stores a reference to it and when the receiving variable goes out of scope, it is garbage collected (at some point in time). This required for some scheduling of garbage collection. When that was done, it worked quite well. So I guess this fulfills both 12 in the above list of use for Lua, both building functionality inside lua, and using C++ code exported into lua. Why choose:-) Just my 2 cents. /Anders On Dec 11, 2007 11:50 PM, James Halliday [EMAIL PROTECTED] wrote: Jan Ciger wrote: Actually, I think that the focus should be on providing a meaningful API to export to these languages. That could even mean a wrapper in order to eliminate/minimize usage of pointers and some C++ functionality that is difficult to translate (templates?). Once you have that, the language bindings could be done very quickly for almost any language, even in an automated way (e.g. using SWIG or something similar). Ideally, the wrappers should be made automatically from the current code. I've been using osgswig ( http://code.google.com/p/osgswig/ ) for a project on a cave-type system combining python, vrjuggler, and osg. osgswig supports python, ruby, java and lua, although I've only played with the python features. I had tried to use osgPython and pyosg before, but they only work with older versions of osg. Jan Ciger wrote: / 1) Application is written in C/C++ and calls embedded scripts. This is/ / fairly typical for game development - game is written in C/C++ and e.g./ / AI is scripted using a built-in scripting engine. Here Lua is great (it/ / was written for it), because it is fairly easy to maintain separation/ / between different scripts (exception/error in one script does not crash/ / the whole thing). Furthermore, Lua is really tiny, with negligible/ / overhead. Another contender is Javascript (e.g. VRML standard uses it/ / for exactly this purpose). I wouldn't target this case, because it is/ / very application-specific and there is little a generic scene graph/ / binding could provide to it. /// / 2) Application is written in a high level language and calls into C/C++/ / code to run the performance critical stuff. I think that this is what/ / you want (... enable us to/ / develop applications purely from scripting languages, so developers in/ / this realm would just need the binaries to the OSG installed, and no/ / need for C++ dev environment). /The osgswig project seems to be primarily designed for scenario 2, although in my application I've been using osgswig as in scenario 1 by getting out a void pointer to the opaque values from the python api. I'm not sure how possible this approach is with other languages though. ~ James ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Anders Backman Email:[EMAIL PROTECTED] HPC2N/VRlab Phone:+46 (0)90-786 9936 Umea university Cellular: +46 (0)70-392 64 67 S-901 87 UMEA SWEDEN Fax: +46 90-786 6126 http://www.cs.umu.se/~andersb ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
Hi Cedric, On Dec 10, 2007 10:48 AM, Cedric Pinson [EMAIL PROTECTED] wrote: I would not like to have those node kit in the core of osg, because the functionnality they provide is not the core of osg, they are adaptators for others libs, and for me it should be a nodekit in a third party. The problem with 3rd party libs out in the community is often there are many different variants, but essentially do the same thing, this fractures the user/developer base using them and makes keeping things in sync with the core more problematic. It also requires users to go chasing this commonly used down. The downside for people who don't need these extra NodeKit is more source code, but since Cmake picks up on dependencies automatically - if you don't need them then the build system won't build them - so there is no overhead for you. Its not quite free as the snv update etc will be larger, but its actually pretty low cost for those who don't need them. Instead i think an osgPython or osgOQ are a place in the core, because it's realated directly with openGL and the scripting (osgPython) is a wrapper to osg. But it seems i am the only one to have this opinion so it means it will be integrated in the core ;) For the scripting language i would prefer osgPython because python is a language Object and lua not (maybe now it is ?). Lua can do OO just fine, its a very flexible little language. Also exposing functionality like osgAL and osgCal is easier within the scripted languages if they are already built as part of the core. End users will be much nearer the one stop shop when it comes to use of the OSG. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
On Sat, 2007-12-08 at 14:07 +, Robert Osfield wrote: Hi All, After a two month break I'm now doing a purge of the submissions backlog. I doubt I'll get all the way through before Monday, but on Monday I'll tag the first dev release since 2.2 stable was made. This dev release will be 2.3.0 and be the first concrete step towards the final 2.4. This leads me on to asking the question - what features should we aim to integrate with 2.4? My own short list for contenders for integration are: osgOQ - Occlusion Querry support osgCal - Cal3D integration I noticed there was a lot of Cal3D discussion going on here so I'd figure I'd chime in and say a few things. I have write access to Cal3D SVN I obtained a year or so ago when Palle Raabjerg and myself rewrote the Cal3D Blender exporter, which we built by starting from the version in the Soya project; I've also fixed a few small bugs here and there in Cal3D proper. I'm pretty familiar with Cal3D in general, and with the various Cal3D OSG plugins that exist. As a matter of fact, I'm the one who made the Cal3D videos on the website, and I used OSG to do it. :) http://home.gna.org/cal3d/ For a bit of info (and some personal opinion): Firstly, there is the generally-referred-to osgCal (officially called osgCal2), which was originally made by Ruben Lopez and has had many additional edits since then. There is also a GPL version that is incredibly more sophisticated which was created by the people at Underware, but the license wouldn't not allow for wholesale inclusion into OSG. Vladimir Shabanov recently made some changes to osgCal2, and I believe he and Ruben coordinated so that his changes were committed upstream. However, as I mentioned back then and I believe Jan Ciger has alluded to earlier in this thread: the code will need a lot of love before it's ready for serious inclusion. For example, the last time I checked, the shaders were somehow parsed by sed before actually being written into a valid shader file, and there's simply no way I can see anyone in the Windows or Mac world willing to accept such a restriction. One thing that should be kept in mind when using Cal3D is that in it's current state, Cal3D isn't a skeletal system alone--it's a skeletal animation system+mesh format, and one cannot be divorced from the other. Furthermore, there is a lot of data reproduction in Cal3D that already exists in OSG, and no way to easily (or cleanly) make changes therein. In the opinion of someone who is familiar with Cal3D, I'd say that we wait a bit on inclusion of this until someone has the time to cleanup the current plugin. Hardware skinning is a pretty common performance boost these days, and whatever solution arises for OSG, I'd personally look at support for this feature as the make-or-break aspect. We also need exporters, and while I wrote a significant portion of the Cal3D Blender exporter currently in SVN, I did it at a time where my knowledge of both Cal3D, Blender, and graphics/3D development in general was very poor, and thus cannot attest for it's reliability or cleanliness. :) As far as ReplicantBody is concerned I'm unsure--I've never looked at it. To be completely honest, character animation is such a huge issue unto itself that it probably deserves a lot of discussion and review before any steps are taken--but that's just my opinoin. Every time I'm forced to put any thought into the issue, I just get sleepy. What we __really__ need is an osgSkeleton NodeKit, which can then be exercised/demonstrated in the Collada importer, but would be usable alone as well in true OSG style: osgSkeleton::Skeleton* skel = new osgSkeleton::Skeleton(); osgSkeleton::Bone* root = new osgSkeleton::Bone(); osgSkeleton::Bone* child = new osgSkeleton::Bone(); root-addChildBone(child); skel-setRootBone(root); I bet once a basic, simple system was released, people would go to town making the necessary changes to bring it up to speed with other kits. It wouldn't have to be perfect, but as long as it was adaptable and done in true OSG fashion, people could subcass things in osgSkeleton for their own uses or to inject their desired interpolation algorithms (which is a big area of interest for animations buffs)... P. S. When I finish a release-candidate version of osgHUD (or whatever you want to change the name to), I'll be peddling that for inclusion as well. :) I've made a number of changes in the last few days if anyone is keeping up with SVN, and almost done with a decent implementation of a table layout, very similar to how HTML tables are done... however, no one posted any complaints to my first thread, so I'm just going to keep proceeding as normal, though I did remove the silly functional code that no one could have possibly understood but myself... it's a shame how difficult it is to do use something as [conceptually] easy as std::for_each()--it's a nightmare, when you can almost always
Re: [osg-users] Looking towards 2.4, and what might go into it.
Hi, could we get support for multiple render targets (MRT) integrated into 2.4? I know some people are using hacky patches for this. Some patches have been submitted, but they have to be reworked. I can help with this if needed. regards jp Robert Osfield wrote: Hi All, After a two month break I'm now doing a purge of the submissions backlog. I doubt I'll get all the way through before Monday, but on Monday I'll tag the first dev release since 2.2 stable was made. This dev release will be 2.3.0 and be the first concrete step towards the final 2.4. This leads me on to asking the question - what features should we aim to integrate with 2.4? My own short list for contenders for integration are: osgOQ - Occlusion Querry support osgCal - Cal3D integration osgAL - OpenAL integration I'm not personally familiar with these libraries, but do know that they are known to work with the latest OSG so should be relatively straight forward to integrate. Thoughts for the authors, maintainers? What extra work would be appropriate before integration? Would you be happy with integration? My own inclination towards integration is to make it a bit easier for OSG users to assemble their application without chasing down lots of different nodekits all of which are maintained in different places with different build system and different release schedules. The downside for me is there is more work involved at my end at least initially while we get the build systems working well across the range of platforms that the OSG supports. Long term I'd hope that this will diminish and it'll be less support work associated with helping end users get things working at there end. It should also be possible to make the overall OSG dev experience for end users slicker as we should be able properly test and get areas like multiple window/multi-threaded usage properly excercised. I would also like to see the core OSG have support for scripting out of the bag, as well as integration with the main browsers. One has to gauage what is doable in what time frame so should be considered in terms of 2.4 or 2.6 etc versions. I'd like to see scripting supported out of the box to enable us to develop applications purely from scripting languages, so developers in this realm would just need the binaries to the OSG installed, and no need for C++ dev environment. There are limits to how much functionality you can expose in this direction, but my guess is it should be possible to write reasonable useful apps, and especially good for prototyping and cross platform portability. One has to ask which scripting languages to go for - Lua and/or Python? Lua would be the easiest to integrate in terms of being very self contained i.e. which could stick the whole of the lua interpreter into the core OSG distribution and one would hardly notice as its so tiny. Thoughts? Robert. ps. I'm still very busy with other on going work so please don't expect me to be able to dive into this stuff right away. Come 2008 I should start become a bit more available and able to start looking at progressing some of the above, so opening this stuff off for discussion now will help us mesh gears better when the time comes. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
Hi Paul, On Dec 8, 2007 4:48 PM, Paul Martz [EMAIL PROTECTED] wrote: It is one Node, OcclusionQueryNode, derived from Group. This node has a few supporting classes that aren't exported. It also has a handful of small NodeVisitors for utility purposes. If we put this Node in a NodeKit rather than the osg library, how would it delete the query IDs? In our previous discussion on this subject, you outlined a new design for deleting OpenGL objects; I don't have the cycles to contribute to this development. If we put the node directly into the core osg library then issue of deleting ID's would be easily solvable but just encoding it into the library. Cull traversal wise it might make it more convenient to merge with the core OSG as well, i.e. osgUtil could then know about it explicitly and be able to do things accordingly. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
On Dec 8, 2007 9:12 PM, Anders Backman [EMAIL PROTECTED] wrote: I would say that osgAL is working rather well with osg as for now. OpenAL++ is a rather healthy abstraction rather than integrating OpenAL directly into osg... You get support for ogg-vorbis, streaming sound, capture (from input devices) etc... Is OpenAL++ is now part of osgAL? So I don't thing integrating osgAL would introduce any major problems, it depends on OpenAL and ogg-vorbis, thats it. Both are more or less standard in unix environments, and can easily be included in the OpenSceneGraph dependency package for windows, so no issues there as far as I see. Is the ogg-vorbis integration optional? Could it be factored out into a plugin? I'm just thinking about keeping a lid on essential external dependencies. What I have been lacking is CMake environment. Most of the questions regarding osgal I get is about building it together with osg, and it is usually in linux. I really like CMake, and introducing Cmake into osgal would make it pretty easy to integrate with osg. CMake integration should be straight forward, the only real extra job would be adding FindOpenAL.cmake and FindOgg-Vorbis.cmake. What is the feature list for osgCal these days? Im not following it in any detail, and I guess Im home-blind as we developed ReplicantBody and have been rather satisfied with that... Would there be any interest to merge the two? As far as I know, there are a few things in ReplicantBody that is good to have, ground following, animation blending, fileformat specification etc I am aware of both osgCal and ReplicantBody body am not very familiar with the code bases/current feature sets. I would like to see consolidation of related functionality. There is also the osgCharacter library out in the the community section that could be considered in terms of functionality. I do wonder if something like osgCal could be the basis for a more generic osgAnimation library. Items like key frame animation would be great to support, as well as skeletal animation like in Cal3D. It be desirable to integrate Cal3D style functionality directly within such a library and do away with the external dependency. This is longer term speculation though, we need to walk before we can run, so having some character animation support would be a good first step. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
Yes osgAL is tied with OpenAL++ And with Cmake it would be rather easy to make the ogg/vorbis integration a simple choice in the Cmake gui. /Anders On Dec 9, 2007 1:28 PM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Jan, On Dec 8, 2007 7:11 PM, Jan Ciger [EMAIL PROTECTED] wrote: Another good contender for integration would be some physics engine. I have experience with ODE, Bullet and the Opal wrapper, all three are reasonably usable with OSG (I have running code for this). However, physics integration is a bit more involved - there needs to be support for loaders of physically-simulated objects because the collision proxies need to match the geometry being displayed and the rigid bodies being simulated need to be initialized as well. Collada has some support for this already and it would be great to have this integrated. I know that Bullet has a Collada loader implemented already. One really cool thing would be to integrate osgCal with e.g. Bullet or ODE to provide rag dolls - I have this on my plate for a while already, unfortunately the days have only 24 hours :) I have been thinking about physics integration as well, but not suggested it on this round as there wasn't a contender sitting of the shelf ready to integrate. Longer term I'd like to see physics integration, ideally in a way that we can plug in different physics engine implementation, be them open source or commercial. OPAL might the a basis for such an implementation, or perhaps just inspiration to how to tackle/how not to tackle it ;-) I'd suggest member of the community experienced in this area propose what they see as a workable route forward. Even better get some code together for it 8-D One has to ask which scripting languages to go for - Lua and/or Python? Lua would be the easiest to integrate in terms of being very self contained i.e. which could stick the whole of the lua interpreter into the core OSG distribution and one would hardly notice as its so tiny. That does not make really sense. And that doesn't really parse ;-) There are actually two very different ways of integrating scripting: 1) Application is written in C/C++ and calls embedded scripts. This is fairly typical for game development - game is written in C/C++ and e.g. AI is scripted using a built-in scripting engine. Here Lua is great (it was written for it), because it is fairly easy to maintain separation between different scripts (exception/error in one script does not crash the whole thing). Furthermore, Lua is really tiny, with negligible overhead. Another contender is Javascript (e.g. VRML standard uses it for exactly this purpose). I wouldn't target this case, because it is very application-specific and there is little a generic scene graph binding could provide to it. 2) Application is written in a high level language and calls into C/C++ code to run the performance critical stuff. I think that this is what you want (... enable us to develop applications purely from scripting languages, so developers in this realm would just need the binaries to the OSG installed, and no need for C++ dev environment). In this case I would go for a full featured language with a rich set of libraries. Python trumps Lua very easily here with its huge collection of libraries and tools. Lua is a very minimalistic language designed for embedding, not for writing whole applications in. Soya3D 3D engine is written in this manner - programs are written in Python, calling C/C++ libraries that provide the functionality on top of OpenGL. Moreover, the Python bindings (osgPython?) do exist already, even though probably unmaintained at the moment ... Agree with all the above, and this is what I had in mind with my own introduction of motives. One of the reasons to integrate osgLua and/or osgPython with the core is facilitate all the above usage, but also help consolidate the effort on making these libraries better supported and maintained. There libraries will need work to get them fully functional. This is something I can help mentor, but being stretched for time and skills will be unlikely to be able contribute too much to the development. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Anders Backman Email:[EMAIL PROTECTED] HPC2N/VRlab Phone:+46 (0)90-786 9936 Umea university Cellular: +46 (0)70-392 64 67 S-901 87 UMEA SWEDEN Fax: +46 90-786 6126 http://www.cs.umu.se/~andersb ___ osg-users mailing list osg-users@lists.openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rizzen wrote: Good points Jan, though maybe we should have a compromise here. Thus OSG supports two scripting languages, the best one for each scenario. Scenario 1: Have Lua for embedded scripting via osgLua, which would go well for the gaming environment where processing speed is important. However, this is extremely application specific - you typically want to manipulate the game objects at a higher level from this type of scripts, such as reduce hitpoints on missile impact or make a path-finding/AI decision when your character sees a target. There is little need to access the scene graph directly from such code. That is easier (and a lot faster) to do from the C/C++ side. Think Quake C or Unreal script here. I am not sure how can you make this generic enough to be actually useful - - almost everybody would need to add their own bindings to the engine in order to explicitly expose the application-specific objects and the bulk of the OSG-related code will go unused. The only exception would be to make a another VRML where the scripting is used to drive/animate the scene graph objects themselves, but that has a fairly limited use if you do not expose additional functionality. Scenario 2: While have Python for high level language dev environment via osgPython, where speed is not important for idea testing, or business or scientific applications where maximum speed is not important, but ease of development is important. Actually, this has nothing at all to do with execution speed. The perception Python large = slow and Lua small = fast is first incorrect and second irrelevant here. In this case the performance-critical code (rendering and such) would be written in C/C++ (e.g. core OSG code) and only controlled from Python or another language. Basically, if the code is properly written, it should make no difference whether you write your application in C/C++ only or in Python - the performance bottlenecks will be always in the C/C++ code, not in Python. However, you do gain the advantage of very fast development with Python. The Python code handles things like GUI, user input and perhaps some business logic/reasoning and for that Python is plenty fast. Have a look either at Soya3D (http://home.gna.org/oomadness/en/soya3d/index.html) or PyOpenGL (http://pyopengl.sourceforge.net/) in order to get a taste of development in this style. Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFHXC6Qn11XseNj94gRAjS/AJ4vj+1dJlxsdT82c+dkBRXwofoZKgCg2eqk x2FgMhQriTt3m7q+HIYOv4k= =By0b -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Osfield wrote: I am aware of both osgCal and ReplicantBody body am not very familiar with the code bases/current feature sets. I would like to see consolidation of related functionality. There is also the osgCharacter library out in the the community section that could be considered in terms of functionality. osgCharacter is more an experiment in hardware skinning than a useful tool IMHO, it doesn't have even the basic animation-related functionality. Moreover, I do not think that it is maintained any more. I do wonder if something like osgCal could be the basis for a more generic osgAnimation library. Items like key frame animation would be great to support, as well as skeletal animation like in Cal3D. It be desirable to integrate Cal3D style functionality directly within such a library and do away with the external dependency. This is longer term speculation though, we need to walk before we can run, so having some character animation support would be a good first step. osgCal is essentially only a tiny rendering wrapper on top of Cal3D. Cal3D does the animation (loading, interpolation, blending, mixing ...) and calculates the skinned mesh for you if you want, but you need to provide your own rendering code. That is what osgCal does - it takes pre-calculated data from Cal3D and renders them using either osg::Geometry or more recently using some shader code to do the skinning in hardware. There are other renderers, even some using DirectX based on Cal3D. On the other hand Replicant is providing some higher level functionality on top of Cal3D - such as ground following, including calculation of the correct translation speed to avoid feet sliding. However, it has its own rendering back-end, not using osgCal at the moment. This would be good thing to merge, because osgCal rendering is quite a bit faster. I am not sure what are you referring to when speaking about keyframe animation, though. Do you mean 3D morphing of meshes? I would keep that separate, it is a completely different beast with different problems than skeletal animation. Animation of an inflating baloon is quite different issue than animation of a human or an octopus :) Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFHXDFcn11XseNj94gRAhtuAJ48xRX7Tz4u+F2jNqZEfl5YfTTxXwCg6S1j /myXSz4kIBk9FRuOChFIH1w= =pEMo -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Osfield wrote: I have been thinking about physics integration as well, but not suggested it on this round as there wasn't a contender sitting of the shelf ready to integrate. Longer term I'd like to see physics integration, ideally in a way that we can plug in different physics engine implementation, be them open source or commercial. OPAL might the a basis for such an implementation, or perhaps just inspiration to how to tackle/how not to tackle it ;-) Opal looks OK, but it doesn't seem to be actively developed. The most recent version of ODE breaks with it quite horribly. However, some of the design is quite nice. I'd suggest member of the community experienced in this area propose what they see as a workable route forward. Even better get some code together for it 8-D I have working code for Bullet at the moment, but this has worked the same for Opal too. Basically, it consists of three things: 1) A special node powering Bullet engine on every frame, either by means of an update callback or through an overridden accept(). This steps the physical simulation by elapsed real time between frames, calculating collisions and resolving them on the way. Here we can play with real/non-real time, decoupling between rendering and simulation time, etc. 2) Every rigid body has an update callback that when called updates the OSG transform of the node from the corresponding Bullet transform of the rigid body. This ensures that the objects are rendered where Bullet tells them to be and with right orientations. 3) Object loader. This is the tricky beast, because physics engines support objects built up out of several pieces connected by joints (hierarchies). Think of a car or a rag doll. Each piece has a collision proxy mesh and physical properties (mass, position, initial velocity and torque, material parameters ...) At the moment I have only a loader that takes a simple geometry (something osgDB can load) and builds up a collision proxy either automatically using bounding boxes or takes one from a config file, together with the remaining parameters. I do not support joint hierarchies yet, but the code exists in Bullet examples for this. Then the loader has to instantiate all rigid bodies and all geometry, link them together using update callbacks and ideally deliver the whole collection of objects somewhere as a higher level object (e.g. called car or character). Here one would think that the hierarchy should have a root and you simply keep a reference to that, but it may not actually have one - e.g. a simple car could be 4 cylinders (wheels) and a platform, connected by joints - there isn't really an explicit notion of a root transform in the scene graph sense. All pieces are simulated independently in world coordinates, the joints ensuring that the pieces stay together (or not - Bullet supports breakable joints). I have this solved by something called an object manager which keeps track of these kind of objects, but I am fairly open to design discussion because I do not like this too much - it is hassle to deal with, e.g. from scripting code. I am willing to contribute this code, however I am not sure whether this is a meaningful design - especially when it comes to possible scalability issues with all those callbacks and the object loading/management. Also, loading of the physics data should be ideally integrated with loading of the geometry itself - e.g. Collada supports export of physical properties of objects. That does not make really sense. And that doesn't really parse ;-) :-p Agree with all the above, and this is what I had in mind with my own introduction of motives. One of the reasons to integrate osgLua and/or osgPython with the core is facilitate all the above usage, but also help consolidate the effort on making these libraries better supported and maintained. There libraries will need work to get them fully functional. This is something I can help mentor, but being stretched for time and skills will be unlikely to be able contribute too much to the development. Actually, I think that the focus should be on providing a meaningful API to export to these languages. That could even mean a wrapper in order to eliminate/minimize usage of pointers and some C++ functionality that is difficult to translate (templates?). Once you have that, the language bindings could be done very quickly for almost any language, even in an automated way (e.g. using SWIG or something similar). Ideally, the wrappers should be made automatically from the current code. It also neatly sidesteps a problem that some people may not like Python or Lua or whatever for any kind of reason - they are free to build their own bindings, since the API is there already and it would be only a matter of running SWIG or whatever on it. Even something like CORBA binding to OSG would be possible without too much hassle. Think scene/viewer control
Re: [osg-users] Looking towards 2.4, and what might go into it.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Anders, Anders Backman wrote: If the new osgCal, or whatever name it will have can make benefit of a tight osg connection, together with the high-level functionality of rbody, I think this is a good start. Then when its working, it can be re-factored to meet other functionality. We will actually have some time in the beginning of next year to look over ReplicantBody and perhaps the integration/merge of osgCal rendering... That would be great - I am willing to help with that work as I need to get this working myself. Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFHXDjKn11XseNj94gRAr+zAKDQGX8H7GeFAw8Xus0nyIxxMdi4vACgjoOp aljRZtJZ+m14PTHFHhsh0C8= =mclP -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
Hello Anders and Jan, I agree, the most logical path (and I think we have discussed this quite a few times before) is to merge osgCal (with its better rendering back-end), with the higher functionality of ReplicantBody. That would be excellent! I am sure I am not the only one who wanted at one point to integrate some character animation into a project and couldn't decide between osgCal(2) and ReplicantBody. A merge and integration into core OSG would be a great boon to the community I think. I look forward to seeing an testing your work, J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
Hi Robert -- I'm happy to help with integrating osgOQ into the core distribution. At this point, .ive support needs to be added, but this should be trivial. Then it'd be nice to have a solution for cleaning up query IDs (discussed recently); I can easily use the existing framework if the OcclusionQueryNode is added to the osg library. I'm getting some testing from ISU (who funded the project), but nothing other than run the demo testing from others. It'd be nice to see more testing. I am investigating one bug at this time, but it is only in non-osgViewer usage, so this shouldn't be a showstopper for 2.4 integration. -Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Saturday, December 08, 2007 7:08 AM To: OpenSceneGraph Users Subject: [osg-users] Looking towards 2.4, and what might go into it. Hi All, After a two month break I'm now doing a purge of the submissions backlog. I doubt I'll get all the way through before Monday, but on Monday I'll tag the first dev release since 2.2 stable was made. This dev release will be 2.3.0 and be the first concrete step towards the final 2.4. This leads me on to asking the question - what features should we aim to integrate with 2.4? My own short list for contenders for integration are: osgOQ - Occlusion Querry support osgCal - Cal3D integration osgAL - OpenAL integration I'm not personally familiar with these libraries, but do know that they are known to work with the latest OSG so should be relatively straight forward to integrate. Thoughts for the authors, maintainers? What extra work would be appropriate before integration? Would you be happy with integration? My own inclination towards integration is to make it a bit easier for OSG users to assemble their application without chasing down lots of different nodekits all of which are maintained in different places with different build system and different release schedules. The downside for me is there is more work involved at my end at least initially while we get the build systems working well across the range of platforms that the OSG supports. Long term I'd hope that this will diminish and it'll be less support work associated with helping end users get things working at there end. It should also be possible to make the overall OSG dev experience for end users slicker as we should be able properly test and get areas like multiple window/multi-threaded usage properly excercised. I would also like to see the core OSG have support for scripting out of the bag, as well as integration with the main browsers. One has to gauage what is doable in what time frame so should be considered in terms of 2.4 or 2.6 etc versions. I'd like to see scripting supported out of the box to enable us to develop applications purely from scripting languages, so developers in this realm would just need the binaries to the OSG installed, and no need for C++ dev environment. There are limits to how much functionality you can expose in this direction, but my guess is it should be possible to write reasonable useful apps, and especially good for prototyping and cross platform portability. One has to ask which scripting languages to go for - Lua and/or Python? Lua would be the easiest to integrate in terms of being very self contained i.e. which could stick the whole of the lua interpreter into the core OSG distribution and one would hardly notice as its so tiny. Thoughts? Robert. ps. I'm still very busy with other on going work so please don't expect me to be able to dive into this stuff right away. Come 2008 I should start become a bit more available and able to start looking at progressing some of the above, so opening this stuff off for discussion now will help us mesh gears better when the time comes. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
Hi Paul, How big is osgOQ? I am wondering if its small enough it could be integrated into another NodeKit. Thoughts? Robert. On Dec 8, 2007 4:19 PM, Paul Martz [EMAIL PROTECTED] wrote: Hi Robert -- I'm happy to help with integrating osgOQ into the core distribution. At this point, .ive support needs to be added, but this should be trivial. Then it'd be nice to have a solution for cleaning up query IDs (discussed recently); I can easily use the existing framework if the OcclusionQueryNode is added to the osg library. I'm getting some testing from ISU (who funded the project), but nothing other than run the demo testing from others. It'd be nice to see more testing. I am investigating one bug at this time, but it is only in non-osgViewer usage, so this shouldn't be a showstopper for 2.4 integration. -Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Saturday, December 08, 2007 7:08 AM To: OpenSceneGraph Users Subject: [osg-users] Looking towards 2.4, and what might go into it. Hi All, After a two month break I'm now doing a purge of the submissions backlog. I doubt I'll get all the way through before Monday, but on Monday I'll tag the first dev release since 2.2 stable was made. This dev release will be 2.3.0 and be the first concrete step towards the final 2.4. This leads me on to asking the question - what features should we aim to integrate with 2.4? My own short list for contenders for integration are: osgOQ - Occlusion Querry support osgCal - Cal3D integration osgAL - OpenAL integration I'm not personally familiar with these libraries, but do know that they are known to work with the latest OSG so should be relatively straight forward to integrate. Thoughts for the authors, maintainers? What extra work would be appropriate before integration? Would you be happy with integration? My own inclination towards integration is to make it a bit easier for OSG users to assemble their application without chasing down lots of different nodekits all of which are maintained in different places with different build system and different release schedules. The downside for me is there is more work involved at my end at least initially while we get the build systems working well across the range of platforms that the OSG supports. Long term I'd hope that this will diminish and it'll be less support work associated with helping end users get things working at there end. It should also be possible to make the overall OSG dev experience for end users slicker as we should be able properly test and get areas like multiple window/multi-threaded usage properly excercised. I would also like to see the core OSG have support for scripting out of the bag, as well as integration with the main browsers. One has to gauage what is doable in what time frame so should be considered in terms of 2.4 or 2.6 etc versions. I'd like to see scripting supported out of the box to enable us to develop applications purely from scripting languages, so developers in this realm would just need the binaries to the OSG installed, and no need for C++ dev environment. There are limits to how much functionality you can expose in this direction, but my guess is it should be possible to write reasonable useful apps, and especially good for prototyping and cross platform portability. One has to ask which scripting languages to go for - Lua and/or Python? Lua would be the easiest to integrate in terms of being very self contained i.e. which could stick the whole of the lua interpreter into the core OSG distribution and one would hardly notice as its so tiny. Thoughts? Robert. ps. I'm still very busy with other on going work so please don't expect me to be able to dive into this stuff right away. Come 2008 I should start become a bit more available and able to start looking at progressing some of the above, so opening this stuff off for discussion now will help us mesh gears better when the time comes. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.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] Looking towards 2.4, and what might go into it.
It is one Node, OcclusionQueryNode, derived from Group. This node has a few supporting classes that aren't exported. It also has a handful of small NodeVisitors for utility purposes. If we put this Node in a NodeKit rather than the osg library, how would it delete the query IDs? In our previous discussion on this subject, you outlined a new design for deleting OpenGL objects; I don't have the cycles to contribute to this development. -Paul Hi Paul, How big is osgOQ? I am wondering if its small enough it could be integrated into another NodeKit. Thoughts? Robert. On Dec 8, 2007 4:19 PM, Paul Martz [EMAIL PROTECTED] wrote: Hi Robert -- I'm happy to help with integrating osgOQ into the core distribution. At this point, .ive support needs to be added, but this should be trivial. Then it'd be nice to have a solution for cleaning up query IDs (discussed recently); I can easily use the existing framework if the OcclusionQueryNode is added to the osg library. I'm getting some testing from ISU (who funded the project), but nothing other than run the demo testing from others. It'd be nice to see more testing. I am investigating one bug at this time, but it is only in non-osgViewer usage, so this shouldn't be a showstopper for 2.4 integration. -Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Saturday, December 08, 2007 7:08 AM To: OpenSceneGraph Users Subject: [osg-users] Looking towards 2.4, and what might go into it. Hi All, After a two month break I'm now doing a purge of the submissions backlog. I doubt I'll get all the way through before Monday, but on Monday I'll tag the first dev release since 2.2 stable was made. This dev release will be 2.3.0 and be the first concrete step towards the final 2.4. This leads me on to asking the question - what features should we aim to integrate with 2.4? My own short list for contenders for integration are: osgOQ - Occlusion Querry support osgCal - Cal3D integration osgAL - OpenAL integration I'm not personally familiar with these libraries, but do know that they are known to work with the latest OSG so should be relatively straight forward to integrate. Thoughts for the authors, maintainers? What extra work would be appropriate before integration? Would you be happy with integration? My own inclination towards integration is to make it a bit easier for OSG users to assemble their application without chasing down lots of different nodekits all of which are maintained in different places with different build system and different release schedules. The downside for me is there is more work involved at my end at least initially while we get the build systems working well across the range of platforms that the OSG supports. Long term I'd hope that this will diminish and it'll be less support work associated with helping end users get things working at there end. It should also be possible to make the overall OSG dev experience for end users slicker as we should be able properly test and get areas like multiple window/multi-threaded usage properly excercised. I would also like to see the core OSG have support for scripting out of the bag, as well as integration with the main browsers. One has to gauage what is doable in what time frame so should be considered in terms of 2.4 or 2.6 etc versions. I'd like to see scripting supported out of the box to enable us to develop applications purely from scripting languages, so developers in this realm would just need the binaries to the OSG installed, and no need for C++ dev environment. There are limits to how much functionality you can expose in this direction, but my guess is it should be possible to write reasonable useful apps, and especially good for prototyping and cross platform portability. One has to ask which scripting languages to go for - Lua and/or Python? Lua would be the easiest to integrate in terms of being very self contained i.e. which could stick the whole of the lua interpreter into the core OSG distribution and one would hardly notice as its so tiny. Thoughts? Robert. ps. I'm still very busy with other on going work so please don't expect me to be able to dive into this stuff right away. Come 2008 I should start become a bit more available and able to start looking at progressing some of the above, so opening this stuff off for discussion now will help us mesh gears better when the time comes. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce
Re: [osg-users] Looking towards 2.4, and what might go into it.
Hi! Any chance for http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2007-October/003523.html Regards Panagiotis Papadakos ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Looking towards 2.4, and what might go into it.
Hi All, After a two month break I'm now doing a purge of the submissions backlog. I doubt I'll get all the way through before Monday, but on Monday I'll tag the first dev release since 2.2 stable was made. This dev release will be 2.3.0 and be the first concrete step towards the final 2.4. This leads me on to asking the question - what features should we aim to integrate with 2.4? My own short list for contenders for integration are: osgOQ - Occlusion Querry support osgCal - Cal3D integration osgAL - OpenAL integration I'm not personally familiar with these libraries, but do know that they are known to work with the latest OSG so should be relatively straight forward to integrate. Thoughts for the authors, maintainers? What extra work would be appropriate before integration? Would you be happy with integration? My own inclination towards integration is to make it a bit easier for OSG users to assemble their application without chasing down lots of different nodekits all of which are maintained in different places with different build system and different release schedules. The downside for me is there is more work involved at my end at least initially while we get the build systems working well across the range of platforms that the OSG supports. Long term I'd hope that this will diminish and it'll be less support work associated with helping end users get things working at there end. It should also be possible to make the overall OSG dev experience for end users slicker as we should be able properly test and get areas like multiple window/multi-threaded usage properly excercised. I would also like to see the core OSG have support for scripting out of the bag, as well as integration with the main browsers. One has to gauage what is doable in what time frame so should be considered in terms of 2.4 or 2.6 etc versions. I'd like to see scripting supported out of the box to enable us to develop applications purely from scripting languages, so developers in this realm would just need the binaries to the OSG installed, and no need for C++ dev environment. There are limits to how much functionality you can expose in this direction, but my guess is it should be possible to write reasonable useful apps, and especially good for prototyping and cross platform portability. One has to ask which scripting languages to go for - Lua and/or Python? Lua would be the easiest to integrate in terms of being very self contained i.e. which could stick the whole of the lua interpreter into the core OSG distribution and one would hardly notice as its so tiny. Thoughts? Robert. ps. I'm still very busy with other on going work so please don't expect me to be able to dive into this stuff right away. Come 2008 I should start become a bit more available and able to start looking at progressing some of the above, so opening this stuff off for discussion now will help us mesh gears better when the time comes. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Osfield wrote: Hi All, After a two month break I'm now doing a purge of the submissions backlog. I doubt I'll get all the way through before Monday, but on Monday I'll tag the first dev release since 2.2 stable was made. This dev release will be 2.3.0 and be the first concrete step towards the final 2.4. This leads me on to asking the question - what features should we aim to integrate with 2.4? My own short list for contenders for integration are: osgOQ - Occlusion Querry support osgCal - Cal3D integration osgAL - OpenAL integration I'm not personally familiar with these libraries, but do know that they are known to work with the latest OSG so should be relatively straight forward to integrate. Thoughts for the authors, maintainers? What extra work would be appropriate before integration? Would you be happy with integration? osgCal is pretty small and its inclusion to the core would be a good opportunity to clean up the code. However, be careful about the two version of this library - one is GPL and the other is LGPL licensed. Regarding OpenAL integration - I am not sure how well is osgAL maintained. We have integrated OpenAL with OSG on our own, because osgAL had some additional dependencies and didn't seem to be maintained at the time. It may have changed in the meantime, though. One way or another, OpenAL is fairly easy to interface with OSG - it needs only the positions of the sound sources and the listener's position, the rest is independent from the scene graph (sound data management, triggering of sounds, etc.) Another good contender for integration would be some physics engine. I have experience with ODE, Bullet and the Opal wrapper, all three are reasonably usable with OSG (I have running code for this). However, physics integration is a bit more involved - there needs to be support for loaders of physically-simulated objects because the collision proxies need to match the geometry being displayed and the rigid bodies being simulated need to be initialized as well. Collada has some support for this already and it would be great to have this integrated. I know that Bullet has a Collada loader implemented already. One really cool thing would be to integrate osgCal with e.g. Bullet or ODE to provide rag dolls - I have this on my plate for a while already, unfortunately the days have only 24 hours :) One has to ask which scripting languages to go for - Lua and/or Python? Lua would be the easiest to integrate in terms of being very self contained i.e. which could stick the whole of the lua interpreter into the core OSG distribution and one would hardly notice as its so tiny. That does not make really sense. There are actually two very different ways of integrating scripting: 1) Application is written in C/C++ and calls embedded scripts. This is fairly typical for game development - game is written in C/C++ and e.g. AI is scripted using a built-in scripting engine. Here Lua is great (it was written for it), because it is fairly easy to maintain separation between different scripts (exception/error in one script does not crash the whole thing). Furthermore, Lua is really tiny, with negligible overhead. Another contender is Javascript (e.g. VRML standard uses it for exactly this purpose). I wouldn't target this case, because it is very application-specific and there is little a generic scene graph binding could provide to it. 2) Application is written in a high level language and calls into C/C++ code to run the performance critical stuff. I think that this is what you want (... enable us to develop applications purely from scripting languages, so developers in this realm would just need the binaries to the OSG installed, and no need for C++ dev environment). In this case I would go for a full featured language with a rich set of libraries. Python trumps Lua very easily here with its huge collection of libraries and tools. Lua is a very minimalistic language designed for embedding, not for writing whole applications in. Soya3D 3D engine is written in this manner - programs are written in Python, calling C/C++ libraries that provide the functionality on top of OpenGL. Moreover, the Python bindings (osgPython?) do exist already, even though probably unmaintained at the moment ... Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFHWux2n11XseNj94gRAieUAJ90RrKitL+FunLHNFkIhOzWcD+2IACgnaH7 I1Jq6mvn7/nOnfPd7CZOsds= =9xr/ -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
My own short list for contenders for integration are: osgOQ - Occlusion Querry support osgCal - Cal3D integration osgAL - OpenAL integration osgEphemeris would be a nice node kit to integrate for 2.4 as well. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
I would say that osgAL is working rather well with osg as for now. OpenAL++ is a rather healthy abstraction rather than integrating OpenAL directly into osg... You get support for ogg-vorbis, streaming sound, capture (from input devices) etc... So I don't thing integrating osgAL would introduce any major problems, it depends on OpenAL and ogg-vorbis, thats it. Both are more or less standard in unix environments, and can easily be included in the OpenSceneGraph dependency package for windows, so no issues there as far as I see. What I have been lacking is CMake environment. Most of the questions regarding osgal I get is about building it together with osg, and it is usually in linux. I really like CMake, and introducing Cmake into osgal would make it pretty easy to integrate with osg. What is the feature list for osgCal these days? Im not following it in any detail, and I guess Im home-blind as we developed ReplicantBody and have been rather satisfied with that... Would there be any interest to merge the two? As far as I know, there are a few things in ReplicantBody that is good to have, ground following, animation blending, fileformat specification etc Comments? /Anders On Dec 8, 2007 9:42 PM, KSpam [EMAIL PROTECTED] wrote: My own short list for contenders for integration are: osgOQ - Occlusion Querry support osgCal - Cal3D integration osgAL - OpenAL integration osgEphemeris would be a nice node kit to integrate for 2.4 as well. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Anders Backman Email:[EMAIL PROTECTED] HPC2N/VRlab Phone:+46 (0)90-786 9936 Umea university Cellular: +46 (0)70-392 64 67 S-901 87 UMEA SWEDEN Fax: +46 90-786 6126 http://www.cs.umu.se/~andersb ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
Jan Ciger wrote: One has to ask which scripting languages to go for - Lua and/or Python? Lua would be the easiest to integrate in terms of being very self contained i.e. which could stick the whole of the lua interpreter into the core OSG distribution and one would hardly notice as its so tiny. That does not make really sense. There are actually two very different ways of integrating scripting: 1) Application is written in C/C++ and calls embedded scripts. This is fairly typical for game development - game is written in C/C++ and e.g. AI is scripted using a built-in scripting engine. Here Lua is great (it was written for it), because it is fairly easy to maintain separation between different scripts (exception/error in one script does not crash the whole thing). Furthermore, Lua is really tiny, with negligible overhead. Another contender is Javascript (e.g. VRML standard uses it for exactly this purpose). I wouldn't target this case, because it is very application-specific and there is little a generic scene graph binding could provide to it. 2) Application is written in a high level language and calls into C/C++ code to run the performance critical stuff. I think that this is what you want (... enable us to develop applications purely from scripting languages, so developers in this realm would just need the binaries to the OSG installed, and no need for C++ dev environment). In this case I would go for a full featured language with a rich set of libraries. Python trumps Lua very easily here with its huge collection of libraries and tools. Lua is a very minimalistic language designed for embedding, not for writing whole applications in. Soya3D 3D engine is written in this manner - programs are written in Python, calling C/C++ libraries that provide the functionality on top of OpenGL. Moreover, the Python bindings (osgPython?) do exist already, even though probably unmaintained at the moment ... Good points Jan, though maybe we should have a compromise here. Thus OSG supports two scripting languages, the best one for each scenario. Scenario 1: Have Lua for embedded scripting via osgLua, which would go well for the gaming environment where processing speed is important. Scenario 2: While have Python for high level language dev environment via osgPython, where speed is not important for idea testing, or business or scientific applications where maximum speed is not important, but ease of development is important. Rizzen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
