Re: [osg-users] Debugging example hangs in Cygwin and need some insight into cygwin_osgdb_osg.dll
El Jueves 29 Mayo 2008ES 22:06:09 Brian Keener escribió: Alberto Luaces wrote: This almost seems as if iot has something to do with the actually writing of the osg file when it writes the data and then something not terminating as it should. I think this could be a non-valid example, because osgDB::DynamicLibrary on UNIX (including Cygwin) only loads symbols when needed (it opens them with the RTLD_LAZY specifier), so the OSG's plugin register could realize the mismatch before trying to load any symbols from the DLL. Alberto, I'm not sure I understand. Are you saying that even though the debug messages say that the dll was opened that there are still parts of the dll whcih have not been loaded and that it is within these areas (when they are finally loaded) that the interaction with cygwin causing the hang ultimately makes itself visible? Thus the simple fact of open and closing the dll does nothing that helps us unless we can get to the point of something occurring which causes the parts of the dll we need to be loaded. Not really sure how to ask what I wrote above so I hope you can understand what I am asking. Brian, yes, this is what I meant. To load a dynamic symbol you have first to open the DLL file containing it, and then load it explicitly before use (if you used RTLD_LAZY). The source code at DynamicLibrary.cpp shows this. This can explain why it hangs depending on the data file loaded. I think we could search for the differences between the .osg plugin and the well-behaved others. Alberto ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgDEM usage...
On Mon, Jun 2, 2008 at 11:14 PM, Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC [EMAIL PROTECTED] wrote: Robert (or anyone else), Can you enlighten me on the --TERRAIN, --LOD, and --PagedLOD options in osgdem? What are the benefits or drawbacks for using these? Which is the best combination to use for performance, quality, etc.? --terrain tells the build to use osgTerain::TerrainTile for terrain rather than using osg::Geometry. Have a search through the last few months archives on this topic, I've written plenty. --LOD vs --PagedLOD, weill this is just whether it builds a single database containing osg::LOD, or a paged database of many separate tiles using osg::PagedLOD. Just use the default which is --PagedLOD as this is really what VPB is about, the --LOD is really just there for testing purposes. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph 2.4.1 stable release?? If/when/when/who
Hi Eric, Thanks for the offer of help. Having a hard a fast rule w.r.t binary compatibility will preclude some important bug fixes, this has happened with previous releases, and includes fixes to 2.4.0. So I'd suggest that one uses discretion about what parts get merged and if it means breaking compatibility so be it, one can bump the SO version number, even if it means skipping a few to be newer than the last developer release - we just have to coordinate between ourselves. Robert. On Mon, Jun 2, 2008 at 10:47 PM, Eric Sokolowsky [EMAIL PROTECTED] wrote: I'm willing to help port bug fixes back to stable branches. I have an ulterior motive though; I made a particular change in the Inventor plugin that is now in SVN that I would like to see in a stable release. I think that only bug fixes should be ported back; API changes would have to wait for a developer release or a new stable release. This would prevent SO version conflicts between release and developer versions. -Eric Robert Osfield wrote: Hi Paul, On Mon, Jun 2, 2008 at 4:03 PM, Paul Melis [EMAIL PROTECTED] wrote: Why not branch to _create_ the 2.6.x series, instead of branching _after_ 2.6.0? The former is far more commonplace. The system since the 1.9.x dev series has been that we tag when ready to officially make a release, with the 1.9.x series converging towards a point when 2.0.0, using the last few dev releases as release candidates, and finally the trunk was in good enough state to have 2.0.0 tagged from SVN trunk. The other approach, which you suggest, is rather than use the dev releases as release candidates, branch a stable release when we get to a feature freeze period and then make release candidates based on this branch. The final official release would then bee a branch + a revision number than holds the particular release in a point in time. When moving to having maintainence releases of a stable series using dev series as pre releases doesn't work, as the dev series already heads off in towards then next major stable point release. So... now we a proposing the stable maintaince releases then we need to move to a new system - branch first then stabilising this code base in readiness for a 2.4.1, 2.4.2 seems like the way to go from here on out. For 2.6.0, it'd suggest we use SVN trunk/later 2.5.x dev series as pre releases of 2.6.0 get things tested enough to know we are roughly in the right ball park functionality/quality wise, then copy trunk across to a 2.6.0 branch and then use this as the base of release candidate series before the final 2.6.0. Once the 2.6.0 branch happens the stable release maintainer would then become actively involved in shepherding the code base to its eventual official release. As the differences between 2.4 and SVN are still small now is the time to start the process... I'm willing to help to backport fixes and other things from trunk to the 2.4 branch. I can't tell you at this moment if this would be a long-term commitment, though. I think it'd be hard for anyone to sign up long term to something, taking short term responsibility won't be a problem as long as we all follow a set of systems that are published and adhered too/use the same scripts/tools - so others can easily drop in to help out when others move on/are away on holiday. Right now we don't have all the systems published/scripts etc, so it'd be a case of documenting as we go along. First step is to find a set of volunteers who are willing to going along this journey, get them write access to making branches of the OSG. It might even be worth having a scratch pad set of branches that we can new maintainers can experiment with. I'm open to suggestions. 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] Community Documentation Initiative [Was: Too much support!!!!!]
Hi all,
I have created a new page on the wiki that list all the example programs
that comes with OSG in table form. In the TOC is listed under
Documentation | Examples. If you (excl. Robert at this point) are
familiar with or have authored any of the example programs, then please
go to the page below and add you input. Newbies like me will be ever so
grateful.
http://www.openscenegraph.org/projects/osg/wiki/Support/Examples
Best regards,
John
Jean-Sébastien Guay wrote:
Hello John,
I'm a total newbe to OSG and as a newbe I hunger for info. Here's a
few things that I am really missing, and I think most of these things
can be done by the community rather than Robert:
All three of your ideas are really good and pretty easy to do. Some
comments:
1) There are lots of excellent example programs provided with OSG.
However, I sometimes find it hard to find the example I need to study
to solve my newbe questions. What I'd really like to see on the wiki
is a list of all the example programs with ditto summary of what
features they demonstrate and techniques used.
Excellent idea. There have been requests before to document the examples
themselves (code comments), but this is a big job and hard to
coordinate. However, a wiki page which lists all the examples ('ls
OpenSceneGraph/examples', copy-paste) could then be filled by people
gradually...
See;)
http://www.openscenegraph.org/projects/osg/wiki/Support/Examples
In general, I think the wiki could use a chief editor. Some info is
well categorized, but other info is a bit scattered. But before this
happens, I think we need to be able to create accounts on the wiki so
that people are accountable for their changes.
2) Summary and detailed documentation of the tools that come with VPB.
Check the archives, Robert has stated that once the major work he is
doing on these was done, he would start documenting them. They are
currently moving targets, so any formal documentation might be out of
date really quickly. But if anyone has the time, they can start and at
least write the parts for the tools that look like they're stable.
3) For all OSG classes, I'd love to see more high-level class
information (e.g. purpose, etc.). For certain classes that implements
special programming techniques, it would be wonderful if the
documentation included a link to external resources explaining the
technique in general.
Yes, that would be great. In general, the doxygen comments are very
low-level implementation details (or what a method does, instead of why
it does it). So the kinds of info you're suggesting would help a lot.
Documentation submissions could be marked with doc-only or similar
topic tags.
Another good idea. In general, I think tagging messages would allow
Robert to ignore some categories of threads where the subject alone
doesn't say enough about it.
I hope I have managed to convince at least some of you to participate
in a community documentation initiative.
Personally, I have always agreed that it was needed. The hard part is
coordinating this work and getting it all done, when most users are busy
working on their actual jobs. But I think it's a case where if someone
steps up and agrees to take charge (I can't in this case, sorry) then
the community could make small individual steps that when taken as a
whole, would count for a lot.
I hope this becomes a reality soon. I'll certainly participate.
Thanks,
J-S
--
Best regards,
John
WeatherOne
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Community Documentation Initiative [Was: Too much support!!!!!]
Hi John, On Tue, Jun 3, 2008 at 9:21 AM, John Vidar Larring [EMAIL PROTECTED] wrote: I have created a new page on the wiki that list all the example programs that comes with OSG in table form. In the TOC is listed under Documentation | Examples. If you (excl. Robert at this point) are familiar with or have authored any of the example programs, then please go to the page below and add you input. Newbies like me will be ever so grateful. http://www.openscenegraph.org/projects/osg/wiki/Support/Examples This is a good start. One could link the actual example code available in svn to the example as well so one can browse the source. One could also introduce an extra column for an screenshot and a column for the main classes used in the example, in addition to the wordy explanation. I have a threading bug to chase up right now so I'll get my head down once again... Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Community Documentation Initiative [Was: Too much support!!!!!]
Hi all, please see below... Robert Osfield wrote: Hi John, On Tue, Jun 3, 2008 at 9:21 AM, John Vidar Larring [EMAIL PROTECTED] wrote: I have created a new page on the wiki that list all the example programs that comes with OSG in table form. In the TOC is listed under Documentation | Examples. If you (excl. Robert at this point) are familiar with or have authored any of the example programs, then please go to the page below and add you input. Newbies like me will be ever so grateful. http://www.openscenegraph.org/projects/osg/wiki/Support/Examples This is a good start. One could link the actual example code available in svn to the example as well so one can browse the source. One could also introduce an extra column for an screenshot and a column for the main classes used in the example, in addition to the wordy explanation. * Column for thumbnails/screenshot added (Please set image size to 200x150). * Added links to SVN source code. Add text in front of source link. I have a threading bug to chase up right now so I'll get my head down once again... Yes, please do;) Best regards, John -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Threading crash in osg::notify() fixed
Robert Osfield wrote on Tuesday 03 June 2008: The fix to this bug has been to implement a custom stream buffer that just silently discards all calls to it, this not only fixes the bug but also doubles the performance of associated osg::notify() calls. An svn update will give you this fix. This would be a good candidate for 2.4.1 then ? I'm no good programmer so I won't propose to help with stable releases, but I can help testing. Zoltán -- Zoltan http://sourceforge.net/projects/zsim ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph 2.4.1 stable release?? If/when/when/who
Hi Paul, It sounds like we are now on roughly the same wavelength w.r.t how to progress. Right, but that is for maintenance of the next stable branch. How about the current one (2.4)? I'd suggest going with a branch from 2.4.0 or 2.5.1 (if you want to be lazy) i,e svn copy http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.4.0 http://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/OpenSceneGraph-2.4.x Or name the branch OpenSceneGraph-2.4, or OpenSceneGraph-2.4.series. I'm open to suggestions on naming of a branch - whatever makes sense to those browsing the branches. Or perhaps we should start with an OpenSceneGraph-test branch. At this point I'd suggest to create the 2.4 branch and allow some people to backport stuff from the trunk as a first step. When we get to a point where a 2.4.1 release is viable we can look at the infrastructure needed in terms of scripts. This first release might even be done by hand to get to know what is needed and what can be automated. I can post my simple scripts on the wiki, scripts are good as once you have one that works reliably you can make releases without worrying about making typo's at a crucial moment. For the actual merging from trunk to the stable branch I suggest we take a good look at svnmerge (http://www.orcaware.com/svn/wiki/Svnmerge.py). This is a script that assists in the merging process, preventing the same things to become merged twice among other things. It also keeps a list of revisions already merged for a branch and has an option to block certain revisions from being merged. The other nice thing is that it copies the log messages of revisions being merged, so it's easy to track what a merged revision actually contained (assuming the original log message was descriptive). The Python folks use it extensively and seem to be happy with it. Here's an example log message from the branch being merged _into_, note the two revisions coming in: I'll leave it up to you guys to work out what tools. Another thing that might be useful is watching svn check-ins, as well as convansing users requests for particular fixes to be merged. -- I can easily make the branch once we decide upon an name, then we'll need Jose Luis Hidalgo to add logins and write permissions for yourself, Eric and any others who wish to work on maintaining 2.4.x. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Threading crash in osg::notify() fixed
On Tue, Jun 3, 2008 at 12:35 PM, Zoltán [EMAIL PROTECTED] wrote: Robert Osfield wrote on Tuesday 03 June 2008: The fix to this bug has been to implement a custom stream buffer that just silently discards all calls to it, this not only fixes the bug but also doubles the performance of associated osg::notify() calls. An svn update will give you this fix. This would be a good candidate for 2.4.1 then ? Yes it'd be a good candidate for 2.4.1, since it's just one file that's changed it should be an easy merge too. I think once we have some maintainers in place for a 2.4.x series users will be able request that particular fixes get considered - noting the revision number that the fix was part of would be a good way of pinpoint, also the submission message would be good too. Note the ChangeLog in the 2.5.x series will provide much of this info. I'm no good programmer so I won't propose to help with stable releases, but I can help testing. Testers are very useful :-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph 2.4.1 stable release?? If/when/when/who
Robert Osfield wrote: Hi Paul, On Mon, Jun 2, 2008 at 4:03 PM, Paul Melis [EMAIL PROTECTED] wrote: Why not branch to _create_ the 2.6.x series, instead of branching _after_ 2.6.0? The former is far more commonplace. The system since the 1.9.x dev series has been that we tag when ready to officially make a release, with the 1.9.x series converging towards a point when 2.0.0, using the last few dev releases as release candidates, and finally the trunk was in good enough state to have 2.0.0 tagged from SVN trunk. The other approach, which you suggest, is rather than use the dev releases as release candidates, branch a stable release when we get to a feature freeze period and then make release candidates based on this branch. The final official release would then bee a branch + a revision number than holds the particular release in a point in time. For the latter you can easily use an SVN tag, but I'm sure you knew that. When moving to having maintainence releases of a stable series using dev series as pre releases doesn't work, as the dev series already heads off in towards then next major stable point release. So... now we a proposing the stable maintaince releases then we need to move to a new system - branch first then stabilising this code base in readiness for a 2.4.1, 2.4.2 seems like the way to go from here on out. For 2.6.0, it'd suggest we use SVN trunk/later 2.5.x dev series as pre releases of 2.6.0 get things tested enough to know we are roughly in the right ball park functionality/quality wise, then copy trunk across to a 2.6.0 branch and then use this as the base of release candidate series before the final 2.6.0. Once the 2.6.0 branch happens the stable release maintainer would then become actively involved in shepherding the code base to its eventual official release. Right, but that is for maintenance of the next stable branch. How about the current one (2.4)? As the differences between 2.4 and SVN are still small now is the time to start the process... I'm willing to help to backport fixes and other things from trunk to the 2.4 branch. I can't tell you at this moment if this would be a long-term commitment, though. I think it'd be hard for anyone to sign up long term to something, taking short term responsibility won't be a problem as long as we all follow a set of systems that are published and adhered too/use the same scripts/tools - so others can easily drop in to help out when others move on/are away on holiday. Right now we don't have all the systems published/scripts etc, so it'd be a case of documenting as we go along. First step is to find a set of volunteers who are willing to going along this journey, get them write access to making branches of the OSG. It might even be worth having a scratch pad set of branches that we can new maintainers can experiment with. I'm open to suggestions. At this point I'd suggest to create the 2.4 branch and allow some people to backport stuff from the trunk as a first step. When we get to a point where a 2.4.1 release is viable we can look at the infrastructure needed in terms of scripts. This first release might even be done by hand to get to know what is needed and what can be automated. For the actual merging from trunk to the stable branch I suggest we take a good look at svnmerge (http://www.orcaware.com/svn/wiki/Svnmerge.py). This is a script that assists in the merging process, preventing the same things to become merged twice among other things. It also keeps a list of revisions already merged for a branch and has an option to block certain revisions from being merged. The other nice thing is that it copies the log messages of revisions being merged, so it's easy to track what a merged revision actually contained (assuming the original log message was descriptive). The Python folks use it extensively and seem to be happy with it. Here's an example log message from the branch being merged _into_, note the two revisions coming in: r63798 | benjamin.peterson | 2008-05-29 23:22:40 +0200 (Thu, 29 May 2008) | 17 lines Merged revisions 63460,63464 via svnmerge from svn+ssh://[EMAIL PROTECTED]/python/trunk r63460 | ronald.oussoren | 2008-05-18 15:54:47 -0500 (Sun, 18 May 2008) | 6 lines - Add unittests for platform.mac_ver (or rather, ensure that the unittest for that function actually tests something on OSX). - Add documentation to platform.mac_ver that explains why the middle element of the return value will not contain useful information. r63464 | benjamin.peterson | 2008-05-18 17:07:42 -0500 (Sun, 18 May 2008) | 2 lines fix test_platform (os was not imported) I must admit that I haven't used it at all, but it seems like a useful tool to do this sort of work. I especially like the automatic documentation of what was merged. One last thing to mention is that the script _never_ commits anything by itself, that is still the
[osg-users] Job offer on VR webGIS in Archaeology based on OSG
Dear Osg Users The Italian National Council of Researches, Institute of Technologies Applied to Cultural Heritage (CNR ITABC), Rome, Italy is seeking for one expert professional who will be employed in the following activities: Development of new functionalities of an Open Source rendering web engine, dedicated to archaeological terrains and models (VR webGIS). Duration: 5 months Total salary in Euro: 11.500,00 Deadline: 15th June Reference: [EMAIL PROTECTED] Web site: http://www.vhlab.itabc.cnr.it/jobs ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph 2.4.1 stable release?? If/when/when/who
Robert Osfield wrote: Hi Paul, It sounds like we are now on roughly the same wavelength w.r.t how to progress. Right, but that is for maintenance of the next stable branch. How about the current one (2.4)? I'd suggest going with a branch from 2.4.0 or 2.5.1 (if you want to be lazy) i,e svn copy http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.4.0 http://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/OpenSceneGraph-2.4.x Or name the branch OpenSceneGraph-2.4, or OpenSceneGraph-2.4.series. I'm open to suggestions on naming of a branch - whatever makes sense to those browsing the branches. I'd suggest OpenSceneGraph-2.4. As it is located under /branches, that should be clear enough. Or perhaps we should start with an OpenSceneGraph-test branch. At this point I'd suggest to create the 2.4 branch and allow some people to backport stuff from the trunk as a first step. When we get to a point where a 2.4.1 release is viable we can look at the infrastructure needed in terms of scripts. This first release might even be done by hand to get to know what is needed and what can be automated. I can post my simple scripts on the wiki, scripts are good as once you have one that works reliably you can make releases without worrying about making typo's at a crucial moment. I assume these are shell scripts? Should we decide in advance that the release scripts are targeted at a Linux/Unix system? Should we support two sets (one for Linux, one for Windows) to support maintainers on Windows? For the actual merging from trunk to the stable branch I suggest we take a good look at svnmerge (http://www.orcaware.com/svn/wiki/Svnmerge.py). This is a script that assists in the merging process, preventing the same things to become merged twice among other things. It also keeps a list of revisions already merged for a branch and has an option to block certain revisions from being merged. The other nice thing is that it copies the log messages of revisions being merged, so it's easy to track what a merged revision actually contained (assuming the original log message was descriptive). The Python folks use it extensively and seem to be happy with it. Here's an example log message from the branch being merged _into_, note the two revisions coming in: I'll leave it up to you guys to work out what tools. Another thing that might be useful is watching svn check-ins, as well as convansing users requests for particular fixes to be merged. Do you mean the RSS feed? Or is there a separate mailing list? One thing about the feed that bugs me is that the messages don't contain newlines (the body tag contains a single pre tag containing the log message without newlines). Is this something that can be fixed? They're really hard to read in the current state. I can easily make the branch once we decide upon an name, then we'll need Jose Luis Hidalgo to add logins and write permissions for yourself, Eric and any others who wish to work on maintaining 2.4.x. One thing about subversion is that it's relatively easy to set up a local file-based repository containing some representative files to experiment with. Perhaps we don't need a test branch, but on the other hand testing on the actual infrastructure is probably a good idea. Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph 2.4.1 stable release?? If/when/when/who
Robert Osfield wrote: I can easily make the branch once we decide upon an name, then we'll need Jose Luis Hidalgo to add logins and write permissions for yourself, Eric and any others who wish to work on maintaining 2.4.x. Let's not use just a first name for the user accounts. We're clashing a bit there already on the mailing list :) Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [VPB] vpbmaster doesn't exit on Win32
Hi Glenn and Robert, Is this problem resolved ? I am currently using an OperationThread on my app and I have the same problem, it doesn't want to exit (it blocks into the cancel method). Thanks ! On Mon, Mar 31, 2008 at 6:47 PM, Glenn Waldron [EMAIL PROTECTED] wrote: Robert, Here are all 5 thread stack traces. Glenn On Mon, Mar 31, 2008 at 12:02 PM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Glenn, Thanks for the track trace, unfortunately on its own doesn't pinpoint what might be wrong with the thread cancellation. Could you get the trace traces for the other threads that are still running? Robert. On Mon, Mar 31, 2008 at 4:43 PM, Glenn Waldron [EMAIL PROTECTED] wrote: Following up here is a stack trace from the debugger. On Sat, Mar 29, 2008 at 1:12 PM, Glenn Waldron [EMAIL PROTECTED] wrote: Not sure whether this has been reported, but vpbmaster does not exit under Win32. Once the build completes you have to kill it from the Windows task manager. I have not had time to look into it yet - just wanted to throw it out there for now.. Glenn -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : 703-652-4791 ___ 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 -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : 703-652-4791 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [VPB] vpbmaster doesn't exit on Win32
On Tue, Jun 3, 2008 at 4:19 PM, Serge Lages [EMAIL PROTECTED] wrote: Hi Glenn and Robert, Is this problem resolved ? I am currently using an OperationThread on my app and I have the same problem, it doesn't want to exit (it blocks into the cancel method). I haven't looked at VPB issue yet, the stack traces that Glenn produced suggest that the release of the block hasn't been released for some reason - even though the release is being called on the block by the main thread. This suggests a bug in OpenThreads::block() under Windows, but I guess it could be problem elsewhere, but just has shown itself yet. As to whether the problem that Glenn is seeing is what also have is not possible to say, it may well be just that you own operations are busy and not playing nice with the gentle cancellation that OperationThread tries to achieve via it's _done flag (note it doesn't call OpenThreads::cancel(), instead using the cooraprative approach of setting a _done flag.) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Database Pager
Hi all, is there a concept how the new database pager is working. as i am using an extended version of the database pager in my application, i requested once for the osgDB::DatabasePager::prototype() method. i come just around rebuilding my application. there is no longer a database pager thread, means no longer extended from openthreads. how should i change the application, or should i change to default pager for avoiding in near future next code changes? regards adrian -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New Improved DatabasePager, now with even more threading! Please take a taste today :-)
On Tue, May 27, 2008 at 12:08 PM, Tim Moore [EMAIL PROTECTED] wrote: Indeed. I've made the necessary changes to FlightGear, and it seems to be working fine. Except for being a cpu hog. Apparently, the pager thread is not blocked properly and continuously spins. The fact that the queue is empty is confirmed by the debug messages printed after the block call: HANDLE_NON_HTTP 0: _pager-_requestList.size()= 0 to delete = 0 I have been trying to find the place where the blocking is re-established when the queue goes empty, but could not find it. So I added an updateBlock() call at the end of DatabasePager::RequestQueue::takeFirst that seems to fix the issue. Could have added the call within the if-block, but this has the additional benefit of stopping runaway loops should somehow the pager thread get woken up without work to do. Index: DatabasePager.cpp === --- DatabasePager.cpp (revision 8398) +++ DatabasePager.cpp (working copy) @@ -273,6 +273,7 @@ databaseRequest = _requestList.front(); _requestList.erase(_requestList.begin()); } +updateBlock(); } I am not sure if I need an osg-submissions mail for this? -- Cheers, Csaba/Jester ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Threading problem when using two viewers
Hi,
when I create two instances of osgViewer::Viewer in one program, then
the first viewer freezes (no trackball manipulation possible) when
setting threading model of both viewers to SingleThreaded. Is that
expected behaviour and why, or is it a bug?
When I'm setting one or both viewer(s) to e.g. ThreadPerContext, then
both viewers are working properly.
I'm using OSG-Rev. 8402 and OpenSUSE-10.2-64.
Thanks in advance!
Rudi
The following code reproduces the problem:
#include osg/ref_ptr
#include osgDB/ReadFile
#include osgViewer/Viewer
#include osgGA/TrackballManipulator
int main( int argc, char * argv[] )
{
// read model
osg::ref_ptr osg::Node model = osgDB::readNodeFile( cow.osg );
// create viewer #1
osg::ref_ptr osgViewer::Viewer viewer1 = new osgViewer::Viewer;
viewer1-setSceneData( model.get() );
viewer1-setUpViewInWindow( 10, 10, 400, 300 );
viewer1-setCameraManipulator( new osgGA::TrackballManipulator() );
viewer1-setThreadingModel( osgViewer::Viewer::SingleThreaded );
// viewer1-setThreadingModel( osgViewer::Viewer::ThreadPerContext );
// create viewer #2
osg::ref_ptr osgViewer::Viewer viewer2 = new osgViewer::Viewer;
viewer2-setSceneData( model.get() );
viewer2-setUpViewInWindow( 500, 10, 200, 300 );
viewer2-setCameraManipulator( new osgGA::TrackballManipulator() );
viewer2-setThreadingModel( osgViewer::Viewer::SingleThreaded );
// viewer2-setThreadingModel( osgViewer::Viewer::ThreadPerContext );
// render
while( ( viewer1-done() == false ) ( viewer2-done() == false ) )
{
viewer1-frame();
viewer2-frame();
}
return 0;
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New Improved DatabasePager, now with even more threading! Please take a taste today :-)
On Tue, Jun 3, 2008 at 4:48 PM, Robert Osfield [EMAIL PROTECTED] wrote: Could you do an svn update on the OSG and let know if things are no work fine at your end, It works, thanks. -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fwd: cmake 2.6 issue, latest svn head
Hello, Philip, any chance you could work that CMake 2.6 magic you did on OSG into the VPB CMakeLists.txt files? It has the same CMP0003 problem OSG had, and same symptoms on building (libs don't have an extension, so Visual C++ thinks they're .obj files). I've never built VPB before so it probably would be best to leave this to someone more familiar with the software. Also, I'm on vacation and away from my typical dev environment anyways. Honestly the changes I submitted to Robert to make OSG work on CMake 2.6.x were relatively minor, nothing magic about them. =) I've started making the changes to VPB's CMake files for CMake 2.6. I'm just using the diff from the commit of Philip's changes as a guide. I'll send the result in as soon as I have something that builds :-) J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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] OpenSceneGraph 2.4.1 stable release?? If/when/when/who
On Tue, Jun 3, 2008 at 3:04 PM, Paul Melis [EMAIL PROTECTED] wrote: I'd suggest OpenSceneGraph-2.4. As it is located under /branches, that should be clear enough. OK, OpenSceneGraph-2.4 it is then. I assume these are shell scripts? The ones I have are. Should we decide in advance that the release scripts are targeted at a Linux/Unix system? Should we support two sets (one for Linux, one for Windows) to support maintainers on Windows? Unix or Windows, rather than Linux or Windows ;-) There is always Cygwin if you we need to use shell scripts. Or perhaps CMake scripting itself would one way forward for making things cross platform. I'd suggest crossing the portable script bridge when we get to it. For starters unix could be assumed to be the main platform for maintainers. Right now do we have any volunteers wanting to do stable release maintenance form Windows? Do you mean the RSS feed? Or is there a separate mailing list? I was thinking about RSS feed, but I've never personally tried it yet... One thing about the feed that bugs me is that the messages don't contain newlines (the body tag contains a single pre tag containing the log message without newlines). Is this something that can be fixed? They're really hard to read in the current state. I have no clue about the status of the RSS feed side so can't comment about suitability of what we currently support or what we might amend to make things easier. One thing about subversion is that it's relatively easy to set up a local file-based repository containing some representative files to experiment with. Perhaps we don't need a test branch, but on the other hand testing on the actual infrastructure is probably a good idea. Testing out scripts on the actual infrastructure is useful too. I could create a branch/OpenSceneGraph-sandbox if desired. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New Improved DatabasePager, now with even more threading! Please take a taste today :-)
Hi Csaba,
Thanks for spotting the missing updateBlock(). I've now added this
and checked it in. I put the updateBlock() inside the if () {} code
block, but other than that is identical to your own change.
Must admit I hadn't spotted the problem, the downside of having a four
core machine...
Could you do an svn update on the OSG and let know if things are no
work fine at your end,
Cheers,
Robert.
On Tue, Jun 3, 2008 at 3:14 PM, Csaba Halász [EMAIL PROTECTED] wrote:
On Tue, May 27, 2008 at 12:08 PM, Tim Moore [EMAIL PROTECTED] wrote:
Indeed. I've made the necessary changes to FlightGear, and it seems to
be working fine.
Except for being a cpu hog.
Apparently, the pager thread is not blocked properly and continuously
spins. The fact that the queue is empty is confirmed by the debug
messages printed after the block call:
HANDLE_NON_HTTP 0: _pager-_requestList.size()= 0 to delete = 0
I have been trying to find the place where the blocking is
re-established when the queue goes empty, but could not find it. So I
added an updateBlock() call at the end of
DatabasePager::RequestQueue::takeFirst that seems to fix the issue.
Could have added the call within the if-block, but this has the
additional benefit of stopping runaway loops should somehow the pager
thread get woken up without work to do.
Index: DatabasePager.cpp
===
--- DatabasePager.cpp (revision 8398)
+++ DatabasePager.cpp (working copy)
@@ -273,6 +273,7 @@
databaseRequest = _requestList.front();
_requestList.erase(_requestList.begin());
}
+updateBlock();
}
I am not sure if I need an osg-submissions mail for this?
--
Cheers,
Csaba/Jester
___
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] Database Pager
Hi -- The DatabasePager was changed recently so that it has a thread, rather than is a thread. Check the archives for recent discussion regarding the DatabasePager. Serge Lages also derives a class from DatabasePager, so the discussion between he and Robert might be applicable to your issue. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ +1 303 859 9466 _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adrian Egli OpenSceneGraph (3D) Sent: Tuesday, June 03, 2008 9:37 AM To: OpenSceneGraph Users Subject: [osg-users] Database Pager Hi all, is there a concept how the new database pager is working. as i am using an extended version of the database pager in my application, i requested once for the osgDB::DatabasePager::prototype() method. i come just around rebuilding my application. there is no longer a database pager thread, means no longer extended from openthreads. how should i change the application, or should i change to default pager for avoiding in near future next code changes? regards adrian -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Database Pager
Look in the archives for posts with this subject line New Improved DatabasePager,now with even more threading! Please take a taste today :-). This thread contains the discussion I was referring to. -Paul _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Tuesday, June 03, 2008 10:08 AM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] Database Pager Hi -- The DatabasePager was changed recently so that it has a thread, rather than is a thread. Check the archives for recent discussion regarding the DatabasePager. Serge Lages also derives a class from DatabasePager, so the discussion between he and Robert might be applicable to your issue. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ +1 303 859 9466 _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adrian Egli OpenSceneGraph (3D) Sent: Tuesday, June 03, 2008 9:37 AM To: OpenSceneGraph Users Subject: [osg-users] Database Pager Hi all, is there a concept how the new database pager is working. as i am using an extended version of the database pager in my application, i requested once for the osgDB::DatabasePager::prototype() method. i come just around rebuilding my application. there is no longer a database pager thread, means no longer extended from openthreads. how should i change the application, or should i change to default pager for avoiding in near future next code changes? regards adrian -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Segfault in VTP, but looks like OSG
This sounds like something is quite broke at the OpenThreads level. Are you
able to run any of the OSG examples or applications?
-Paul
I'm having trouble with a segfault in VTP's glutsimple
application, but it looks like the problem traces back into
OSG. For reference, I'm using OSG 2.2.0 on Fedora 9, and VTP 080506.
Here's a backtrace:
ScopedLock
OpenThreads/ScopedLock:31
osg::Referenced::refosg/Referenced:128
osg::ref_ptrosg::MatrixTransform::operator= osg/ref_ptr:50
vtTransform NodeOSG.cpp:1223
...
The problem occurs when the osg::MatrixTransform* is assigned
to an osg::ref_ptr and in particular when the ref_ptr
assignment tries to lock the mutex. It appears that the mutex
protected member Referenced._refMutex._prvData is a null pointer.
Here's a modified piece of code from VTP replacing the
vtTransform constructor that results in a segfault:
vtTransform::vtTransform() : vtGroup(true), vtTransformBase() {
// Constructs a transform where
Referenced._refMutex._prvData is null
osg::MatrixTransform* pxform = new osg::MatrixTransform;
// segfaults on locking since _prvData is null
osg::ref_ptrMatrixTransform rpxform = pxform;
m_pTransform = pxform;
SetOsgGroup(m_pTransform);
}
Tracing a bit deeper, the problem seems to be somewhere
between the osg::MatrixTransform and osg::Transform
constructors, but I'm not sure how or where.
Inspecting Referenced._refMutex._prvData after the
osg::Transform constructor has completed,
Referenced._refMutex = 0x1cb8e70 and
Referenced._refMutex._prvData = 0x1cb8e90 (both valid pointers).
But, at the end of the osg::MatrixTransform constructor
Referenced._refMutex still has it's valid pointer to
0x1cb8e70 but now Referenced._refMutx._prvData is now 0x00 (null).
Anyone else encountered this? BTW, I tried OSG 2.4 and
experienced the same behavior.
Thanks,
Rick
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce
negraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Debugging example hangs in Cygwin and need some insight into cygwin_osgdb_osg.dll
Alberto Luaces wrote: yes, this is what I meant. To load a dynamic symbol you have first to open the DLL file containing it, and then load it explicitly before use (if you used RTLD_LAZY). The source code at DynamicLibrary.cpp shows this. This can explain why it hangs depending on the data file loaded. Good - glad I understand. I think we could search for the differences between the .osg plugin and the well-behaved others. The interesting thing is I have only been able (in Cygwin) to get it to process osg and build a .osg or .ive file. I have been unable to get it to do anything with .gif .bmp .jpg or others like that - I always get the Error no data loaded message and then it terminates cleanly so based on that I cannot swear it would perform cleanly with other type files - it may be as you say that since it never uses a file it quits cleanly but when it does use a file like .osg to .osg or osg to .ive it hangs. Can someone give me an example of osg to gif or jpg or gif to bmp or bmp to gif or something (proper syntax a must) that should work that I can use as a test. Thanks bk ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple Viewers, Multiple Scenes, Texture::setUnRefImageDataAfterApply()
Hello, This might sound naïve, but what about setting the texture2d image to null manually, after you no longer need it. (maybe it's not elegant but shouldn't it work?) Guy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alan Ott Sent: Tuesday, June 03, 2008 9:40 PM To: osg-users@lists.openscenegraph.org Subject: [osg-users] Multiple Viewers, Multiple Scenes, Texture::setUnRefImageDataAfterApply() I accidently just sent this to the old openscenegraph.net list address. If it shows up twice in your inbox, I apologize. Hello, I have somewhat of a weird situation. I have an application which uses a non-osg rendering system. In this application, I have my library which draws somewhere in the middle of the draw() phase of the external renderer. I actually draw twice during the external renderer's draw(), because I draw to two different parts of the screen, and because the application must draw over the top of my OSG stuff. It goes like this: external renderer draws some stuff my first osgViewer::Viewer draws some stuff external renderer draws more stuff my second osgViewer::Viewer draws some more stuff external renderer draws final stuff The reason it's like this is because the external renderer needs to draw over the top of my 3D image, and the two Viewers are drawing separate scenes. I'm doing this using two osgViewer::Viewer objects. Each OSG Viewer is unaware of the other. This setup appears to be working fine. THE PROBLEM The problem is that I have some rather large textures, and would like to use Texture::setUnRefImageDataAfterApply() to remove texture image data after it's been pushed to the scene. This works well if I only have one osgViewer::Viewer instance, but when I have two Viewers, Texture2D won't ever free the Image data because Texture::areAllTextureObjectsLoaded() will return false because the textures have not been loaded to _both_ Viewer's contexts. The reality is that in my application, they _never_will_ be loaded to both Viewer's contexts because the two viewers contain completely separate scenes (and thus textures). I can't figure out a good way to make Texture2D unref the Image. Does anyone have any ideas? This all came about because I'm in the process of upgrading my software to use OSG 2.4 from 1.0 (Yeah, it's been a while...). In OSG 2.4 (and also in 2.2) the application seems to require almost _four_times_ the system memory to load the same textures as it did in version 1.0. Has anyone else run into this? I would like to make setUnRefImageDataAfterApply() work ideally, but I'd also be happy with the OSG 1.0 amount of ram usage. A solution to either would be very much appreciated. Thank you very much, and thank you for your hard work on OSG. Alan. ___ 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
