Re: [osg-users] Resolved! Re: Text color not what I'm expecting
Hi,
Cory Riddell wrote:
I'm not sure if this is correct, but it seems that my text was picking
up a material setting from some parent node. It was rendering the text
with the diffuse color from the material.
I ended up turning GL_LIGHTING off for my osgText::Text node and now the
text is being rendered with the color I was expecting.
One question, is the GL_LIGHTING bit the correct setting to turn off, or
is there a more correct way to turn of material usage for a drawable?
I think so, I also use it when I absolutely want the colour I assigned
to end up on the screen.
jp
Thanks,
cory
Cory Riddell wrote:
1. Fixed the typo in the subject. (now - not)
2. I discovered that if I remove the material setting at the geode
level, the material set in my osgText::Text instance takes effect.
I'm still confused.
Cory
Cory Riddell wrote:
Can somebody please take a look at the attached osg file. If you open it
with osgviewer, you will see the alphabet rendered at the bottom of the
screen (might be small) in white. I'm trying to figure out why the text
isn't black. I've set a material on my osgText::Text instance but it
seems to be ignored.
To find the text drawable, search for ABCDEF. The material looks like:
Material {
UniqueID Material_106
ColorMode AMBIENT
ambientColor 0.2 0.2 0.2 1
diffuseColor FRONT 0 0 0 1
diffuseColor BACK 0.8 0.8 0.8 1
specularColor FRONT 1 1 1 1
specularColor BACK 0 0 0 1
emissionColor 0 0 0 1
shininess FRONT 120
shininess BACK 0
}
Thanks.
Cory
___
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
--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean. MailScanner thanks Transtec Computers for their support.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] wxPython and CullVisitor nan on Mac
Oh, yes. The exact same Python extension works correctly on both systems in the GLUT environment. On 2009-10-08, Randolph Fritz rfritz...@gmail.com wrote: On 2009-10-07, Randolph Fritz rfritz...@gmail.com wrote: More details at http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2009-June/029500.html I have now confirmed that, just as Mike Wozniewski found in June, this problem occurs on Macintosh (MacBook Pro, Mac OS 10.5.8) but not on Linux (Ubuntu 8.04 LTS). I badly need it working on Windows or Mac, and would really rather have it working on Mac. Dare I hope that this problem has been debugged in the 2.8 trunk? (I have a few more tests to run if it hasn't already been fixed. Experimenting with osgviewerWX would probably be a good thing to try, but it's a nuisance to build against the MacPorts OSG.) -- Randolph Fritz design machine group, architecture department, university of washington rfr...@u.washington.edu -or- rfritz...@gmail.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] Shader from Rendermonkey : Collada plugin
Hi, i'm sorry the second question in the post above was my typing error in the project properties (i have written .dll instead .lib). So i can compile plugin DAE correctly with openscenegraph 2.8.2. But i get the same warning message of 2.8.0 : unsupported effect profile profile_GLSL. when i load a dae file (created with rendermonkey) in osgviewer. Thank you! Cheers, Andrea -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=18073#18073 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] Shader from Rendermonkey : Collada plugin
Hi Andrea, only effects with profile_COMMON are currently supported in the Collada reader/writer. The profile_GLSL will be ignored and will result in the warning you mentioned. Heinrich Fink did implement GLSL support in an older OpenSceneGraph version, but those modifications were never merged with the current Collada loader in the SVN. His source code was later modified by AMD/ATI to improve the support specifically aimed at handling RenderMonkey output. The source code for their modification is available at their website. I've looked at merging their changes with the current Collada loader, but the source code has drifted apart too far for a quick merge. kind regards, Roland Smeenk -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=18074#18074 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Databasepager + multiple views + different camera positions = memory leak?
Hello everyone, We are having the exact same problem at our company for quite some time (currently on osg 2.8.0 via Delta3D and using TerraPage terrains). I have verified that viewing the terrain in the osgViewer works fine, but in our app, which also uses multiple cameras, the memory-keeps-growing-until-crash issue occurs when the cameras are not looking at the exact same thing (have the same projection and view matrices with the same LOD scale). The more different they are, the easier it is to trigger the issue, it seems. What we did to work around the issue, is to make sure that no two cameras in the graph render the same PagedLOD node. That is, we load the terrain multiple times using osgDB::readNodeFile and point each camera to each instance. I hope this helps on shedding some light on what is going on. Additional info: Delta3D design currently limits OSG to single-threaded mode. I am on WindowsXP, using an NVidia card, not that I think that makes a difference. I also seem to recall, that the active lod node list in the pager starts to grow rapidly when I put the second camera into the scene graph at runtime. Cheers, Michael -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=18075#18075 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] GLU requirement now optional
Hi All, As part of the work on porting the OpenSceneGraph to OpenGL ES-2.0 I have had to loosen the OpenSceneGraph's reliance on GLU. Yesterday I implemented a Cmake and associated #define of OSG_GLU_AVAILABLE. If you don't have GLU installed when you first run cmake it'll automatically set this to OFF, and it'll also comment out the new #define OSG_GLU_AVAILABLE from include/osg/Config. Within the source code the new #define OSG_GLU_AVAILABLE is used to protect all GLU calls, with a fallback of simply issuing of a feature unsupported message as console warning when those now optional code paths aren't available. The OSG can actually be used pretty easily without touching the GLU dependent features, but it does require you to prepare you scene graphs so that don't require image resizing, or rely on mipmap generation that GLU provides. You'll also have to avoid using the glu dependent tessellation codes in osgUtil::Tessellator or the lwo and dw plugins with both use the glu tessellation. If you do have GLU installed on your system then the changes I checked into svn/trunk yesterday evening shouldn't effect you in any way. If you do wish to test out a GLU free existence then even on these GLU capable systems you can switch off the need for GLU by running ccmake . or CMakeSetup and setting the OSG_GLU_AVAILABLE to OFF (it's an advanced option so you'll need to press 't' to toggle on the advanced options.) For systems without GLU libs and headers installed Cmake will now automatically set OSG_GLU_AVAILABLE to OFF and not both to compile or link against GLU. It would be worth being mindful of moving to a new system and forgetting to install GLU if you actually need it as right now the OSG build system won't shout at you that you don't have GLU, it'll just silently get on with compiling without GLU. What you will notice is that if you require GLU the features highlighted above won't work, and you might get erroneous tessellations or white textures where you'd expect valid ones. The with GLU and without GLU versions of the OSG are binary compatible (there are no interface changes between the two) so just compiling the OSG against GLU will allow you app to work without a need to recompile your application. In the longer term I'd like to get to a point where we replace the current GLU usage with equivalent functions, this is not a small task though, so it's not one I'll tackle right away. If you are curious about what needs replacing just do a recursive grep through the OSG sources for OSG_GLU_AVAILABLE. Assistance in developing/integrating these equivalent functions would be greatly appreciated :-) Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Restoring a Viewer's MatrixManipulator
Greetings, all. I've been a lightweight user of OSG for some time now, and have a fair understanding on how the basic components fit together. There's something I'm missing, though, in my current quest. I'm adding XML persistence to my OSG objects. In general, I wrap OSG objects in my own objects, and it's those objects that will be doing the persisting. For the most part, all is well. My Viewer object, though, is having trouble with restoring its camera. I've succeeded in restoring the camera to its home position, but have not been able to restore its current position (getMatrix(), setByMatrix()). My Viewer object uses either a MatrixManipulator or a Camera, and my XML implementation persists the values of those correctly. With respect to the MatrixManipulator, I'm doing (paraphrased): myViewerObject - its osgViewer -setCameraManipulator( a restored myMaxtrixManipulator - its osgMatrixManipulator); // I expect this to do the whole job, but... myMatrixManipulator - its osgMatrixManipulator = myViewerObject - its osgViewer -getCameraManipulator(); // setCameraManipulator seems to create a copy, and I want to be wrapping the current one. // Since the above seems to restore just the home position and not the current, I've tried adding: Matrixd testMatrix = myViewer - its osgViewer - getCameraManipulator() -getMatrix(); // testMatrix is correct. myViewerObject - its osgViewer -getCameraManipulator() -setByMatrix( testMatrix); // These last seem redundant (and aren't succeeding), but I'm trying things where things seem broken. I've disabled all home() calls, and yet, after loading a persisted MatrixManipulator, I see my scene from the home position, not the saved position. I imagine I have a flawed mental model of some facet of this. Can someone point me in the right direction? Thanks, in advance, Phil Philip A. Tessier ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New OpenGL texture object and buffer object pool support
Hi Robert, I updated to the svn trunk today, and i can notice a crash when quitting my application. To be sure it was with the new texture manager i defined USE_NEW_TEXTURE_POOL to 0 and then to 1. I dont have yet found the problem, but i guess it's linked with my texture manager, i own some static that reference texture. The segfault appear when quitting Program received signal SIGSEGV, Segmentation fault. #0 0xb6ef7ddf in ?? () from /lib/libc.so.6 #1 0xb5dddc40 in ?? () from //usr//lib/opengl/nvidia/lib/libGLcore.so.1 #2 0xb5dddc40 in ?? () from //usr//lib/opengl/nvidia/lib/libGLcore.so.1 #3 0xb54f2008 in ?? () #4 0xb54f2008 in ?? () #5 0xb6193d60 in ?? () from //usr//lib/opengl/nvidia/lib/libGLcore.so.1 #6 0xb6fd0bcb in ?? () from /lib/libc.so.6 #7 0xb6fd26e8 in ?? () from /lib/libc.so.6 #8 0xb6fcf469 in ?? () from /lib/libc.so.6 #9 0xb6fcf442 in ?? () from /lib/libc.so.6 #10 0xbfc68254 in ?? () #11 0xa7200010 in ?? () #12 0x001d in ?? () #13 0x in ?? () I guess there is something wrong with my texture management and the new texture pool. I continue to dig Cheers, Cedric -- +33 659 598 614 Cedric Pinson mailto:cedric.pin...@plopbyte.net http://www.plopbyte.net On Fri, 2009-10-02 at 22:21 +0100, Robert Osfield wrote: Hi All, I've been pretty quiet and the public list/forum through September, keeping my head down developing new functionality for the OSG... and the new functionality I'm pleased to announce today is that we now have a loverly new back-end implementation for texture objects and buffer objects (VertexBufferObject, ElementBufferObjects and PixelBufferObjects's) that provides a set of GL objects pools that enable recycling of both orphaned GL objects and reuse of GL objects that are still attached to the scene graph, but are stale - i.e. haven't been rendered in the last frame. The benefit the GL object pools provide is that we can scale up the scene graph in main memory without blowing OpenGL driver and GPU memory as we would do without the new pools. This feature also reduces the likely-hood of thrashing of OpenGL driver and GPU memory so that where we might have previously seen frame drops due to memory management we avoid them completely or reduce there impact. The memory pools will come in there own once we scale down the GPU memory size, such as embedded systems, or on desktop/workstation applications where GPU memory can be overflowed due to massive databases being kept in main memory. In the later case this issue is more compounded on some OS's, such as Vista, that limits the amount of memory that OpenGL drivers can allocate, so here it should help make the app more stable (avoid the crashes due to out of memory errors) and faster. So... how to try out the new texture and buffer object pools? First up you'll need to update to the latest OpenScenGraph svn/trunk. Next you'll need to enable the pools by setting the env vars: (example below for bash) export OSG_TEXTURE_POOL_SIZE=1 // size in bytes (100Mb) export OSG_BUFFER_OBJECT_POOL_SIZE=2 // size in bytes (200Mb) Then run your app with some big data, such a large paged database, you can push the amount of main memory used by enabling the MaxPagedLOD feature in the DatabasePager via: export OSG_MAX_PAGEDLOD=10 // keep in memory a maximum of 100,000 PagedLOD nodes You can also set these values programmatically via osg::DisplaySettings. A word of warning though, I have almost completely rewritten the way that the backend that drives texture objects and buffer objects, even when you don't enable the texture/buffer object pools, the code managing the GL objects is still completely different. With major changes like this comes the likelihood of regressions. I've been doing a range of tests at my end, but it's still far more limited in scope to what the community will expose the OSG to, so... there you may way see problems that I haven't. The best I can do is endeavor to get them fixed as quickly as possible, just let me know if you see something odd and I we can work together to spot what the underlying problem and squish it. The more testing we can get the quicker we can shape the code up to being release quality. Have fun with it :-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org signature.asc Description: This is a digitally signed message part ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] osgOcean 1.0 (LGPL) Released
Hi Kim, I'll have a look at how this is done in the OSG CMakelists, For the OSG, CMake has always defaulted to a debugrelease build configuration under windows, I just presumed that was the norm. Please give me a few minutes, I'll try to work this out on my Ubuntu VM and report back. There are a few issues being mixed up here and I'd like to keep things consistent. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] How to run osgOcean
Hi Gopal, osgviewer cow.osg output.txt 21 You need to do this before: (on Windows:) set OSG_NOTIFY_LEVEL=DEBUG (on bash:) export OSG_NOTIFY_LEVEL=DEBUG and then run the osgviewer command. That will tell OSG to be verbose about everything and the output.txt should contain the info we need. But even then, as I said before, on the video card you have you won't be able to do much with osgOcean in its present form. It was just not designed to run with reduced features like that. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] osgOcean 1.0 (LGPL) Released
Don't worry I wasn't going to jump on this immediately. Kim. 2009/10/8 Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com Hi Kim, I'll have a look at how this is done in the OSG CMakelists, For the OSG, CMake has always defaulted to a debugrelease build configuration under windows, I just presumed that was the norm. Please give me a few minutes, I'll try to work this out on my Ubuntu VM and report back. There are a few issues being mixed up here and I'd like to keep things consistent. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [osgPlugins] Adding an alias for .osg
Hi, I'm trying to save and open an osg node, but instead of using the .osg extension id like to use .custom. I've understood it that I should call: osgDB::Registry::instance()-addFileExtensionAlias(custom, osg); In order to create an alias for .custom to .osg, but it does not work to load a file with: osgDB::readNodeFile(test.custom); Anything else I need to do? I am using the svn trunk of openscenegraph. Thank you! Cheers, yohan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=18008#18008 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] osgOcean 1.0 (LGPL) Released
Hi Kim, Jan, I'll have a look at how this is done in the OSG CMakelists, For the OSG, CMake has always defaulted to a debugrelease build configuration under windows, I just presumed that was the norm. Let's be specific here. There are two separate issues: 1. Whether the CMake scripts ask you for debug libraries or not (and also whether it's an error if the debug libraries are not found) 2. Whether the Release build is the default. Issue 2 is the simplest: On Windows, solution files are generated that contain Debug, Release, RelWithDebugInfo and MinSizeRelease configurations. That should continue to be the case. On Linux, you need to specify the configuration you want at CMake-configure-time (CMAKE_BUILD_TYPE). If you don't specify anything, you get Release. For both OSG and osgOcean, CMake will generate all four build types on Windows, and will let you specify what you want in CMAKE_BUILD_TYPE on Linux and build release by default. So we can dismiss issue 2, it's the same for both OSG and osgOcean. For issue 1, on *both* Windows and Linux, OSG's CMake will ask you for the path to debug and release versions of your libraries when it makes sense. For example, OSG has fields for both release and debug libraries for COLLADA and Boost. For other libraries it will only ask for release. I'm not sure what the behavior is when it doesn't find the debug versions, but it does ask for them. In the interest of making things simpler for Linux users, I've made a change to osgOcean's root CMakeLists.txt. If not on Windows, if any of the _DEBUG libraries are empty or not found, it will use the release variant in its place. (I think Linux and MacOS X users will want to do the same thing here) On Windows that would actually be an error, so CMake will still generate an error if the debug libs are not found. Since the configuration is chosen from the Solution file and not at CMake-configure-time, we have no way of making sure the user will only ever make release builds, so I prefer to err on the side of safety and require users to have debug OSG libraries. Jan, can you update osgOcean and see if that works for you? Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Text::setFont() installs the Font's StateSet?
My app uses the same font everywhere. So, I have a global method to
return a reference to a single Font instance:
osg::ref_ptrosgText::Font getArialFont() {
static osg::ref_ptrosgText::Font s_font =
osgText::readFontFile("fonts/arial.ttf");
return s_font;
}
When I pass it to Text::setFont(), the Text instance's StateSet gets
set to the Font's StateSet. Every Text instance ends up sharing the
same StateSet and changes to it end up acting globally. Here's the code
from osgText::Text:
void Text::setFont(osg::ref_ptrFont font)
{
if (_font==font) return;
osg::StateSet* previousFontStateSet = _font.valid() ?
_font-getStateSet() : DefaultFont::instance()-getStateSet();
osg::StateSet* newFontStateSet = font.valid() ?
font-getStateSet() : DefaultFont::instance()-getStateSet();
if (getStateSet() == previousFontStateSet)
{
setStateSet( newFontStateSet );
}
_font = font;
computeGlyphRepresentation();
}
If I later set some text to be depth sorted and other text to not be
depth sorted, then whomever makes the setting last, wins.
I have two questions.
1) Why would you want the Font's StateSet to become the Text's
StateSet? Text and Font are very different concepts.
2) Ideally, StateSet would have COW semantics, but it doesn't and it
wouldn't be trivial to add. Would it be reasonable to pass a copy of
newFontStateSet to Text::setStateSet()?
Cory
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Text::setFont() installs the Font's StateSet?
Hi Cory,
For the purpose of state sorting and lazy state updating it's
important to shader StateSet - which is why all Text that share the
same Font will share the same StateSet.
Perhaps setting the StateSet of the Geode that sits above the Text
drawable will answer your needs.
Robert.
On Thu, Oct 8, 2009 at 4:27 PM, Cory Riddell c...@codeware.com wrote:
My app uses the same font everywhere. So, I have a global method to return a
reference to a single Font instance:
osg::ref_ptrosgText::Font getArialFont() {
static osg::ref_ptrosgText::Font s_font =
osgText::readFontFile(fonts/arial.ttf);
return s_font;
}
When I pass it to Text::setFont(), the Text instance's StateSet gets set to
the Font's StateSet. Every Text instance ends up sharing the same StateSet
and changes to it end up acting globally. Here's the code from
osgText::Text:
void Text::setFont(osg::ref_ptrFont font)
{
if (_font==font) return;
osg::StateSet* previousFontStateSet = _font.valid() ? _font-getStateSet()
: DefaultFont::instance()-getStateSet();
osg::StateSet* newFontStateSet = font.valid() ? font-getStateSet() :
DefaultFont::instance()-getStateSet();
if (getStateSet() == previousFontStateSet)
{
setStateSet( newFontStateSet );
}
_font = font;
computeGlyphRepresentation();
}
If I later set some text to be depth sorted and other text to not be depth
sorted, then whomever makes the setting last, wins.
I have two questions.
1) Why would you want the Font's StateSet to become the Text's StateSet?
Text and Font are very different concepts.
2) Ideally, StateSet would have COW semantics, but it doesn't and it
wouldn't be trivial to add. Would it be reasonable to pass a copy of
newFontStateSet to Text::setStateSet()?
Cory
___
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] [3rdparty] osgOcean 1.0 (LGPL) Released
Hi Jean-Sébastien, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Kim, Jan, I'll have a look at how this is done in the OSG CMakelists, For the OSG, CMake has always defaulted to a debugrelease build configuration under windows, I just presumed that was the norm. Let's be specific here. There are two separate issues: 1. Whether the CMake scripts ask you for debug libraries or not (and also whether it's an error if the debug libraries are not found) 2. Whether the Release build is the default. For both OSG and osgOcean, CMake will generate all four build types on Windows, and will let you specify what you want in CMAKE_BUILD_TYPE on Linux and build release by default. So we can dismiss issue 2, it's the same for both OSG and osgOcean. The original problem was that even despite not specifying anything (i.e. default release build), the cmake was failing because of missing OpenThreads debug libs, despite them not really being needed on Linux. This should be fixed now, hopefully. For issue 1, on *both* Windows and Linux, OSG's CMake will ask you for the path to debug and release versions of your libraries when it makes sense. For example, OSG has fields for both release and debug libraries for COLLADA and Boost. For other libraries it will only ask for release. I'm not sure what the behavior is when it doesn't find the debug versions, but it does ask for them. This is OK if the debug release is being built. It is not OK, in my opinion to fail the build even though I am asking for release only (or didn't specify the option - should default to release). Jan, can you update osgOcean and see if that works for you? I did, but it tries to build *both* debug and release when I run cmake . : (ja...@dvalin)-(07:02 PM Thu Oct 08)-(osgocean-read-only) $ cmake . -- Creating a debug and release build. ^ ... and then it fails because it doesn't find the OpenThreads debug libraries - the issue that was discussed elsewhere. I must specify release build explicitly to avoid this problem or to manually set the OPENTHREADS_LIBRARY_DEBUG variable. For the record, svn update shows me at revision 138 as being up-to-date - the same as yesterday. When did you make the change? Regards, Jan signature.asc Description: This is a digitally signed message part. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New OpenGL texture object and buffer object pool support
Hi Robert, I cleaned all my singleton before quitting the application. Now i have the following crash but sometimes it's random. It seems the TextureObjectManager is deleted before the cache is cleared by Registry destructor and produce a crash somewhere. I am a bit confuse now, i continue to track it. Just for info i use the cache of the registry... #0 0x081290a8 in ScopedLock (this=0xbf8132b4, m...@0x82d2004) at /home/mornifle/dev/osg-trunk-svn/debug/lib/../include/OpenThreads/ScopedLock:31 #1 0xb7f87645 in osg::Texture::TextureObjectSet::orphan (this=0x82d1ff8, to=0x892a078) at /home/mornifle/dev/osg-trunk-svn/src/osg/Texture.cpp:558 #2 0xb7f87723 in osg::Texture::TextureObjectManager::releaseTextureObject (this=0xa594ed90, to=0x892a078) at /home/mornifle/dev/osg-trunk-svn/src/osg/Texture.cpp:736 #3 0xb7f87796 in osg::Texture::releaseTextureObject (contextID=0, to=0x892a078) at /home/mornifle/dev/osg-trunk-svn/src/osg/Texture.cpp:819 #4 0xb7f8780a in osg::Texture::dirtyTextureObject (this=0xb3af02d8) at /home/mornifle/dev/osg-trunk-svn/src/osg/Texture.cpp:1298 #5 0xb7f87b73 in ~Texture (this=0xb3af02d8) at /home/mornifle/dev/osg-trunk-svn/src/osg/Texture.cpp:1186 #6 0xb7f7cc2f in ~Texture2D (this=0xb3af02d8) at /home/mornifle/dev/osg-trunk-svn/src/osg/Texture2D.cpp:52 #7 0x0810f6a2 in osg::Referenced::unref (this=0xb3af02d8) at /home/mornifle/dev/osg-trunk-svn/debug/lib/../include/osg/Referenced:183 #8 0x0813434c in ~ref_ptr (this=0xb3af0994) at /home/mornifle/dev/osg-trunk-svn/debug/lib/../include/osg/ref_ptr:33 #9 0x0813436c in ~pair (this=0xb3af0990) at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g ++-v4/bits/stl_pair.h:73 #10 0x0813437f in __gnu_cxx::new_allocatorstd::pairint const, osg::ref_ptrosg::Texture2D ::destroy (this=0xbf81343f, __p=0xb3af0990) at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g ++-v4/ext/new_allocator.h:118 #11 0x081343b4 in std::_Rb_treeint, std::pairint const, osg::ref_ptrosg::Texture2D , std::_Select1ststd::pairint const, osg::ref_ptrosg::Texture2D , std::lessint, std::allocatorstd::pairint const, osg::ref_ptrosg::Texture2D ::_M_destroy_node (this=0xb4a0a078, __p=0xb3af0980) at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g ++-v4/bits/stl_tree.h:390 #12 0x0813443e in std::_Rb_treeint, std::pairint const, osg::ref_ptrosg::Texture2D , std::_Select1ststd::pairint const, osg::ref_ptrosg::Texture2D , std::lessint, std::allocatorstd::pairint const, osg::ref_ptrosg::Texture2D ::_M_erase (this=0xb4a0a078, __x=0xb3af0980) at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g ++-v4/bits/stl_tree.h:943 #13 0x0813441e in std::_Rb_treeint, std::pairint const, osg::ref_ptrosg::Texture2D , std::_Select1ststd::pairint const, osg::ref_ptrosg::Texture2D , std::lessint, std::allocatorstd::pairint const, osg::ref_ptrosg::Texture2D ::_M_erase (this=0xb4a0a078, __x=0xb3af0a40) at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g ++-v4/bits/stl_tree.h:941 #14 0x0813441e in std::_Rb_treeint, std::pairint const, osg::ref_ptrosg::Texture2D , std::_Select1ststd::pairint const, osg::ref_ptrosg::Texture2D , std::lessint, std::allocatorstd::pairint const, osg::ref_ptrosg::Texture2D ::_M_erase (this=0xb4a0a078, __x=0xb3af0a20) at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g ++-v4/bits/stl_tree.h:941 #15 0x0813441e in std::_Rb_treeint, std::pairint const, osg::ref_ptrosg::Texture2D , std::_Select1ststd::pairint const, osg::ref_ptrosg::Texture2D , std::lessint, std::allocatorstd::pairint const, osg::ref_ptrosg::Texture2D ::_M_erase (this=0xb4a0a078, __x=0xb3af0a60) at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g ++-v4/bits/stl_tree.h:941 #16 0x0813441e in std::_Rb_treeint, std::pairint const, osg::ref_ptrosg::Texture2D , std::_Select1ststd::pairint const, osg::ref_ptrosg::Texture2D , std::lessint, std::allocatorstd::pairint const, osg::ref_ptrosg::Texture2D ::_M_erase (this=0xb4a0a078, __x=0xb4a09ea0) at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g ++-v4/bits/stl_tree.h:941 #17 0x0813441e in std::_Rb_treeint, std::pairint const, osg::ref_ptrosg::Texture2D , std::_Select1ststd::pairint const, osg::ref_ptrosg::Texture2D , std::lessint, std::allocatorstd::pairint const, osg::ref_ptrosg::Texture2D ::_M_erase (this=0xb4a0a078, __x=0xb4a09e80) at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g ++-v4/bits/stl_tree.h:941 #18 0x0813441e in std::_Rb_treeint, std::pairint const, osg::ref_ptrosg::Texture2D , std::_Select1ststd::pairint const, osg::ref_ptrosg::Texture2D , std::lessint, std::allocatorstd::pairint const, osg::ref_ptrosg::Texture2D ::_M_erase (this=0xb4a0a078, __x=0xb4a006b8) at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g ++-v4/bits/stl_tree.h:941 #19 0x0813446e in ~_Rb_tree (this=0xb4a0a078) at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g ++-v4/bits/stl_tree.h:585 #20 0x081344c1 in ~map (this=0xb4a0a078) at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g++-v4/bits/stl_map.h:92 #21 0x08134cff in ~DeckNode (this=0xb4a09ff8) at
Re: [osg-users] [3rdparty] osgOcean 1.0 (LGPL) Released
Hi Jan, The original problem was that even despite not specifying anything (i.e. default release build), the cmake was failing because of missing OpenThreads debug libs, despite them not really being needed on Linux. Yes, but somewhere in the discussion the issues got mixed up. I just wanted to set things straight. This should be fixed now, hopefully. Yes indeed. For issue 1, on *both* Windows and Linux, OSG's CMake will ask you for the path to debug and release versions of your libraries when it makes sense. For example, OSG has fields for both release and debug libraries for COLLADA and Boost. For other libraries it will only ask for release. I'm not sure what the behavior is when it doesn't find the debug versions, but it does ask for them. This is OK if the debug release is being built. It is not OK, in my opinion to fail the build even though I am asking for release only (or didn't specify the option - should default to release). I totally agree, which is the goal of what I did. But that doesn't answer my question of what happens for OSG? For example, if you want to build the COLLADA plugin, do you need both the debug and release COLLADA libs even on Linux? Or does the release lib get used for both if you don't have the debug version (as we now do)? I don't know, I never build OSG with COLLADA support on Linux... But you'll note that there are variables COLLADA_DYNAMIC_LIBRARY and COLLADA_DYNAMIC_LIBRARY_DEBUG, so I assume it will run into the same issues as we are here. Jan, can you update osgOcean and see if that works for you? I did, but it tries to build *both* debug and release when I run cmake . : [...] For the record, svn update shows me at revision 138 as being up-to-date - the same as yesterday. When did you make the change? Sorry, I had made the change into the 1.0 branch instead of the trunk. Try to update again and it should be better. No need for an additional option that can be on by default on Linux but off by default on Windows... Let me know how it goes. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN commit bottleneck
Robert Osfield wrote: have had to start this round of work immediately after completing other client work so haven't had a window opportunity to catch up with submissions and go for making 2.10 as I had originally hoped. If community members are keen to see a 2.10 release sooner rather than later then we'll need to rely upon other members of the community to take charge of a 2.10 branch and push it all the way to release without me at the helm. I don't think I'm qualified to nominate myself for this right now. However, I'm wondering who does have SVN commit access, and if one of these people is willing to accept interim changes? I have several finished changes ready to check in, and I worry about them getting stale. With concurrent development, other people could potentially get conflicted with my changes and make more messy work for down the road than inf they had my changes to start from. Likewise, I dislike submitting more than one change at a time -- for example, I revised Vec3d for a particular purpose. I would like to get that in with the purpose/explanation before I make any new changes to Vec3d for a different purpose -- that way the SVN commit chain of evidence is clear that this one checking serves on single purpose. Is anyone else willing to accept, screen and integrate SVN changes right now? -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture Wrapping Texture2DArray (Clamping doesn't work)
Hi, this is definitly no osg issue - i could reproduce it with nativ opengl. Just switch to see the difference. //#define NOARRAY http://www.jotschi.de/download/opengl_texture_array_glsl_example.tgz I will send this to ati / amd though i don't think that will help me in any way. Cheers, Johannes -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=18089#18089 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] osgOcean 1.0 (LGPL) Released
Hi Jan, Let me know how it goes. I should mention that on my Ubuntu VM, with these changes (root CMakeLists.txt at rev 139 at least), I can start with a fresh checkout of osgOcean and only the Release OSG libraries, and go all the way to make install. The only thing I did manually is I changed the CMAKE_INSTALL_PREFIX to point to a subdir of my home, but that's just me :-) I just added checking an env var for the FFT libraries and include paths, so for example if you didn't install FFTSS system-wide, but you set FFTSS_DIR to the path where it's installed (where its include and lib directories are) before running CMake, it will find them and you won't have to set them manually. Just so you know where I stand. I hope these changes work for you. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Texture missing when adding slaves dynamically to osgViewer
Hello, I'm having trouble with textures on slave cameras added to an osgViewer. Textures won't appear if I add the slaves after a first call to osgViewer::frame(). My application is composed of a rendering thread calling osgViewer::frame() every 15 ms (for a 60 Hz framerate) and a main thread handling windows and menus interactions (using MFC on Windows). One of those interactions is to add and remove camera slaves on the go (adding a projection and camera offset for multiple points of view). Here's the steps I follow to add a slave camera: · Pause my rendering thread calling osgViewer::frame() and wait for it to be idle; · Call osgViewer::stopThreading() to make sure the last frame is done drawing; · Create a child window with its own graphics context; · Add a slave to osgViewer using the newly created window handle (each slave camera uses its own osg::GraphicsContext object); · Call osgViewer::realize() to reinitialize the viewer and start threading again; · Unpause my rendring thread which starts calling osgViewer::frame() again. I use a similar approach to destroy slaves. Everything works fine except for the textures which are not displayed on the slave windows (but I can see the primitives). Note that if I add slaves before the first call to osgViewer::frame(), textures are ok. But removing and adding them again makes the textures disappear. I tried all the threading models in osgViewer, I also tried to share the master context in the osg::GraphicsContext::Traits object of every slave. None of those solutions is working. My comprehension of OpenGL state sets is limited so I'm probably missing something here. What am I doing wrong? Is adding slaves dynamically to an osgViewer even possible? Thanks for your help! Frederic Drolet, M. Sc. Computing Solutions and Experimentations | Solutions informatiques et expérimentations Systems of Systems | Systèmes de systèmes DRDC Valcartier | RDDC Valcartier 2459, boul. Pie-XI North Quebec, Quebec G3J 1X5 CANADA Phone | Téléphone: (418) 844-4000 ext : 4820 Fax | Télécopieur: (418) 844-4538 E-mail | Courriel: frederic.dro...@drdc-rddc.gc.ca mailto:frederic.dro...@drdc-rddc.gc.ca Web : www.valcartier.drdc-rddc.gc.ca http://www.valcartier.drdc-rddc.gc.ca ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Whats going wrong in osg::Simplifier and osg::LOD
Hi,
i want to auto generate a few LODs with osg::Simplifier
then i want to add these nodes to an LOD
whats going wrong
i see only the first Node from 0 - 300 pixels distance
iam using Version 2.8.2 of OSG
Code:
int main( int argc, char **argv )
{
glutInit(argc, argv);
glutInitDisplayMode( GLUT_DOUBLE | GLUT_RGBA | GLUT_DEPTH | GLUT_ALPHA );
glutInitWindowPosition( 100, 100 );
glutInitWindowSize( 800, 600 );
glutCreateWindow( argv[0] );
glutDisplayFunc( display );
glutReshapeFunc( reshape );
glutMouseFunc( mousebutton );
glutMotionFunc( mousemove );
glutPassiveMotionFunc( passivemousemove );
glutKeyboardFunc( keyboard );
osg::ref_ptrosg::Group root = new osg::Group;
osg::ref_ptrosg::Node loadedModel =
osgDB::readNodeFile(C:\\3001.ive);
osg::ref_ptrosg::LOD pLod = new osg::LOD ;
pLod-setRangeMode( osg::LOD::DISTANCE_FROM_EYE_POINT );
float sampleRatio = 0.5f;
float maxError = 4.0f;
float multiplier = 0.8f;
float minRatio = 0.001f;
float ratio = sampleRatio;
float LODnear = 0.0;
float LODfar = 300.0;
for ( int i = 0 ; i 3; i++)
{
ratio *= multiplier;
osgUtil::Simplifier simplifier(ratio, maxError);
osg::ref_ptrosg::Node simplNode =
(osg::Node*)loadedModel-clone(osg::CopyOp::DEEP_COPY_ALL);
simplNode-accept(simplifier);
pLod-addChild( simplNode.get(), LODnear, LODfar );
LODnear = LODfar;
LODfar += 300.0;
}
root-addChild( pLod.get() );
viewer = new osgViewer::Viewer;
window = viewer-setUpViewerAsEmbeddedInWindow(100,100,800,600);
viewer-setSceneData( root.get());
viewer-setCameraManipulator( new cSphericalManipulator );
viewer-addEventHandler(new osgViewer::StatsHandler);
viewer-realize();
glutMainLoop();
return 0;
}
Thank you!
Cheers,
Matthias[/code]
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=18092#18092
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] osgOcean 1.0 (LGPL) Released
Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: But that doesn't answer my question of what happens for OSG? For example, if you want to build the COLLADA plugin, do you need both the debug and release COLLADA libs even on Linux? Or does the release lib get used for both if you don't have the debug version (as we now do)? I don't know, I never build OSG with COLLADA support on Linux... But you'll note that there are variables COLLADA_DYNAMIC_LIBRARY and COLLADA_DYNAMIC_LIBRARY_DEBUG, so I assume it will run into the same issues as we are here. Not really - the debug version of the library on Linux means only two things - the library keeps debug symbols and is (usually) compiled without optimizations, in order to keep debugging easier. There is no different memory allocator or anything like that like on Windows, so the debug/release versions are fully interchangeable. So you do not *need* the debug version. Whether or not debug is replaced by release in the absence of the debug versions for the COLLADA plugin, I do not know, though. In general, on a non-Windows platform if you are not going to debug the plugin itself or OSG, it is perfectly fine to build only release versions. The consequence will be that e.g. in a backtrace you wouldn't be able to see the exact line of the code if a crash occurs in the plugin (the debug symbols are gone), but that is all. Even that could be alleviated by building as RelWithDebInfo (release, but not stripped, keeps debug symbols). The only issues will be be that certain optimizations that reorder code interfere with debugging (gdb shows wrong line) and the files are larger. But everything else works. Jan, can you update osgOcean and see if that works for you? I did, but it tries to build *both* debug and release when I run cmake . : [...] For the record, svn update shows me at revision 138 as being up-to-date - the same as yesterday. When did you make the change? Sorry, I had made the change into the 1.0 branch instead of the trunk. Try to update again and it should be better. Indeed, it works fine now. Thanks! Regards, Jan signature.asc Description: This is a digitally signed message part. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] osgOcean collision detection
Hi Jan, While I was at it, I started integrating the changes for getting the ocean surface height at a position. I went with a combination of Jean-Claude's and Dimitrios' code, with a few small modifications. The only problem is I have no way of testing it (it builds, thus it works by definition, right? :-) ). Would it be possible (for either you, Dimitrios, or Jean-Claude) to make a very simple test using the oceanExample as base code, perhaps just making the Cessna from OSG-Data float on the water the way you want? Then I could test if the modifications I made work. I really dislike committing work-in-progress code... So I'd prefer to do it that way. Therefore the function needs to be exposed at the abstract OceanTechnique level already, not only in the FFTOceanSurface. It even makes sense - the sea surface height is likely not going to be dependent on which simulation technique you use to implement it. I have put a pure virtual function in the OceanTechnique which is then redefined in the FFTOceanSurface. I totally agree. OceanTechnique (and thus FFTOceanSurface) already had getSurfaceHeight(), so I added this method as getSurfaceHeightAt() and added comments explaining that the former gets the average height, whereas the latter gets it at a specific position. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] osgOcean 1.0 (LGPL) Released
Hi Jan, Whether or not debug is replaced by release in the absence of the debug versions for the COLLADA plugin, I do not know, though. This was the only thing I was wondering about. I was aware of all the rest. I've done my share of development on Linux you know. I just use Windows at work, but I'm not for or against one or the other. Indeed, it works fine now. Thanks! Great, thanks for testing. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture missing when adding slaves dynamically toosgViewer
Bonjour Frédéric, I’m having trouble with textures on slave cameras added to an osgViewer. Textures won’t appear if I add the slaves after a first call to osgViewer::frame(). This is an FAQ. By default, osg::Texture* will unref the image data after it has been applied, i.e. once it's been uploaded to the graphics hardware and is not generally needed in main memory anymore. You can change this by calling setUnRefImageDataAfterApply(false) on your textures, or by running the osgUtil::Optimizer::TextureVisitor with changeAutoUnref=true and valueAutoUnref=false on your models. Hope this helps. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture missing when adding slaves dynamically to osgViewer
Hi Frederic, If you are creating new graphics contexts and applying and old scene graph to it then you can't use the Texture::setUnRefImageDataAfterApply(true) feature of osg::Texture as this will discard the imagery once it's applied to all the graphics contexts that it knows about. By default the osgUtil::Optimizer will switch this on to save memory, so try not calling the Optimizer to see if makes a difference. It's possible that the original database also has this options set, but for most databases it'll be off, which is the default. Robert. On Thu, Oct 8, 2009 at 8:21 PM, Drolet, Frederic frederic.dro...@drdc-rddc.gc.ca wrote: Hello, I’m having trouble with textures on slave cameras added to an osgViewer. Textures won’t appear if I add the slaves after a first call to osgViewer::frame(). My application is composed of a rendering thread calling osgViewer::frame() every 15 ms (for a 60 Hz framerate) and a main thread handling windows and menus interactions (using MFC on Windows). One of those interactions is to add and remove camera slaves on the go (adding a projection and camera offset for multiple points of view). Here’s the steps I follow to add a slave camera: · Pause my rendering thread calling osgViewer::frame() and wait for it to be idle; · Call osgViewer::stopThreading() to make sure the last frame is done drawing; · Create a child window with its own graphics context; · Add a slave to osgViewer using the newly created window handle (each slave camera uses its own osg::GraphicsContext object); · Call osgViewer::realize() to reinitialize the viewer and start threading again; · Unpause my rendring thread which starts calling osgViewer::frame() again. I use a similar approach to destroy slaves. Everything works fine except for the textures which are not displayed on the slave windows (but I can see the primitives). Note that if I add slaves before the first call to osgViewer::frame(), textures are ok. But removing and adding them again makes the textures disappear. I tried all the threading models in osgViewer, I also tried to share the “master” context in the osg::GraphicsContext::Traits object of every slave. None of those solutions is working. My comprehension of OpenGL state sets is limited so I’m probably missing something here. What am I doing wrong? Is adding slaves dynamically to an osgViewer even possible? Thanks for your help! Frederic Drolet, M. Sc. Computing Solutions and Experimentations | Solutions informatiques et expérimentations Systems of Systems | Systèmes de systèmes DRDC Valcartier | RDDC Valcartier 2459, boul. Pie-XI North Quebec, Quebec G3J 1X5 CANADA Phone | Téléphone: (418) 844-4000 ext : 4820 Fax | Télécopieur: (418) 844-4538 E-mail | Courriel: frederic.dro...@drdc-rddc.gc.ca Web : www.valcartier.drdc-rddc.gc.ca ___ 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] [3rdparty] How to run osgOcean
Hi S-J, may I know the minimum config of the machine that will be successful to run the osgOcean along with the graphic card requirement Thank you! :) gopal -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=18099#18099 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] How to run osgOcean
Hello Gopal, may I know the minimum config of the machine that will be successful to run the osgOcean along with the graphic card requirement For processor type I'm not sure, most of the processing is offloaded to the GPU so you might be able to get away with something quite modest, though with the current way osgOcean switches tiles and frames of animation there's a bit going on in the Update traversal. GPU side, you need something that supports GLSL shaders at the very least, and that's if you disable all the special effects like reflection/refraction, depth of field, etc. For those, you'll need a card that supports FrameBuffer Objects (FBOs). In concrete terms, I've personally tested osgOcean on nVidia cards of the 7800, 7900, 8800 and 9800 lines. Realistically, I think anything above 7800 should run it fine. There are even some really good deals in the recent GTX 2xx line that will run it admirably well. Perhaps the 6x00 line might run it as well, but I haven't tested it personally. And I doubt the 5x00 line and below will run it at all. Those (the 5x00s) had finicky shader support IIRC. As for ATI, well, I haven't tested anything other than a Radeon HD 4350, which runs it well (though I had other problems, see another thread that hasn't gotten any answers yet). Basically I guess anything that's in the same generations as what I said about nVidia cards above should perform similarly. But I can't guarantee anything. I think I'll put up a page on the osgOcean wiki for people to report their experiences with different cards. It would give us a better idea of where it's supported, and maybe even if we can do something to support older cards (which as I said I'll be working on soon). Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osg::LOD range distance Coordinate System Question
This may be a simple question - is the LOD range distance specified in object or world coordinates? I seems as if it should be in world coordinates, but I've got an example with numerous LOD nodes in sub-graphs, and if I sent a constant distance range in each of them (0.0, 30.0f) so that each LOD node has the same range - the LOD switch only behaves as expected if the transforms above each LOD node are identical. The moment I have a scale matrix above the LOD the switch becomes dependent on the scaling...e.g. larger LODs switch before smaller ones. This leads me to think that the LOD range distance is in object coordinates, and needs to be scaled by the localToWorld transform. I've had a look at the source, and it seems logical (not to mention that I'd be shocked if someone hadn't had a problem before this if it were incorrect) Comments? Thoughts? cheers, sean ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::LOD range distance Coordinate System Question
Studying the source a bit harder, I think the range-distance is definitely in Object (local) coordinate. The distance calculation (osg::LOD.cpp) is: required_range = nv.getDistanceToViewPoint(getCenter(),true); where getDistanceToViewPoint is (osgUtil::CullVisitor.cpp) (pos-getViewPointLocal()).length()*getLODScale(); So, this raises the question: is there a good reason why there is no option to specify the LOD range distance in World Coordinates? This would make complex LOD graphs like the one I'm working on much, much simpler. Perhaps there is another method that I just do not see? cheers, sean On Thu, Oct 8, 2009 at 10:50 PM, Sean Spicer sean.spi...@aqumin.com wrote: This may be a simple question - is the LOD range distance specified in object or world coordinates? I seems as if it should be in world coordinates, but I've got an example with numerous LOD nodes in sub-graphs, and if I sent a constant distance range in each of them (0.0, 30.0f) so that each LOD node has the same range - the LOD switch only behaves as expected if the transforms above each LOD node are identical. The moment I have a scale matrix above the LOD the switch becomes dependent on the scaling...e.g. larger LODs switch before smaller ones. This leads me to think that the LOD range distance is in object coordinates, and needs to be scaled by the localToWorld transform. I've had a look at the source, and it seems logical (not to mention that I'd be shocked if someone hadn't had a problem before this if it were incorrect) Comments? Thoughts? cheers, sean ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
