Re: [osg-users] NodeKit integration in OpenSceneGraph-2.x series
Hi Jan, On Sun, Nov 9, 2008 at 7:03 PM, Jan Ciger [EMAIL PROTECTED] wrote: Just a parenthesis - I gave quite a bit of feedback to Cedric about this. I think that there are some design issues that need to be addressed first, before it even reaches basic feature parity with existing code in osgCal or Replicant when concerning basic animation support (not the more advanced stuff in Replicant). And this is why I wanted to encourage discussion about it from those experienced with osgCal etc. ;-) osgAnimation does have a lot of promise, that promise is most likely to be fulfilled with usage and refinement. This is exactly how the core OSG shaped up from being a tiny niche scene graph that could render a shiny cow to one that can do what it does today. Physics is an integration issue as we'll never attempt to do wholesale physics ourselves, I haven't reviewed any strong candidates for this role yet. I wouldn't try to integrate physics as such - that is a monstrous job and you would be tied to one engine that doesn't fit everyone (which one? ODE? Bullet? Havoc? ...) I would rather make things easy to integrate by the end users (e.g. an easy way to get bounding boxes and meshes from the nodes at runtime for collision detection) and perhaps include a collision detection support in the core scenegraph. This has been a persistent question over the years and a good integration of collision detection needs support from the scenegraph. I covered this point in my email on the physics integration thread - I don't want an osgPhysics library tied to specific physics engine, but rather a NodeKit that facilitates the integration of physics engines. It's best to track down this email as it goes into my thoughts on this topic in far more detail than is appropriate to repeat here. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] NodeKit integration in OpenSceneGraph-2.x series
Hi Robert, I agree that a new library should be added carefully, or it will become a burden for developers and users. I plan to devide the modeling library into several parts: basic modelers (extrusions, revolutions), parametric curves and surfaces (Bezier and NURBS), polygon technologies (simplification, subdivision and triangle striping) and helpers (BSP, animation deformers, k-dop, OBB bounding boxes, boolean operators). Some of them are in progress and some in design. It need a long time before practical uses, but I will try to make the library stable and usable and prepare for the integration at any time. I would also help improve the documents of OSG classes and functions. At present, I am a maintainer of the osgchina website and try to help some of the Chinese beginners realize OSG principles more easily, also have translated Paul Martz's famous OSGQSG into Chinese and finished writing series of tutorials. Maybe I could help complete some of the comments in comming days. Regards, Wang Rui 2008/11/10 Robert Osfield [EMAIL PROTECTED] Hi Wang Rui, I was wondering about mentioning modelling functionality in my email, but held back as it's potentially a huge and complex topic in itself. I certainly open to nurbs support in the core OSG, hard stuff are items like computing accurate intersections between nurbs. The same goes for basic geometry construction. Currently we have various things for creating scene graph elements in osgUtil, and the ShapeDrawable in core osg. If we had a osgModelling NodeKit/utility library then these elements might be best moved into osgModelling. The are a number of areas in geometry creation that can get very complex, I know because I've done a work in this in the past - sometimes things get far more complex than original expected once you deal with real world data. This complexity also raises the bar for how many users are capable of helping maintain it. The fewer the users available to maintain the more often it falls on my shoulders to fix problems, but given my role these days I have to function as a multi-tasker covering many different topics it makes it very hard for me to have sufficient time and focus to tackle these complex problems. Due to this maintenance issue taking on any NodeKit makes me bit nervous, the more advanced it is the more of challenge it will be for me to keep on top of it. There already couple of NodeKit's in the OSG that I already feel not fully able to maintain them, and these NodeKit's have been effectively orphaned so it has ended up on my shoulders to maintain them. New NodeKit's don't solve these existing maintenance issue only add to the possible burden so I have to be very careful. Having NodeKit's develop out in the community and be shook down prior to integration is the way forward on this. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] NodeKit integration in OpenSceneGraph-2.x series
Hi Sukender, On Mon, Nov 10, 2008 at 11:06 AM, Sukender [EMAIL PROTECTED] wrote: I agree that dependencies are generally a burden when compiling OSG (thanks to those who maintain 3rd party libs!). And I won't suggest intagration of huge libs anymore! But do you think some users could be interested in code that has dependencies, but distrubuted *outside* OSG? I mean perhaps some people already said I want library XYZ to be integrated into OSG ; so maybe this could be useful to put links to existing code on the wiki? Maybe a Already-coded libs integrations-like paragraph anywhere on the wiki could be useful? Well, that's just an idea... We already have a Wiki page for community maintained NodeKits. http://www.openscenegraph.org/projects/osg/wiki/Community/NodeKits Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Allright, I thought it was only for nodekits, not for integration of a specific library. -- Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] NodeKit integration in OpenSceneGraph-2.x series
Hi Sukender, On Mon, Nov 10, 2008 at 11:06 AM, Sukender [EMAIL PROTECTED] wrote: I agree that dependencies are generally a burden when compiling OSG (thanks to those who maintain 3rd party libs!). And I won't suggest intagration of huge libs anymore! But do you think some users could be interested in code that has dependencies, but distrubuted *outside* OSG? I mean perhaps some people already said I want library XYZ to be integrated into OSG ; so maybe this could be useful to put links to existing code on the wiki? Maybe a Already-coded libs integrations-like paragraph anywhere on the wiki could be useful? Well, that's just an idea... We already have a Wiki page for community maintained NodeKits. http://www.openscenegraph.org/projects/osg/wiki/Community/NodeKits Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] NodeKit integration in OpenSceneGraph-2.x series
Hi Robert, Hi Sukender, On Mon, Nov 10, 2008 at 9:56 AM, Sukender [EMAIL PROTECTED] wrote: ** About utilities: I coded some little features that could be integreated into OSG, but I have one problem: these are often specific and very small (not enough to create a nodekit). So what? May I suggest them to be integrated into osgUtil or such? In osg-submissions perhaps? Note : I'm also working a lille bit on audio (OpenAL - osgAL) and UDP networking (TNL). We have to be careful about when and where we do feature integration. Sometime integration could be put into a pre-exisitng library, I do raise this point in my first post, but countering this if extra external dependencies are brought in by an addition. Err... well, I'm not sure I explained myself the right way. I was saying that I coded some utilities *that have no other depedency* than OSG but that could be a little bit specific. So you think that I may discuss them on osg-submissions, or here? (The note about openAL/TNL was something completely different...) ** About dependencies: I agree that dependencies should be added only when really needed, but in another hand, it is sometimes useful to link against lower-level portable libraries. I'm actually thinking about boost libraries (filesystem.path, program_options, and smart pointers). For instance, I coded overloads of osgSB::read*() that take boost::filesystem::path. The main benefit is of course to handle paths the same way under many OSes. Do you think that it could be possible in OSG? Each dependency needs to be viewed on its own merit, and kept to specific scope. The larger the dependency the smaller the scope it should have, i.e. be kept to a plugin or a specific NodeKit. This approach allows users to be able to gain the bulk of OSG functionality without needing to pull together other significant libs. Boost is something that I'd put under the category of a big dependency and as such isn't something that should go any where near the core OSG that needs to be kept as light and easily portable with minimal dependencies. You are welcome to add such dependencies to your own app, but for the OSG I need to keep the core clean as possible as it's the common denominator that we all share. As guide I'd recommend having a look at the way I've managed exisiting NodeKits and dependencies. You'll find the core OSG libs all just depend upon principally C++ and OpenGL, this is something that has guided OSG development right from the beginning and is something that has helped the OSG port to far more platforms than competing real-time graphics toolkits. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org I agree that dependencies are generally a burden when compiling OSG (thanks to those who maintain 3rd party libs!). And I won't suggest intagration of huge libs anymore! But do you think some users could be interested in code that has dependencies, but distrubuted *outside* OSG? I mean perhaps some people already said I want library XYZ to be integrated into OSG ; so maybe this could be useful to put links to existing code on the wiki? Maybe a Already-coded libs integrations-like paragraph anywhere on the wiki could be useful? Well, that's just an idea... Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] NodeKit integration in OpenSceneGraph-2.x series
Hi Robert, hi everyone, I agree with your vision and think that this will push OSG to more power and popularity. Grouping, refactoring and factorizing are always great ideas - even if that would require a lot of work from the whole community. About physics: I want to say something, but I didn't found the physics integration thread... (I just changed my email address so that my inbox is almost empty!) ** About utilities: I coded some little features that could be integreated into OSG, but I have one problem: these are often specific and very small (not enough to create a nodekit). So what? May I suggest them to be integrated into osgUtil or such? In osg-submissions perhaps? Note : I'm also working a lille bit on audio (OpenAL - osgAL) and UDP networking (TNL). ** About organization: I think that work that is enough general purpose should be integrated into OSG, but that maybe needs a little bit organization: as the number of functions and classes will grow, the user may get lost. Here are some ideas: - Create sub-namespaces to split big ones - Create an index (in reference docs) by theme (meshes boolean operations, image processing, post-render effects, spatialized audio...) - And of course update the wiki as it is already! For me, that's leaving less and less code in my engine, which is great news - since it could be useful to more people of course. ** About dependencies: I agree that dependencies should be added only when really needed, but in another hand, it is sometimes useful to link against lower-level portable libraries. I'm actually thinking about boost libraries (filesystem.path, program_options, and smart pointers). For instance, I coded overloads of osgSB::read*() that take boost::filesystem::path. The main benefit is of course to handle paths the same way under many OSes. Do you think that it could be possible in OSG? Sincerely, -- Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Sun, 09 Nov 2008 17:25:34 +0100, Robert Osfield [EMAIL PROTECTED] a écrit: Hi All, There has been lots of discussion about various NodeKit or last month or two. In OSG-2.6 we saw the introduction of osgWidget from the community, in OSG-2.8 we'll see the integration of new osgVolume library. OSG-2.10 is likely to see the integration of osgAnimation, but if things converge quickly for this NodeKIt it might even make it into OSG-2.8. There are other NodeKits out into the community, some are up to date and well maintained others rather dormant or even orphaned. Each of these NodeKit could be put forward for integration with the core OSG. Whether any of these should be integrated and if so how one goes about is something that is worthy of discussion. I don't think we need heavily structured metrics to measure NodeKits against, but some informal metrics might help provide some transparency in the process. Here's a couple to get started with: 1) What overall feature set does the OpenSceneGraph need as it evolves to better meet the common needs of the community? All NodeKits needs to be take as a step towards this goal, this includes ones already in OpenSceneGraph trunk. But how to define the goals for the OpenSceneGraph for the 2.x and 3.x series and beyond? 2) All NodeKit to make into the core OpenSceneGraph need to be portable across all platforms. (Or might there be exceptions??) 3) All NodeKit to make into the core OpenSceneGraph need to fit to the C++ design and coding style 4) All NodeKit need to be activity used and supported by a range of members in the community. 5) Granularity of NodeKits need to fit the function as well as the breadth/complexity of functionality encompassed. 6) Where functionality of two NodeKits overlap then for integration to occur the NodeKit need to be merged in some fashion, this might be that osgOriginal and osgNew get merged into osgOriginal, or even into a osgBetterNameForCombination. Migration to new merged classes/NodeKits would require a system for helping existing users migrate / provide deprecated functionality for a defined period. 7) Naming of NodeKits should be descriptive of it's function, prefer long descriptive name over short acronyms. 8) NodeKits should have ascii read/write support, but ideally binary support too (we really need an extensible binary format). 9) NodeKits must be wrap-able via osgIntrospection/genwrapper. 10) NodeKit should facilitate collaboration and quell fragmentation of code and developer resources. 11) NodeKit should be of solid design and implementation quality. 12) NodeKit and dependency proliferation should be deemed a negative quality - a NodeKit must add real value to compensate for the extra complexity it introduces. OK, feel free to add more/refine the above. Once this discussion reaches some kind of conclusion I'll put up a page on the WIKI summarising it all. Putting the above
Re: [osg-users] NodeKit integration in OpenSceneGraph-2.x series
Hi Wang Rui, I was wondering about mentioning modelling functionality in my email, but held back as it's potentially a huge and complex topic in itself. I certainly open to nurbs support in the core OSG, hard stuff are items like computing accurate intersections between nurbs. The same goes for basic geometry construction. Currently we have various things for creating scene graph elements in osgUtil, and the ShapeDrawable in core osg. If we had a osgModelling NodeKit/utility library then these elements might be best moved into osgModelling. The are a number of areas in geometry creation that can get very complex, I know because I've done a work in this in the past - sometimes things get far more complex than original expected once you deal with real world data. This complexity also raises the bar for how many users are capable of helping maintain it. The fewer the users available to maintain the more often it falls on my shoulders to fix problems, but given my role these days I have to function as a multi-tasker covering many different topics it makes it very hard for me to have sufficient time and focus to tackle these complex problems. Due to this maintenance issue taking on any NodeKit makes me bit nervous, the more advanced it is the more of challenge it will be for me to keep on top of it. There already couple of NodeKit's in the OSG that I already feel not fully able to maintain them, and these NodeKit's have been effectively orphaned so it has ended up on my shoulders to maintain them. New NodeKit's don't solve these existing maintenance issue only add to the possible burden so I have to be very careful. Having NodeKit's develop out in the community and be shook down prior to integration is the way forward on this. Robert. On Mon, Nov 10, 2008 at 12:45 AM, Wang Rui [EMAIL PROTECTED] wrote: Hi Robert. I wonder if there is a plan to add a modeling library to the core OSG in future. Not because I'm working on a similar library 'osgModeling', but also from the experiences of other 3D graphics APIs. Take VRS3D for example, it has a number of common functionalitys which help build user customized models from curves and parameters, like extrusions (VRS::Extrusion), revolutions (VRS::Hyperboloid), torus and the most important, Bezier and NURBS. Of course, OSG focuses on how to improve the efficiency of rendering and most models are generated from external libraries and software (like 3dsmax). But some times we may need build models from curve and point data of end-users. It is a trouble if these data should be converted by other software and transferred back to OSG, especially on the network. Also a modeling nodekit is a good place for some of existing classes to live in, like Delaunay, Simplifier and SmoothingVisitor, and a good start for future developments. Maybe we could create and assemble models using a modeling nodekit and control them with an animation nodekit in comming days. I would like to help develop such nodekits and share my existing code if others have better plans and actions. Also I would keep on developing osgModeling as a external project if a modeling library is not needed at present, and be glad to do any work to improve and popularize OSG. There are thousands of OSG members in China (statistics from the osgchina forum) and it will be a great power of the OSG community in any time. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] NodeKit integration in OpenSceneGraph-2.x series
Animation is something that is under-way in the form of osgAnimation, which started life as AnimTK and has evolved rapidly to tick many more of the above items, so it looks to be rapidly becoming a good candidate for inclusion. Just a parenthesis - I gave quite a bit of feedback to Cedric about this. I think that there are some design issues that need to be addressed first, before it even reaches basic feature parity with existing code in osgCal or Replicant when concerning basic animation support (not the more advanced stuff in Replicant). Jan, I followed your comments to Cedric and above with interest. You made several important remarks to ensure that osgAnimation will properly support character animation / skeletal animation. However, I wonder if you are not putting too much emphasis on just this aspect while there may be more ways to do and use animation. It is my understanding that animation means that a certain aspect of a scene is under control so it can be changed over time. This aspect is usually orientation, position or scale, but may also be color, a float weight, a bool, a string, etc... maybe some custom type. IMHO osg should take a generic approach towards animation, albeit probably not too generic :). Perhaps 3D studio max (or similar - I just happen to have some experience with this app) can be taken as an example how to approach animation. It uses animation controllers and key frame animation to implement animation and in my experience this is quite flexible. I wonder how far osgAnimation should go in replicating similar functionality. This said, I must admit that I have only quickly glanced over osgAnimation in its current state, and I believe it already supports much of what I mentioned. Cheers, Erik den Dekker ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] NodeKit integration in OpenSceneGraph-2.x series
Hi Robert. I wonder if there is a plan to add a modeling library to the core OSG in future. Not because I'm working on a similar library 'osgModeling', but also from the experiences of other 3D graphics APIs. Take VRS3D for example, it has a number of common functionalitys which help build user customized models from curves and parameters, like extrusions (VRS::Extrusion), revolutions (VRS::Hyperboloid), torus and the most important, Bezier and NURBS. Of course, OSG focuses on how to improve the efficiency of rendering and most models are generated from external libraries and software (like 3dsmax). But some times we may need build models from curve and point data of end-users. It is a trouble if these data should be converted by other software and transferred back to OSG, especially on the network. Also a modeling nodekit is a good place for some of existing classes to live in, like Delaunay, Simplifier and SmoothingVisitor, and a good start for future developments. Maybe we could create and assemble models using a modeling nodekit and control them with an animation nodekit in comming days. I would like to help develop such nodekits and share my existing code if others have better plans and actions. Also I would keep on developing osgModeling as a external project if a modeling library is not needed at present, and be glad to do any work to improve and popularize OSG. There are thousands of OSG members in China (statistics from the osgchina forum) and it will be a great power of the OSG community in any time. Best wishes, Wang Rui 2008/11/10 Robert Osfield [EMAIL PROTECTED] Hi All, There has been lots of discussion about various NodeKit or last month or two. In OSG-2.6 we saw the introduction of osgWidget from the community, in OSG-2.8 we'll see the integration of new osgVolume library. OSG-2.10 is likely to see the integration of osgAnimation, but if things converge quickly for this NodeKIt it might even make it into OSG-2.8. There are other NodeKits out into the community, some are up to date and well maintained others rather dormant or even orphaned. Each of these NodeKit could be put forward for integration with the core OSG. Whether any of these should be integrated and if so how one goes about is something that is worthy of discussion. I don't think we need heavily structured metrics to measure NodeKits against, but some informal metrics might help provide some transparency in the process. Here's a couple to get started with: 1) What overall feature set does the OpenSceneGraph need as it evolves to better meet the common needs of the community? All NodeKits needs to be take as a step towards this goal, this includes ones already in OpenSceneGraph trunk. But how to define the goals for the OpenSceneGraph for the 2.x and 3.x series and beyond? 2) All NodeKit to make into the core OpenSceneGraph need to be portable across all platforms. (Or might there be exceptions??) 3) All NodeKit to make into the core OpenSceneGraph need to fit to the C++ design and coding style 4) All NodeKit need to be activity used and supported by a range of members in the community. 5) Granularity of NodeKits need to fit the function as well as the breadth/complexity of functionality encompassed. 6) Where functionality of two NodeKits overlap then for integration to occur the NodeKit need to be merged in some fashion, this might be that osgOriginal and osgNew get merged into osgOriginal, or even into a osgBetterNameForCombination. Migration to new merged classes/NodeKits would require a system for helping existing users migrate / provide deprecated functionality for a defined period. 7) Naming of NodeKits should be descriptive of it's function, prefer long descriptive name over short acronyms. 8) NodeKits should have ascii read/write support, but ideally binary support too (we really need an extensible binary format). 9) NodeKits must be wrap-able via osgIntrospection/genwrapper. 10) NodeKit should facilitate collaboration and quell fragmentation of code and developer resources. 11) NodeKit should be of solid design and implementation quality. 12) NodeKit and dependency proliferation should be deemed a negative quality - a NodeKit must add real value to compensate for the extra complexity it introduces. OK, feel free to add more/refine the above. Once this discussion reaches some kind of conclusion I'll put up a page on the WIKI summarising it all. Putting the above metric against the core OSG NodeKits we see a couple of libs that perhaps could be renamed/refactored. osgSim and osgGA aren't descriptive names at all. osgDB is not much better, put probably not quite so bad and it's not a NodeKit so exempt from all common sense :-) osgGA is very old and clunky which could do with a revamp, such as revamp might be a good time to merge the functionality it provides into other NodeKits. Perhaps some functionality going into
