Re: [osg-users] Ideas for OSG v3.0 or how to make it younger :)
For my job currently I'm using the statistics package R and writing things using LaTeX. Both have a very structured method to manage and document addons. Look at http://stat.ethz.ch/CRAN/ (very good) and at: http://www.ctan.org/tex-archive/ (less clear). These could be an inspiration for the future NodeKits structure and management, I think. Just my 0.05 CHF mario Robert Osfield wrote: Hi Art, I understand the issues you talk about. External NodeKit can be neglected by potential users because they aren't visible enough, and there are also issue of compatibility and maintenance of these external NodeKits. It's not just an issue of NodeKits, it applies to plugins or applications that live around the core OSG project. I don't think the solution need be a pure software management issue, it's strongly related to management of website resources. We've had various different initiatives over the years to try and address this issue - the wiki is one avenue, another was the formation of osgforge.org and hosting of several ancilery projects like VPB, Present3D, osgLua and osgPython. My hope was osgforge would become a incubator for projects that could make it into the core, or become part of the close nit family of NodeKits. Such initiatives haven't thrived as perhaps they could have, partly because the various contributors haven't pushed things forward, and partly that wiki/website management takes time and dedicated manpower. I'm open to suggestions on how better to streamline and manage this side of things. The bottom line is a key missing ingredient has been engineers who put the time into keep websites up to date. As for re-factoring handling of NodeKits in 3.0, I'm open to this. It might even make the most sense to build 3.0 incrementally, starting with a re-factored core scene graph and then bit by bit re-introduce the NodeKits as they get ported across. Quite a few of the older NodeKits would be best rewritten using shaders, or to be incorporated into other NodeKits. Having some scheme where 3rd party NodeKits can be pulled in by end users may well help facilitate a move over to a 3.0. One thing I have thought about in the past of have an "Open Graphics Suite" that is collection of related libraries/applications, with a scene graph one element of the suite, then you'd have extra libraries, exporters, applications all populate this suite. The suite would contain optional components that could be selected from to provide the tools required for different apps. Modern linux packaging repositories provide this model and the scale of 10's of thousands of compatible libraries and applications. Robert. On Fri, Jan 23, 2009 at 5:34 PM, Art Tevs wrote: Hi folks, The community becames bigger and bigger and there are more and more projects/nodekits which offers additional features to osg. And therefor I think OSG 3.0 is the best time to refactor the whole nodekit maintaining structure. Hence here are couple of ideas, how to do so. In my opinion, nodeKits/plugins which were not lucky to be included into osg main core wouldn't survive, because the people would just forget about them. Making everyday advertisment, that this and this nodekit does provide the functionality you are looking for is also not the solution. New users are not used to read wiki pages or search in google, they do not even read ReadMes which are essential for proper work. They just download and compile the osg and want to have either an example showing how to do it or try to reinvent the wheel everytime again and again. Nodekits which are then not included in the main core (or better say: main download) are not noticed by users. What I propose is to rearrange/refactor/cleanup osg main core to basic functionality of a scene graph, so to remove everything which has nothing to do with a scene graph on its own. Then provide something like official category of nodekits, where all previuosuly filtered nodekits would be moved. Robert will became main maintainer, who is responsible for the whole code and for bringing the category maintainers together. A category maintainer is responsible for his category and maintainers of each individaul projects which are covered by his category. The individual maintainer is responsible only for its own project. This would create some kind of hierarchy of nodekits and its maintainers, which would make the further development of OpenSceneGraph more flexible, I think. All the maintainers of the nodekits should get their own svn permissions to being able to commit to the svn, however only to their own projects. Maintainers of a category would get responsible to bring all the projects into one NodeKit-Pack/Category-Pack and make sure, that the pack is compileable and compatible with current osg version. This will free up Robert, who is spending maybe his whole time to the project, and will also make the decision about new fea
[osg-users] OverlayNode + export to osg
Hi @all, I have created a scene with a texture overlay using osgSim::OverlayNode and want to export the objects + texture as .osg or .ive file. Doing this, the texture is missing... had anybody similar problems and perhaps found a solution? greetings, Luc ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgEarth - terrain on demand
Hi everyone, I've just committed some CMake fixes and osgEarth now builds and runs for me on Ubuntu. The only thing I had to do extra to get it to work was manually copy the plugins generated by osgEarth to the osgPlugins directory (/usr/local/lib/osgPlugins-2.7.9 on Ubuntu with SVN). I'm going to see if I can get osgEarth to install it's plugins directly in the osgPlugins directory during install. Could those of you trying on Linux do an update and let me know how things work? Thanks! Jason On Fri, Jan 23, 2009 at 7:04 PM, Jason Beverage wrote: > Hi Jan, > > I'm trying to figure out why that is this evening. I committed some fixes > earlier to get the core library building and the plugins are the last bit of > CMake wizardry I need to figure out:) > > Thanks! > > Jason > > > On Fri, Jan 23, 2009 at 5:22 PM, Jan Ciger wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Jason Beverage wrote: >> > Hi Robert, >> > >> > I'm going to take a look at the Cmake issues under Linux and I'll let >> > you know when I've figured them out. >> > >> > Thanks! >> > >> >> I have managed to configure it on Linux, but when compiling, it tries to >> link the plugins in strange place: >> >> $ make >> - -- Configuring done >> - -- Generating done >> - -- Build files have been written to: /media/backup/osg/osgearth >> [ 55%] Built target osgEarth >> Linking CXX shared module //osgdb_earth.so >> /usr/bin/ld: cannot open output file //osgdb_earth.so: Permission denied >> collect2: ld returned 1 exit status >> make[2]: *** [/osgdb_earth.so] Error 1 >> make[1]: *** [src/osgPlugins/earth/CMakeFiles/osgdb_earth.dir/all] Error 2 >> make: *** [all] Error 2 >> >> It is not supposed to put anything in the root directory. Is there an >> environment variable or something to configure to tell it where to put >> these libraries? >> >> Jan >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v1.4.9 (GNU/Linux) >> Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org >> >> iD8DBQFJekMMn11XseNj94gRAvjdAJ4tA5sRUFdKsY/E8vVIOKH/oj3+WQCfWPsy >> FxLybfu23L0kJnfEXOCeRdU= >> =Bpow >> -END PGP SIGNATURE- >> ___ >> 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] osgEarth - terrain on demand
Hi Jan, I'm trying to figure out why that is this evening. I committed some fixes earlier to get the core library building and the plugins are the last bit of CMake wizardry I need to figure out:) Thanks! Jason On Fri, Jan 23, 2009 at 5:22 PM, Jan Ciger wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Jason Beverage wrote: > > Hi Robert, > > > > I'm going to take a look at the Cmake issues under Linux and I'll let > > you know when I've figured them out. > > > > Thanks! > > > > I have managed to configure it on Linux, but when compiling, it tries to > link the plugins in strange place: > > $ make > - -- Configuring done > - -- Generating done > - -- Build files have been written to: /media/backup/osg/osgearth > [ 55%] Built target osgEarth > Linking CXX shared module //osgdb_earth.so > /usr/bin/ld: cannot open output file //osgdb_earth.so: Permission denied > collect2: ld returned 1 exit status > make[2]: *** [/osgdb_earth.so] Error 1 > make[1]: *** [src/osgPlugins/earth/CMakeFiles/osgdb_earth.dir/all] Error 2 > make: *** [all] Error 2 > > It is not supposed to put anything in the root directory. Is there an > environment variable or something to configure to tell it where to put > these libraries? > > Jan > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org > > iD8DBQFJekMMn11XseNj94gRAvjdAJ4tA5sRUFdKsY/E8vVIOKH/oj3+WQCfWPsy > FxLybfu23L0kJnfEXOCeRdU= > =Bpow > -END PGP SIGNATURE- > ___ > 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] Please test svn/trunk in prep for 2.7.9 dev release
I did a clean compile of current svn head on Mac OSX 10.5, and then rebuilt and tested some of my projects that use OSG. All is well. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Friday, January 23, 2009 9:11 AM To: OpenSceneGraph Users Subject: [osg-users] Please test svn/trunk in prep for 2.7.9 dev release Hi All, I would like to finish this week with a 2.7.9 dev release, could users do a check out of svn/trunk and let know if your build succeeds/or where it fails. Thanks, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgEarth - terrain on demand
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jason Beverage wrote: > Hi Robert, > > I'm going to take a look at the Cmake issues under Linux and I'll let > you know when I've figured them out. > > Thanks! > I have managed to configure it on Linux, but when compiling, it tries to link the plugins in strange place: $ make - -- Configuring done - -- Generating done - -- Build files have been written to: /media/backup/osg/osgearth [ 55%] Built target osgEarth Linking CXX shared module //osgdb_earth.so /usr/bin/ld: cannot open output file //osgdb_earth.so: Permission denied collect2: ld returned 1 exit status make[2]: *** [/osgdb_earth.so] Error 1 make[1]: *** [src/osgPlugins/earth/CMakeFiles/osgdb_earth.dir/all] Error 2 make: *** [all] Error 2 It is not supposed to put anything in the root directory. Is there an environment variable or something to configure to tell it where to put these libraries? Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJekMMn11XseNj94gRAvjdAJ4tA5sRUFdKsY/E8vVIOKH/oj3+WQCfWPsy FxLybfu23L0kJnfEXOCeRdU= =Bpow -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] Development plan for imminent stable OSG-2.8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I have just compiled the trunk on Linux (Mandriva 2009, i586) without a hitch and it seems to be working after some light testing. Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJej9On11XseNj94gRAmHSAJ9CAhkY8jqlCkA9lxFRGgeNb4d0FACgrdPg MNUIwW7r2TpjmooAT2sNQAs= =wIkN -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Inconsistency for INSTALL target and BUILD_DOCUMENTATION
Hi all, I just noticed a small inconsistency. Normally, the INSTALL target should have as dependencies any other targets that it needs to install. But it seems that the documentation targets (openscenegraph_doc and openthreads_doc) are not dependencies of the INSTALL target. But they should be. If I have previously built the documentation, the INSTALL target installs it to its proper place. But if I have not explicitly built the docs myself, the INSTALL target does not build them and hence does not install the docs (though it doesn't give any error either). The package targets all seem to have the right dependencies though. It's a small detail, and probably not worth holding up 2.8, but I just found it weird... Perhaps someone with the necessary knowledge could fix it? J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg/Export disabling MSVC "deprecated" warning
Hi Robert, In the great scheme of things, for OSG-2.8 I now want to be getting the code ready for release and fixing real bugs rather polishing what remains of the most stubborn and unhelpful of warnings. OK, let's move on then. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Development plan for imminent stable OSG-2.8
Hi Robert, If svn/trunk is looking near perfect for the release we may even be able to get OSG-2.8.0 out this month, but probably we'll be talking about a release in the first week of February. Regarding this, I just did a build of current SVN and it went well, with the latest warning fixes and suppressions it's pretty much warning free (didn't pay close attention, I will next time I do a build). I would very much like for us to get the OSG binaries sorted out for this OSG-2.8, both for platforms like Windows [...] On Windows making packages is a no-brainer now, thanks to the recent work. Great work Mattias! All we need is a submission mechanism. If I want my binaries to be available, where do I upload them? Some FTP site could perhaps be set up with an /incoming directory... Do we want some testing by the community before they're made available on the Downloads page? I can take care of packages for VC8, debug and release, if we can sort these questions out. Possibly VC7.1 and VC9 too, but if someone else could do those it would be better for my work schedule :-) Thanks, and looking forward to 2.8! J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg/Export disabling MSVC "deprecated" warning
Hi JS, > But as I said, perhaps adding these as command line options instead of > inside osg/Export would be better. So /wd4244 /wd4251 /wd4275 or something > like that. Because as soon as they're in osg/Export, then these warnings are > also disabled for user code which includes any OSG header (since any OSG > header includes osg/Export). I think it's "wrong" for a library to dictate > what happens when compiling user code... I understand the problem with the warning disable bleeding into end user apps, and really isn't ideal practice, but... if we don't then all these unhelpful warnings will spill over into the build of end users apps. Disable the warnings using compile options might solve this issue with the OSG build itself but doesn't solve the problem of warnings in the end user apps. I think we're either stuck with using the include/osg/Export pragma's or to use the push/pop which isn't ideal either as we'd potentially end up touch lots of OSG files. It might be we could just use push/pop for the Vec* classes and use include/osg/Export to disable the dll warnings. In the great scheme of things, for OSG-2.8 I now want to be getting the code ready for release and fixing real bugs rather polishing what remains of the most stubborn and unhelpful of warnings. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Development plan for imminent stable OSG-2.8
Hi All, I've now completed all the key feature development for OSG-2.8, and I'm focus on getting the svn/trunk stable enough to make the OpenSceneGraph-2.8 branch. My current thought is to complete the outstanding submission merges over the weekend and make the last dev release 2.7.9 on Monday. This will need lots of build and runtime testing from the community, and if things look good then make an OSG-2.8 branch mid to end of next week. This OSG-2.8 branch would make the feature freeze for 2.8 and the beginning of a series of release candidates for the final stable OSG-2.8.0. Once 2.8.0 goes out the OSG-2.8 branch will then be maintained with any further stable patch release (2.8.1 etc) being sourced from this. If svn/trunk is looking near perfect for the release we may even be able to get OSG-2.8.0 out this month, but probably we'll be talking about a release in the first week of February. This is a two week window that I feel is doable given good support from the community in getting the OSG tested and debugged across platforms. Towards this effort I would suggest it would be great time to volunteer more system for doing nightly builds of svn/trunk and the OSG-2.8 branch when it comes out, the CDash page is at: http://www.cdash.org/CDashPublic/index.php?project=OpenSceneGraph I would very much like for us to get the OSG binaries sorted out for this OSG-2.8, both for platforms like Windows and OSX, and for linux, in particular knocking on the Linux distro doors to get OSG-2.8 in the up coming linux releases. I greatly appreciate any assistance you can provide in terms or testing or helping out on the coordinating with packaging of the final release. Thanks in advance, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [forum] New Feature (no need of same email address as on the mailing list)
Hi folks, I recently added a new feature to the forum. From now on there is no need to use the same email address for the forum as for the mailing list. You can setup your profile to use forum's default email address in the "From" headers of mails sent through the forum. This feature allows you to unsubscribe your mail box from the mailing list and move to forum use only. It also allows you to hide your email address from users outside of the forum. Only registered forum users could then find out your real email address. If you post a topic/message on the forum following happens: - if you have enabled forum's default mail adress in from header, the email posted on the mailing list will be posted as "From: Your Name " - if this feature is not enabled, then it will be posted as "From: Your Name " - in this case your email adress has to be subscribed on the mailing list An example how it works you can see when you take a look on the header of this mail. My name and forum's email adress were used for the "From" header. Best regards and have fun, art P.S. To enable the feature login on the forum and click on "Mail2Forum Settings" right to the logo. Or just visit here http://osgforum.tevs.eu/m2f_usercp.php. Per default the feature is disabled -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=5046#5046 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg/Export disabling MSVC "deprecated" warning
Hi Robert, I've now fixed the two of the sets of warnings I mentioned in my previous email, so leaves just the float/double casting, and dll linkgage related warnings: #if defined(_MSC_VER) && defined(OSG_DISABLE_MSVC_WARNINGS) #pragma warning( disable : 4244 ) #pragma warning( disable : 4251 ) #pragma warning( disable : 4275 ) #endif But as I said, perhaps adding these as command line options instead of inside osg/Export would be better. So /wd4244 /wd4251 /wd4275 or something like that. Because as soon as they're in osg/Export, then these warnings are also disabled for user code which includes any OSG header (since any OSG header includes osg/Export). I think it's "wrong" for a library to dictate what happens when compiling user code... For example, if I'm concerned about data type truncation so I want to have warning C4244 active in my own code, _but_ I include OSG headers, then I'll have to re-enable the warning manually each time I include OSG headers like this: #include #include #pragma warning( enable : 4244 ) (note that I have to do this in each file that includes OSG headers!) I'd think that not forcing users to do this would be better. Note that in my case, I don't really mind (for now) but others visibly do (as indicated by the person who started this thread). At this time I think doing a purge of casts would introduce too many opportunities for bugs to be introduced this close to a release. I totally agree. I wasn't arguing. :-) You (and others) are welcome to have a bash at trying to fix these warnings, but it comes with the same qualification with the casting task - right now we can't afford to change lots of OSG headers as each change does introduce another chance for a typo bug to be accidentally introduced. I just checked, and the warning also shows up for any std container type which contains OSG types. So for example this well-known line generates the warning: typedef std::vector ParentList; ParentList _parents; warning C4251: 'osg::Node::_parents' : class 'std::vector<_Ty>' needs to have dll-interface to be used by clients of class 'osg::Node' Since we can't modify std::vector to add OSG_EXPORT to it ( :-) ) I think we don't have a choice but to suppress the two warnings at large. So the three warnings you ended up suppressing should be fine. I still question the method of suppression though (see above). J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Why is using an IntersectVisitor with drawables using indices so time consuming?
Hi Reed, Are you talking about doing indices with osg::Geometry vertex indices or DrawElement*() primitive set. Vertex indices are deprecated because they perform very poorly w.r.t OpenGL as it forces the OSG to send everything to OpenGL via slow paths. It's far far more efficient to use DrawElemenet*() primitive sets. osgUtil::IntersectVisitor is also a deprecated, and only kept around for compatibility with OSG-1.x code. The modern and more flexible version is osgUtil::IntersectionVisitor. However, both approaches still be are slow because the vertex index data to be expanded before being passed to the generic triangle intersection code. Please port your code across to use DrawElementUShort or DrawElementUInt(), this will solve rendering issues as well as intersections issues. Robert. On Fri, Jan 23, 2009 at 7:44 PM, Reed McKenna wrote: > I generate large drawables using indices (UIntArray) that point to the > actual vertices (Vec3Array). When an IntersectVisitor visits this drawable, > it takes at least four times the amount of processing time as that used for > the same drawable created without indices. What is the huge difference? It > seems that the one level of indirection for indices should only have a minor > impact. I would appreciate any feedback to help me understand how to get the > memory savings gained by using indices yet maintain the efficiency of the > IntersectVisitor. Thanks. > > ___ > 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] Problem in FluidFrictionOperator
Hi Lionel, On Fri, Jan 23, 2009 at 5:24 PM, Robert Osfield wrote: > Thanks for the test model, I've now tested but as yet don't have any > conclusion, will need to dig deeper. I've just reviewed the svn log for FluidFrictionOperation.cpp and the if block you've removed in your changes is part of the original code submitted by Macro Jez, and hasn't been touched save for a name change of the enum. This makes me very hesitant to remove code that was clearly written for a purpose and has worked without much complaint for 7 years. The code may have buggy for all those 7 years, or perhaps the particle setup you've chosen breaks it, just removing it certainly doesn't look appropriate. Perhaps Marco Jez can be coaxed out to do a review of your model and the code to see if he can spot what is going wrong with your particle system setup :-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Why is using an IntersectVisitor with drawables using indices so time consuming?
I generate large drawables using indices (UIntArray) that point to the actual vertices (Vec3Array). When an IntersectVisitor visits this drawable, it takes at least four times the amount of processing time as that used for the same drawable created without indices. What is the huge difference? It seems that the one level of indirection for indices should only have a minor impact. I would appreciate any feedback to help me understand how to get the memory savings gained by using indices yet maintain the efficiency of the IntersectVisitor. Thanks. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test svn/trunk in prep for 2.7.9 dev release
Hi Paul, On Fri, Jan 23, 2009 at 7:30 PM, Paul Melis wrote: > And the OVERRIDE flag not making it to the .osg file, is that as > expected as well? Oh missed that issue. Currently the .osg format doesn't have support for tracking the override flags. It's a missing feature ;-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Ideas for OSG v3.0 or how to make it younger :)
Hi Art, I understand the issues you talk about. External NodeKit can be neglected by potential users because they aren't visible enough, and there are also issue of compatibility and maintenance of these external NodeKits. It's not just an issue of NodeKits, it applies to plugins or applications that live around the core OSG project. I don't think the solution need be a pure software management issue, it's strongly related to management of website resources. We've had various different initiatives over the years to try and address this issue - the wiki is one avenue, another was the formation of osgforge.org and hosting of several ancilery projects like VPB, Present3D, osgLua and osgPython. My hope was osgforge would become a incubator for projects that could make it into the core, or become part of the close nit family of NodeKits. Such initiatives haven't thrived as perhaps they could have, partly because the various contributors haven't pushed things forward, and partly that wiki/website management takes time and dedicated manpower. I'm open to suggestions on how better to streamline and manage this side of things. The bottom line is a key missing ingredient has been engineers who put the time into keep websites up to date. As for re-factoring handling of NodeKits in 3.0, I'm open to this. It might even make the most sense to build 3.0 incrementally, starting with a re-factored core scene graph and then bit by bit re-introduce the NodeKits as they get ported across. Quite a few of the older NodeKits would be best rewritten using shaders, or to be incorporated into other NodeKits. Having some scheme where 3rd party NodeKits can be pulled in by end users may well help facilitate a move over to a 3.0. One thing I have thought about in the past of have an "Open Graphics Suite" that is collection of related libraries/applications, with a scene graph one element of the suite, then you'd have extra libraries, exporters, applications all populate this suite. The suite would contain optional components that could be selected from to provide the tools required for different apps. Modern linux packaging repositories provide this model and the scale of 10's of thousands of compatible libraries and applications. Robert. On Fri, Jan 23, 2009 at 5:34 PM, Art Tevs wrote: > Hi folks, > > The community becames bigger and bigger and there are more and more > projects/nodekits which offers additional features to osg. And therefor I > think OSG 3.0 is the best time to refactor the whole nodekit maintaining > structure. Hence here are couple of ideas, how to do so. > > > In my opinion, nodeKits/plugins which were not lucky to be included into osg > main core wouldn't survive, because the people would just forget about them. > Making everyday advertisment, that this and this nodekit does provide the > functionality you are looking for is also not the solution. New users are not > used to read wiki pages or search in google, they do not even read ReadMes > which are essential for proper work. They just download and compile the osg > and want to have either an example showing how to do it or try to reinvent > the wheel everytime again and again. Nodekits which are then not included in > the main core (or better say: main download) are not noticed by users. > > > What I propose is to rearrange/refactor/cleanup osg main core to basic > functionality of a scene graph, so to remove everything which has nothing to > do with a scene graph on its own. Then provide something like official > category of nodekits, where all previuosuly filtered nodekits would be moved. > Robert will became main maintainer, who is responsible for the whole code and > for bringing the category maintainers together. A category maintainer is > responsible for his category and maintainers of each individaul projects > which are covered by his category. The individual maintainer is responsible > only for its own project. This would create some kind of hierarchy of > nodekits and its maintainers, which would make the further development of > OpenSceneGraph more flexible, I think. > > > All the maintainers of the nodekits should get their own svn permissions to > being able to commit to the svn, however only to their own projects. > Maintainers of a category would get responsible to bring all the projects > into one NodeKit-Pack/Category-Pack and make sure, that the pack is > compileable and compatible with current osg version. This will free up > Robert, who is spending maybe his whole time to the project, and will also > make the decision about new features more democratic :) > > > What I imagine is that when you download osg you get just the basic > functionality and nothing more. Then you decide to have gui functionality, > hence you download the GUI-NodeKit and you get the osgGA, osgWidget, osgText > and other nodekits which are still marked as official OSG GUI nodekits. All > that nodekits/nodekit categor
Re: [osg-users] Please test svn/trunk in prep for 2.7.9 dev release
Robert Osfield wrote: > Hi Paul, > > I have just tried your example out and the OSG is working perfectly, > the problem stems for dumptruck.osg not defining a color array on one > of the geometries, but defining it for the other two. In your app you > enable the AMBIENT_AND_DIFFUSE colour material mode, which shows up > this disparity, but dumptruck.osg disable the the colour material mode > which makes OpenGL ignore any vertex colour arrays so hides the > problem in the model. > Ah, interesting, I didn't suspect it would be something like that. > If you are seeing similar problems in your own app/models then go > looking for missing colour/normal arrays on geometries. > > For dumptruck.osg I've added the missing colour array and checked into > into svn/trunk of OpenSceneGaph-Data, this fixes the problem you've > observed. > Great! And the OVERRIDE flag not making it to the .osg file, is that as expected as well? Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test svn/trunk in prep for 2.7.9 dev release
Sounds good. I don't really have time to dive too deep into this issue, I just wanted to report the problem. I use ITK and OSG extensively in in my work. I will keep an eye on this issue and I'll let you know if I learn anything. Frank On Fri, Jan 23, 2009 at 07:06:53PM +, Robert Osfield wrote: > HI Frank, > > It should be possible to link the dicom plugin with a static version > of ITK, other plugins link to static versions of their respectively > libraries. ITK itself might not be best used as a static lib though - > as it does raise questions about how ITK's plugins mechanisms work. > I'm no ITK expert though, so can't really dive too deep in this topic. > The best help I can provide would be to have look over your errors > perhaps I or someone else can spot something. > > W.r.t the dicom loader, I currently used DCMTK as a loader as it's far > more capable a DICOM loader than ITK is, the ITK path was just written > as quick hack to get something imported. ITK is actually far better > suited for use for image processing rather than image loading, and in > later osgVolume work I expect to be using ITK for handling tasks such > as segmentation. > > Robert. > > On Fri, Jan 23, 2009 at 5:57 PM, Frank Miller wrote: > > Hi Robert, > > > > I don't know if this qualifies as a build error but I will share it > > anyway. Yesterday I built a fresh *dynamic* osg because I wanted to > > play with osgVolume. I told cmake about my *static* ITK installation and > > the build failed. I assumed at the time that it is impossible to link a > > static library into a dynamic library. When I rebuilt osg without any > > reference to ITK everything worked fine. > > > > Was my assumption correct or is this an error? > > > > By the way, I got side-tracked and never played with osgVolume. I do > > look forward to working with it. > > > > Frank > > > > On Fri, Jan 23, 2009 at 04:10:34PM +, Robert Osfield wrote: > >> Hi All, > >> > >> I would like to finish this week with a 2.7.9 dev release, could users > >> do a check out of svn/trunk and let know if your build succeeds/or > >> where it fails. > >> > >> Thanks, > >> Robert. > >> ___ > >> osg-users mailing list > >> osg-users@lists.openscenegraph.org > >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > ___ > > osg-users mailing list > > osg-users@lists.openscenegraph.org > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test svn/trunk in prep for 2.7.9 dev release
Hi Paul,
I have just tried your example out and the OSG is working perfectly,
the problem stems for dumptruck.osg not defining a color array on one
of the geometries, but defining it for the other two. In your app you
enable the AMBIENT_AND_DIFFUSE colour material mode, which shows up
this disparity, but dumptruck.osg disable the the colour material mode
which makes OpenGL ignore any vertex colour arrays so hides the
problem in the model.
If you are seeing similar problems in your own app/models then go
looking for missing colour/normal arrays on geometries.
For dumptruck.osg I've added the missing colour array and checked into
into svn/trunk of OpenSceneGaph-Data, this fixes the problem you've
observed.
Robert.
On Fri, Jan 23, 2009 at 5:24 PM, Paul Melis
wrote:
> Paul Melis wrote:
>> Paul Melis wrote:
>>> Hi Robert,
>>>
>>> Robert Osfield wrote:
I would like to finish this week with a 2.7.9 dev release, could users
do a check out of svn/trunk and let know if your build succeeds/or
where it fails.
>>> Not really a build failure of such, but could you take a look at the
>>> example I posted in the thread "Re: [osg-users] Statesets with
>>> renderBin make sub-models invisible", dated 01/22/2009 10:18 AM.
>>> Either I'm misunderstanding overriding of stateset attributes or
>>> something weird is going on.
>> Yaiks, I did testing of the code in that post with 2.6. I'll retry
>> with SVN tonight, to see if the behaviour shows there as wel..
> Ok, with SVN the behaviour is the same, i.e. not all Geometries are
> using the material override (see attachement), nor is the OVERRIDE value
> saved to the output file mat.osg.
>
> Paul
>
> #include
> #include
> #include
> #include
> #include
>
> int main()
> {
>osg::ref_ptr model;
>
>model = osgDB::readNodeFile("dumptruck.osg");
>
>osg::ref_ptr mat;
>mat = new osg::Material();
>mat->setColorMode(osg::Material::AMBIENT_AND_DIFFUSE);
>mat->setDiffuse(osg::Material::FRONT_AND_BACK, osg::Vec4(0, 0.99, 0.9, 0));
>
>osg::StateSet *ss = model->getOrCreateStateSet();
>ss->setAttributeAndModes(mat.get(),
> osg::StateAttribute::ON|osg::StateAttribute::OVERRIDE);
>
>osgDB::writeNodeFile(*(model.get()), "mat.osg");
>
>osgViewer::Viewer viewer;
>
>viewer.setSceneData(model.get());
>viewer.run();
> }
>
> ___
> 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] Please test svn/trunk in prep for 2.7.9 dev release
HI Frank, It should be possible to link the dicom plugin with a static version of ITK, other plugins link to static versions of their respectively libraries. ITK itself might not be best used as a static lib though - as it does raise questions about how ITK's plugins mechanisms work. I'm no ITK expert though, so can't really dive too deep in this topic. The best help I can provide would be to have look over your errors perhaps I or someone else can spot something. W.r.t the dicom loader, I currently used DCMTK as a loader as it's far more capable a DICOM loader than ITK is, the ITK path was just written as quick hack to get something imported. ITK is actually far better suited for use for image processing rather than image loading, and in later osgVolume work I expect to be using ITK for handling tasks such as segmentation. Robert. On Fri, Jan 23, 2009 at 5:57 PM, Frank Miller wrote: > Hi Robert, > > I don't know if this qualifies as a build error but I will share it > anyway. Yesterday I built a fresh *dynamic* osg because I wanted to > play with osgVolume. I told cmake about my *static* ITK installation and > the build failed. I assumed at the time that it is impossible to link a > static library into a dynamic library. When I rebuilt osg without any > reference to ITK everything worked fine. > > Was my assumption correct or is this an error? > > By the way, I got side-tracked and never played with osgVolume. I do > look forward to working with it. > > Frank > > On Fri, Jan 23, 2009 at 04:10:34PM +, Robert Osfield wrote: >> Hi All, >> >> I would like to finish this week with a 2.7.9 dev release, could users >> do a check out of svn/trunk and let know if your build succeeds/or >> where it fails. >> >> Thanks, >> Robert. >> ___ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with ReaderWriterTGA library
Thanks, I just might do that. -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=5014#5014 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgEarth - terrain on demand
Donn, LibZip is optional -- if you leave it blank in CMake, you should be ok. It is only there to enable a ZIP-file-based cache, which is experimental anyway. Otherwise, I posted a pre-built LibZip for windows on the wiki under the build docs. Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : +1.703.652.4791 On Fri, Jan 23, 2009 at 12:28 PM, Donn Mielcarek < globalvisualizationproc...@gmail.com> wrote: > I've been trying to get it to compile under Windows. > Apparently there is no libzip currently available for > Windows (which uses zip.h, not to be confused with > ziplib, which uses zlib.h). > > > > > On Fri, Jan 23, 2009 at 12:15 PM, Robert Osfield > wrote: > >> Hi Glenn, >> >> On Fri, Jan 23, 2009 at 4:47 PM, Glenn Waldron >> wrote: >> > Thanks for the kind words. I've added it to the Community News page as >> you >> > recommended. >> >> Thanks. >> >> I've just checked out osgEarth svn/trunk and attempted to compile but >> found that the FIND_PACKAGE(LIBZIP) in osgEarth/CMakeLists.txt should >> read FIND_PACKAGE(LibZip), I presume you do most of dev under >> Windows... >> > > > > ___ > 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] Please test svn/trunk in prep for 2.7.9 dev release
Hi Robert, I don't know if this qualifies as a build error but I will share it anyway. Yesterday I built a fresh *dynamic* osg because I wanted to play with osgVolume. I told cmake about my *static* ITK installation and the build failed. I assumed at the time that it is impossible to link a static library into a dynamic library. When I rebuilt osg without any reference to ITK everything worked fine. Was my assumption correct or is this an error? By the way, I got side-tracked and never played with osgVolume. I do look forward to working with it. Frank On Fri, Jan 23, 2009 at 04:10:34PM +, Robert Osfield wrote: > Hi All, > > I would like to finish this week with a 2.7.9 dev release, could users > do a check out of svn/trunk and let know if your build succeeds/or > where it fails. > > Thanks, > Robert. > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Ideas for OSG v3.0 or how to make it younger :)
Hi folks, The community becames bigger and bigger and there are more and more projects/nodekits which offers additional features to osg. And therefor I think OSG 3.0 is the best time to refactor the whole nodekit maintaining structure. Hence here are couple of ideas, how to do so. In my opinion, nodeKits/plugins which were not lucky to be included into osg main core wouldn't survive, because the people would just forget about them. Making everyday advertisment, that this and this nodekit does provide the functionality you are looking for is also not the solution. New users are not used to read wiki pages or search in google, they do not even read ReadMes which are essential for proper work. They just download and compile the osg and want to have either an example showing how to do it or try to reinvent the wheel everytime again and again. Nodekits which are then not included in the main core (or better say: main download) are not noticed by users. What I propose is to rearrange/refactor/cleanup osg main core to basic functionality of a scene graph, so to remove everything which has nothing to do with a scene graph on its own. Then provide something like official category of nodekits, where all previuosuly filtered nodekits would be moved. Robert will became main maintainer, who is responsible for the whole code and for bringing the category maintainers together. A category maintainer is responsible for his category and maintainers of each individaul projects which are covered by his category. The individual maintainer is responsible only for its own project. This would create some kind of hierarchy of nodekits and its maintainers, which would make the further development of OpenSceneGraph more flexible, I think. All the maintainers of the nodekits should get their own svn permissions to being able to commit to the svn, however only to their own projects. Maintainers of a category would get responsible to bring all the projects into one NodeKit-Pack/Category-Pack and make sure, that the pack is compileable and compatible with current osg version. This will free up Robert, who is spending maybe his whole time to the project, and will also make the decision about new features more democratic :) What I imagine is that when you download osg you get just the basic functionality and nothing more. Then you decide to have gui functionality, hence you download the GUI-NodeKit and you get the osgGA, osgWidget, osgText and other nodekits which are still marked as official OSG GUI nodekits. All that nodekits/nodekit categories provided on the main webpage are officialy validated. Projects which are like to became officialy validated, would have to be investigated by the main maintainer (Robert) and by the submaintainer, responsible for the nodekit group where the new project like to be included in. Release of osg 3.0 will be a good point to do so, because the backward compaitibility has no to be fully supported as it was done during the 2.x development. And my personal opinion is, that this kind of project development will make it more flexible and will let evaluate the OpenSceneGraph faster, which more or less became a game engine rather than a scene graph ;) Best regards, art -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=5006#5006 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] how to do a cutting plane?
Thank you! That is very close to what I need. I just didn't know where to look. I appreciate the pointer. Cory Jason Daly wrote: Cory Riddell wrote: I've been evaluating a bunch of software and one product has cutting planes. For these, you define a plane and you can intersect it with your model and it "clips" the model. Follow this link for a better description: http://www.openhsf.org/docs_hsf/Hoops3DGS/prog_guide/02_13_geometry_cutting_planes.html How difficult would this be to set up with OSG? I'm trying to just get a sense if are all the pieces there or would it be a difficult task? Sounds like you're looking for a ClipNode. Look at the osgclip example to see how it works. --"J" ___ 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] osgEarth - terrain on demand
Hi Robert, I'm going to take a look at the Cmake issues under Linux and I'll let you know when I've figured them out. Thanks! Jason On Fri, Jan 23, 2009 at 12:15 PM, Robert Osfield wrote: > Hi Glenn, > > On Fri, Jan 23, 2009 at 4:47 PM, Glenn Waldron wrote: > > Thanks for the kind words. I've added it to the Community News page as > you > > recommended. > > Thanks. > > I've just checked out osgEarth svn/trunk and attempted to compile but > found that the FIND_PACKAGE(LIBZIP) in osgEarth/CMakeLists.txt should > read FIND_PACKAGE(LibZip), I presume you do most of dev under > Windows... > > Fixing this doesn't get me a complete build yet though, I get the > following error, but not being CMake expert I can't spot right away > how to fix the problem: > > cmake . > CMake Error at CMakeModules/ModuleInstall.cmake:38 (INSTALL): > install TARGETS given no LIBRARY DESTINATION for shared library target > "osgEarth". > Call Stack (most recent call first): > src/osgEarth/CMakeLists.txt:73 (INCLUDE) > > > -- Configuring incomplete, errors occurred! > > > Robert. > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgEarth - terrain on demand
I've been trying to get it to compile under Windows. Apparently there is no libzip currently available for Windows (which uses zip.h, not to be confused with ziplib, which uses zlib.h). On Fri, Jan 23, 2009 at 12:15 PM, Robert Osfield wrote: > Hi Glenn, > > On Fri, Jan 23, 2009 at 4:47 PM, Glenn Waldron wrote: > > Thanks for the kind words. I've added it to the Community News page as > you > > recommended. > > Thanks. > > I've just checked out osgEarth svn/trunk and attempted to compile but > found that the FIND_PACKAGE(LIBZIP) in osgEarth/CMakeLists.txt should > read FIND_PACKAGE(LibZip), I presume you do most of dev under > Windows... > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem in FluidFrictionOperator
Hi Lionel, Thanks for the test model, I've now tested but as yet don't have any conclusion, will need to dig deeper. Robert. On Fri, Jan 23, 2009 at 3:36 PM, Lionel Lagarde wrote: > Sorry ... > > osgviewer bigparticle.osg plane.osg > > Hi Robert, > > the attached file show the problem. > > With the SVN version the particles get weird speed. > > With the revised version of FluidFrictionOperator.cpp, the > problem disappear. > > > > There is also another issue with the unmodified version of > FluidFrictionOperator.cpp. > > The overall scene is blinking ... > > > ___ > 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] Please test svn/trunk in prep for 2.7.9 dev release
Paul Melis wrote:
> Paul Melis wrote:
>> Hi Robert,
>>
>> Robert Osfield wrote:
>>> I would like to finish this week with a 2.7.9 dev release, could users
>>> do a check out of svn/trunk and let know if your build succeeds/or
>>> where it fails.
>>>
>> Not really a build failure of such, but could you take a look at the
>> example I posted in the thread "Re: [osg-users] Statesets with
>> renderBin make sub-models invisible", dated 01/22/2009 10:18 AM.
>> Either I'm misunderstanding overriding of stateset attributes or
>> something weird is going on.
> Yaiks, I did testing of the code in that post with 2.6. I'll retry
> with SVN tonight, to see if the behaviour shows there as wel..
Ok, with SVN the behaviour is the same, i.e. not all Geometries are
using the material override (see attachement), nor is the OVERRIDE value
saved to the output file mat.osg.
Paul
#include
#include
#include
#include
#include
int main()
{
osg::ref_ptr model;
model = osgDB::readNodeFile("dumptruck.osg");
osg::ref_ptr mat;
mat = new osg::Material();
mat->setColorMode(osg::Material::AMBIENT_AND_DIFFUSE);
mat->setDiffuse(osg::Material::FRONT_AND_BACK, osg::Vec4(0, 0.99, 0.9, 0));
osg::StateSet *ss = model->getOrCreateStateSet();
ss->setAttributeAndModes(mat.get(),
osg::StateAttribute::ON|osg::StateAttribute::OVERRIDE);
osgDB::writeNodeFile(*(model.get()), "mat.osg");
osgViewer::Viewer viewer;
viewer.setSceneData(model.get());
viewer.run();
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgEarth - terrain on demand
Hi Glenn, On Fri, Jan 23, 2009 at 4:47 PM, Glenn Waldron wrote: > Thanks for the kind words. I've added it to the Community News page as you > recommended. Thanks. I've just checked out osgEarth svn/trunk and attempted to compile but found that the FIND_PACKAGE(LIBZIP) in osgEarth/CMakeLists.txt should read FIND_PACKAGE(LibZip), I presume you do most of dev under Windows... Fixing this doesn't get me a complete build yet though, I get the following error, but not being CMake expert I can't spot right away how to fix the problem: cmake . CMake Error at CMakeModules/ModuleInstall.cmake:38 (INSTALL): install TARGETS given no LIBRARY DESTINATION for shared library target "osgEarth". Call Stack (most recent call first): src/osgEarth/CMakeLists.txt:73 (INCLUDE) -- Configuring incomplete, errors occurred! Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgEarth - terrain on demand
Robert, Thanks for the kind words. I've added it to the Community News page as you recommended. Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : +1.703.652.4791 On Fri, Jan 23, 2009 at 10:27 AM, Robert Osfield wrote: > Hi Glenn, > > Congratulations on a great looking addition to the OSG family ;-) > > Please add notice of the osgEarth library to the community news page > listed on the OSG front page. > >http://www.openscenegraph.org/projects/osg/wiki/News/AddCommunityNews > > I'm sure opengl.org and modsim.org and game dev websites would also be > interested in the new development too. > > Cheers, > Robert. > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test svn/trunk in prep for 2.7.9 dev release
Paul Melis wrote: Hi Robert, Robert Osfield wrote: I would like to finish this week with a 2.7.9 dev release, could users do a check out of svn/trunk and let know if your build succeeds/or where it fails. Not really a build failure of such, but could you take a look at the example I posted in the thread "Re: [osg-users] Statesets with renderBin make sub-models invisible", dated 01/22/2009 10:18 AM. Either I'm misunderstanding overriding of stateset attributes or something weird is going on. Yaiks, I did testing of the code in that post with 2.6. I'll retry with SVN tonight, to see if the behaviour shows there as wel.. Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgPPU into main osg core?
Hi Art, On Fri, Jan 23, 2009 at 4:10 PM, Art Tevs wrote: > I do not see why osgPPU shadows one of the existing approaches from the main > osg core. I think there is currently no class/nodekit in the main core which > offeres the functionality of osgPPU. In my opinion, the library is completly > orthogonal to the main core and it's nodekits. I'm afraid I just don't feel osgPPU is appropriate for integration at this pint, just because it's available and has been proposed for integration doesn't mean I'm ready to pull it into the core and take responsibility for it. Moving it into the core may like easier for users of osgPPU, but it adds more work for me and I'm not convinced about the extra value it would bring for this extra work. I do see value in osgPPU, and I see areas of the core OSG that could evolve to better fit with the type of functionality that osgPPU addresses, and it's evolving the core OSG which I feel is more appropriate in this instance. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test svn/trunk in prep for 2.7.9 dev release
Hi Robert, Robert Osfield wrote: I would like to finish this week with a 2.7.9 dev release, could users do a check out of svn/trunk and let know if your build succeeds/or where it fails. Not really a build failure of such, but could you take a look at the example I posted in the thread "Re: [osg-users] Statesets with renderBin make sub-models invisible", dated 01/22/2009 10:18 AM. Either I'm misunderstanding overriding of stateset attributes or something weird is going on. Thanks, Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Please test svn/trunk in prep for 2.7.9 dev release
Hi All, I would like to finish this week with a 2.7.9 dev release, could users do a check out of svn/trunk and let know if your build succeeds/or where it fails. Thanks, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgPPU into main osg core?
Hi Robert, Robert Osfield wrote: > > When I talk about high level encapsulation I mean that it wrap > existing OSG features that would normally use a combination of > Camera's and shaders. While this might use and be compatible with > existing core features, conceptually the encapsulation take quite a > different take to that of the way one would take using core features. > Of course, but is this not a way how every NodeKit is done? It encapsulate osg's functionality to provide classes with new features. osgPPU do exactly the same. The only one class you maybe not like is the osgPPU::ShaderAttribute (note osgPPU::Shader is deprecated and will be removed soon) class, which provides just more than an osg::Program. However users are not asked to use it, they still can go with simple osg::Program, osg::Shader and osg::Uniform if they like that. There are no more additional classes which might somehow replace core osg functionality, I think. > > There are certain parts of the code, it's the concepts about how one > should put together this type of functionality, the core OSG has have > good continuity of concepts and granularity of class design. If we > have too many different approaches mixing in together lots of issues > will arise in trying to convey when one should use one approach or > another. I do not see why osgPPU shadows one of the existing approaches from the main osg core. I think there is currently no class/nodekit in the main core which offeres the functionality of osgPPU. In my opinion, the library is completly orthogonal to the main core and it's nodekits. cheers art -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=4992#4992 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] COLLADA plugin diffuse color assertion failed
Color should be 4 floats. You are using an invalid Collada file.
Here's the result of the coherency test:
> - Executing input
> - Executing coherencytest-1
> CHECK_schema Error msg=Element
> '{http://www.collada.org/2005/11/COLLADASchema}color': [facet 'minLength']
> The value has a length of '3'; this underruns the allowed minimum length of
> '4'.
>
>
> CHECK_schema Error msg=Element
> '{http://www.collada.org/2005/11/COLLADASchema}color': '0.27451 0.27451
> 0.27451' is not a valid value of the list type
> '{http://www.collada.org/2005/11/COLLADASchema}fx_color_common'.
>
>
>
> *** EXECUTION SUCCESSFUL ***
--
Roland
--
Read this topic online here:
http://osgforum.tevs.eu/viewtopic.php?p=4991#4991
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem in FluidFrictionOperator
Lionel Lagarde wrote: Hi Robert, the attached file show the problem. Hmm, did you forget to attach something? Paul With the SVN version the particles get weird speed. With the revised version of FluidFrictionOperator.cpp, the problem disappear. ___ 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] Problem in FluidFrictionOperator
HI Lionel, On Fri, Jan 23, 2009 at 3:30 PM, Lionel Lagarde wrote: > the attached file show the problem. Your file didn't make it through, could you repost, directly if it's too large for the list. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Problem in FluidFrictionOperator
Hi Robert, the attached file show the problem. With the SVN version the particles get weird speed. With the revised version of FluidFrictionOperator.cpp, the problem disappear. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgEarth - terrain on demand
Hi Glenn, Congratulations on a great looking addition to the OSG family ;-) Please add notice of the osgEarth library to the community news page listed on the OSG front page. http://www.openscenegraph.org/projects/osg/wiki/News/AddCommunityNews I'm sure opengl.org and modsim.org and game dev websites would also be interested in the new development too. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg/Export disabling MSVC "deprecated" warning
Hi JS, On Fri, Jan 23, 2009 at 2:47 PM, Jean-Sébastien Guay wrote: >> My inclination right now is to disable C4251, C4275 and C4244 and keep >> them in the include/osg/Export header, and then address the rest of >> the warnings. > > I thought the conclusion was to put the warning disable flags as > compile-time options (in CFLAGS/CXXFLAGS) instead of in osg/Export, since > then they would apply to user code too? The 'ideal' solution w.r.t warnings would be to disable no warnings on the headers and have them compile cleanly without any need for warning disable, and only disable warnings for the implementations where the warnings aren't helpful. Given the nature of these warnings I'm not sure it would be possible to fix the remaining warnings without lots of changes across many headers, so the fallback of using headers. We might be able to fix them without too many intrusive change though, so the door if we can spot ways of fixing the warnings without modifiying hundreds of files. I've now fixed the two of the sets of warnings I mentioned in my previous email, so leaves just the float/double casting, and dll linkgage related warnings: #if defined(_MSC_VER) && defined(OSG_DISABLE_MSVC_WARNINGS) #pragma warning( disable : 4244 ) #pragma warning( disable : 4251 ) #pragma warning( disable : 4275 ) #endif >> Thoughts, suggestions? > > About C4244, I have no preference, if you don't want to add casts then go > ahead and disable the warning. At this time I think doing a purge of casts would introduce too many opportunities for bugs to be introduced this close to a release. If some one can fix these warnings and show that it's only half dozen or so files that are changed then I'm open to merging these changes. I won't embark on such a purge myself though as I have plenty of other work do, and can't even reproduce the warnings myself so wouldn't be able to check to see if things are fixed... > About C4251 and C4275, couldn't this indicate that users would have problems > when deriving classes from those classes? I think they essentially mean that > there are missing OSG_EXPORT directives which are not necessary for direct > OSG usage, but which could matter if the user were to derive classes. But I > could be wrong. > > So I wonder if just adding a few extra OSG_EXPORT directives would remove > these, especially if the warning comes up whenever ref_ptr is included... Or > perhaps it could be disabled only for the ref_ptr header using push at the > top and pop at the bottom (because we don't expect anyone to want to derive > classes from ref_ptr, and the missing OSG_EXPORT never caused a problem > before)? > > #pragma warning( push ) > #pragma warning( disable : 4251 ) > #pragma warning( disable : 4275 ) > > // the rest of the ref_ptr header > > #pragma warning( pop ) > > But other cases could be fixed by adding OSG_EXPORT where needed... You (and others) are welcome to have a bash at trying to fix these warnings, but it comes with the same qualification with the casting task - right now we can't afford to change lots of OSG headers as each change does introduce another chance for a typo bug to be accidentally introduced. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg/Export disabling MSVC "deprecated" warning
Hi Robert, My inclination right now is to disable C4251, C4275 and C4244 and keep them in the include/osg/Export header, and then address the rest of the warnings. I thought the conclusion was to put the warning disable flags as compile-time options (in CFLAGS/CXXFLAGS) instead of in osg/Export, since then they would apply to user code too? Thoughts, suggestions? About C4244, I have no preference, if you don't want to add casts then go ahead and disable the warning. About C4251 and C4275, couldn't this indicate that users would have problems when deriving classes from those classes? I think they essentially mean that there are missing OSG_EXPORT directives which are not necessary for direct OSG usage, but which could matter if the user were to derive classes. But I could be wrong. So I wonder if just adding a few extra OSG_EXPORT directives would remove these, especially if the warning comes up whenever ref_ptr is included... Or perhaps it could be disabled only for the ref_ptr header using push at the top and pop at the bottom (because we don't expect anyone to want to derive classes from ref_ptr, and the missing OSG_EXPORT never caused a problem before)? #pragma warning( push ) #pragma warning( disable : 4251 ) #pragma warning( disable : 4275 ) // the rest of the ref_ptr header #pragma warning( pop ) But other cases could be fixed by adding OSG_EXPORT where needed... J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg/Export disabling MSVC "deprecated" warning
Here's a bit of analysis of the include/osg/Export disabled warnings: -- C4244 #pragma warning( disable : 4244 ) > grep C4244 * | wc 91105 1385287 15479278 Example of warning: C:\public\OpenSceneGraph\include\osg/Plane(178) : warning C4244: 'return' : conversion from 'const osg::Plane::value_type' to 'float', possible loss ofdata -- C4251 #pragma warning( disable : 4251 ) > grep C4251 * | wc 85799 1715980 18686366 Example of warning: C:\public\OpenSceneGraph\include\osg/Object(164) : warning C4251: 'osg::Object::_userData' : class 'osg::ref_ptr' needs to have dll-interface to be used by clients of class 'osg::Object' -- C4267 #pragma warning( disable : 4267 ) > grep C4267 * | wc 0 0 0 No examples of this warning!!! :-) -- C4275 #pragma warning( disable : 4275 ) grep C4275 * | wc 4364 65460 869453 Example of warning: C:\public\OpenSceneGraph\include\osg/GraphicsThread(122) : warning C4275: non dll-interface struct 'osg::State::DynamicObjectRenderingCompletedCallback' used as base for dll-interface class 'osg::EndOfDynamicDrawBlock' -- C4290 #pragma warning( disable : 4290 ) grep C4290 * | wc 0 0 0 No examples of this warning :-) -- C4786 #pragma warning( disable : 4786 ) > grep C4786 * | wc 0 0 0 No examples of this warning :-) -- C4305 #pragma warning( disable : 4305 ) >grep C4305 * | wc 18 1992524 Example of warning: C:\public\OpenSceneGraph\src\osgPlugins\bsp\VBSPGeometry.cpp(557) : warning C4305: 'argument' : truncation from 'double' to 'osg::Vec3f::value_type' -- C4996 #pragma warning( disable : 4996 ) > grep C4996 * | wc 2 52 421 Example of warning: C:\public\OpenSceneGraph\src\osgPlugins\shp\ESRIShape.cpp(42) : warning C4996: 'read': The POSIX name for this item is deprecated. Instead, use the ISO C++ conformant name: _read. See online help for details. -- >From this right away we know we can remove C4786, C4290 and C4267 from being disabled by include/osg/Export without introducing any new warnings to members of the community, so I've gone ahead and removed these and check it in - although it might enable this warnings in user code though but this is a good thing :-) For the next category of warnings I'd say that the low occurancies of C4996 and C4305 make them ones that we should be able to clean up without much effort. I'd do a review right now of each of these with a view to fixing them and then removing the disable of these from include/osg/Export. The we have dll related warnings C4251, C4275. Given that we have lots of people using the OSG under VS without any problems with linking and running there applications it would seem that these warning aren't particularly useful. I have to defer to VS experts though, is there anything of use for use behind these warnings? What would the required changes be to fix this type of warning? Finally we have a slew of warnings about possible data truncation C4244, such as double to float casts. Fixing these will require addition of lots of explictl static_cast etc. Going through the OSG to fix these warnings will require quite a bit of work, and as it's adding extra keywords to the source code it does add to the possibility of typo's introducing new bugs. There is chance that some of these warnings may be of relevance to deficiency in the API or perhaps even a bug, but in the grand scheme of things this is very unlikely uncover any significant problems that need addressing - so the risk of introducing new errors vs chance of fixing existing ones is not a great tradeoff to risk so I'm very hesitant to sanction a great warning purge in this direction. My inclination right now is to disable C4251, C4275 and C4244 and keep them in the include/osg/Export header, and then address the rest of the warnings. Another item to consider is that we are very close to a feature freeze for OSG-2.8, so large scale changes to the OSG, even if each one is quite minor is not appropriate. Thoughts, suggestions? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg/Export disabling MSVC "deprecated" warning
Hi Mattias, Thanks for the warnings dump. Boy... it was big... I've just done a review and it looks like the vast majority of the warnings are C4244 & C4251. Using grep and wc I get: > grep "warning C" * | wc 181529 3169354 35072133 > grep "warning C4251" * | wc 85799 1715980 18686366 > grep "warning C4244" * | wc 91105 1385287 15479278 The first number in each line is the number of times that warning appears. Clearly there are many many repeated warnings from the same headers being introduced, so we don't really have 181 thousand warnings... Given the overwhelming number of warnings, almost all of which don't actually relate to possible bugs I'd suggest we disable the warnings of least value, the above two have to be two good candidates. Then we might be able to spot some useful warnings amongst the huge forest of unhelpful warnings. I'll do abit more analysis of the warnings file, then post a mapping of the disabled warnings from include/osg/Export and how often they occur. Robert. On Fri, Jan 23, 2009 at 12:45 PM, Mattias Helsing wrote: > Hi Robert, > > here's > 500k lines of VS output from building osg head from this > morning using nmake and the msvc8sp1 compiler. AGGRESIVE_WARNINGS=ON > DISABLE_MSVC_WARNINGS=OFF. > Get nediting ;-) > > Mattias > > On 1/23/09, Mattias Helsing wrote: >> Hi Robert, >> >> On 1/23/09, Robert Osfield wrote: >>> The last discussion on warnings ended with me awaiting on feedback of >>> how things stand with warnings under VS with/without the >>> OSG_DISABLE_MSVC_WARNINGS. I can only guess that as everyone is busy >>> they have other things to chase up which are a higher priorty. Feel >>> free to dive in and do this testing and send in the warning output >>> that you get when you switch off the warning disable so that we can >>> review what changes would be best to implement. >> >> I have been meaning to ask how you were doing with the review of my VS >> output but saw from my svn updates that you were busy with osgVolume >> work and of course the submissions. I was sure that I sent you the >> first half > 200k lines of warnings but can't find it and now it's >> lost forever. Starting a fresh build now and getting back to you. >> >> Mattias >> >>> >>> Cheers, >>> Robert. >>> >>> On Wed, Jan 21, 2009 at 11:23 PM, Erik Johnson >>> wrote: Hi, Through some debugging, I discovered that the osg/Export header file is disabling the C4996 "method is deprecated" compiler warning message*. That's all well and good when compiling OSG, but it is affecting *any* project that happens to include that file (directly or indirectly). In my case, I have a class method marked as deprecated but since the class derives from an OSG class, the osg/Export header gets pulled in a squelches my compiler warning. Would it be agreeable to remove the disabling of the MSVC 4996 warning in the osg/Export file? It doesn't appear that OSG itself is generating any deprecated compile warnings. *The MSVC C4996 compile warning is generated when a method declaration is prefixed with " __declspec(deprecated)" and is useful to notify the user that a deprecated method is being used. Thanks, Erik Johnson ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>> ___ >>> osg-users mailing list >>> osg-users@lists.openscenegraph.org >>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>> >> > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg/Export disabling MSVC "deprecated" warning
Hi Robert, I just posted 2.6mb of zipped VS warnings. It's awating moderator approval because of it's size. Should I send them to you off list instead? Mattias On 1/23/09, Mattias Helsing wrote: > Hi Robert, > > On 1/23/09, Robert Osfield wrote: >> The last discussion on warnings ended with me awaiting on feedback of >> how things stand with warnings under VS with/without the >> OSG_DISABLE_MSVC_WARNINGS. I can only guess that as everyone is busy >> they have other things to chase up which are a higher priorty. Feel >> free to dive in and do this testing and send in the warning output >> that you get when you switch off the warning disable so that we can >> review what changes would be best to implement. > > I have been meaning to ask how you were doing with the review of my VS > output but saw from my svn updates that you were busy with osgVolume > work and of course the submissions. I was sure that I sent you the > first half > 200k lines of warnings but can't find it and now it's > lost forever. Starting a fresh build now and getting back to you. > > Mattias > >> >> Cheers, >> Robert. >> >> On Wed, Jan 21, 2009 at 11:23 PM, Erik Johnson >> wrote: >>> Hi, >>> >>> Through some debugging, I discovered that the osg/Export header file is >>> disabling the C4996 "method is deprecated" compiler warning message*. >>> That's all well and good when compiling OSG, but it is affecting *any* >>> project that happens to include that file (directly or indirectly). In >>> my >>> case, I have a class method marked as deprecated but since the class >>> derives >>> from an OSG class, the osg/Export header gets pulled in a squelches my >>> compiler warning. >>> >>> Would it be agreeable to remove the disabling of the MSVC 4996 warning >>> in >>> the osg/Export file? It doesn't appear that OSG itself is generating >>> any >>> deprecated compile warnings. >>> >>> *The MSVC C4996 compile warning is generated when a method declaration >>> is >>> prefixed with " __declspec(deprecated)" and is useful to notify the user >>> that a deprecated method is being used. >>> >>> Thanks, >>> Erik Johnson >>> >>> >>> >>> ___ >>> osg-users mailing list >>> osg-users@lists.openscenegraph.org >>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>> >>> >> ___ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgPPU into main osg core?
HI Art, On Fri, Jan 23, 2009 at 11:46 AM, Art Tevs wrote: > Ok, I understand what you means. However I do not understand what you means > with high level encapsulation of camera class. There exists an additional > shader class derived from osg::Program, which offers more functionality than > a usual osg::Program. Current osgPPU doesn't force you to use it, user can > still use osg only shader classes. The ShaderAttribute class is just provided > as a wrapper over the osg classes with more 'daily use' methods. As to the > Camera: in osgPPU there is no high level camera classes or so. The only one > class which seems to be same as in osg is the ShaderAttribute, which has not > to be used. When I talk about high level encapsulation I mean that it wrap existing OSG features that would normally use a combination of Camera's and shaders. While this might use and be compatible with existing core features, conceptually the encapsulation take quite a different take to that of the way one would take using core features. >> After my review I came away with the feeling that osgPPU points some >> deficiences of the core OSG's manage of RTT support in terms of how to >> address certain types of features, and rather than an extra library >> that provides a different way of tackling RTT what we really should >> have is a core support that can better tackle some of the features >> that aren't ideal right now. >> > > Sorry, but I do not get the point what do you mean here. Could you point me > on certain parts of the code, which has to be investigate further to be > included into main core? There are certain parts of the code, it's the concepts about how one should put together this type of functionality, the core OSG has have good continuity of concepts and granularity of class design. If we have too many different approaches mixing in together lots of issues will arise in trying to convey when one should use one approach or another. I feel that the approach you've taken with osgPPU has it's merits, and in fact points to need for the core OSG to handle this type of usage as integral to its class design, something that it doesn't do well right now. This suggests to be that the core OSG code do with a refactor w.r.t RTT and shaders, such a refactor will be required anyway as part of wider changes for support of OpenGL 3.0 etc. As to what these changes need to be I really can't answer without spending several months review the ongoing evolution of hardware, graphics API's, and needs of scene graph users. Right now I'm focused on getting a stable OSG 2.8 out the door, and am very much not in the position to dive in to such speculative work. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgPPU into main osg core?
Hi Robert, Ok, I understand what you means. However I do not understand what you means with high level encapsulation of camera class. There exists an additional shader class derived from osg::Program, which offers more functionality than a usual osg::Program. Current osgPPU doesn't force you to use it, user can still use osg only shader classes. The ShaderAttribute class is just provided as a wrapper over the osg classes with more 'daily use' methods. As to the Camera: in osgPPU there is no high level camera classes or so. The only one class which seems to be same as in osg is the ShaderAttribute, which has not to be used. > > After my review I came away with the feeling that osgPPU points some > deficiences of the core OSG's manage of RTT support in terms of how to > address certain types of features, and rather than an extra library > that provides a different way of tackling RTT what we really should > have is a core support that can better tackle some of the features > that aren't ideal right now. > Sorry, but I do not get the point what do you mean here. Could you point me on certain parts of the code, which has to be investigate further to be included into main core? cheers -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=4973#4973 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg/Export disabling MSVC "deprecated" warning
Hi Robert, On 1/23/09, Robert Osfield wrote: > The last discussion on warnings ended with me awaiting on feedback of > how things stand with warnings under VS with/without the > OSG_DISABLE_MSVC_WARNINGS. I can only guess that as everyone is busy > they have other things to chase up which are a higher priorty. Feel > free to dive in and do this testing and send in the warning output > that you get when you switch off the warning disable so that we can > review what changes would be best to implement. I have been meaning to ask how you were doing with the review of my VS output but saw from my svn updates that you were busy with osgVolume work and of course the submissions. I was sure that I sent you the first half > 200k lines of warnings but can't find it and now it's lost forever. Starting a fresh build now and getting back to you. Mattias > > Cheers, > Robert. > > On Wed, Jan 21, 2009 at 11:23 PM, Erik Johnson > wrote: >> Hi, >> >> Through some debugging, I discovered that the osg/Export header file is >> disabling the C4996 "method is deprecated" compiler warning message*. >> That's all well and good when compiling OSG, but it is affecting *any* >> project that happens to include that file (directly or indirectly). In my >> case, I have a class method marked as deprecated but since the class >> derives >> from an OSG class, the osg/Export header gets pulled in a squelches my >> compiler warning. >> >> Would it be agreeable to remove the disabling of the MSVC 4996 warning in >> the osg/Export file? It doesn't appear that OSG itself is generating any >> deprecated compile warnings. >> >> *The MSVC C4996 compile warning is generated when a method declaration is >> prefixed with " __declspec(deprecated)" and is useful to notify the user >> that a deprecated method is being used. >> >> Thanks, >> Erik Johnson >> >> >> >> ___ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> >> > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Render to Texture and per vertex colors
Hi all,
I want to do an RTT of the current camera to do some PostProcesses on it
(using shaders). When the geometry is textured, everything works ok, but
when i use non-textured objects, the objects renders in black. I tryed
the code in osgprerender example in my app and it does the same thing,
but the osgprerender example works correctly (with the cessna model for
ex.). I Attach an image of the result.
Here is the code i use:
/// Texture for RTT ///
{
sourceSceneTexture = new osg::Texture2D;
sourceSceneTexture->setTextureSize(textureWidth, textureHeight);
sourceSceneTexture->setInternalFormat(GL_RGBA);
sourceSceneTexture->setFilter(osg::Texture2D::MIN_FILTER,osg::Texture2D::LINEAR);
sourceSceneTexture->setFilter(osg::Texture2D::MAG_FILTER,osg::Texture2D::LINEAR);
}
// Geode without ilumination for attaching the RTT
rttPlaneGroup = new osg::Group;
osg::ref_ptr geo = new osg::Geode;
geo->setName("PlanoGeode");
osg::StateSet* ss = geo->getOrCreateStateSet();
ss->setMode(GL_LIGHTING, osg::StateAttribute::OFF);
finalPlaneGeometry = new osg::Geometry();
finalPlaneGeometry->setName("PlanoGeometry");
geo->addDrawable(finalPlaneGeometry.get());
osg::Vec3Array* vertex = new osg::Vec3Array;
vertex->push_back( osg::Vec3 (0,0,0) ); // down left
vertex->push_back( osg::Vec3 (1,0,0) ); // down right
vertex->push_back( osg::Vec3 (1,1,0) ); // up right
vertex->push_back( osg::Vec3 (0,1,0) ); // up left
finalPlaneGeometry->setVertexArray(vertex);
GLuint vertplane[4] = {3,2,1,0};
finalPlaneGeometry->addPrimitiveSet(new
osg::DrawElementsUInt(osg::PrimitiveSet::QUADS, 4, vertplane));
osg::Vec4Array* colors = new osg::Vec4Array;
colors->push_back(osg::Vec4(1.0, 1.0, 1.0, 1.0));
colors->push_back(osg::Vec4(1.0, 1.0, 1.0, 1.0));
colors->push_back(osg::Vec4(1.0, 1.0, 1.0, 1.0));
colors->push_back(osg::Vec4(1.0, 1.0, 1.0, 1.0));
finalPlaneGeometry->setColorArray(colors);
finalPlaneGeometry->setColorBinding(osg::Geometry::BIND_PER_VERTEX);
osg::Vec2Array* tcoords = new osg::Vec2Array(4);
(*tcoords)[0].set(0.0f, 0.0f);
(*tcoords)[1].set(1.0f, 0.0f);
(*tcoords)[2].set(1.0f, 1.0f);
(*tcoords)[3].set(0.0f, 1.0f);
finalPlaneGeometry->setTexCoordArray(0, tcoords);
geo->addDrawable(finalPlaneGeometry);
rttPlaneGroup->addChild(geo.get());
/FBO -
Scene
// then create the camera node to do the render to texture
{
camShot = new osg::Camera;
camShot->setName("CamShot");
camShot->setClearColor(osg::Vec4(0.7,0.1,0.3,1));
camShot->setClearMask(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
camShot->setProjectionMatrix(osg::Matrix::identity());
camShot->setViewMatrix(osg::Matrix::identity());
camShot->setReferenceFrame(osg::Transform::RELATIVE_RF);
camShot->setViewport(0, 0, textureWidth, textureHeight);
camShot->setRenderOrder(osg::Camera::PRE_RENDER);
camShot->setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT);
camShot->attach(osg::Camera::COLOR_BUFFER, sourceSceneTexture);
camShot->addChild(root);
rttPlaneGroup->addChild(camShot.get());
}
osg::ref_ptr camPlano = new osg::Camera;
camPlano->setReferenceFrame(osg::Transform::ABSOLUTE_RF);
camPlano->setProjectionMatrixAsOrtho2D(0, 1, 0, 1);
camPlano->setViewMatrix(osg::Matrix::identity());
camPlano->setName("CamPlano");
camPlano->setClearColor(osg::Vec4(0.0,0.0,0.0,1.0));
camPlano->addChild(geo.get());
rttPlaneGroup->addChild(camPlano.get());
osg::StateSet* stateset = new osg::StateSet;
stateset->setTextureAttributeAndModes(0, sourceSceneTexture
,osg::StateAttribute::ON);
rttPlaneGroup->setStateSet(stateset);
where root is the original scene and rttPlaneGroup the final render group.
Thanks in advance!!
J.
<>___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New SVN Broke osgAnimation?
Hi Ryan, In order to help you i need to know those elements: - Are you using the trunk ? - Can you send me your file (osg and blender file) ? Then i will be able to reproduce the problem Cheers, Cedric Ryan Morris wrote: Thanks for the updates! I downloaded the new exporter and it works in blender but when i run it against osganimationviewer it seg faults. my brain hurts. lol thanks in advance. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- +33 (0) 6 63 20 03 56 Cedric Pinson mailto:morni...@plopbyte.net http://www.plopbyte.net ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG in an existing OpenGL context
Hi Uli,
Integration of the OSG with an existing OpenGL context is a bit
awkward virtue of the OSG doing lazy state updating - something it
does for performance reasons.
There state has to be protected in two ways - first up you need to
protect your own OpenGL code from be affected by OSG state - the
glPushAttrib()/glPopAttrib() should be used for this, and then ideally
the same down you you own OpenGL code, then the OSG itself should also
be told that the state has been reset, so do a
sceneview->getState()->reset() previous to calling sceneview->draw().
Perhaps another solution would be to render the OSG scene to a a
pbuffer and then use the pbuffer as a texture source for the original
graphics context. This would isolate the OSG and your own OpenGL
context completely from each other.
Robert.
On Fri, Jan 23, 2009 at 9:56 AM, Ulrich von Zadow
wrote:
> Hi,
>
> we are using OSG here to render into an OpenGL context created outside of
> OSG. The application renders some stuff into the context, then OSG renders
> its scene graph, and then the application renders some more things on top of
> what OSG has rendered. This raises some state management questions.
>
> Here is some pseudocode that shows what we're doing:
>
> void render()
> {
>renderApplicationScene();
>
>pushGLState();
>hackToSetStateToWhatOSGExpects();
>
>m_pSceneView->update();
>m_pSceneView->cull();
>m_pSceneView->draw();
>
>popGLState();
>
>renderMoreApplicationStuff();
> }
>
> This works, but the line that sais 'hackToSetStateToWhatOSGExpects()'
> bothers me ;-). Is there a way to tell OSG to set the OpenGL state in a
> non-lazy fashion once?
>
> Some background: This is a plugin for the 2d engine libavg that places an
> OSG scene graph inside of the 2d scene graph that libavg uses. libavg itself
> has no dependency on OSG and it's rendering state should be completely
> independent of the OSG state.
>
> Any ideas?
>
> Thanks,
>
> Uli
>
> --
> Ulrich von Zadow
> Software Engineer (Dipl. Inf.)
> Exhibit Development
>
> Tel +49 (0)30 / 2000 577 12
> Fax +49 (0)30 / 2000 577 20
> Skype: uzadow
>
> Archimedes Solutions GmbH
> SaarbrüŸcker Str. 24 10405 Berlin
>
> www.archimedes-solutions.com
>
> GeschŠftsfŸührung:
> A. Valder | D. Feser | W. Rien | J. Schmidtsiefen | S. Spenling
>
> Amtsgericht: Berlin Charlottenburg
> HR Nr.: 107563 B
> UST-ID Nr.: DE-253.771.793
>
>
>
>
>
> ___
> 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] Need Help
HI Amit, >From OSG-2.0 onwards we officially dropped support for Visual Studio 6. This compiler is terribly broken w.r.t C++ and was becoming very difficult to maintain support for even before 2.0 came out two years ago. MS provide free versions dev tools now so it should be possible grab these in place of VS 6.0. Robert. On Fri, Jan 23, 2009 at 8:18 AM, Amit Kalhapure wrote: > Hello all, > > I have downloaded osg 2.40 for windows but have some problem in compiling. > While executing an example file osganimate.cpp in Visual Studio 6, i am > getting following errors . > > c:\program files\openscenegraph\include\osg\operationthread(35) : error > C2437: 'Referenced' : already initialized > c:\program files\openscenegraph\include\osgviewer\graphicswindow(45) : error > C2143: syntax error : missing ',' before '*' > c:\program files\openscenegraph\include\osgviewer\graphicswindow(45) : error > C2059: syntax error : '*' > c:\program files\openscenegraph\include\osgviewer\graphicswindow(156) : > error C2061: syntax error : identifier 'GraphicsContext' > c:\program files\openscenegraph\include\osgviewer\graphicswindow(211) : > error C2143: syntax error : missing ',' before '*' > c:\program files\openscenegraph\include\osgviewer\graphicswindow(211) : > error C2059: syntax error : '*' > Error executing cl.exe. > > I don't know how to fix these bugs. I tried alot but all wasted.. > Can anyone please help me in removing these errors > > Thank you... > > > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSG in an existing OpenGL context
Hi,
we are using OSG here to render into an OpenGL context created outside
of OSG. The application renders some stuff into the context, then OSG
renders its scene graph, and then the application renders some more
things on top of what OSG has rendered. This raises some state
management questions.
Here is some pseudocode that shows what we're doing:
void render()
{
renderApplicationScene();
pushGLState();
hackToSetStateToWhatOSGExpects();
m_pSceneView->update();
m_pSceneView->cull();
m_pSceneView->draw();
popGLState();
renderMoreApplicationStuff();
}
This works, but the line that sais 'hackToSetStateToWhatOSGExpects()'
bothers me ;-). Is there a way to tell OSG to set the OpenGL state in
a non-lazy fashion once?
Some background: This is a plugin for the 2d engine libavg that places
an OSG scene graph inside of the 2d scene graph that libavg uses.
libavg itself has no dependency on OSG and it's rendering state should
be completely independent of the OSG state.
Any ideas?
Thanks,
Uli
--
Ulrich von Zadow
Software Engineer (Dipl. Inf.)
Exhibit Development
Tel +49 (0)30 / 2000 577 12
Fax +49 (0)30 / 2000 577 20
Skype: uzadow
Archimedes Solutions GmbH
Saarbrücker Str. 24 10405 Berlin
www.archimedes-solutions.com
Geschftsführung:
A. Valder | D. Feser | W. Rien | J. Schmidtsiefen | S. Spenling
Amtsgericht: Berlin Charlottenburg
HR Nr.: 107563 B
UST-ID Nr.: DE-253.771.793
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgPPU into main osg core?
Hi Art + Roland, Apologies with not replying. I needed to do a proper code review of osgPPU before I could answer any question on suitability on merge, the timing of the email was when I was particularly rushed off my feet so I couldn't just dive in right away and do a review. At the end of last year I did pull down osgPPU and do a quick review and while I can't claim to under the class design fully I could see a difference between how the core OSG managers shaders and Cameras and how PPU manages them, with PPU provide high level encapsulation of these features. I understand the motivation of doing this higher level encapsulation, but it would raise questions to engineers considering how to implement a feature in their apps - which route to take use PPU or a Camera and standard OSG shaders in a scene graph. Given that there isn't a seamless gradient between the two approaches I can see lots of support coming in because of this. After my review I came away with the feeling that osgPPU points some deficiences of the core OSG's manage of RTT support in terms of how to address certain types of features, and rather than an extra library that provides a different way of tackling RTT what we really should have is a core support that can better tackle some of the features that aren't ideal right now. Such a refactor of the core will take some time, but is needed, and might be appropriate to tackle once we start looking at how to make it possible to have OpenGL 3.0, OpenGL ES 1.x, 2.x and maintain OpenGL 1.x + 2.x support. Such sweeping changes are really an OSG 3.x era feature development. Hope this helps, Robert. On Thu, Jan 22, 2009 at 12:33 PM, Art Tevs wrote: > Hi Roland, > > yes the mail wasn't answered, hence I didn't make any pressure on that. My > current release strategy is to release one osgPPU version for each osg stable > version. Hence as soon as 2.8 comes out, I will release osgPPU v0.4, which > will only be compatible with osg 2.8 > > However, of course, if osgPPU will be moved into main core, I would be also > happy with that. > > Best regards, > art > > -- > Read this topic online here: > http://osgforum.tevs.eu/viewtopic.php?p=4901#4901 > > > > > > ___ > 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] moving a vehicle at constant velocity
Hi Alfonso, Is it possible to disable the second core? It'd be interesting to see if this affects the quality of the results from the timer. Also are you running your app with vsync enabled? Robert. On Thu, Jan 22, 2009 at 9:22 AM, Alfonso Callejo Goena wrote: > I'm using a Core 2 Duo 1.8 GHz 3 GB and a GeForce 8600 512 MB. > I have seen that some jumps come when the time between callbacks is between > the average 0.016 s and 0.040 s, and others with a delta time higher than > 0.040 s. I can understand the latter jumps, but not the former... > I will try what Jim suggested about computing an average time and > translation between frames, but I don't think this will help because > regardless the delta time between frames, I am eventually multiplying the > velocity by the current time. > Of course if the time returned by the timer is not consistent, the > translation is not computed correctly... Is this possible? > > Thanks, > Alfonso > ___ > 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] osg/Export disabling MSVC "deprecated" warning
Hi Erik, Over the last four weeks there has been lots of discussion about warnings including the VS pragrma disables in osg/Export. There is already support in the CMake build system to switching off these VS disables - see the OSG_DISABLE_MSVC_WARNINGS variable when you run CMakeSetup, so you could try this. If you track down the discussions on osg-users you'll see that I favour moving the pragma's out of the headers completely and work to get the headers compiling cleanly where possible. VS does produce some rather misleading and unhelpful warnings though that are generated in the implementation where the code is perfectly correctly, so disabling these specific warnings is still appropriate and best done by using compiler options rather than pragma. Again there is some support for this in the CMake build system. The last discussion on warnings ended with me awaiting on feedback of how things stand with warnings under VS with/without the OSG_DISABLE_MSVC_WARNINGS. I can only guess that as everyone is busy they have other things to chase up which are a higher priorty. Feel free to dive in and do this testing and send in the warning output that you get when you switch off the warning disable so that we can review what changes would be best to implement. Cheers, Robert. On Wed, Jan 21, 2009 at 11:23 PM, Erik Johnson wrote: > Hi, > > Through some debugging, I discovered that the osg/Export header file is > disabling the C4996 "method is deprecated" compiler warning message*. > That's all well and good when compiling OSG, but it is affecting *any* > project that happens to include that file (directly or indirectly). In my > case, I have a class method marked as deprecated but since the class derives > from an OSG class, the osg/Export header gets pulled in a squelches my > compiler warning. > > Would it be agreeable to remove the disabling of the MSVC 4996 warning in > the osg/Export file? It doesn't appear that OSG itself is generating any > deprecated compile warnings. > > *The MSVC C4996 compile warning is generated when a method declaration is > prefixed with " __declspec(deprecated)" and is useful to notify the user > that a deprecated method is being used. > > Thanks, > Erik Johnson > > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] COLLADA plugin diffuse color assertion failed
Hi osg-users,
I found an assertion that fails when trying to convert collada files with
diffuse color in daearray.h :
/**
* Gets the object at a specific index in the @c daeArray.
* @param index Index of the object to get, asserts if the index is out
of bounds.
* @return Returns the object at @c index.
*/
T& operator[](size_t index) {
assert(index < _count);
return ((T*)_data)[index]; }
it's due to the daerMaterial.cpp in latest osg svn version :
domFloat4 &f4 = cot->getColor()->getValue();
mat->setDiffuse( osg::Material::FRONT_AND_BACK, osg::Vec4(
f4[0], f4[1], f4[2], f4[3] ) );
retVal = true;
If you want to reproduce just try to convert a dae file with a diffuse color
like that :
*0.27451 0.27451 0.27451*
Unfortunately I cannot send you my collada file because of my company
restrictions...
I use the Collada DOM 2.1.1
Kind regards,
--
Alexandre AMALRIC Ingénieur R&D
===
PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille
http://www.pixxim.fr
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Bug : LightSpacePerspectiveShadowMapDB and cow.ive
Roger,
You are probably right that one should overwrite ViewData if he/she wants to
add Shadow computation specific uniforms (especially if they are supposed to be
updated in cull traversal). Thats something I have neglected because I had no
such uniforms in my code. It could be a good idea to create simpler mechanism
to add user uniforms along with their shaders. Maybe we could add
_viewDataCommonStateSet memeber to osgShadow::StandardShadowMap. This stateset
would be a placeholder for states and uniforms which would be passed to all
associated ViewDatas in ViewData::init.
Before such mechanism is added, you can, as J-S suggests, add your uniforms in
any Node/Drawable StateSet that lies on shadow render/apply cull traversal path.
Cheers,
Wojtek
- Original Message -
From: Roger James
To: OpenSceneGraph Users
Sent: Friday, January 23, 2009 1:49 AM
Subject: Re: [osg-users] Bug : LightSpacePerspectiveShadowMapDB and cow.ive
Wojciech Lewandowski wrote:
Guys,
Sorry if I offend anyone but I thought this should be obvious. Looks like
only J-S got it ;-) So I now shout to make it clear:
If you don't like Vertex shader I use you can easily turn it off and switch
to Fragment shader only version. You can easily adopt approach where you have
only one Fragment shader as older osgShadow::ShadowMap did. I have added Vertex
Shader only for one reason: to make sure ambient color is not wiped.
But if you want fixed vertex pipeline - simply call:
lispmObject->setMainVertexShader( NULL );
lispmObject->setShadowVertexShader( NULL );
and voila you got rid of VertexShaders.
Of course you will also have to substitute Fragment shaders with yours,
because my Fragment shaders expect that ambient term colorAmbientEmissive would
be passed from VertexShaders you turned off.
But further replacing fragmentShaders with something similar to
osgShadow::ShadowMap shaders is really straight forward. Just set
setMainFragmentShader with your Shader. And call setShadowFragmentShader with
NULL argument and then you will land with configuration similar to
osgShadow::ShadowMap. Which means you will lose ambient ;-).
Roger, You dont need to override ViewData if you only want to replace
shaders. Simply change the shaders in your DerivedShadowMap constructor. I
thought you want to do something more complicated when you presented me your
class.
Wojtek
PS. Actually there are a ways to compute ambient component in fragment
shader if one is desperate, but it would require other sacirfices. I wrote a
post on this topic few weeks ago.
- Original Message -
From: Roger James
To: OpenSceneGraph Users
Sent: Thursday, January 22, 2009 6:27 PM
Subject: Re: [osg-users] Bug : LightSpacePerspectiveShadowMapDB and
cow.ive
Alexandre Amalric wrote:
Hi osg-users,
has anyone tried to launch osgShadow example with --lispsm and cow.ive
model, apparently LightSpacePerspectiveShadowMapDB do not handle multi-textured
model.
Is there any specific configuration to make it work ?
I'm using osg svn.
Kind regards,
--
Alexandre AMALRIC Ingénieur R&D
Alexandre,
It is not a bug, and you cannot configure round it. The fragment shaders
in osgShadow::StandardShadowMap which are used by all the lispsm variants do
not support multi-texturing or the use of texgens. The only way round it is to
write your own shadow technique which derives from lispsm and overrides the
shaders with ones that do what you want. Here is a very useful code snippet
provided by Wojtek that shows how it is done.
class CComplexShadowTechnique : public
osgShadow::LightSpacePerspectiveShadowMapVB
{
public:
/** Convenient typedef used in definition of ViewData struct and
methods */
typedef CComplexShadowTechnique ThisClass;
/** Convenient typedef used in definition of ViewData struct and
methods */
typedef osgShadow::LightSpacePerspectiveShadowMapVB BaseClass;
CComplexShadowTechnique()
{
// Override shaders here
}
struct ViewData: public BaseClass::ViewData
{
virtual void init( ThisClass * st, osgUtil::CullVisitor * cv )
{
BaseClass::ViewData::init( st, cv );
// Add additional uniforms here
}
};
// This macro is required if you override ViewData and ViewData::init
// It generates virtual stub function in trhe Base class which
// calls associated ViewData::init.
// Probably this was the reason your ViewData::init was not called.
// Its just a case where virtualization does not help because I
actually
// want to virtuali
[osg-users] Need Help
Hello all, I have downloaded osg 2.40 for windows but have some problem in compiling. While executing an example file osganimate.cpp in Visual Studio 6, i am getting following errors . c:\program files\openscenegraph\include\osg\operationthread(35) : error C2437: 'Referenced' : already initialized c:\program files\openscenegraph\include\osgviewer\graphicswindow(45) : error C2143: syntax error : missing ',' before '*' c:\program files\openscenegraph\include\osgviewer\graphicswindow(45) : error C2059: syntax error : '*' c:\program files\openscenegraph\include\osgviewer\graphicswindow(156) : error C2061: syntax error : identifier 'GraphicsContext' c:\program files\openscenegraph\include\osgviewer\graphicswindow(211) : error C2143: syntax error : missing ',' before '*' c:\program files\openscenegraph\include\osgviewer\graphicswindow(211) : error C2059: syntax error : '*' Error executing cl.exe. I don't know how to fix these bugs. I tried alot but all wasted.. Can anyone please help me in removing these errors Thank you... ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Is there a relationship between nodes and switchsets?
2009/1/23 Ulrich Hertlein :
> Hi Francesco,
>
> Quoting Francesco Argese :
>> Now i like to enable dof management of a switch only when it is
>
> What do you mean by 'dof management'?
I intend to handle dof considering the relationship with the switch.
>
>> enabled. To do so i need to understand what is the relationship
>> between opensceneGraph nodes and SwitchSet index. When i enable switch
>> i specify an int representing the SwitchSet in the function void
>> setActiveSwitchSet (unsigned int switchSet).
>
> (I assume you're talking about calling 'setActiveSwitchSet' on 'sw01' and that
> 'sw01' is an osgSim::MultiSwitch.)
>
> 'switchSet' determines which children of 'sw01' are considered visible.
> 'getValueList(switchSet)' gives you a list which children (by index) are
> visible is this switch set.
Ok. I had not understood this relationship beetween children and
SwitchSet: now it is more clear. Now i can try to retrieve the
information i need linking the index to the children's name of my
switch.
>
> For example switchSet==0 could enable the first child
> ('First_Switch_Alternative'), switchSet==1 would enable the second child, and
> switchSet==2 would activate the first and the second child.
>
> In this case you would have three switchSets [0..2] of which each contains two
> values, one for each child.
>
>> Another thing that i have not understood: is if there is a manner to
>> enable a switch with the name of the children?
>
> No, not that I'm aware of.
>
> Hope this helps,
Thanks, it is very useful.
Francesco Argese
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
