Re: [osg-users] osgText::Text character spacing
Hi Thorsten, On Mon, May 9, 2011 at 6:41 PM, Thorsten Brehm bre...@gmail.com wrote: Oh, of course, that's our main font: http://www.gitorious.org/fg/fgdata/blobs/raw/958c11a1b8e67c24035c19d2ef75aeeec387c58b/Fonts/Helvetica.txf Plenty more txf fonts available here: http://www.gitorious.org/fg/fgdata/trees/master/Fonts Thanks for the pointer, using the Helvetic.txf I've recreated the problem by running osgtext3d --2d -f Helvetica.txt, this co-opting the osgtext3D example to render some text in 2D, but it does nicely demostrate that the both the spacing and the sizing of the text is wrong. If you run osgtext3D --2d it'll use ariel.ttf as the font and it's able to show how the new osgText support can properly place both the 3D and the 2D text in exactly the same place, this was broken previous to the changes to osgText, but alas this improvements have obviously not been properly handling in the txf plugin. I'll look to fixing this today. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgText::Text character spacing
Hi Thorsten, I have tracked down the problem to the txf plugin not setting the width and height of the glyph, adding this addressed the sizing/spacing problems I saw when running the osgtext3D --2d --no-3d -f Helvetica.txf test. My fix is now checked into svn/trunk. Could you please test svn/trunk and let me know whether this addresses the problems you've been seeing. Thanks, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to know when paged scene is loaded
HI Lars, On Mon, May 9, 2011 at 3:17 PM, Lars Ivar Haave lars.ivar.ha...@kongsberg.com wrote: I would like to know if there is any way to get a callback or something when a paged scene is finished loading. My scene (terrain) is paged from disk and when i move my camera it will take some time to page in all the geometry and so on. What would be the best way to check when all geometry are finished loading ? I know there are some kind of queue system on what files to load when working with paged files. Could i for example check that, and when the queue is empty, i could assume that everything is loaded ? Or is there already some mechanism in osg for this ? If someone could point me in the right direction, i would be very happy! :) DatabasePager::getRequestsInProgress() returns true when there are still database requests being served. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using osg without output window
Hi Dennis, For a pure physics sim I wouldn't have thought you'd need any viewer at all. You'd just need to use a UpdateVisitor and your own updating of the FrameStamp to signal the new frames. You will need to the updates from the physics to update the scene graph, I'm not familiar with osgNV+PhysX combination so can't comment how this would be done, or what is already provided for you. One would typically implement a pull mechanism from the scene graph where an update callback gets the data from the physics simulation, or a push mechanism where once per frame you apply all the data from the physics simulation to the scene graph in one go. Robert. On Mon, May 9, 2011 at 4:20 PM, Dennis Loeben dennis.loe...@gmx.net wrote: Hi, I'm using osg in combination with osgNV+PhysX to simulate physical objects. This works fine. Now I want to suppress the visual rendering of the scene and use only the scenegraph system of osg to simulate the physics without a graphic window (standalone application). I tried to call the necessary traversals directly but without the renderingTraversal(): Code: viewer.advance(); viewer.eventTraversal(); viewer.updateTraversal(); It seems that updateTraversal does not synchronise the position of osg objects with the position of the physical objects. Is there something missing? Or does anybody know a better solution to avoid a graphical window but provide the backend simulation of osg+osgNV? Thank you! Cheers, Dennis[/code] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39210#39210 ___ 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] RecordCameraPathHandler where is the saved_animation.path file?
Hi Gianni, On Tue, May 10, 2011 at 4:02 PM, Gianni Ambrosio ga...@vi-grade.com wrote: robertosfield wrote: I do plan to add support for this in the 2.9.x dev series using the ffmpeg plugin to do the video encoding, but I don't have any dates for the work. Is there anything new about this topic? No news yet sorry. Have plenty of items on my TODO list infront of video encoding and haven't put in any plans to develop it soon. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [vpb] vpbmaster and aspect ratio 2
Hi Ido, I'm rather rusty on VirtualPlanetBuilder code since it's a while since I was working on it. From your description it sounds like I made some assumptions about the likely aspect ratio of the input data and how to subdivide it. VPB does aim for a quad tree decomposition of the extents, and in the case you are describing while an aspect ratio that doesn't neatly fit into a straight half division of a dimension what would be required is a level 0 or level 1 division that isn't a quad tree, and starts the quad tree subdivision below this initial division to handle the unusual aspect ratio. Feel free to dive into the code and see how you might set this up, if you get it working post the changes to osg-submissions so I can test it. Alternatively post a sample source dataset that illustrates the problem so that others might be able to pitch in a help address the issue. Cheers, Robert. On Wed, May 11, 2011 at 1:59 PM, Ido Schwartzman paz...@bezeqint.net wrote: Hi, I've come across a problem when building databases with sources that have aspect ratios which are bigger than 2 when using vpbmaster - it seems to work fine with osgdem, but not with vpbmaster. I believe the problem is that several DataSet methods assume each tile is divided by two at at the most, while long and narrow (or wide and short) sources can actually be divided, at level 1, into three or more tiles. This is evident in DataSet::createNewDestinationGraph, where the j_lower value is calculated by right-shifting only. That is also why (I think...) it only affects vpbmaster builds - that piece of code is inside the if (getGenerateSubtile()) clause - that's why my osgdem builds work fine for the same dataset (no entry into that block). So...I would be very happy to try and fix it as my first OSG/VPB contribution, but since I still don't know enough about the code, I'm afraid I'll wrack something. Looks like a more complex calculation inside the if (getGenerateSubtile()) block, which uses _C1 and _R1 would do the trick, but might not be enough. Thoughts anyone? Bye for now, Ido Schwartzman -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39270#39270 ___ 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] Fluctuations in frame rate for static scene
Hi Kris, On Wed, May 11, 2011 at 11:10 PM, Kris Dale cdd0...@uah.edu wrote: I am seeing the fluctuations in osgviewer as well, but anything I run that's strictly OpenGL is steady. Is this indicative of something being up with my OSG build perhaps? I'm building against release libraries, I've already double checked that I think we have a case of not seeing the wood from the trees.. Running benchmarks that are very simply without vsync on will really tell you very little about anything, small changes in timings per frames can make huge difference to results. Go measure the flucuation in absolute time rather than frame rate, then you'll realize you are fretting over such a tiny about of time that it's a meanignless waste of your time. Small changes in threading or cache coherency can easily swap small time values. It does change the fact tht the results are meanignless in the greater scheme of things. Please benchmark proper amongst of geometry, state and nodes, something that can be measured in milliseconds rather than micro seconds. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] how to create a fade effect?
Hi, Gianluca NataleYou can use simple 2pass osgFX effect with 1st pass writing only depth, and second pass writing only color with correct alpha value set to material and depth func set to equal. There could be problems with multiple layers of transparency in fading object.Cheers, Sergey.07.05.2011, 18:58, "Gianluca Natale" nat...@europe.altair.com:Hi everybody, I'm developing an osg based application that needs to fade some objects out of the scene when it is destroyed. So, instead of a sudden disappearing, I would like to make it slowly disappear from the screen, let's say for example in 1 second. I think that I could: 1) draw the final image (object completely removed) in a separate pixel buffer, then get that image and create a texture with it; 2) copy the content of the front buffer (the initial image) in another texture; 3) create a temporary scenegraph made only by a geode containing 2 drawables, each of which draws a rectangle with the same size of the screen. And attach the texture created at step 1 in one drawable, and the texture created at step 2 in the other one. 4) finally draw that simple geode in n steps, using at each step a different blending factor for plane 1 (copy of the front buffer) and 2 (final image). I mean, starting from alpha1 = 1.0 and alpha2 = 0.0 at step 1, till alpha1 = 0.0 and alpha2 = 1.0 at step n. It should give me the effect I want. Or not? Do you think it is doable? Do you think it might be also fast? Finally, do you have some example in osg about writing to a texture, copying the front buffer into a texture, etc...? I know that for sure there are things already implemented there. Actually I'm also quite sure that osg is so powerful that I could accomplish what I want with no more the 30-40 lines of code. But I don't know how to do that quickly. Thanks in advance. Gianluca Natale ___osg-users mailing listosg-users@lists.openscenegraph.orghttp://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] problems building osg-2.9.14, dicom plugin won't compile
Hi all,
In our CentOS environment I can build osg-2.9.10 just fine with the command:
cmake \
-D CMAKE_INSTALL_PREFIX=$DIR/osg-$v/installed \
-D INVENTOR_INCLUDE_DIR=`coin-config --prefix`/include \
-D INVENTOR_LIBRARY=`coin-config --prefix`/lib/libCoin.so \
-D OSG_USE_AGGRESSIVE_WARNINGS=OFF \
-D DCMTK_DIR=$HEVROOT/external/dcmtk/dcmtk-3.x \
../OpenSceneGraph
make install
When trying to build osg-2.9.14 using the same cmake command (and after
adding a trailing space to include/osg/GraphicsCostEstimator to get rid of a
lot of annoying compiler warnings) I get:
[ 83%] Building CXX object
src/osgPlugins/dicom/CMakeFiles/osgdb_dicom.dir/ReaderWriterDICOM.o
/usr/local/HEV-beta/external/osg/osg-2.9.14/OpenSceneGraph/include/osg/View:98:
warning: ‘struct osg::View::Slave’ has virtual functions but non-virtual
destructor
/usr/local/HEV-beta/external/osg/osg-2.9.14/OpenSceneGraph/src/osgPlugins/dicom/ReaderWriterDICOM.cpp:
In member function ‘virtual osgDB::ReaderWriter::ReadResult
ReaderWriterDICOM::readImage(const std::string, const osgDB::Options*) const’:
/usr/local/HEV-beta/external/osg/osg-2.9.14/OpenSceneGraph/src/osgPlugins/dicom/ReaderWriterDICOM.cpp:287:
error: expected `)' before ‘{’ token
/usr/local/HEV-beta/external/osg/osg-2.9.14/OpenSceneGraph/src/osgPlugins/dicom/ReaderWriterDICOM.cpp:298:
error: ‘Images’ was not declared in this scope
/usr/local/HEV-beta/external/osg/osg-2.9.14/OpenSceneGraph/src/osgPlugins/dicom/ReaderWriterDICOM.cpp:298:
error: expected `;' before ‘images’
/usr/local/HEV-beta/external/osg/osg-2.9.14/OpenSceneGraph/src/osgPlugins/dicom/ReaderWriterDICOM.cpp:304:
error: ‘images’ was not declared in this scope
/usr/local/HEV-beta/external/osg/osg-2.9.14/OpenSceneGraph/src/osgPlugins/dicom/ReaderWriterDICOM.cpp:308:
error: ‘images’ was not declared in this scope
/usr/local/HEV-beta/external/osg/osg-2.9.14/OpenSceneGraph/src/osgPlugins/dicom/ReaderWriterDICOM.cpp:310:
error: ‘images’ was not declared in this scope
/usr/local/HEV-beta/external/osg/osg-2.9.14/OpenSceneGraph/src/osgPlugins/dicom/ReaderWriterDICOM.cpp:316:
error: ‘Images’ is not a class or namespace
/usr/local/HEV-beta/external/osg/osg-2.9.14/OpenSceneGraph/src/osgPlugins/dicom/ReaderWriterDICOM.cpp:316:
error: expected `;' before ‘itr’
/usr/local/HEV-beta/external/osg/osg-2.9.14/OpenSceneGraph/src/osgPlugins/dicom/ReaderWriterDICOM.cpp:317:
error: name lookup of ‘itr’ changed for new ISO ‘for’ scoping
/usr/local/HEV-beta/external/osg/osg-2.9.14/OpenSceneGraph/src/osgPlugins/dicom/ReaderWriterDICOM.cpp:299:
error: using obsolete binding at ‘itr’
/usr/local/HEV-beta/external/osg/osg-2.9.14/OpenSceneGraph/src/osgPlugins/dicom/ReaderWriterDICOM.cpp:317:
error: ‘images’ was not declared in this scope
/usr/local/HEV-beta/external/osg/osg-2.9.14/OpenSceneGraph/src/osgPlugins/dicom/ReaderWriterDICOM.cpp:320:
error: ‘struct std::basic_stringchar, std::char_traitschar,
std::allocatorchar ’ has no member named ‘get’
make[2]: ***
[src/osgPlugins/dicom/CMakeFiles/osgdb_dicom.dir/ReaderWriterDICOM.o] Error 1
make[1]: *** [src/osgPlugins/dicom/CMakeFiles/osgdb_dicom.dir/all] Error 2
make: *** [all] Error 2
I'm using dcmtk-3.6 in each case.
Any ideas what I might be doing wrong?
I'm happy to include extra details, but at this point I'm not sure what's
relevant to the problem.
Thanks,
John___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] save a movie
Hi, Gianni In linux you can use glc for grabbing video from opengl render in realtime. osgscreencapture-like screen capture takes a lot of time each frame and would be slow as hell in good resolutions (you can speedup it to some point by writing to drive created in ram). 11.05.2011, 12:17, Gianni Ambrosio ga...@vi-grade.com: Hi All, I know this topic have been already discussed in the past but I didn't find clear solution. Basically I need to save a movie of what is shown in an osgViewer embedded in a Qt widget. I gave a rough look at the osgscreencapture example. Is the recommended way to implement what I need? Regards Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39265#39265 ___ 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 2.8.5 stable release discussion
On Wed, May 11, 2011 at 7:55 PM, Paul Martz pma...@skew-matrix.com wrote: Would this be an improvement that would better be separated into a distinct option string like OutputRelativeTextures or something like that? Yes, that's the way I'm leaning now. Your patch changes behavior, and would break any apps or utilities that depend on the current behavior. I'd be a lot more comfortable with this if it were a feature addition rather than a change to existing functionality. Do you think OutputRelativeTextures is a good name for it? If so, I can rewrite the submission locally (but you'll need to test it). -Paul It makes sense to me, at least. Thanks! Okay, this is now in. Please test. I've coded it so that if OutputRelativeTextures and OutputTextureFiles are both present, OutputRelativeTextures will take precedent. -Paul Thanks! I can confirm that this works properly! Noticed some other minor issues when testing this that probably should block 2.8.5 for now - will send to osg-submissions. Ryan -- Ryan Pavlik HCI Graduate Student Virtual Reality Applications Center Iowa State University rpav...@iastate.edu http://academic.cleardefinition.com Internal VRAC/HCI Site: http://tinyurl.com/rpavlik ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problems building osg-2.9.14, dicom plugin won't compile
Hi John, Is you version of CentOS and old or recent one? 2011/5/12 John Kelso ke...@nist.gov: When trying to build osg-2.9.14 using the same cmake command (and after adding a trailing space to include/osg/GraphicsCostEstimator to get rid of a lot of annoying compiler warnings) I get: Could you pass on the warnings. I'm not getting any warnings on my Kubuntu system. Also you can explain exactly why and where you added a trailing space to GraphicsCostEstimator, ideally posting the modified file as well. [ 83%] Building CXX object src/osgPlugins/dicom/CMakeFiles/osgdb_dicom.dir/ReaderWriterDICOM.o /usr/local/HEV-beta/external/osg/osg-2.9.14/OpenSceneGraph/include/osg/View:98: warning: ‘struct osg::View::Slave’ has virtual functions but non-virtual destructor /usr/local/HEV-beta/external/osg/osg-2.9.14/OpenSceneGraph/src/osgPlugins/dicom/ReaderWriterDICOM.cpp: In member function ‘virtual osgDB::ReaderWriter::ReadResult ReaderWriterDICOM::readImage(const std::string, const osgDB::Options*) const’: /usr/local/HEV-beta/external/osg/osg-2.9.14/OpenSceneGraph/src/osgPlugins/dicom/ReaderWriterDICOM.cp Curious. I'm build against DCMTK 3.6.1 and OSG svn/trunk without any problems. What version of g++ do you have? On my system I have: g++ --version g++ (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2 This is with Kubunut 11.04. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problems building osg-2.9.14, dicom plugin won't compile
Hi Robert, Please see below... On Thu, 12 May 2011, Robert Osfield wrote: Hi John, Is you version of CentOS and old or recent one? As far as I know it's a fairly new one. If I type /proc/version I get this: Linux version 2.6.18-238.9.1.el5 (mockbu...@builder10.centos.org) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-50)) #1 SMP Tue Apr 12 18:10:13 EDT 2011 2011/5/12 John Kelso ke...@nist.gov: When trying to build osg-2.9.14 using the same cmake command (and after adding a trailing space to include/osg/GraphicsCostEstimator to get rid of a lot of annoying compiler warnings) I get: Could you pass on the warnings. I'm not getting any warnings on my Kubuntu system. Also you can explain exactly why and where you added a trailing space to GraphicsCostEstimator, ideally posting the modified file as well. I just finished rebuilding it with warnings enabled, and compressed typescript and the CMakeCache.txt files are attached. I hope that's not a no-no on this list. All I did to GraphicsCostEstimator was to add a newline at the end of the last line. My mistake- it wasn't a space I added but a newline. [ 83%] Building CXX object src/osgPlugins/dicom/CMakeFiles/osgdb_dicom.dir/ReaderWriterDICOM.o /usr/local/HEV-beta/external/osg/osg-2.9.14/OpenSceneGraph/include/osg/View:98: warning: ‘struct osg::View::Slave’ has virtual functions but non-virtual destructor /usr/local/HEV-beta/external/osg/osg-2.9.14/OpenSceneGraph/src/osgPlugins/dicom/ReaderWriterDICOM.cpp: In member function ‘virtual osgDB::ReaderWriter::ReadResult ReaderWriterDICOM::readImage(const std::string, const osgDB::Options*) const’: /usr/local/HEV-beta/external/osg/osg-2.9.14/OpenSceneGraph/src/osgPlugins/dicom/ReaderWriterDICOM.cp Curious. I'm build against DCMTK 3.6.1 and OSG svn/trunk without any problems. You got dcmtk 3.6.1? The latest I saw to download was 3.6.0. It's probably not important... I hope. I did need to use a newer version of cmake than came with CentOS. I installed a private copy of cmake 2.8.4 which I used to build OSG. As a test I used this same version to build 2.9.10 and it worked fine, so I don't think cmake's an issue. What version of g++ do you have? On my system I have: g++ --version g++ (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2 gcc-version: gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-50) Thanks again, John typescript.gz Description: GNU Zip compressed data CMakeCache.txt.gz Description: GNU Zip compressed data ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problems building osg-2.9.14, dicom plugin won't compile
Hi John, Thanks for the clarification and warning output. I've added a newline to the end of GraphicsCostEstimator. I can only guess that recent versions of gcc don't have problems with the lack of newline. Your gcc seems rather out of date by comparison to what I've been using for a while, this shouldn't cause major problems though, the more recent compilers tend to be stricter and compile less code rather than more, so typically if compiles under gcc 4.5.1 it'll compile in older versions as well. I have also added a virtual destructor to View::Slave. The DCMTK build issue looks to me like a missing ) from a line in the USE_ITK block in the ReaderWriterDICOM.cpp. I haven't tested the ITK path recently so this is probably why I hadn't spotted this regression. I will install ITK and tweak the dicom/CMakeLists.txt so it doesn't compile with DCMTK that I have installed. I will have to do this tweak as the dicom plugin will always use DCTMK over ITK if DCMTK is found. This fact points to CMake not finding your local DCMTK install, so run ccmake . in the OpenSceneGraph/ directory and have a look at the variable settings, it might be that DCMTK has installed itself in an odd place that our find script hasn't spotted automatically. I have check in the two warning fixes and the compile fix in the ReaderWriterDICOM.cpp. Could you let me know how you get on. Robert. On Thu, May 12, 2011 at 7:28 PM, John Kelso ke...@nist.gov wrote: Hi Robert, Please see below... On Thu, 12 May 2011, Robert Osfield wrote: Hi John, Is you version of CentOS and old or recent one? As far as I know it's a fairly new one. If I type /proc/version I get this: Linux version 2.6.18-238.9.1.el5 (mockbu...@builder10.centos.org) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-50)) #1 SMP Tue Apr 12 18:10:13 EDT 2011 2011/5/12 John Kelso ke...@nist.gov: When trying to build osg-2.9.14 using the same cmake command (and after adding a trailing space to include/osg/GraphicsCostEstimator to get rid of a lot of annoying compiler warnings) I get: Could you pass on the warnings. I'm not getting any warnings on my Kubuntu system. Also you can explain exactly why and where you added a trailing space to GraphicsCostEstimator, ideally posting the modified file as well. I just finished rebuilding it with warnings enabled, and compressed typescript and the CMakeCache.txt files are attached. I hope that's not a no-no on this list. All I did to GraphicsCostEstimator was to add a newline at the end of the last line. My mistake- it wasn't a space I added but a newline. [ 83%] Building CXX object src/osgPlugins/dicom/CMakeFiles/osgdb_dicom.dir/ReaderWriterDICOM.o /usr/local/HEV-beta/external/osg/osg-2.9.14/OpenSceneGraph/include/osg/View:98: warning: ‘struct osg::View::Slave’ has virtual functions but non-virtual destructor /usr/local/HEV-beta/external/osg/osg-2.9.14/OpenSceneGraph/src/osgPlugins/dicom/ReaderWriterDICOM.cpp: In member function ‘virtual osgDB::ReaderWriter::ReadResult ReaderWriterDICOM::readImage(const std::string, const osgDB::Options*) const’: /usr/local/HEV-beta/external/osg/osg-2.9.14/OpenSceneGraph/src/osgPlugins/dicom/ReaderWriterDICOM.cp Curious. I'm build against DCMTK 3.6.1 and OSG svn/trunk without any problems. You got dcmtk 3.6.1? The latest I saw to download was 3.6.0. It's probably not important... I hope. I did need to use a newer version of cmake than came with CentOS. I installed a private copy of cmake 2.8.4 which I used to build OSG. As a test I used this same version to build 2.9.10 and it worked fine, so I don't think cmake's an issue. What version of g++ do you have? On my system I have: g++ --version g++ (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2 gcc-version: gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-50) Thanks again, John ___ 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] Intersection testing in a separate thread
Hi, I have an OSG-based simulation that I'm considering retrofitting to decouple the actual simulation rate from the render frame rate. It's not viewer-based. A simplified example would be and application that listens for a network message identifying two world positions, performs and intersection test, and returns a response, while rendering/updating the scene. Currently this happens serially, but I want to put the network listener and intersection testing on a separate thread. Obviously the shared data here is (a portion of) the scenegraph, which may be modified by the render/update thread. I want the network/query thread to be able to respond as quickly as possible, and not depend on how fast the scene can be drawn, as it is currently. Does anyone have any advice/experience/examples for how to best approach this kind problem? Is it even feasible? Thanks, Craig ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Intersection testing in a separate thread
Craig, We've done something similar to what you want to do but in a separate process rather than a separate thread. We have done it in an asynchronous thread as well. The reason we chose to go with a process is that it allows us to run it on a remote machine away from the rendering process if need be. The process has a listening thread that receives two world positions (e.g. line of sight from ownship to target) over the network. Upon reception, it computes the intersection with a terrain database (i.e. node read into a scenegraph) and returns the closest intersection distance back over the network to the other process that made the request via a sending thread. Bottom line is that it can be done. It basically amounts to having asynchronous traversal of the same scenegraph, one for rendering traversal and the other for intersections. These traversals can either be done in different threads or different processes. -Shayne -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Craig S. Bosma Sent: Thursday, May 12, 2011 1:14 PM To: OpenSceneGraph Users Subject: [osg-users] Intersection testing in a separate thread Hi, I have an OSG-based simulation that I'm considering retrofitting to decouple the actual simulation rate from the render frame rate. It's not viewer-based. A simplified example would be and application that listens for a network message identifying two world positions, performs and intersection test, and returns a response, while rendering/updating the scene. Currently this happens serially, but I want to put the network listener and intersection testing on a separate thread. Obviously the shared data here is (a portion of) the scenegraph, which may be modified by the render/update thread. I want the network/query thread to be able to respond as quickly as possible, and not depend on how fast the scene can be drawn, as it is currently. Does anyone have any advice/experience/examples for how to best approach this kind problem? Is it even feasible? Thanks, Craig ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Intersection testing in a separate thread
Hi Shayne, Craig, Bottom line is that it can be done. It basically amounts to having asynchronous traversal of the same scenegraph, one for rendering traversal and the other for intersections. These traversals can either be done in different threads or different processes. But the case of a different thread vs a different process is not the same. In his case, there will be (optimally) one copy of the scene graph, and both the rendering and the intersection thread will access it. He will need a mutex which would be held by the rendering thread while it's in the update phase, and by the intersection thread while it does an intersection. In your case, you have two copies of the scene graph, so there are no threading issues. (how did you update the scene graph between processes?) But that doesn't mean it can't be done, just that it's not quite as simple as that. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Intersection testing in a separate thread
J-S, Yes, a great point I failed to bring up about the mutex. Thanks for mentioning that. We did have to do that to protect the shared resource when we used threading. For our stuff, one process (out-the-window) does the usual traversal (via viewer.frame) while the other sits idle until a request comes in for either HAT/HOT or LOS. Once a request comes in, it just computes the intersection with the terrain via the osgSim class and sends the scalar result back. Both processes load the same PagedLOD terrain node but they're using completely different graphs. We only check for intersection with terrain and nothing else... -Shayne -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien Guay Sent: Thursday, May 12, 2011 2:37 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Intersection testing in a separate thread Hi Shayne, Craig, Bottom line is that it can be done. It basically amounts to having asynchronous traversal of the same scenegraph, one for rendering traversal and the other for intersections. These traversals can either be done in different threads or different processes. But the case of a different thread vs a different process is not the same. In his case, there will be (optimally) one copy of the scene graph, and both the rendering and the intersection thread will access it. He will need a mutex which would be held by the rendering thread while it's in the update phase, and by the intersection thread while it does an intersection. In your case, you have two copies of the scene graph, so there are no threading issues. (how did you update the scene graph between processes?) But that doesn't mean it can't be done, just that it's not quite as simple as that. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ 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
