[osg-users] ubuntu11.10 same: was Re: Fedora 16 + nouveau + OSG 3.0.1 = assertion failure
as a data point, on ubuntu 11.10, i see this assertion with osg 3.x but *not* with osg 2.8.5. bob On Nov 9, 2011, at 4:38 AM, Robert Osfield wrote: Hi Stuart, On 8 November 2011 22:13, Stuart Mentzer stuart_ment...@objexx.com wrote: Just updated to Fedora 16 running the nouveau video driver and now my app using OSG and osgviewer give this on exit: Inconsistency detected by ld.so: dl-close.c: 759: _dl_close: Assertion `map-l_init_called' failed! Anyone else seeing/seen this? I see this occasionally with some of OSG apps since I upgraded to Kubuntu 11.11. 3.x prior to the upgrade in the OSG was fine and never produced these errors so it looks to be related to one of the core C libraries. Searches on the web revealed that the OSG isn't alone in seeing this warnings appear on exit when upgrading the OS, but for all my searching for an answer when the warnings first appear I've found no answer. Perhaps a search now would uncover more information about what might be going on. 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] osg/vpb course: oct 5-7, south lake union, seattle, wa
hi gang, just a quick reminder about the upcoming openscenegraph course. we've extended the course discount extended through end-of-week, to accomodate more students. if you're working this through your own system, but your purchasing people are slow, contact me and we can arrange an early-bird registration on a handshake. as a quick reminder: This three-day course teaches the fundamentals of OpenSceneGraph. Developers attending the course learn the mechanisms behind effective development from scenegraph creation and manipulation through debugging optimizing. Through instruction and labs, students build scenes and interact with real code from day one. The course is fast-paced, requires creativity and problem solving, and leaves users with a thorough immersion in OpenSceneGraph. Instruction is hands-on with numerous labs where students directly turn concepts into practical knowledge. http://techsoupcorp.com/news/osg-080210-pr.html hope to see you in seattle! bob -- bob kuehne ceo - blue newt software www.blue-newt.com 734/834-2696 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Open Scene Graph Training
hi david, thanks for the re-post - i *did* know about this. ;) i thought i posted a few weeks back. if it didn't make it through everyone's filters, then here it is again! two weeks remain for discounted pricing, and it'll be a good course. we've given this course for a number of years, and it's fast-paced, in-depth, and eye-opening (that means we're providing coffee). full pricing begins on 09/02/10. -- Tech Soup announces open registration for its next OpenSceneGraph (OSG) course, October 5-7, 2010, in South Lake Union, Seattle, Washington. This class will teach students everything to be proficient in OSG in a 3-day intensive course. This course covers everything developers need to know to take maximum advantage of OpenSceneGraph from intermediate through advanced. We'll also take a tour through VirtualPlanetBuilder so you can build geospecific, tiled, paged datasets. This three-day course teaches the fundamentals of OpenSceneGraph. Developers attending the course learn the mechanisms behind effective development from scenegraph creation and manipulation through debugging optimizing. Through instruction and labs, students build scenes and interact with real code from day one. The course is fast-paced, requires creativity and problem solving, and leaves users with a thorough immersion in OpenSceneGraph. Instruction is hands-on with numerous labs where students directly turn concepts into practical knowledge. full details, hotel, and travel info: http://techsoupcorp.com/news/osg-080210-pr.html -- there are still seats available, hope you can join us! bob On Aug 18, 2010, at 12:08 PM, David Glenn wrote: Greetings! I found out through the Khronos web site that there is going to be an Open Scene Graph Corse offered in Seattle on Oct 5th-7th by Bob Kuehne. Did anyone else knew about this? ... D Glenn D Glenn (a.k.a David Glenn) - Join the Navy and See the World ... from your Desk! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=30883#30883 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org bob kuehne ceo - blue newt software www.blue-newt.com734/834-2696 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osg course: oct 5-7, seattle, wa
hi all, it's time again for our osg course! registration is open now, with a 15% discount off the full course price until 09/02. the class is a small one, so register early (and often, if you like). here are the details: -- Tech Soup announces open registration for its next OpenSceneGraph (OSG) course, October 5-7, 2010, in South Lake Union, Seattle, Washington. This class will teach students everything to be proficient in OSG in a 3-day intensive course. This course covers everything developers need to know to take maximum advantage of OpenSceneGraph from intermediate through advanced. We'll also take a tour through VirtualPlanetBuilder so you can build geospecific, tiled, paged datasets. Topics: * Building Debugging * Memory Management * Nodes * State Lighting * Visitors * Viewing Manipulating * Plugins * Optimization * Terrain * Data Tiling Paging This three-day course teaches the fundamentals of OpenSceneGraph. Developers attending the course learn the mechanisms behind effective development from scenegraph creation and manipulation through debugging optimizing. Through instruction and labs, students build scenes and interact with real code from day one. The course is fast-paced, requires creativity and problem solving, and leaves users with a thorough immersion in OpenSceneGraph. Instruction is hands-on with numerous labs where students directly turn concepts into practical knowledge. -- full course announcement: http://www.techsoupcorp.com/news/osg-080210-pr.html registration details here: http://www.techsoupcorp.com/courses/openscenegraph.html hope to see you in seattle! bob bob kuehne ceo - blue newt software www.blue-newt.com734/834-2696 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Mac OS X plugins confusion
hi don, i fixed this by change some cmake to take a different code path so that it creates xxxd and osgdb_xxxd.so style names for os x as well as other platforms. i forgot to submit this for a while, but will right now. watch your osg-submissions channel... bob On Dec 16, 2008, at 8:52 PM, Don Leich wrote: On Mac OS X *debug* version executables look for *release* version named plug-in shared libraries. $ osgviewerd cow.osg Warning: Could not find plugin to read objects from file cow.osg. osgviewerd: No data loaded With OSG_NOTIFY_LEVEL=DEBUG... DynamicLibrary::failed loading osgPlugins-2.7.7/osgdb_osg.so I worked around the problem by creating links like this $ ln -s osgdb_osgd.so osgdb_osg.so for all plugin libraries. This was seen with a fresh debug only build of Friday's 2.7.7 release for Mac OS X. A similar build on 64- bit Linux did not exhibit this problem. Also, nothing to do with out-of-source builds. -Don Leich ___ 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
yeah, i had this warning (add parenthesis to disambiguate intention of
the ) as well. so, i think you're saying the expected code is:
if ( ( it-second.second osg::StateAttribute::ON ) ==
osg::StateAttribute::ON )
b
On Fri, Oct 3, 2008 at 4:07 PM, Adrian Egli OpenSceneGraph (3D)
[EMAIL PROTECTED] wrote:
No problem, but append some parentheses to be sure that the compiler
understand well what you are doing or what you like to do
adrian
2008/10/3 Art Tevs [EMAIL PROTECTED]
Hi Adrian,
I think it should. This is just a quick test if a program attribute is
enabled. I haven't found a best solution for that, hence implemented it in
this way.
However I think the operator is applied before == operator, which yields
in the same operation as your first solution. It do just check if the ON
attribute is present in the state attribute. However I agree, it is better
to change that. I'll do this next.
Cheers,
art
Is the code doing what we want?
// now apply all uniforms which are in the database
for (osg::StateSet::UniformList::const_iterator it =
mUniforms.begin();
it != mUniforms.end(); it++)
{
if (it-second.second
osg::StateAttribute::ON ==
osg::StateAttribute::ON)
lastAppliedProgram-apply(*(it-second.first));
}
we should use
if (* ( it-second.second osg::StateAttribute::ON
)* ==
osg::StateAttribute::ON)
or
if (it-second.second * (osg::StateAttribute::ON ==
osg::StateAttribute::ON)* )
or
if (it-second.second *
*osg::StateAttribute::ON ==
osg::StateAttribute::ON )
see @
f:\dev\OpenSceneGraph\osgPPU\src\osgPPU\ShaderAttribute.cpp
at line 363
--
Adrian Egli
___
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
--
Adrian Egli
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
bob kuehne
founder and ceo - blue newt software
www.blue-newt.com734/834-2696
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] obj loader: map_* only reads last component
hi all, i recently was working with some .obj files (and associated .mtl files) and ran into the problem where the loader would truncate only the last component of a filename containing spaces. so, for example, in the .mtl file would be an entry like: map_Kd my texture name.jpg which is valid under many filesystems, however, the loader would truncate it to just 'name.jpg' and of course, not resolve that (or resolve a wrong texture). so i did a little research, and the specifications for mtl seem to simply say that: map_Kd filename is valid. my question is to whomever wrote the mtl file parser - why are the filenames truncated? i'd say the should be stripped (ie, ' my file name.jpg ' should resolve to 'my file name.jpg') but never only the last component used. if that's the case, then i've got a patch ready to go. anyone? bob ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osg-submissions] API configurations in aseparateConfig include file
-mail for such purpose. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- bob kuehne founder and ceo - blue newt software www.blue-newt.com 734/834-2696 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osg-submissions] API configurations in aseparateConfig include file
hi gang, sorry about the widespread expression of frustration with this particular change - it's come at an inconvenient time for a few projects i'm working on. i continue to be osg's #1 fan, and user, though i might be considered a wee bit critical at times. it's because i'm very intersested in seeing osg evolve well. :) apologies! bob On Jun 25, 2008, at 9:40 AM, Bob Kuehne wrote: quite the interesting change, eh? gets back to a point of problem i have with this project - that it isn't designed, but mostly just implemented. and even that is done without a lot of thought as to the larger consequences... sigh. anyway, how's your new thing going? well? b -- Forwarded message -- From: Brian R Hill [EMAIL PROTECTED] Date: Wed, Jun 25, 2008 at 9:10 AM Subject: Re: [osg-users] [osg-submissions] API configurations in aseparateConfig include file To: OpenSceneGraph Users osg-users@lists.openscenegraph.org I second Paul's statement - it breaks every other project that uses osg. Brian [EMAIL PROTECTED] wrote: - To: 'OpenSceneGraph Users' osg-users@lists.openscenegraph.org From: Paul Martz [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] Date: 06/25/2008 08:47AM Subject: Re: [osg-users] [osg-submissions] API configurations in aseparateConfig include file This is most definitely not a transparent change. It is not backwards compatible with application projects designed to build against an OSG source/build tree. -Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Killian Sent: Tuesday, June 24, 2008 10:18 PM To: OpenSceneGraph Users Subject: Re: [osg-users] [osg-submissions] API configurations in aseparateConfig include file What was suppose to happen is that all of the changes were to be transparent in such a way where he need not write additional info. The problem of course is that when the code was checked in it was not tested for the windows platform, and now that I finally understand how it is suppose to work there are two known issues: 1. On my setup using 2.4.8 and VS 7.1 platform the cmake fails to identify that I can use interlocked and threaded environment, and so the config files written are for single threaded, and some of my bounding variables were defined as float. 2. I suspect that cmake scripts included the *build* include for only OpenThreads and OSG (and these could build fine)... problem is that all projects dependent on either of these will also need to add the build path to search, and this triggered the why can't my application find the Config header? issues. It should be easy to fix #2 if in fact that is the intended direction (and to the best of my knowledge) it was. If these things are working properly, it should be a transparent workflow. I will certainly test this and provide feedback once the windows.h issues are resolved. James Killian - Original Message - From: Paul Martz [EMAIL PROTECTED] To: 'OpenSceneGraph Submissions' [EMAIL PROTECTED] Cc: 'OpenSceneGraph Users' osg-users@lists.openscenegraph.org Sent: Tuesday, June 24, 2008 4:56 PM Subject: Re: [osg-users] [osg-submissions] API configurations in a separateConfig include file I was surprised to see a change with such widespread ramifications discussed only on osg-submissions, so I'm cross-posting. I think I've now waded through enough of the posts in this thread to understand why this was done, and how to cope with the fact that OSG header files are now in the build directory. Mathias, could you take the time to enter a FAQ on the wiki regarding this? I foresee many posts when people upgrade to the latest OSG of the form: why can't my application find the Config header?. Users will need to know the following: * OSG now generates headers in the build tree. If your app links with OSG from a source/build tree, your app will now need to look for headers in multiple locations. * You can get around this by installing OSG. You can customize the install location with an OSG cmake variable. * Any other info you think is relevant. A FAQ on the wiki would be better than having people search the osg-submissions archives. Thanks, -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org This is a PRIVATE message. If you are not the intended
Re: [osg-users] [osg-submissions] API configurations in aseparateConfig include file
osg-users, what fun would this list be if someone (lucky me) didn't get to stick their foot in their mouth from time to time. :) don't get me wrong: i think osg is by _far_ the best designed and implemented scenegraph out there. and robert does the best job at balancing an admittedly difficult task - incorporating changes from users, his own ideas and designs, and criticism from all fronts (mine included). i use osg for 100% of the projects i do work on and would have it no other way. having been involved with osg since it's inception, i'm both very satisfied and very critical of it, out of concern that it continues to evolve in a way that takes care of it's users yet adapts to the ever-changing graphics landscape. and i do try to contribute to make it better in little ways here and there. and so, as an act of contrition (yes, i was raised a catholic child), i submit my updated 'FindOSG.cmake' which i use to create builds of apps with osg on windows, linux, and the mac. this cmake FIND_PACKAGE tool will setup the variable OSG_INCLUDE_DIRS to point to both the generated and installed source of osg, as well as the OSG_LIBRARY_DIR for the discovered osg libraries. i'll post an entire standalone example to submissions later, because i think having a way for users to build a standalone app would be a useful addition, especially with the changing build landscape. sheepishly, (not a scotland joke) bob Findosg.cmake Description: Binary data ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Changing texture coordinates of built-in shape drawables
in general, don't use shape drawables if performance is important. shape drawables render in immediate mode: the slowest form of rendering on modern gfx hardware. this is a topic paul and i discuss in our course in detail. bob ps - shameless plug: next osg course: june 11-13, boulder colorado On May 7, 2008, at 7:02 AM, Robert Osfield wrote: Hi Franclin, You can't modify the texture coordinates of ShapeDrawable, as explain yesterday, ShapeDrawable is just a simple class for enabling rendering shape primitives, its not meant as a general purpose rendering tool. Please build geometries using osg::Geometry as per the osggeometry example for general purpose rendering. Robert. On Wed, May 7, 2008 at 11:00 AM, Franclin Foping [EMAIL PROTECTED] wrote: Hi, I would like to achieve a multitexture effect on built-in shape drawable objects (Box, Capsules and so forth). My question is how to get and/or change the texture coordinates of these objects? Waiting for your reply. Franclin. __ Do You Yahoo!? En finir avec le spam? Yahoo! Mail vous offre la meilleure protection possible contre les messages non sollicités http://mail.yahoo.fr Yahoo! Mail ___ 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] .ive plugin: incorrect ReadResult?
hi gang, so the problem with these, and what we're trying to fix is one of policy : what's the right error to return. jeremy noted: Also, you don't HAVE to return a ReadResult::ReadStatus enum directly; it can also be a string (I submitted a patch for this a long time ago) giving some useful error message; in this case, the status is set to ERROR_IN_READING_FILE. and i wrote a few days back the 'policy' for the enums: FILE_NOT_HANDLED, //! file is not appropriate for this file reader, due to some incompatibility, but *not* a read error FILE_NOT_FOUND, //! file could not be found or could not be read FILE_LOADED, //! file successfully found, loaded, and converted into osg FILE_LOADED_FROM_CACHE, //! file found in cache and returned ERROR_IN_READING_FILE //! file found, loaded, but an error was encountered during processing which brings me to my proposal: 1) the policy for errors is to fit them into the appropriate enum buckets first. however... 2) if an actual file error is encountered, the user may then (and only then) return a string as jeremy's patch enables. this gives us consistent error reporting, with optional details when an actual error is encountered. thoughts? bob -- bob kuehne founder and ceo - blue newt software www.blue-newt.com 734/834-2696 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VPB on a cluster of headless Linux systems
hi robert, we tried this with mesa at our latest training code. it didn't exactly work - problems cropped up mostly wrt extension features even though we had disabled most features which would require them. i didn't take the time to track down all the odd corners, given that vpb is a work in progress. and, if anyone wants exactly this feature, it's a great community effort. :) but it's good to know authoritatively that osgdem still requires a gfx context for some cases. thanks, bob On Tue, May 6, 2008 at 11:12 AM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Paul, On Wed, Apr 30, 2008 at 2:06 PM, Paul Martz [EMAIL PROTECTED] wrote: Hi Robert -- I'd like to run VPB on a cluster of display-less Linux systems. Is this possible, and if so, can you post a list of osgdem command line options that would make this possible? There is no support for this right now, but it should be possible with further evolution of the code. Right now the problem area would be the creation of graphics context for doing OpenGL texture compression and mipmapping. (I know some osgdem command line options control use - or non-use - of the graphics hardware. A list of all the options necessary to completely disable use of the graphics hardware should allow VPB to run without error in a display-less cluster environment, right?) It'd be the mipmapping/texture compression that would need to be disabled. Use of Mesa might well be a way of getting round this without even modifying VPB. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- bob kuehne founder and ceo - blue newt software www.blue-newt.com 734/834-2696 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] how to use OpenGL code in osg
hi su - we cover this (and more!) in the intermediate training course we teach. however, it's a pretty simple answer - the drawImplementation is only executed once, because it's converted to a display list the first time drawn. so, disable display lists on that drawable, and you'll be set! bob On May 2, 2008, at 5:13 AM, su hu wrote: Hi all, I have some opengl codes and want to use these codes in osg program. I do it as follow: 1. Add a geode to root scene and define a drawable (derived from osg::Drawable). 2. The drawable is added as child of the geode. OpenGL code is added in DrawCallback of the drawable(in drawImplementation). But it seems that the DrawCallback function is called by osg only once. When I add other node to root scene, the drawable will disappear. Could you please tell me how to add opengl code to osg program?A simple sample will be appreciated. Thanks a lot. Regards, t s ___ 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] .ive plugin: incorrect ReadResult?
hi robert, osg community, to amplify on what paul said: * we do a lab in our course in which we explore what plugins are capable of reading/writing. * but! our results always show that plugins support an inconsistent mix of return values, sometimes returning ERROR_IN_READING_FILE when they really mean that they don't handle files of that extension, sometimes returning FILE_NOT_HANDLED when there's an error in reading the file data. * as part of our course in paris this week, we've then wondered aloud if there's an official osg policy for these return values, and if robert had an original design idea behind each return value. our impression is that these mean, as follows: FILE_NOT_HANDLED, //! file is not appropriate for this file reader, due to some incompatibility, but *not* a read error FILE_NOT_FOUND, //! file could not be found or could not be read FILE_LOADED, //! file successfully found, loaded, and converted into osg FILE_LOADED_FROM_CACHE, //! file found in cache and returned ERROR_IN_READING_FILE //! file found, loaded, but an error was encountered during processing if this interpretation of the errors are correct, i'd like to add doxygen documentation to that effect, and the above comments can be in-line replaced in the code to do so. and i've sent a fixed osgDB/ReadResult to osg-submissions for this purpose. the second thing i'd like to do, though i don't have the time, is to clean up the loaders so that the above return scheme is used consistently. the big problem with the current loaders is that there seems to not be a lot of consistency in error reporting among all loaders. thoughts? bob On Apr 29, 2008, at 12:11 PM, Paul Martz wrote: Hi Robert -- If the .ive file can't read a node file for any reason, it returns FILE_NOT_HANDLED. This is correct if the file type isn't .ive, but if it _is_ a .ive file and it is simply corrupt or something else went wrong (permissions, whatever), the plugin should return ERROR_IN_READING_FILE, shouldn't it? Many plugins appear to use return values inconsistently, so this might be a widespread issue. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osg reference manuals
hi osg-users, it came to my attention at the recent paris user's group meeting that some were not aware that there is a series of osg reference manuals available for those who like printed documentation. we also produce pretty nice hyperlinked pdfs which really add a lot to understanding how all the pieces of osg fit together. that itself is pretty useful, but paul and i have done more to make these books better than just a reference. paul martz and i, co-editors on the reference manual series, have done extensive editing of the reference pages generated by doxygen and also created some useful introductory and specialized topics on transitioning from osg 1.x to 2.x, in the front of each of the reference manuals. the most recent version, for example, includes a nice chapter on all the current 2.X environment variables that can be used to customize osg apps when they launch. so, if you're interested in some printed documentation on osg, and more to come (we're working on the 2.4 manual now!), please check out our books: http://www.osgbooks.com thanks! bob bob kuehne founder and ceo - blue newt software www.blue-newt.com734/834-2696 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New Device Input
hi renan, i did this with eric wing for a client of ours. we only did it for mac os x, because the packaging was easiest. we decided against the windows stuff for the reasons paul mentioned. bob On Apr 3, 2008, at 3:01 PM, Paul Martz wrote: Hi Renan - I looked at adding support for this device to OSG, but was put off by the fact that they have per-platform SDKs. I think Mike Weiblen was looking at adding this into VRPN. Anyhow, why not just derive a new class from MatrixManipulator and add that to the viewer? Then hide all your device-specific code inside that class. You'd need to attach your manipulator before calling run() of course. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Renan Mendes Sent: Thursday, April 03, 2008 12:23 PM To: OSG Mailing List Subject: [osg-users] New Device Input Hi, I'm working on a project that requires the use of a new input device, called space navigator. I have the method that gets the 6 coordinates from it. I'd like to know how to get it at every frame. I thought of using a callback, but it doesn't seem right, for the object from that class is not conceptually a osg::Node. Can I include it in my viewer.run() ? Thanks for your tip, Renan M Z Mendes ___ 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] RE FLT export submission imminent (Paul Martz)
hi all, robert is clearly best focused on moving osg forward at the trunk, and does great work there. but paul and i realize others may need support for older versions, and provide that through our support plans. so if you really really want this feature in 1.2, please consider one of the support plans paul and i offer. it's precisely through these support plans, training, and custom development work, that paul and i are able to do things that contribute back to osg. at any rate, we offer support plans which provide maintained branches of osg for 1.2, 2.2, or whatever you require. please see my site for details: http://blue-newt.com/products/ bob bob kuehne founder and ceo - blue newt software www.blue-newt.com734/834-2696 On Mar 28, 2008, at 7:05 AM, Robert Osfield wrote: Hi Neil and Michael, It may be possible to back port the new changes to the OpenFlight plugin to 1.2 as most of the core scene graph is similar, but it requires work to do the initial port then there is the issue about ongoing maintenance. I am not about to go volunteer to administer such a awkward maintenance job as have more than enough work on my plate, but as it's all be open source does make it possible for you to maintain a branch. However, perhaps the best workaround would be to export your models to 1.2 .ive and then use a 2.x version of osgconv to do the conversion from 1.2 .ive to .flt. All the 2.x libs and plugins are versioned so it should be possible to mix. It's certainly not an idea solution but it might give you something to trial without the need for branch the 2.x code base. 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] dc users group picture
On Jan 27, 2008, at 12:50 PM, Jean-Sebastien Guay wrote: Nice photo, got a higher res version for the site? no - that's what was left after photoshop. but i'm not sure anyone else would want to see more pixels of my head anyway. ;) bob ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ANN: Reference Manual for v2.2 now available
given the enthusiasm for this from a number of fronts, expect more formal thoughts from the two of us in the next few weeks. and while you're dreaming of sugarplums, dream of your own chapter in the osg gems book. :) happy holidays! bob On Dec 19, 2007, at 3:34 PM, sherman wilcox wrote: However, I like the idea of a community-written OSG Gems book, and I don't want to underestimate the community's willingness to contribute. So, I'll give this some thought, look into other Gems-style books' business models, and see if I can find a way to make this work (time-wise, as an editor). Initial thought: rather than here's how to use some feature in OSG type of articles, it might be better to have here's how I did this really cool thing using OSG or here's how my company is using OSG, if you know what I mean. I think this is more in line with other Gems books I've read. A gems book is a great idea. I second the here's how I did this really cool thing using OSG route. ___ 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] ANN: Reference Manual for v2.2 now available
I haven't been tempted by the reference manual book because I know how to navigate the source code and can't see how the relatively sparse comments therein would be more helpful compiled together. I think the situation is even worse once you get i thought this would be my experience too, after writing it, but i've been surprised. simply seeing all the methods laid out in a logical fashion (rather than how they might be typed into the header), seeing the documentation for a class side-by-side with it's _full_ inheritance hierarchy, and seeing some context (early chapters for osg overview, env var documentation, etc) have actually been interesting. i've even learned a few things in the process of writing / editing these things. yes, you can teach an old dog new tricks. outside the core OSG classes, so a credible documentation job would mean a lot of work for someone. i'll second that comment. at best, these things pay for beer and aspirin, both necessary after beating one's head against doxygen and latex. :) bob ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ANN: Reference Manual for v2.2 now available
let me pile on and say i'm thrilled we're done with this too. :) i'd also ask of all those users out there who are interested in better documentation to send us an email: [EMAIL PROTECTED] - tell us what would is most important to you in our next book. what you'd like to see, what you think needs more elaboration, etc. we're very interested in ensuring that these books are relevant, focused, and good, and that we increase overall goodness of the documentation and tools available to osg users. thanks! bob ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] intermediate osg training: washington dc, jan 22/23 (osg terrain on 01/24)
hi gang, just a reminder about paul and my forthcoming osg training this january in washington dc. what better way to celebrate the holidays than by getting a loved one an osg training? give a man a polygon, he'll render for a day, teach him to tessellate, and he'll render for the rest of his life. or something like that. anyway, we've got a nice group of students already, but space is still available. so, join us in the heart of washington dc, with easy access to the metro and parking, and we'll provide all the coffee you'll need. here's what we'll be teaching: january 22 23: OSG intermediate course we'll teach you everything you need to know to move from basic OSG usage, to advanced things like building custom drawables, plugins, etc. here's what you'll learn: * Memory management * Nodes, various node types, custom nodes and NodeKits * Traversals, NodeVisitors, Callbacks * Data manipulation tools * Drawables, Geometry, and state * Using plugins * Threads * Viewing and camera manipulation * Window system integration * Optimization techniques january 24: terrain databases in OSG and of course, our bonus round this year is a terrain day. we'll teach you how to build the world, and deal with thorny issues of scale. specifically: * Large data set construction, display, and optimization * Paged data sets * Network served data * VirtualPlanetBuilder data generation * Shading * Tools Workflow we hope you can join us! bob ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Development-system for Mac-OS
hi andreas, you can get whatever mac you want, as the sdk and os are independent, to some extent. that is, you can be running 10.5, but build applications that target 10.4 or earlier. so, for osg, this means building your app against the 10.4 sdk (included as part of the development tools). i've been building and using osg and osg apps on 10.5 for months now, without problems... bob On Dec 12, 2007, at 2:57 PM, Andreas Goebel wrote: Berg, Michael schrieb: I don't think the problems weren't just 64-bit. About a month ago (), I posted a message with the subject Undefined Symbols in OSG on Mac OS X The OSG binary installer for Mac OS X 10.4 (the 10.4u SDK) *mostly* worked, but my applications would not compile if I made calls to osg::Image::readPixels() or osg::StateSet::setMode(). E. Wing replied that: = Yeah, Apple screwed up and broke binary compatibility between 10.4 and 10.5 when using OpenGL and C++. I have notes and binaries coming on this, but the short story is you can't use 10.4 built frameworks against the 10.5 SDK or you get the linking problems you see. Either switch to the 10.4u SDK on Leopard, or use a set of OSG frameworks built against the 10.5 SDK. = Anyway, once the Mac OS X 10.5 SDK (32-bit only) was released and I upgraded to it (http://www.openscenegraph.org/projects/osg/wiki/Downloads ) it solved the linking problems I was having. If you look through the release notes for the 10.5 SDK, it mentions that Apple changes some of the types in the OpenGL headers, so OSG had to be rebuilt for that. Hi, thanks for the info. But does that mean that I would avoid those problems by simply using Mac OS 10.4 ? Regards, Andreas ___ 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 version
i like this idea, paul. perhaps the version could be tagged something indicating 'development' between release tags, for example: '2.3.0- beta', and then once robert gets to his release point, changing to '2.3.0', tagging, and then immediately changing to '2.3.0-beta'. or maybe this immediately post-release version number is something like '2.3.1'. ruminate... bob On Dec 12, 2007, at 5:00 PM, Paul Martz wrote: I'll bump the version number up once I tag the 2.3.0 release, I've been hanging back while more testing is carried out. Can I suggest a change in policy? The version number should get bumped as soon as the first post-release change is committed. At that point, the code no longer matches the previous release; the version number should increment to reflect that. If the SVN head version number contains post-release changes but the version number is unchanged, then code written for specific releases might not run on the current SVN head, thus delaying testing. -Paul ___ 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] osgOQ occlusion query release candidate available
hi paul, excellent work! this works great on mac os x 10.5. just tried it, and got a lovely 60hz on the 'ptViewer --stock' included demo. one note: the viewer 'ptViewer.cpp' force loads a loader which i don't have, and probably others as well - osgdb_PolyTrans.dll (not to mention, of course, that the plugin load mechanism would be different on several platforms). so i'd excise lines 251-263. diff attached. but it works great - very nice piece of engineering. congrats! bob ptViewer.diff Description: Binary data On Nov 29, 2007, at 12:46 AM, Paul Martz wrote: As announced at the SIGGRAPH OSG BOF. I've added OpenGL occlusion query support to OSG. Although some open issues remain, I'm making it available now to the OSG community to solicit your feedback. http://www.openscenegraph.org/projects/osg/wiki/Community/NodeKits/osgOQ This has been tested on Windows using VS7 and OSG v2.2. If you encounter problems on other platforms, please let me know. After outstanding issues are identified and resolved, I'll submit this to Robert for possible inclusion in core OSG. Thanks to Doug McCorkle, ISU, and Ames Laboratory for funding this development effort. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org bob kuehne founder and ceo - blue newt software www.blue-newt.com734/834-2696 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VTP height field issue
hi jim - this is a transform generated by osgdem (consumed via vpb) -
i think it's a different transform than the kind you suggest, or at
the least, it's not normalized. the transform _is_ correct for one of
the images, and it's how robert has been generating these vpb config
files for a while. so i think the elements are right, but just a bit
off. full vpb config attached.
bob
globe.vpb
Description: Binary data
but, On Nov 28, 2007, at 8:52 PM, Jim Brooks wrote:
how would i flip it? i suspect i need to change the
transform somehow:
Transform {
360 0 0 0
0 180 0 0
0 0 1 0
You're on the right track, but the matrix elements
are unit float {0.0,..,1.0} values, not degrees.
These 3 rows are 3D unit vectors that
define the 3 orthogonal axises.
-1 0 0 # -1 = 180' rotation
0 1 0
0 0 1
-180 -90 0 1
No, the last row is the origin of the matrix
(coordinate space).
Changing them results in translation, not rotation.
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
bob kuehne
founder and ceo - blue newt software
www.blue-newt.com734/834-2696
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgOQ occlusion query release candidate available
On Nov 29, 2007, at 9:48 AM, Paul Martz wrote: Do me a favor, cycle through the threading models using the 'm' key to make sure they all work on your system (tested OK on mine: Pentium HT, single NVIDIA card with dual monitors). worked fine with one monitor in all modes, will try with two later. bob ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VTP height field issue
oh, fyi - my simple solution was simply to flip the image
appropriately, and let osgdem do what it wanted with it. i know,
hacky, but i'm past the problem. getting things done! woo! :)
On Nov 29, 2007, at 8:09 AM, Bob Kuehne wrote:
hi jim - this is a transform generated by osgdem (consumed via vpb)
- i think it's a different transform than the kind you suggest, or
at the least, it's not normalized. the transform _is_ correct for
one of the images, and it's how robert has been generating these vpb
config files for a while. so i think the elements are right, but
just a bit off. full vpb config attached.
bob
globe.vpb
but, On Nov 28, 2007, at 8:52 PM, Jim Brooks wrote:
how would i flip it? i suspect i need to change the
transform somehow:
Transform {
360 0 0 0
0 180 0 0
0 0 1 0
You're on the right track, but the matrix elements
are unit float {0.0,..,1.0} values, not degrees.
These 3 rows are 3D unit vectors that
define the 3 orthogonal axises.
-1 0 0 # -1 = 180' rotation
0 1 0
0 0 1
-180 -90 0 1
No, the last row is the origin of the matrix
(coordinate space).
Changing them results in translation, not rotation.
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
bob kuehne
founder and ceo - blue newt software
www.blue-newt.com734/834-2696
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
bob kuehne
founder and ceo - blue newt software
www.blue-newt.com734/834-2696
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] vsync (was: OSG CPU usage)
On Nov 19, 2007, at 6:02 AM, Robert Osfield wrote: On Nov 19, 2007 9:25 AM, Ákos Maróy [EMAIL PROTECTED] wrote: Paul Martz wrote: Vsync is usually on by default, can be toggled on or off by some driver options, and can also sometimes be toggled by OpenGL extensions. but does this mean that if I call rendering blocks unti the next vsync clock tick? in short: yes. OpenGL drivers have a FIFO, your app fills the fifo with tokens and data, at the end of the frame you send in a swap buffers token and this goes into the FIFO with everything else. Normally the swap buffers call itself doesn't block (although some implementations do this), but the FIFO itself can only be cleared at the rate for one swap buffers call per frame so it'll fill and once filled up it will effectively block until previous frame was begun dispatching. The driver may allow several frames worth data in the fifo before block, this is driver dependent, and also dependent on just how data you have to pass to OpenGL- if you have massive models the CPU will be block on the FIFO right on the same frame rather than more than one frame begin backed in the FIFO. The end result of this is simpler though - put vsync on, and your frame loop will block and should iddle while its waiting for the FIFO to begin accepting new data. Some OpenGL drivers have been known to CPU resources when waiting rather than idling - ATI drivers were doing this for a while, but I believe this has now been fixed. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org bob kuehne founder and ceo - blue newt software www.blue-newt.com734/834-2696 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG CPU usage
in fact, what paul says is very similar to what i often do in test apps:
while ( !viewer.done() )
{
usleep( timeToSleepToGetMeToMyDesiredFrameRate );
viewer.frame();
}
in a more commercial-style app, i'd recommend only redrawing when data
actually
changes. so in a cad app, when the user moves the mouse, or edits the
data, in a
flight sim, when the eyepoint, or any on-screen data changes, etc.
bob
On Nov 15, 2007, at 10:11 AM, Paul Martz wrote:
how can I display my scene graph so that it is idle when
there's nothing to do?
The osgviewer app calls viewer.run(), which is effectively the same
as:
while (!viewer.done())
viewer.frame() // draw a single frame
So, if you only want to draw when your app is not idle, then you
should not
use viewer.run(). Instead, you should call viewer.frame() only when
the
image needs to be updated.
Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com
303 859 9466
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
bob kuehne
founder and ceo - blue newt software
www.blue-newt.com734/834-2696
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Retrieving occlusion query results prior to swap(was: RE: Need a post-swap traversal)
bob kuehne - [EMAIL PROTECTED] - 734-834-2696 On Oct 22, 2007, at 6:47 PM, Paul Martz [EMAIL PROTECTED] wrote: Thanks for the note, Robert -- The high level approach does suffer from a round trip to the graphics card - you still have to wait till all the queries are returned before you can dispatch the last bit of data into the OpenGL fifo. Claiming this eliminates the latency is rather stretching things, it hides it a bit, bit only a bit, you are still stalling the CPU till the GPU is done so parallelism between the CPU and the GPU is heavily compromised. The total time for the hardware to generate the results is the same in either case, you're right. The latency I was referring to is a visual latency, not a time latency per se: seeing (or not seeing) the actual geometry in frame N is based on query results from frame N-1. My current implementation suffers from this latency. I'm not pleased with the results, and recent discussions (such as the thread concerning only rendering when needed rather than with a continuous rendering loop) indicate that there are OSG use cases under which such an implementation would be a poor choice. Personally I'd rather taking the hit and doing everything in one frame rather than having a frame overlap and then having to come up with clever frame coherency tricks to ensure that you don't get false negatives in the next frame. There are certain models types that are already breaking frame by a long way - i.e. hitting 10fps, so for these a round trip to the GPU is relatively low compared to the potential gain of culling geometry and state from the draw dispatch, for these occlusion culling in frame will be a godsend. Yep, I'm leaning this way as well. So, then, the question becomes: How to implement this in OSG? As for mods the rendering backend, I'd suggest some sort RenderLeaf extension that allows leaves to be switched off, and during draw traversal the switched off leaves are ignored. The toggling code be done be the pre RenderStage you set up to do the occlusion query. Hm. I really want all the occlusion queries to be done after all other normal rendering has finished (to maximize the chance for occlusion to occur). So it seems I really want a POST RenderStage that issues the queries, then iterates looking for available results; as each result becomes available, it checks for visibility and renders or skips the actual Drawables accordingly. Also, I don't want to limit this to Drawable-level queries. It is very useful to be able to perform a single occlusion query to test for the visibility of an entire subtree. Thoughts on that? I'll look into this, but look forward to any additional thoughts or directions from you. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OpenSceneGraph 2.2 Training: November, January
hi osg-ers, hot on the heels of two successful training courses (one public, one on-site private), we're heading into our fall training schedule. on the radar at this moment is the forthcoming Open Source Retreat early in november. we've got a lot of stuff we're putting in on the docket for this five day intensive, with a heavy focus on what's new and great about osg 2.2. we're looking forward to this course! -- Bob Kuehne and Paul Martz will co-instruct two week-long comprehensive OSG courses hosted by the Open Source Retreat. The first will be in Charlottesville, VA, November 12-16, 2007, and the second will be in Rome, Italy, January 6-10, 2008. These courses include time set aside for one-on-one consultation and instruction. To register for either of these courses, visit the following URL: http://www.opensourceretreat.com -- spots are available, so sign up early, and sign up often. we hope to see you in virginia in november. if you can't make november, there's also a course in rome, january 6-11, 2008. what could be nicer than pasta, espresso, and geekery in rome? :) bob ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Documentation
And don't forget: http://osgbooks.com bob kuehne - [EMAIL PROTECTED] - 734-834-2696 On Aug 21, 2007, at 9:25 AM, Gordon Tomlinson [EMAIL PROTECTED] wrote: The man pages would be more or less the same as the doxygen pages . but see http://www.skew-matrix.com/books.asp Best Regards Gordon __ Gordon Tomlinson Email : gordon.tomlinson @ overwatch.com YIM/AIM: Gordon3dBrit MSN IM : Gordon3dBrit @ 3dSceneGraph.com __ Telephone (Cell): (+1) 571-265-2612 -- Note New Number Telephone (Work): (+1) 703-437-7651 Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival - Master Tambo Tetsura -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ]On Behalf Of maruti borker Sent: Tuesday, August 21, 2007 9:23 AM To: osg-users@lists.openscenegraph.org Subject: [osg-users] Documentation I am a newbie in OSG , i find the D-oxygen generated documentation very limited as they dont explain what each function do or what the parameters mean . Is there a better documentation like a man page or something to help us newbies out ??? . ___ 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
