Re: [osg-users] Conan C++ dependency manager
Hi, I encounter a problem that the osgDB::readImageFile can not read the image files. I know that the osgDB need related plugins to read files, and I uploaded the osgPlugins folder with other osg libs. It seems conan didn't let osg find the plugins, did anyone encounter similar problem? How to deal with it? mp3butcher wrote: > You can test current recipes and improve them... > https://github.com/mp3butcher/osg_conan_recipe > > Edit: > Here's a blog from a guy that have more experience with conan than me > https://www.micheleadduci.net/blog/2017/02/05/Fourteen-days-with-conan/ > It points some CMake limitations I haven't experienced with Ubuntu and win32 > package... > > > Chris Hanson wrote: > > I've been hoping for Conan support for OSG for some time. > > > > Python is a complex tool, but powerful, and I'm willing to accept its > > complexity in return for what it can do. > > > > > > On Sun, Feb 4, 2018 at 2:05 PM, Julien Valentin < ()> wrote: > > > > > https://www.youtube.com/watch?v=nLdB1ErncBg > > > (https://www.youtube.com/watch?v=nLdB1ErncBg) > > > > > > > > > mp3butcher wrote: > > > > > > > Thanks for the link > > > > I didn't know this tool, i should test it > > > > > > > > In conan, there's tools to download, to unzip, to invoke system package > > > > manager, virtual runtime environment (manage env vars) > > > > python makes conan sexy and flexible. > > > > Further it manages dependancies (will dl what missing -sourcesORbuilt- > > > > for the recipe you wanna build package for) > > > > I know they're trying to do business with package hosting, but who can > > > > blame them > > > > > > > > I don't know if all these features are included in hunter... > > > > If you have knowledge about hunter, can you provide us a simple example > > > > apply to osg win32 package? > > > > > > > > Cheers > > > > > > > > > > > > remoe wrote: > > > > > > > > > Hi All, > > > > > > > > > > Why they use python? Python itself has complicated dependencies. > > > > > Someone has wrote a CMake based system: > > > > > > > > > > https://github.com/ruslo/hunter (https://github.com/ruslo/hunter) > > > > > > > > > > Or write your own in GoLang :) > > > > > > > > > > Cheers, > > > > > Remo > > > > > > > > > > > > > > > > > > > > > > -- > > > Read this topic online here: > > > http://forum.openscenegraph.org/viewtopic.php?p=72923#72923 > > > (http://forum.openscenegraph.org/viewtopic.php?p=72923#72923) > > > > > > > > > > > > > > > > > > ___ > > > osg-users mailing list > > > () > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > (http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org) > > > > > > > > > > > > > > > > > > > -- > > Chris 'Xenon' Hanson, omo sanza lettere. http://www.alphapixel.com/ > > (http://www.alphapixel.com/) > > Training • Consulting • Contracting > > 3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • > > GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL > > Legal/IP • Forensics • Imaging • UAVs • GIS • GPS • osgEarth • Terrain • > > Telemetry • Cryptography • LIDAR • Embedded • Mobile • iPhone/iPad/iOS • > > Android > > @alphapixel (https://twitter.com/alphapixel) facebook.com/alphapixel > > (http://facebook.com/alphapixel) (775) 623-PIXL [7495] > > > > -- > > Post generated by Mail2Forum > -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=74204#74204 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Conan C++ dependency manager
Hi, Great to see integrate osg to conan. Users could use osg from conan without having to rebuild it. ... Thank you! Cheers, Ben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=72721#72721 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to get Center Parameter of CameraManipulator
Hi, Why not use getHomePosition(), which is a member of CameraManipulator ... Thank you! Cheers, Ben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=72720#72720 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Draw thread per opengl context instead of per GraphicsContext
Hi Robert, Ah ok, so the GraphicsContext::Traits::sharedContext doesn't share the actual context, but allows object sharing between contexts. Thanks for clearing that up for me, I think this changes what I am looking for. The reason that I am looking into this, is because of the following measurements. In all tests, the screenspace view sizes and rendered objects are the same. 1. 6 views in one window (singlethreaded) 24.3 fps 2. 6 views in one window (multithreaded)46 fps In these two tests, we have 1 context and 1 draw thread. Enabling multithreading almost doubles the performance. So, performing culling on another thread proves to be very effective. 3. 6 views in separate windows (multithreaded) 11.7 fps 4. 6 views in separate windows with context sharing (singlethreaded)22 fps The last test cannot be done with multiple render threads, which makes sense. But I think (please correct me if I'm wrong), multiple separate cull threads should have no effect on it's correct operation. Looking at the performance difference between test 1 and 2, I am eager to see what culling on a different thread(s) would do here. So my question changes to: for test 4, is it possible to still use separate cull threads while we only use 1 draw thread. And if not, could you give us pointers on what should be taken into consideration if we want to implement this. Thanks! Cheers, Ben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=72376#72376 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Draw thread per opengl context instead of per GraphicsContext
Hi Robert, Thanks again for your quick response. Isn't an opengl context already used by multiple windows when you use GraphicsContext::Traits::sharedContext ? I also came across the following function: BOOL WINAPI wglMakeCurrent( HDC hdc, HGLRC hglrc ); A window device context can be specified here, so it would seem that you can change the window. I also came across the following: https://blog.gvnott.com/some-usefull-facts-about-multipul-opengl-contexts/ This also seems to state that a single opengl context can be used to render to multiple windows. Thank you! Cheers, Ben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=72355#72355 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Draw thread per opengl context instead of per GraphicsContext
Hi Robert, Thank you for your response. I don't want to share the context or GL objects in multiple threads. Basically what I want is 1 draw thread for the 1 opengl context if have and 1 cull thread. I want this 1 opengl context to be shared by multiple windows. However, for each window that I create, a new draw thread is created, even when they share the same opengl context. So I was hoping that it was possible to have 1 draw thread per opengl context, instead of 1 draw thread per window (GraphicsContext). The opengl context would only be used by one thread, so thread safety shouldn't be an issue right? Cheers, Ben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=72353#72353 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Draw thread per opengl context instead of per GraphicsContext
Hi everyone, I want to use the GraphicsContext::Traits::sharedContext to render multiple views (in multiple windows) that share the same context. I already read on some forums that the ThreadingModel::SingleThreaded should be used. However, I would still like to use ThreadingModel::DrawThreadPerContext so that the cull and draw thread can overlap. I tried this, but a draw thread is created per GraphicsContext and thus per window. Because all these windows share an opengl context, I would have expected that only 1 thread would have been created. This results in all sorts of problems. Is there a way in which I can use 1 draw thread per opengl context ? And, if not, is this something that I can easily change by modifying the code ? Thank you! Cheers, Ben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=72344#72344 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph 3.4.0, latest git master: build of ffmpeg plugin fails after upgrade to ffmpeg 3.0+
robertosfield wrote: > Hi Ben, > > On 27 April 2016 at 10:22, Ben Woods < ()> wrote: > > > I have created a pull request to commit this ffmpeg3 patch against the > > master OpenSceneGraph repository on GitHub: > > https://github.com/openscenegraph/OpenSceneGraph/pull/70 > > (https://github.com/openscenegraph/OpenSceneGraph/pull/70) > > > > > For now the official route for submissions to send whole modified files to > the osg-submissions mailing list. I've found the git pull mechanism > problematic, until I find efficient ways around it's diffidences I'll be > sticking to the route outlined on the OSG website's submission page. > > > Robert. > Hi Robert, Thanks for that. I have now sent it through to the osg-submissions mailing lists here: http://lists.openscenegraph.org/pipermail/osg-submissions-openscenegraph.org/2016-May/033913.html Regards, Ben[/url] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=67185#67185 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph 3.4.0, latest git master: build of ffmpeg plugin fails after upgrade to ffmpeg 3.0+
I have created a pull request to commit this ffmpeg3 patch against the master OpenSceneGraph repository on GitHub: https://github.com/openscenegraph/OpenSceneGraph/pull/70 Regards, Ben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=66984#66984 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph 3.4.0, latest git master: build of ffmpeg plugin fails after upgrade to ffmpeg 3.0+
Hi, Please see attached a patch which allows openscenegraph to build successfully against ffmpeg 3.0.x. This was obtained from ArchLinux. Cheers, Ben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=66957#66957 Attachments: http://forum.openscenegraph.org//files/patch_ffmpeg3_202.txt ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [osgPlugins] gstreamer plugin failing to build in osg 3.4.0
Hi, I am attempting to build OpenSceneGraph 3.4.0 on FreeBSD 10.2 (with clang 3.4.1 and cmake 3.5.2). The osgdb_gstreamer is failing during the build with the following error (full build log also attached): > [ 94%] Linking CXX shared module > ../../../lib/osgPlugins-3.4.0/osgdb_gstreamer.so > cd /wrkdirs/usr/ports/graphics/osg/work/.build/src/osgPlugins/gstreamer && > /usr/local/bin/cmake -E cmake_link_script > CMakeFiles/osgdb_gstreamer.dir/link.txt --verbose=1 > /usr/bin/c++ -fPIC -O2 -pipe -fstack-protector -fno-strict-aliasing -Wall > -Wparentheses -Wno-long-long -Wno-import -Wreturn-type -Wmissing-braces > -Wunknown-pragmas -Wunused -Wno-overloaded-virtual -Wno-variadic-macros -O2 > -pipe -fstack-protector -fno-strict-aliasing -fstack-protector -shared -o > ../../../lib/osgPlugins-3.4.0/osgdb_gstreamer.so > CMakeFiles/osgdb_gstreamer.dir/GStreamerImageStream.o > CMakeFiles/osgdb_gstreamer.dir/ReaderWriterGStreamer.o > ../../../lib/libosgDB.so.3.4.0 ../../../lib/libosgUtil.so.3.4.0 > -lgstreamer-1.0 -lgobject-2.0 -lglib-2.0 -lintl -lgstapp-1.0 -lgstbase-1.0 > -lgstreamer-1.0 -lgobject-2.0 -lglib-2.0 -lintl -lgstpbutils-1.0 > -lgstreamer-1.0 -lgobject-2.0 -lglib-2.0 -lintl /usr/local/lib/libglib-2.0.so > /usr/local/lib/libgobject-2.0.so ../../../lib/libosg.so.3.4.0 > ../../../lib/libOpenThreads.so.3.3.0 -pthread -lm -lz /usr/local/lib/libGL.so > -lgstapp-1.0 -lgstbase-1.0 -lgstpbutils-1.0 /usr/local/lib/libglib-2.0.so > /usr/local/lib/libgobject-2.0.so - Wl,-rpath,/wrkdirs/usr/ports/graphics/osg/work/.build/lib:/usr/local/lib: > /usr/bin/ld: cannot find -lgstreamer-1.0 > c++: error: linker command failed with exit code 1 (use -v to see invocation) > *** Error code 1 Any ideas how to fix this? It appears to be because the gstreamer libraries are not linked into this build with -L/usr/local/lib, however I can confirm they are installed in that directory under the gstreamer-1.0 sub-directory. Thank you in advance, Ben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=66916#66916 Attachments: http://forum.openscenegraph.org//files/osg_340log_112.txt ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [osgPlugins] osgjs failing to build in osg 3.5.1
Hi, I am trying to build openscenegraph 3.5.1 on FreeBSD (with clang 3.4.1 and cmake 3.5.2), but I am getting the following error: > [ 92%] Building CXX object > src/osgPlugins/osgjs/CMakeFiles/osgdb_osgjs.dir/Base64.o > cd /wrkdirs/usr/ports/graphics/osg-devel/work/.build/src/osgPlugins/osgjs && > /usr/bin/c++ -Dosgdb_osgjs_EXPORTS > -I/wrkdirs/usr/ports/graphics/osg-devel/work/OpenSceneGraph-3.5.1/include > -I/usr/local/include > -I/wrkdirs/usr/ports/graphics/osg-devel/work/.build/include -O2 -pipe > -fstack-protector -fno-strict-aliasing -Wall -Wparentheses -Wno-long-long > -Wno-import -Wreturn-type -Wmissing-braces -Wunknown-pragmas -Wunused > -Wno-overloaded-virtual -O2 -pipe -fstack-protector -fno-strict-aliasing > -fPIC -o CMakeFiles/osgdb_osgjs.dir/Base64.o -c > /wrkdirs/usr/ports/graphics/osg-devel/work/OpenSceneGraph-3.5.1/src/osgPlugins/osgjs/Base64.cpp > c++ -O2 -pipe -fstack-protector -fno-strict-aliasing-fstack-protector > /wrkdirs/usr/ports/graphics/osg-devel/work/OpenSceneGraph-3.5.1/src/osgPlugins/osgjs/WriteVisitor.cpp > -o > /wrkdirs/usr/ports/graphics/osg-devel/work/OpenSceneGraph-3.5.1/src/osgPlugins/osgjs/WriteVisitor > In file included from > /wrkdirs/usr/ports/graphics/osg-devel/work/OpenSceneGraph-3.5.1/src/osgPlugins/osgjs/WriteVisitor.cpp:1: > /wrkdirs/usr/ports/graphics/osg-devel/work/OpenSceneGraph-3.5.1/src/osgPlugins/osgjs/WriteVisitor:5:10: > fatal error: 'osg/Image' file not found > #include <osg/Image> > ^ > 1 error generated. > *** Error code 1 Any ideas what the problem could be? Thanks in advance, Ben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=66914#66914 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgOcean] Cylinder/Skydome flicker when using CompositeView
Hi, I've done some more poking around and I've found out a few things. If I disable the cylinder completely by simply not adding the _oceanCylinderMT child to the _oceanTransform group in OceanScene.cpp, then the flashing stops. The flashing occurs over the water. The effect is seemingly random, but the color that is shown seems to be the _aboveWaterFogColor, which is odd because the cylinder uses the _underWaterWaterFogColor. I set the above to pure green and the under to pure red and the color that flashes is green. The problem goes away if I reduce my cylinder/skydome size. My application requires a far viewing distance so I've set the respective sizes to 30,000. When I bump the size back down to 1,900 (as is set in the ocean example), the flashing doesn't occur. However, I'd like the flexibility to set my viewing distance to be much farther than 1,900. Thank you! Cheers, Ben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=63162#63162 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [osgOcean] Cylinder/Skydome flicker when using CompositeView
Hi,
I'm using osgOcean in a multi-view, multi-graphics card configuration and I'm
encountering a problem with the ocean's cylinder and skydome causing
flickering effects.
Setup
My setup is that I have 6 cameras all looking into the same scene. They all
have the same position but different orientations and frustums. They all render
to different screens and they're all on their own graphics card. I've disabled
most advanced rendering effects such as:
Refractions
God rays
Silt
Underwater DOF
Glare
Distortion
I have the latest bits from the osgOcean repository and have no problem
compiling them. I'm using FFTSS 3.0.
Main Problem
My problem is that with multiple views and one ocean, I'm seeing that the
skydome and the cylinder tend to move around as if they're on a different
screen. For example, when I'm viewing the ocean at an angle (some degree of
roll), I tend to see one view's cylinder geometry appear on another view's
scene. This produces a brief one-frame flicker effect that is very distracting.
With the skydome, I imagine a similar problem is happening (due to how they're
both updated per view) but it just seems to flicker in and out of visibility.
Attempted Solution
I figured this was a threading issue where one thread would use the values of
another thread's operations. With that in mind, I added multiple
CameraTrackCallbacks to the ocean scene, each referencing the main camera of
one of the views. In operator(), I would check the stored Camera pointer
against the camera obtained through cv-getRenderStage()-getCamera() to see if
the pointers were equal. If so, I would continue to update the cylinder
position. If not, I would continue to traverse.
This seemed to work great for the skydome (no more flickering!) but not as well
for the cylinder.
Example code for adding a new CameraTrackCallback for the skydome:
Code:
void attachCamera(osg::Camera* camera) {
osg::MatrixTransform* transform = new osg::MatrixTransform;
transform-setDataVariance(osg::Object::DYNAMIC);
transform-setMatrix(osg::Matrixf::translate(osg::Vec3f(0.f, 0.f, 0.f)));
transform-setCullCallback(new CameraTrackCallback(camera));
transform-addChild(m_skyDome.get());
m_oceanScene-addChild(transform);
m_oceanScene-addCamera(camera);
}
Side Problem (with solution!)
A problem I did find a solution to was just using osgOcean with a Composite
Viewer set to ThreadPerContext or ThreadPerCamera. In OceanScene.cpp's
CameraTrackCallback::createOrReuseMatrix, I tended to get deletions on
allocated matrices that were already deleted within moments of running my app.
I threw in a mutex that would scope lock within the function which fixed this
but not the flicker.
Question
Has anyone else encountered this issue? Maybe I'm setting up my ocean wrong.
I'm using a modified version of the Scene in the oceanExample project to set up
the OceanScene.
Thank you!
Cheers,
Ben[/list]
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=63144#63144
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Slaves, RTT, and HUD
Hey Robert, Thanks for the reply. I've finally gotten around to implementing a solution to this problem. Unfortunately, when I added the text HUD camera as a child to the RTT main camera, I still wasn't seeing my HUD. However, if I turn the HUD camera into another RTT camera and attach it to the texture of the main RTT camera (with only the GL_DEPTH_BUFFER_BIT set as the clear mask) then it works great! From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Wednesday, November 05, 2014 12:42 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Slaves, RTT, and HUD Hi Ben, Try placing the Text HUD Camera in the scene graph underneath the main scene Camera and leave all the frame buffer/texture attachment settings blank, this way it'll inherit the current frame buffer configuration from it's parent. Robert. On 4 November 2014 20:58, Ben Strukus ben.stru...@flyte.commailto:ben.stru...@flyte.com wrote: Hi Robert, The osgdistortion example is a great resource and I've used it quite a bit to set up the RTT and the distortion mesh, however when it comes to rendering a HUD (text, in my case) to that texture using slaves, I'm not seeing that being done in the example. Here's what I have: - A slave camera that renders the main scene to a texture. - A slave camera that renders a screen-space mesh with the above texture applied to it. - A lone camera acting as a HUD that I would like to render to the texture, but can't seem to get this working. I've tried attaching the lone camera as a child of the RTT camera, and that doesn't seem to work. I can get it to work when the RTT camera isn't a slave, but as soon as I make it a slave it doesn't work. I can get the HUD to render directly to the screen when I attach it as a child of the screen-space mesh camera, however it won't appear distorted. From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.orgmailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Tuesday, November 04, 2014 12:14 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Slaves, RTT, and HUD Hi Ben, Have a look at the osgdistortion example as it does exactly what you describe you want to do. Robert. On 4 November 2014 19:53, Ben Strukus ben.stru...@flyte.commailto:ben.stru...@flyte.com wrote: Hello, I'm looking to get the following scenario working: A scene with a HUD rendering on a distortion mesh using slave cameras. What I've tried so far is... 1. A normal Viewer class with two Cameras in the scene graph, one on a pre-render pass that renders the main scene to a texture and one on a post-render pass that renders a screen space mesh with the other Camera's texture applied to it. 2. A Viewer class with two Cameras attached as slaves, with the same pre- and post-render setup as above. The RTT (pre-render) Camera has the main scene as the child and the mesh (post-render) Camera has just the screen space mesh as a child. For these, I can get a HUD displaying on the following Cameras when I attach it as a child to the respective Camera: - 1's pre-render Camera, attached to the texture and set up as a FBO - 1's post-render Camera - 2's post-render Camera For my HUD, I'm simply creating a Camera with an Absolute reference frame, orthogonal 2D projection, and on the post-render pass. See osghud.cpp, as I've pretty much copied that with the modification of an optional Texture parameter. The part I'm having trouble getting to work is getting that HUD rendering to a texture when that RTT Camera is a slave of a View. The thing that baffles me is I can get it working on a non-slave RTT Camera in the same way, and I can get it working on a non-RTT slave Camera, but not the intersection of both. I've tried searching for a similar solution, but I haven't found anything for this specific scenario. Any help or direction would be appreciated. :) ___ osg-users mailing list osg-users@lists.openscenegraph.orgmailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.orgmailto: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] Aborting frames that take too long
I did some more research into what's going on and, on a hunch, changed my threading model from ThreadPerCamera (default for my PC) to SingleThreaded and ThreadPerContext. I found that setAbortRenderPtr does indeed lock up the camera thread on ThreadPerCamera, however it seems to behave 100% correctly (in not rendering anything when enabled) under the SingleThreaded and ThreadPerContext models. An easy way to reproduce it would be to add a keyboard input event handler that calls setAbortRenderPtr on the viewer state. With ThreadPerCamera, the scene should lock up. With the other models, it should just stop rendering though still remain responsive. From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Ben Strukus Sent: Monday, January 19, 2015 4:08 PM To: OpenSceneGraph Users Subject: [osg-users] Aborting frames that take too long Hi, I'm having a problem trying to use OSG for a specific scenario. My simulation contains several screens all showing the same scene at different angles (think projector setup). I'd like to synchronize the frames among them so that tearing between screens is minimal. Due to the nature of my scenes, some screens will have more to render than others and, as a result, take longer to render (ground vs sky). I'm looking for a way to interrupt a render loop and restart it if I detect it's taking too long for my liking. I've looked at a few proposed solutions by others with a similar problem and I've found about the osg::State::setAbortRenderingPtr(bool*). That indeed cancels the current frame, but it causes the viewer to get locked up waiting for a mutex to become available in the Renderer::ThreadSafeQueue::takeFront() function called from the Renderer::draw() function. I've tried setting the abortRenderPtr to NULL every frame (using the FRAME event on osgGA::GUIEventAdapter) and setting it to NULL immediately after it's been checked in RenderLeaf::render, though that doesn't seem to change anything. The wait function still takes control. I've read that the setAbortRenderingPtr function is old, but is there any knowledge about how it's supposed to be used? Also, if that doesn't seem like the solution for my scenario, does anyone have any suggestions? Thanks! - Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Aborting frames that take too long
Hi, I'm having a problem trying to use OSG for a specific scenario. My simulation contains several screens all showing the same scene at different angles (think projector setup). I'd like to synchronize the frames among them so that tearing between screens is minimal. Due to the nature of my scenes, some screens will have more to render than others and, as a result, take longer to render (ground vs sky). I'm looking for a way to interrupt a render loop and restart it if I detect it's taking too long for my liking. I've looked at a few proposed solutions by others with a similar problem and I've found about the osg::State::setAbortRenderingPtr(bool*). That indeed cancels the current frame, but it causes the viewer to get locked up waiting for a mutex to become available in the Renderer::ThreadSafeQueue::takeFront() function called from the Renderer::draw() function. I've tried setting the abortRenderPtr to NULL every frame (using the FRAME event on osgGA::GUIEventAdapter) and setting it to NULL immediately after it's been checked in RenderLeaf::render, though that doesn't seem to change anything. The wait function still takes control. I've read that the setAbortRenderingPtr function is old, but is there any knowledge about how it's supposed to be used? Also, if that doesn't seem like the solution for my scenario, does anyone have any suggestions? Thanks! - Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Slaves, RTT, and HUD
Hello, I'm looking to get the following scenario working: A scene with a HUD rendering on a distortion mesh using slave cameras. What I've tried so far is... 1. A normal Viewer class with two Cameras in the scene graph, one on a pre-render pass that renders the main scene to a texture and one on a post-render pass that renders a screen space mesh with the other Camera's texture applied to it. 2. A Viewer class with two Cameras attached as slaves, with the same pre- and post-render setup as above. The RTT (pre-render) Camera has the main scene as the child and the mesh (post-render) Camera has just the screen space mesh as a child. For these, I can get a HUD displaying on the following Cameras when I attach it as a child to the respective Camera: - 1's pre-render Camera, attached to the texture and set up as a FBO - 1's post-render Camera - 2's post-render Camera For my HUD, I'm simply creating a Camera with an Absolute reference frame, orthogonal 2D projection, and on the post-render pass. See osghud.cpp, as I've pretty much copied that with the modification of an optional Texture parameter. The part I'm having trouble getting to work is getting that HUD rendering to a texture when that RTT Camera is a slave of a View. The thing that baffles me is I can get it working on a non-slave RTT Camera in the same way, and I can get it working on a non-RTT slave Camera, but not the intersection of both. I've tried searching for a similar solution, but I haven't found anything for this specific scenario. Any help or direction would be appreciated. :) ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Slaves, RTT, and HUD
Hi Robert, The osgdistortion example is a great resource and I've used it quite a bit to set up the RTT and the distortion mesh, however when it comes to rendering a HUD (text, in my case) to that texture using slaves, I'm not seeing that being done in the example. Here's what I have: - A slave camera that renders the main scene to a texture. - A slave camera that renders a screen-space mesh with the above texture applied to it. - A lone camera acting as a HUD that I would like to render to the texture, but can't seem to get this working. I've tried attaching the lone camera as a child of the RTT camera, and that doesn't seem to work. I can get it to work when the RTT camera isn't a slave, but as soon as I make it a slave it doesn't work. I can get the HUD to render directly to the screen when I attach it as a child of the screen-space mesh camera, however it won't appear distorted. From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Tuesday, November 04, 2014 12:14 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Slaves, RTT, and HUD Hi Ben, Have a look at the osgdistortion example as it does exactly what you describe you want to do. Robert. On 4 November 2014 19:53, Ben Strukus ben.stru...@flyte.commailto:ben.stru...@flyte.com wrote: Hello, I'm looking to get the following scenario working: A scene with a HUD rendering on a distortion mesh using slave cameras. What I've tried so far is... 1. A normal Viewer class with two Cameras in the scene graph, one on a pre-render pass that renders the main scene to a texture and one on a post-render pass that renders a screen space mesh with the other Camera's texture applied to it. 2. A Viewer class with two Cameras attached as slaves, with the same pre- and post-render setup as above. The RTT (pre-render) Camera has the main scene as the child and the mesh (post-render) Camera has just the screen space mesh as a child. For these, I can get a HUD displaying on the following Cameras when I attach it as a child to the respective Camera: - 1's pre-render Camera, attached to the texture and set up as a FBO - 1's post-render Camera - 2's post-render Camera For my HUD, I'm simply creating a Camera with an Absolute reference frame, orthogonal 2D projection, and on the post-render pass. See osghud.cpp, as I've pretty much copied that with the modification of an optional Texture parameter. The part I'm having trouble getting to work is getting that HUD rendering to a texture when that RTT Camera is a slave of a View. The thing that baffles me is I can get it working on a non-slave RTT Camera in the same way, and I can get it working on a non-RTT slave Camera, but not the intersection of both. I've tried searching for a similar solution, but I haven't found anything for this specific scenario. Any help or direction would be appreciated. :) ___ osg-users mailing list osg-users@lists.openscenegraph.orgmailto: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] Precise world to screen space transformation
Hi, I would like to get the screen space coordinates of a label in world space. I found a method by which it is supposed to work—by taking points from the bounding box and multiplying them by a few matrices. The points convert fine to screen space coordinates, but this doesn't give me a precise fit. I (again for the screenshots) started a StackOverflow question on this, back when I didn't realize that I couldn't just take two points from the bounding box: http://stackoverflow.com/questions/25999868/world-to-screen-space-coordinates-in-openscenegraph If I calculate this for all points of the bounding box, and take the max/min x and y coordinates, then I get a screen space box that is too big. Is there a good way to get a precise screen space representation of a flat label in screen space? Thanks for your help! :-) Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Warped scene with two sets of Geodes
Hi Robert,
I found out what the Problem was—it *was* my code :-)
In particular, it looks like mixing doubles and floats is very bad.
Pretty much everything is a float except for the vertex array of a street.
If I change that to float and convert the Points to Vec3 instead of
Vec3d, then everything is good.
Do you understand why this is a problem though?
Thanks,
–Ben
On Tue, Sep 2, 2014 at 12:01 PM, Ben Morgan nee...@gmail.com wrote:
Hi Robert,
thanks for your reply. I'm kinda new in the OSG/OpenGL field, so I'm
thankful for all the help and advice I can get.
The goal of the project I'm working on is to develop algorithms for
street label positioning on an active route. So I have a street
network, a pointer that moves along a route in the network and a
camera that follows the pointer, and then I have a bunch of labels
that I position and move around. (I think I might have written
something in this mailing list two years ago.)
I never thought that it could be anything other than a mistake of my
own. The problem occurs on the following configurations:
Thinkpad T420 with i5 CPU/Graphics Card (Intel HD3000 I think)
Arch Linux 3.16.1
OSG version 3.2.1
OSG version 3.0.1
G++ version 4.9.1
Intel Video Driver version 2.99.914
Intel DRI Software version 10.2.6
Thinkpad T60 with Radeon Graphics Card
(I only did this quickly, so I don't have all the details)
Arch Linux 3.16.1
OSG version 3.2.1
G++ version 4.9.1
I tried another program that I knew was working two years ago on this
computer, and it has a similar issue (though different) now—the
pointer is just not there. Additionally, the osgText labels are not
showing up either.
The past few days since your response, I also worked on getting it to
compile on Windows 7, with Visual Studio 12. (FYI: I had to add an
#include algorithm to osgText/Glyph.cpp for it to compile, otherwise
it didn't see min/max.) I'll write again after I finish that.
Is there a better way to represent the street network? Should I have a
Group containing a bunch of street lines and then apply color and line
width at that level? Or do I store the street lines all in a single
Geode?
I updated (and simplified) the source code listing to include the
pointer drawing code—perhaps the problem lies there? (I also changed
the street network to contain a bunch of drawables inside a single
Geode. Is it better that way? Or am I going a completely wrong
direction with that?)
Thanks again for your help!
–Ben
PS: And here is the updated source code (also updated at StackOverflow):
// My libraries:
#include asl/util/color.h
using namespace asl;
#include straph/point.h
#include straph/straph.h
using namespace straph;
// Standard and OSG libraries:
#include utility
#include boost/tuple/tuple.hpp // tie
using namespace std;
#include osg/ref_ptr
#include osg/Array
#include osg/Geometry
#include osg/Geode
#include osg/Group
#include osg/LineWidth
using namespace osg;
#include osgUtil/Tessellator
#include osgViewer/Viewer
using namespace osgViewer;
/*
* Just FYI: A Polyline looks like this:
*
* typedef std::vectorPoint Polyline;
*
* And a Point basically is a simple struct:
*
* struct Point {
* double x;
* double y;
* };
*/
inline osg::Vec3d toVec3d(const straph::Point p, double elevation=0.0)
{
return osg::Vec3d(p.x, p.y, elevation);
}
Geometry* createStreet(const straph::Polyline path)
{
ref_ptrVec3dArray array (new Vec3dArray(path.size()));
for (unsigned i = 0; i path.size(); ++i) {
(*array)[i] = toVec3d(path[i]);
}
Geometry* geom = new Geometry;
geom-setVertexArray(array.get());
geom-addPrimitiveSet(new osg::DrawArrays(GL_LINE_STRIP, 0,
array-size()));
return geom;
}
Geode* load_streets()
{
unique_ptrStraph graph = read_shapefile(mexico/roads, 6);
Geode* root = new Geode();
boost::graph_traitsstraph::Straph::edge_iterator ei, ee;
for (boost::tie(ei, ee) = edges(*graph); ei != ee; ++ei) {
const straph::Segment s = (*graph)[*ei];
root-addDrawable(createStreet(s.polyline));
}
return root;
}
Geode* createPointer(double width, const Color body_color)
{
float f0 = 0.0f;
float f3 = 3.0f;
float f1 = 1.0f * width;
float f2 = 2.0f * width;
// Create vertex array
ref_ptrVec3Array vertices (new Vec3Array(4));
(*vertices)[0].set( f0 , f0, f0 );
(*vertices)[1].set( -f1/f3, -f1/f3 , f0 );
(*vertices)[2].set( f0 , f2/f3 , f0 );
(*vertices)[3].set( f1/f3, -f1/f3 , f0 );
// Build the geometry object
Re: [osg-users] Warped scene with two sets of Geodes
Hi Robert,
thanks for your reply. I'm kinda new in the OSG/OpenGL field, so I'm
thankful for all the help and advice I can get.
The goal of the project I'm working on is to develop algorithms for
street label positioning on an active route. So I have a street
network, a pointer that moves along a route in the network and a
camera that follows the pointer, and then I have a bunch of labels
that I position and move around. (I think I might have written
something in this mailing list two years ago.)
I never thought that it could be anything other than a mistake of my
own. The problem occurs on the following configurations:
Thinkpad T420 with i5 CPU/Graphics Card (Intel HD3000 I think)
Arch Linux 3.16.1
OSG version 3.2.1
OSG version 3.0.1
G++ version 4.9.1
Intel Video Driver version 2.99.914
Intel DRI Software version 10.2.6
Thinkpad T60 with Radeon Graphics Card
(I only did this quickly, so I don't have all the details)
Arch Linux 3.16.1
OSG version 3.2.1
G++ version 4.9.1
I tried another program that I knew was working two years ago on this
computer, and it has a similar issue (though different) now—the
pointer is just not there. Additionally, the osgText labels are not
showing up either.
The past few days since your response, I also worked on getting it to
compile on Windows 7, with Visual Studio 12. (FYI: I had to add an
#include algorithm to osgText/Glyph.cpp for it to compile, otherwise
it didn't see min/max.) I'll write again after I finish that.
Is there a better way to represent the street network? Should I have a
Group containing a bunch of street lines and then apply color and line
width at that level? Or do I store the street lines all in a single
Geode?
I updated (and simplified) the source code listing to include the
pointer drawing code—perhaps the problem lies there? (I also changed
the street network to contain a bunch of drawables inside a single
Geode. Is it better that way? Or am I going a completely wrong
direction with that?)
Thanks again for your help!
–Ben
PS: And here is the updated source code (also updated at StackOverflow):
// My libraries:
#include asl/util/color.h
using namespace asl;
#include straph/point.h
#include straph/straph.h
using namespace straph;
// Standard and OSG libraries:
#include utility
#include boost/tuple/tuple.hpp // tie
using namespace std;
#include osg/ref_ptr
#include osg/Array
#include osg/Geometry
#include osg/Geode
#include osg/Group
#include osg/LineWidth
using namespace osg;
#include osgUtil/Tessellator
#include osgViewer/Viewer
using namespace osgViewer;
/*
* Just FYI: A Polyline looks like this:
*
* typedef std::vectorPoint Polyline;
*
* And a Point basically is a simple struct:
*
* struct Point {
* double x;
* double y;
* };
*/
inline osg::Vec3d toVec3d(const straph::Point p, double elevation=0.0)
{
return osg::Vec3d(p.x, p.y, elevation);
}
Geometry* createStreet(const straph::Polyline path)
{
ref_ptrVec3dArray array (new Vec3dArray(path.size()));
for (unsigned i = 0; i path.size(); ++i) {
(*array)[i] = toVec3d(path[i]);
}
Geometry* geom = new Geometry;
geom-setVertexArray(array.get());
geom-addPrimitiveSet(new osg::DrawArrays(GL_LINE_STRIP, 0,
array-size()));
return geom;
}
Geode* load_streets()
{
unique_ptrStraph graph = read_shapefile(mexico/roads, 6);
Geode* root = new Geode();
boost::graph_traitsstraph::Straph::edge_iterator ei, ee;
for (boost::tie(ei, ee) = edges(*graph); ei != ee; ++ei) {
const straph::Segment s = (*graph)[*ei];
root-addDrawable(createStreet(s.polyline));
}
return root;
}
Geode* createPointer(double width, const Color body_color)
{
float f0 = 0.0f;
float f3 = 3.0f;
float f1 = 1.0f * width;
float f2 = 2.0f * width;
// Create vertex array
ref_ptrVec3Array vertices (new Vec3Array(4));
(*vertices)[0].set( f0 , f0, f0 );
(*vertices)[1].set( -f1/f3, -f1/f3 , f0 );
(*vertices)[2].set( f0 , f2/f3 , f0 );
(*vertices)[3].set( f1/f3, -f1/f3 , f0 );
// Build the geometry object
ref_ptrGeometry polygon (new Geometry);
polygon-setVertexArray( vertices.get() );
polygon-addPrimitiveSet( new DrawArrays(GL_POLYGON, 0, 4) );
// Set the colors
ref_ptrVec4Array body_colors (new Vec4Array(1));
(*body_colors)[0] = body_color.get();
polygon-setColorArray( body_colors.get() );
polygon-setColorBinding( Geometry::BIND_OVERALL );
// Create Geode object
Geode* geode = new Geode;
geode-addDrawable( polygon.get() );
return geode;
}
int main
[osg-users] Warped scene with two sets of Geodes
I did post this question on StackOverflow (
http://stackoverflow.com/questions/25576762/warped-scene-with-two-sets-of-geodes
), but I assume that this is a more appropriate place for questions.
I have a few objects that I want to combine into a scene graph:
Street inherits from Geode and has a Geometry child drawable made up
of a GL_LINE_STRIP.
Pointer inherits from PositionAttitudeTransform and contains a Geode
which contains two Geometry polygons.
When I add a bunch of Streets to a Group, it looks just fine. When I
add only the Pointer to a Group, it also looks fine. But if I somehow
have them both in the scene, the second one is screwed up. (This does
not happen if I have only two Pointers.) I posted some screenshots on
the StackOverflow site, in case you want to see them. Probably I’m
making some simple mistake—but I can’t see it!
Here is some code that causes the problem (I tried to shorten it a little):
// My libraries:
#include asl/util/draw.h
#include asl/util/color.h
using namespace asl;
#include straph/point.h
#include straph/straph.h
using namespace straph;
// Standard and OSG libraries:
#include utility
#include boost/tuple/tuple.hpp // tie
using namespace std;
#include osg/ref_ptr
#include osg/Array
#include osg/Geometry
#include osg/Group
#include osg/LineWidth
using namespace osg;
#include osgUtil/Optimizer
#include osgViewer/Viewer
#include osgViewer/ViewerEventHandlers
using namespace osgViewer;
Geode* createStreet(const straph::Polyline path, double width, const
Color color)
{
ref_ptrGeometry geom (new Geometry);
// Set the shape:
ref_ptrVec3dArray array (new Vec3dArray(path.size()));
for (unsigned i = 0; i path.size(); ++i) {
(*array)[i] = toVec3d(path[i]);
}
geom-setVertexArray(array.get());
geom-addPrimitiveSet(new osg::DrawArrays(GL_LINE_STRIP, 0, array-size()));
// Set the normals:
ref_ptrVec3Array normals (new Vec3Array(1));
(*normals)[0].set( 0.0f, 0.0f, 1.0f );
geom-setNormalArray( normals.get() );
geom-setNormalBinding( Geometry::BIND_OVERALL );
// Set the colors:
ref_ptrVec4Array colors = new Vec4Array();
colors-push_back(color.get());
geom-setColorArray(colors);
geom-setColorBinding(osg::Geometry::BIND_OVERALL);
Geode* g = new Geode();
g-addDrawable(geom.get());
// Set the line width.
ref_ptrLineWidth lwidth (new LineWidth);
lwidth-setWidth(width);
g-getOrCreateStateSet()-setAttributeAndModes(lwidth, StateAttribute::ON);
return g;
}
Group* load_streets()
{
unique_ptrStraph graph = read_shapefile(mexico/roads, 6);
Group* root = new Group();
boost::graph_traitsstraph::Straph::edge_iterator ei, ee;
for (boost::tie(ei, ee) = edges(*graph); ei != ee; ++ei) {
const straph::Segment s = (*graph)[*ei];
root-addChild(createStreet(s.polyline, 2.0, TangoColor::Aluminium4));
}
return root;
}
int main(int, char**)
{
Group* root = load_streets();
Pointer* p = new Pointer(6.0, TangoColor::Scarlet3, TangoColor::Black);
root-addChild(p);
Viewer viewer;
viewer.setSceneData(root);
viewer.getCamera()-setClearColor(Color(TangoColor::White).get());
viewer.run();
}
Thanks for the help! :-)

–Ben Morgan
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Converting TerraPage to IVE
It's puzzling why the initial page-in of the highest LOD is so slow. My apologies for long post (trying to be complete in description). As a test, I removed all the directory children nodes except for 1 cell. The original directory structure consisted of 2 levels (1st containing 26 children subdirectories, and each of those children containing 15 additional children subdirectories) ... for a total of 390 cells (26x15=390). My assumption was that removing the other nodes would cause the 1 remaining cell to load much more quickly, since the remaining cells wouldn't be available to load. Unfortunately, the 1st time to load the highest LOD for the 1 remaining cell still took over 30 seconds. It seems removing the other cells had no effect. I've noticed there are many buildings used that are OpenFlight format. They all reside at the top-level of the directory tree. Is it the compile time to load the buildings that's the problem ... rather than the terrain itself? If so, I wish I could tweak the TerraPage files to reference IVE versions of the buildings rather than FLT. Am I missing something here? Is it possible to edit the top-level TerraPage file and remove the references to all the other nodes and change to IVE buildings -- without terrain tools? For now, I only care about one cell. BTW, the render frame rate is at a steady 60Hz. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42902#42902 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Converting TerraPage to IVE
Hello, Is there a way (e.g. using osgconv or similar) to convert a TerraPage format database (.txp, txf, tpf) to OSG native format (.ive)? Note that the TerraPage database (in this case) has a multi-level directory tree structure containing many children. The file paging is horrendous with the raw TerraPage format. I'm wondering if the paging might be more efficient with an OSG native optimized format. Thanks, Ben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42882#42882 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 2.9.9 compile issues on Mac with Qt 4.6.3, other Qt issues
Hi Chuck all, Did this ever get addressed? I have an OSG 2.8.3 app which i am trying to port to 64-bit Mac (i.e. Cocoa). As of 2.8.4, i see that QOSGWidget.cpp still has this limitation: #elif defined(__APPLE__) // Assume using Carbon on Mac. Is it worth continuing to try to build 2.8.3's QOSGWidget for Cocoa, has anyone ever made it work? Or will i need to bite the bullet and move over to OSG 2.9.12, which apparently has entirely different Qt / Cocoa integration. Thanks, Ben -Original Message- From: Chuck Shaw Sent: Sunday, October 17, 2010 1:37 PM To: osg-users@lists.openscenegraph.org Robert, Sure, i'll be happy to fix it. Chuck -Original Message- From: Robert Osfield Sent: Sunday, October 17, 2010 11:46 AM To: osg-users@lists.openscenegraph.org Hi Chuck, Could you have a bash at getting osgviewerQtWidget to compile with Qt's Cocoa? Thanks, Robert. -Original Message- From: Chuck Shaw Sent: Saturday, October 16, 2010 9:16 PM To: osg-users@lists.openscenegraph.org On Mac OSX, example_osgviewerQT and example_osgviewerQtWidget do not compile on 64bit with Qt's Cocoa. They are hard coded to 32 bit Carbon. . i.e. #elif defined(__APPLE__) // Assume using Carbon on Mac. Chuck ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] OSG and SDL
If you just want to use SDL to read joystick inputs, you don't have to use SDL windows. You can use SDL for joystick inputs, and render OGS to windows managed by Qt, CEGUI, or whatever meets your needs. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Logitech Joystick Extreme 3D pro USB OSG
I've used SDL (Simple Direcmedia Layer) alongside OSG with success (for the Joystick you mentioned as well as gamepads, etc.). SDL is lightweight and simple to use. http://www.libsdl.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Invitation to connect on LinkedIn
LinkedIn OpenSceneGraph, I'd like to add you to my professional network on LinkedIn. - Shoham Shoham Ben-Har Software Eng. at Classified Israel Confirm that you know Shoham Ben-Har https://www.linkedin.com/e/-qywqtf-gd923034-5v/isd/1596264912/hRMVNAaT/ -- (c) 2010, LinkedIn Corporation___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Scaling an Object - Normals
// Normalize normals to correct lighting from the scaling operation. object-getOrCreateStateSet()-setMode(GL_NORMALIZE, osg::StateAttribute::ON); On Fri, Jun 11, 2010 at 4:27 PM, Thomas Canipel thomas.cani...@gmail.com wrote: Hi, I would like to know how I can re-scale the normal of an object loaded after scale the object ? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Scaling an Object - Normals
Mail got formated oddly ... trying again. // Normalize normals to correct lighting from the scaling operation. object-getOrCreateStateSet()-setMode(GL_NORMALIZE,osg::StateAttribute::ON); On 6/11/10, Ben Cain brca...@gmail.com wrote: // Normalize normals to correct lighting from the scaling operation. object-getOrCreateStateSet()-setMode(GL_NORMALIZE, osg::StateAttribute::ON); On Fri, Jun 11, 2010 at 4:27 PM, Thomas Canipel thomas.cani...@gmail.com wrote: Hi, I would like to know how I can re-scale the normal of an object loaded after scale the object ? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to perform a linesegmnt intersection technique?
Here's a utility I wrote ... hope it helps
#include limits
#include iostream
// ...
bool intersect(osg::Node * node, osg::Vec3 pos1, osg::Vec3 pos2,
osg::Vec3 impactPos)
{
bool impact(false);
impactPos = osg::Vec3(std::numeric_limitsdouble::signaling_NaN(),
std::numeric_limitsdouble::signaling_NaN(),
std::numeric_limitsdouble::signaling_NaN());
osgUtil::IntersectVisitor findIntersectionVisitor;
osg::LineSegment * tgtLocSegment(new osg::LineSegment);
tgtLocSegment-set(pos1, pos2);
findIntersectionVisitor.addLineSegment(tgtLocSegment);
node-accept(findIntersectionVisitor);
osgUtil::Hit heightTestResults;
if(findIntersectionVisitor.hits() == true)
{
osgUtil::IntersectVisitor::HitList tgtLocHits =
findIntersectionVisitor.getHitList(tgtLocSegment);
if(!tgtLocHits.empty())
{
impact = true;
heightTestResults = tgtLocHits.front();
impactPos = heightTestResults.getWorldIntersectPoint();
std::cout intersection @ (
impactPos.x() ,
impactPos.y() ,
impactPos.z() ) std::endl;
}
}
return impact;
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Use namespace...
I have found it much safer/easier (in the long run) to not collapse the namespaces. It's a lot of trouble to go back and correct the problem when you start integrating other toolkits. Just my 2 cents worth. On 13 April 2010 17:12, mas oug mas...@gmail.com wrote: Hi, Just curious, I noticed that in a lot of the code, we use stuff like osg::someFunctio() and etc... Could we use a namespace using namespace osg; to avoid having to write osg:: every single time? THANKS!! -Masoug ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer and multiple QGLWidgets
Thanks J-S, I think I have it working now. Although, like you said, the adapter widget will force me to use single-threading mode. My real goal is to have one scene with shared textures, etc. (in shared context) used across multiple windows in a QWorkspace. I wish there was a osgQt library of sorts ... rather than having to tweak example code to get the OSG/Qt support. The Delta3D community provides some Qt/OSG help with their dtQt library. I think it grew out of the Delta3D STAGE development effort (having followed it's code somewhat). They mentioned submitting some of this back to OSG. Here's hoping. Cheers, Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer and multiple QGLWidgets
On 4/9/10, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Ben, I wish there was a osgQt library of sorts ... rather than having to tweak example code to get the OSG/Qt support. Funny you should mention it, there is now :-) KUDOS!!! :) Whoo hoo! Btw, I have a great deal of Qt experience. I'll definitely do what I can to contribute back. I've actually been using Qt for quite a while too, but have struggled at times with the Qt/OSG and Qt/Delta3D integration. Cheers, Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] CompositeViewer and multiple QGLWidgets
Can osgViewer::CompositeViewer be used to manage views in different QGLWidgets? I'm trying to develop an application with a CAD-like interface ... showing multiple views of the same scene (e.g. MDI look-and-feel). In this case, the context is to be shared across all the views ... referencing just one scene. Each view should be able to have it's own camera manipulator, event handlers, etc. Any help much appreciated! Cheers, Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer and multiple QGLWidgets
Guys, much thanks for the inputs! I am getting very confused with shared context using Qt and OSG. I've done this many times over the years with straight OpenGL ... just too stupid tonight to figure out what I'm messing up. BTW, I've been using the OSGAdapterWidget ... trying to specify sharedContext with traits. Unfortunately, everything except the first view is outside of its parent Qt widget (that is in a QWorkspace) ... odd. It shows up on the main desktop with no window decorations. Probably not describing this well. Sorry, it's late. I've looked at all the OSG examples as well as some Delta3D examples, but I can't find one that is Qt based and sharing the graphics context and a single scene. Do you have a simple example? I'd give a weeks salary :) ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG and QT example
mgb_osg wrote: Not sure if it's what you mean but you can easily create multiple OSGWidget windows with the same osg scene data in each of them and have different views into the same model in different windows. There are issues thut must be addressed: multi-threading, thread-safety, Qt keyboard mapping, and context management. The Delta3D dtQt plug-in provides a wrapper for these issues. I was wondering if someone had a simple example using these (or similar). -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=26531#26531 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG and QT example
LEgregius wrote: Hi, Yes, it does fix the keyboard issues, at least most of them, and I have done some minor testing with the threading and it seems to work. Hey David, I'm not sure if this thread is still alive, but have you tested the case of rendering a single OSG scene-graph in multiple Qt windows (i.e. sharing the same graphics context)? If so, do you have a Hello, World example of this with the dtQt elements you referenced? Cheers, Ben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=26498#26498 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Publicly Available TerraPage Database
Ryan.H.Kawicki wrote: We currently have a publicly available database. It is small and not very complex, [...] If you like, I can also make this available to the OSG community. In its uncompressed form, it is about 150 MB. Hi Ryan, I'd be very interested in a sample TerraPage database (simple or not). Can you provide URL? Any compressed format is good (e.g. RAR, ZIP, TAR, ...). Thanks, Ben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=26368#26368 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rapidly updating texture data
Yep, now I can use the full camera resolution of 1024x768. I knew OpenGL 2.x could handle non-power of two textures ... didn't realize it was possible to circumvent the resize. Thanks much Jason. Kudos! On 3/3/10, Jason Daly jd...@ist.ucf.edu wrote: Both Texture2D and TextureRectangle can work with non-power of two textures, if your graphics hardware supports it. Every OpenGL 2.0-compatible graphics card should handle this without a problem. The simplest thing to do is to call setResizeNonPowerOfTwoHint(false) on your Texture2D object, and all should be well. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rapidly updating texture data
Oh my goodness ... did something really stupid. I was taking the camera image which is a non-power-of-2 (1024x768). It had to be scaled down to 1024x512. Doh! It's working quite well now. On 3/2/10, J.P. Delport jpdelp...@csir.co.za wrote: Hi Ben, I rechecked our code and we are using setImage without problem for 5 simult 1360x1024 cameras each at 20Hz. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rapidly updating texture data
Thanks J.P. You say that I can call myim-dirty() or myim-setImage(), but wouldn't calling myim-setImage() cause a slow update? That's what I seem to be experiencing. I need to update based on the sensor around 30Hz. The imagery data (from sensor) is in system memory ... just trying to get a view that shows it without dropping so many frames. Thanks again, Ben On Fri, Feb 26, 2010 at 12:23 AM, J.P. Delport jpdelp...@csir.co.za wrote: Hi Ben, we also pump data from cameras into the GPU. To enable PBOs is simple: // make image osg::ref_ptrosg::Image myim = new osg::Image(); // attach pbo myim-setPixelBufferObject(new osg::PixelBufferObject(myim.get())); // point im to data, avoid copying (mod format here for your app) myim-setImage(ImageFormat_[i].getWidth(), ImageFormat_[i].getHeight(), 1, 1, GL_LUMINANCE, GL_UNSIGNED_BYTE, my_data_pointer, osg::Image::NO_DELETE); // assign to texture mytexture-setImage(myim.get()); Now, when the data update, just call myim-dirty() and all should update. You can also call setImage again. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Rapidly updating texture data
Hello, Is there a way to repeatedly/efficiently update an OSG texture's data ... for example imagery data that is being updating in system memory (e.g. from a sensor capture device). I've tried updating an OSG texture using texture2D-setImage(data) ... but it is very slow. Again, the image data is already in memory. Thanks, Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rapidly updating texture data
Thanks Jason. I've used FBOs before for render-to-texture. I'll take a look at PBOs. On Thu, Feb 25, 2010 at 3:05 PM, Jason Daly jd...@ist.ucf.edu wrote: You might try using PBOs (pixel buffer objects). I think the osgscreencapture example shows them in action. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] PositionAndAttitudeTrabsform
Hi, beginner question : i just used the PositionAndAttitudeTransform with setScale(0.1, 0.1, 0.1) to scale down an object in my scene graph. the object indeed scaled down but the light behaviour changed totaly from blue to white, like in specular highlights. for a different object it just colored everything differently. to my understanding scaling an object should not change normals or colors, and therefore the coloring should stay the same and not change that drastically. what am i missing ? Thank you! Cheers, amit -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22021#22021 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PositionAndAttitudeTrabsform
Hi, Right on the button, Thank you very much amit -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22030#22030 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Missing ShapeDrawables in .obj export
Thanks Robert, I understand ShapeDrawable is an osg construct that obj won't understand. But i was under the impression that the conversion out of the osg format would de-OSG all shapes. in other words, make a mesh out of the ShapeDrawable. But clearly this is not the case. Is this feature on the todo list? Also, i know that the VRML format has some concept of primitive shapes. Do you think that the osg to wrl conversion would include the primitive ShapeDrawables? I would just try it, but unfortunately i did not build osg with vrml writing capabilities, and i won't have the opportunity to rebuild osg for a while. Thanks, -Ben From: osg-users-boun...@lists.openscenegraph.org [osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield [robert.osfi...@gmail.com] Sent: Wednesday, November 25, 2009 5:08 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Missing ShapeDrawables in .obj export Hi Ben, Does .obj support ShapeDrawable? No... it knows nothing about ShapeDrawable so there is no way it can be exported without conveting it into another form that .obj supports. .obj support just meshes, lines and points so if you want to export to .obj then you'll need to stick to these types of objects in your scene graph. Robert, On Wed, Nov 25, 2009 at 5:34 AM, Ben Axelrod baxel...@coroware.com wrote: I have a scene that has some primitive shapes in it created with ShapeDrawables. When i save the scene to a .obj file using osgDB::writeNodeFile() the ShapeDrawables don't show up in the file, but the floor plane i created with simple geometry does. If i save it to a .osg file instead, then everything is in in the file. I get the same results if i use osgconv to convert my .osg file into a .obj. Note: i am viewing the exported files with osgviewer. And i am using OSG version 2.6. Any clue on why this is or how to get around it? Thanks, -Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Missing ShapeDrawables in .obj export
I have a scene that has some primitive shapes in it created with ShapeDrawables. When i save the scene to a .obj file using osgDB::writeNodeFile() the ShapeDrawables don't show up in the file, but the floor plane i created with simple geometry does. If i save it to a .osg file instead, then everything is in in the file. I get the same results if i use osgconv to convert my .osg file into a .obj. Note: i am viewing the exported files with osgviewer. And i am using OSG version 2.6. Any clue on why this is or how to get around it? Thanks, -Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Wayfinding / route finding
Hi there, Having never used OSG so forgive me if this is an old question - I’m really new round here! In short, is there an existing plug-in or method i could use with OSG to provide way finding or route finding functionality? The requirement i have is for large scale building/interior way finding - basically point to point from one room/location to another. Is there already something available or do i need to resource up for custom development? Thank you! Cheers, Ben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=18995#18995 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Nested transparent objects
I am trying to view transparent objects inside of other transparent objects. My objects are simple ShapeDrawables with some color and alpha transparency. I am seeing strange behavior where the inner object is sometimes completely hidden by the outer object depending on camera angle. Also, some of the object edges that should be visible are not. (Again, depending on camera angle). In the attached images: badalpha.png there is a small red cube partially inside of a larger green cube. they both have some transparency and you should be able to see through both objects. however, some edges of the green cube are completely hidden by the red cube. The desired behavior can be seen in badalphamodbyhand.png in which I modified to show what should be shown. This must be a common problem, but I searched the archives and it did not turn up much. my GL_DEPTH_TEST attribute is on as well as GL_BLEND. I am using OSG 2.6.0 with an NVidia series 7 graphics card. Is there some way to improve the transparency visualization? Thanks, -Ben attachment: badalpha.PNGattachment: badalphamodbyhand.png___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VRML Normal Issue
I think we are agreeing with each other. I agree the simplest thing for a user is to specify normals in the file for the best control over shading. And I agree that in order to support the crease angle property, we will have to duplicate vertices. Despite the crease angle being a kludge, I do think that it should be implemented. That is why I submitted the code, in case anyone wanted to implement the crease angle, I think that would be how to do it. Before, you said that duplicating vertices would lead to artifacts. Can you elaborate on this? I don't see how it would when we are in the sharp edge case, and we give it a proper normal, and point the proper face index at the new vertex. Thanks, -Ben -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jan Ciger Sent: Thursday, March 26, 2009 5:07 PM To: OpenSceneGraph Users Subject: Re: [osg-users] VRML Normal Issue -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ben Axelrod wrote: Can normals per primitive and normals per vertex both be used in a single shape? Not that I am aware of. If not, the only way I can imagine having a shape with some smooth and some sharp edges is if there is one normal per vertex per face. Just like the diagram in the VRML spec shows, if a vertex has 2 faces connected to it, it needs 2 normals for a sharp edge, and either 1 or 2 for a smooth edge. That's right, however, if you do not specify the vertex normals explicitly in the model, the vertex normals are calculated from the *face normals* using the crease angle. If the face normals have an angle smaller than the crease angle, the vertex normals will be an average of the two face normals. For sharp edges you will indeed have to duplicate the vertices to accommodate the different face normals (as explained here: http://www.songho.ca/opengl/gl_vertexarray.html) On the other hand, if you want only sharp edges, you can bind normals per face and save yourself this whole escapade. Honestly, it is simpler to export the vertex normals from whatever tool you are using to produce the data than to fidget with the crease angle - it is only a kludge to let the program guess the model author's intentions. Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJy+5tn11XseNj94gRAvHGAKCZxOcaPU9FnL73O06533yTtpSalwCg6GFc Kz6Y4w31hZgcHRjbDyna/jY= =dKWV -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VRML Normal Issue
But normals per primitive or per vertex are 'global' for the entire shape. Aren't they? The crease angle is a 'local' feature so that you can have a shape with some smooth and some sharp edges. Can normals per primitive and normals per vertex both be used in a single shape? If not, the only way I can imagine having a shape with some smooth and some sharp edges is if there is one normal per vertex per face. Just like the diagram in the VRML spec shows, if a vertex has 2 faces connected to it, it needs 2 normals for a sharp edge, and either 1 or 2 for a smooth edge. -Ben -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jan Ciger Sent: Thursday, March 26, 2009 9:08 AM To: OpenSceneGraph Users Subject: Re: [osg-users] VRML Normal Issue -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Ben Axelrod wrote: Thanks for the info. I took a look at the code. Adding crease angle support does seem tricky since I think we would have to create new vertex points on the fly to accommodate 2 or more different normal vectors at that point. Here is some off the cuff pseudo code. I do not see why you would want to do that. Just set the normal binding to be per primitive/face and not per vertex if you want to have sharp edges and define face normals. Otherwise, if the corners/edges are to be smoothed, you use normal binding per vertex and calculate normal as an average of the face normals of the faces adjacent to the vertex. There is no need to duplicate any vertices - in fact, that would only give you artifacts. Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJy34Vn11XseNj94gRAlKlAJ49ebboolwzo75PcdLNog6W5y5vtgCggSZC 2e+pdTpYqi/E3IcYBd6wj1E= =+rJG -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VRML Normal Issue
Just to clarify, the way the normals *should* work is sketched in the attached image. Please verify. When the angle between 2 faces is sharper than the crease angle, there is one normal per face, and when the angle is smoother than the crease angle, the normal is averaged. Thanks, -Ben -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jan Ciger Sent: Tuesday, March 24, 2009 1:36 PM To: OpenSceneGraph Users Subject: Re: [osg-users] VRML Normal Issue -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ben Axelrod wrote: Thanks for the info. Is this standard procedure with mesh files? Because I have noticed similar affects with a variety of file formats. I agree that when no normals are specified, the proper behavior for the parser is to use one normal per face, and calculate the face normals from the vertex points, but the shading I see in badbox.wrl does not look like one normal per face, it looks like one normal per vertex. The shading of goodbox.wrl looks like one normal per face to me. Am I mistaken on how these should look? I can't test it right now, because I do not have the VRML plugin compiled at the moment. I have loaded the models in WhiteDune editor, and both look OK to me, with the badbox one showing some artifacts. I had a look at the code and if you do not specify any normals, the OSG loader will not really handle it right. It seems that in that case an average normal out of the adjacent faces is computed and used per-vertex (i.e. the edges and corners are smoothed ...) This isn't completely correct, the VRML spec specifies use of crease angle parameter that will make all angles smaller than this one averaged and ones larger sharp. However, this is not intended to be a 100% compliant VRML viewer. Originally, the case without normals was not handled at all. You have basically two options: - - generate your VRML including normals - - fix the VRML plugin code to include handling of the crease angle (in IndexedFaceSet.cpp, around lines 240 and on in the VRML plugin) Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJyRn8n11XseNj94gRAhPtAKDd+ov0409iUlfCEoPs0Jgz8z2V/QCfTV6C trLfTvJTRgm+KjV2GCYphTA= =dT7/ -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org attachment: creasenormals.png___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VRML Normal Issue
Thanks for the info.
I took a look at the code. Adding crease angle support does seem tricky since
I think we would have to create new vertex points on the fly to accommodate 2
or more different normal vectors at that point. Here is some off the cuff
pseudo code.
for (int i = 0; i != *it; ++i) // line 268 of IndexedFaceSet.cpp
{
float angle = acos((*normals)[indices[index + i]] * normal);
if (angle = creaseAngle)
{
(*normals)[indices[index + i]] += normal;
}
else
{
// clone this vertex so we can give it 2 normals
coords.push_back(coords[indices[index + i]]);
// give it the new normal
normals.push_back(normal)
// now point this face at the new vertex
indices[index + i] = coords.size() - 1;
}
}
I am not sure if modifying the vertex and normal array on the fly is wise,
possible, or even if that is how it's done. But like I said, it is pseudo code.
What do you think?
-Ben
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jan Ciger
Sent: Wednesday, March 25, 2009 4:43 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] VRML Normal Issue
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ben Axelrod wrote:
Just to clarify, the way the normals *should* work is sketched in the
attached image. Please verify.
When the angle between 2 faces is sharper than the crease angle,
there is one normal per face, and when the angle is smoother than the
crease angle, the normal is averaged.
Correct - what I had in mind was the angle between the normals, not the
faces. The end result would be the same, but this is how the VRML spec
specifies it and it is easier to calculate:
The creaseAngle field, used by the ElevationGrid, Extrusion, and
IndexedFaceSet nodes, affects how default normals are generated. If
the angle between the geometric normals of two adjacent faces is less
than the crease angle, normals shall be calculated so that the faces
are smooth-shaded across the edge; otherwise, normals shall be
calculated so that a lighting discontinuity across the edge is
produced. For example, a crease angle of .5 radians means that an
edge between two adjacent polygonal faces will be smooth shaded if
the geometric normals of the two faces form an angle that is less
than .5 radians. Otherwise, the faces will appear faceted. Crease
angles must be greater than or equal to 0.0.
(from:
http://accad.osu.edu/~pgerstma/class/vnv/resources/info/AnnotatedVrmlRef/ch2-26.htm)
However, as I said - right now the loader will average *always*,
regardless of the crease angle. This is even documented in the code:
IndexedFaceSet.cpp, line 241:
// GvdB: So I ended up computing the smoothing normals myself. Also,
I might add support for creaseAngle if a big need for it rises. //
However, for now I can perfectly live with the fact that all edges
are smoothed despite the use of a crease angle.
Regards,
Jan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFJypdon11XseNj94gRAkaaAKDfByiriOZH8ntvtFI6hYbA/7VW2QCfX1nX
Bpzs2QlM9aiHrkhk40HJt64=
=KjWi
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VRML Normal Issue
Thanks for the info.
I took a look at the code. Adding crease angle support does seem tricky since
I think we would have to create new vertex points on the fly to accommodate 2
or more different normal vectors at that point. Here is some off the cuff
pseudo code.
for (int i = 0; i != *it; ++i) // line 268 of IndexedFaceSet.cpp
{
float angle = acos((*normals)[indices[index + i]] * normal);
if (angle = creaseAngle)
{
(*normals)[indices[index + i]] += normal;
}
else
{
// clone this vertex so we can give it 2 normals
coords.push_back(coords[indices[index + i]]);
// give it the new normal
normals.push_back(normal)
// now point this face at the new vertex
indices[index + i] = coords.size() - 1;
}
}
I am not sure if modifying the vertex and normal array on the fly is wise,
possible, or even if that is how it's done. But like I said, it is pseudo code.
What do you think?
-Ben
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jan Ciger
Sent: Wednesday, March 25, 2009 4:43 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] VRML Normal Issue
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ben Axelrod wrote:
Just to clarify, the way the normals *should* work is sketched in the
attached image. Please verify.
When the angle between 2 faces is sharper than the crease angle,
there is one normal per face, and when the angle is smoother than the
crease angle, the normal is averaged.
Correct - what I had in mind was the angle between the normals, not the
faces. The end result would be the same, but this is how the VRML spec
specifies it and it is easier to calculate:
The creaseAngle field, used by the ElevationGrid, Extrusion, and
IndexedFaceSet nodes, affects how default normals are generated. If
the angle between the geometric normals of two adjacent faces is less
than the crease angle, normals shall be calculated so that the faces
are smooth-shaded across the edge; otherwise, normals shall be
calculated so that a lighting discontinuity across the edge is
produced. For example, a crease angle of .5 radians means that an
edge between two adjacent polygonal faces will be smooth shaded if
the geometric normals of the two faces form an angle that is less
than .5 radians. Otherwise, the faces will appear faceted. Crease
angles must be greater than or equal to 0.0.
(from:
http://accad.osu.edu/~pgerstma/class/vnv/resources/info/AnnotatedVrmlRef/ch2-26.htm)
However, as I said - right now the loader will average *always*,
regardless of the crease angle. This is even documented in the code:
IndexedFaceSet.cpp, line 241:
// GvdB: So I ended up computing the smoothing normals myself. Also,
I might add support for creaseAngle if a big need for it rises. //
However, for now I can perfectly live with the fact that all edges
are smoothed despite the use of a crease angle.
Regards,
Jan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFJypdon11XseNj94gRAkaaAKDfByiriOZH8ntvtFI6hYbA/7VW2QCfX1nX
Bpzs2QlM9aiHrkhk40HJt64=
=KjWi
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VRML Normal Issue
Thanks for the info. Is this standard procedure with mesh files? Because I have noticed similar affects with a variety of file formats. I agree that when no normals are specified, the proper behavior for the parser is to use one normal per face, and calculate the face normals from the vertex points, but the shading I see in badbox.wrl does not look like one normal per face, it looks like one normal per vertex. The shading of goodbox.wrl looks like one normal per face to me. Am I mistaken on how these should look? Thanks, -Ben -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jan Ciger Sent: Saturday, March 21, 2009 12:23 PM To: OpenSceneGraph Users Subject: Re: [osg-users] VRML Normal Issue -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Ben, Ben Axelrod wrote: I have noticed a very strange issue regarding VRML file rendering. This issue happens in OSG viewer version 2.6, with openVRML version 0.14.3. ... Are there some VRML flags to prevent this behavior? Is this a bug in the VRML parser? If so, is this part of OSG or openVRML? I happen to be one of the authors of the VRML plugin. I had a look at your files and badbox.wrl is incorrect. You need to explicitly specify the vertex normals, otherwise it will assume normal per face and if even those are not provided, calculate them from the vertices - leading to the behavior you are describing. The behavior is correct, IMO - the parser has no means to know what you want if you do not specify the normals. Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJxRRkn11XseNj94gRAsiVAKCNve8MXKvwkJ75hLM6kZcn1gZzfwCdH+Pr A8CF98dTVjegSqXWeKQdNm4= =NbCl -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShadowMap Required OpenGL Extensions
I should probably specify the graphics cards in question.
The working card is a NVidia 7300 LE. The card that passes the test, but still
does not work is a NVidia NV37GL [Quadro FX 330/Quadro NVS280] (rev a2)
-Ben
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Ben Axelrod
Sent: Friday, March 20, 2009 12:42 PM
To: OpenSceneGraph Users
Subject: [osg-users] ShadowMap Required OpenGL Extensions
My application checks for the existence of some OpenGL extensions before
allowing ShadowMap to be turned on. So far, I have been using this test:
if (GL_EXT_framebuffer_object
(GL_ARB_fragment_program || GL_EXT_fragment_program)
(GL_ARB_fragment_program_shadow || GL_EXT_fragment_program_shadow))
{
//enable ShadowMap
}
Note that I am using the 'fixed function fallback' by calling clearShaderList()
after init() but before first frame.
However, I have come across a graphics card that passes this test, yet does not
render shadows properly.
This graphics card has these key extensions:
GL_EXT_framebuffer_object
GL_ARB_fragment_program
GL_ARB_fragment_program_shadow
GL_ARB_fragment_shader
As far as I can tell, the only extensions this card does NOT have, that my
other card (which renders shadows fine) does is:
GL_ARB_texture_non_power_of_two
GL_ATI_texture_mirror_once
GL_EXT_clip_volume_hint
GL_EXT_texture_mirror_clamp
Does ShadowMap require any of these extensions?
Also, FYI, the graphics card in question has many more extensions that my
working card does not have:
GL_ARB_fragment_shader
GL_ARB_half_float_pixel
GL_ARB_multisample
GL_ARB_pixel_buffer_object
GL_ARB_shader_objects
GL_ARB_shading_language_100
GL_ARB_texture_rectangle
GL_ARB_transpose_matrix
GL_ARB_vertex_buffer_object
GL_ARB_vertex_shader
GL_S3_s3tc
GL_EXT_compiled_vertex_array
GL_EXT_Cg_shader
GL_EXT_framebuffer_blit
GL_EXT_framebuffer_multisample
GL_EXT_gpu_program_parameters
GL_EXT_packed_depth_stencil
GL_EXT_pixel_buffer_object
GL_EXT_point_parameters
GL_EXT_stencil_two_side
GL_EXT_texture_compression_s3tc
GL_EXT_texture_cube_map
GL_EXT_texture_filter_anisotropic
GL_EXT_texture_lod
GL_EXT_texture_sRGB
GL_EXT_timer_query
GL_IBM_rasterpos_clip
GL_KTX_buffer_region
GL_NV_copy_depth_to_color
GL_NV_depth_clamp
GL_NV_fence
GL_NV_float_buffer
GL_NV_fog_distance
GL_NV_fragment_program
GL_NV_fragment_program_option
GL_NV_framebuffer_multisample_coverage
GL_NV_half_float
GL_NV_multisample_filter_hint
GL_NV_occlusion_query
GL_NV_packed_depth_stencil
GL_NV_pixel_data_range
GL_NV_point_sprite
GL_NV_primitive_restart
GL_NV_register_combiners
GL_NV_register_combiners2
GL_NV_texture_compression_vtc
GL_NV_texture_env_combine4
GL_NV_texture_expand_normal
GL_NV_texture_shader
GL_NV_texture_shader2
GL_NV_texture_shader3
GL_NV_vertex_array_range
GL_NV_vertex_array_range2
GL_NV_vertex_program
GL_NV_vertex_program1_1
GL_NV_vertex_program2
GL_NV_vertex_program2_option
GL_SUN_slice_accum
Thanks,
-Ben
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShadowMap Required OpenGL Extensions
Thanks, Do you think that changing the shadow texture size will have any affect here? I have noticed a somewhat similar failure of ShadowMap when I have a very large mesh file, and decreasing the shadow texture size seems to fix that. -Ben From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jason Daly Sent: Monday, March 23, 2009 1:40 PM To: OpenSceneGraph Users Subject: Re: [osg-users] ShadowMap Required OpenGL Extensions Ben Axelrod wrote: I should probably specify the graphics cards in question. The working card is a NVidia 7300 LE. The card that passes the test, but still does not work is a NVidia NV37GL [Quadro FX 330/Quadro NVS280] (rev a2) The NV37 is a GeForce 5-era card, so it should fully support programmable shading, although there were limits on how long and/or complex the shaders could be. I wonder if you're running into a shader instruction limit or something like that. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShadowMap Required OpenGL Extensions
Oh cool, how do you do that? Thanks, -Ben From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Tomlinson, Gordon Sent: Monday, March 23, 2009 3:39 PM To: OpenSceneGraph Users Subject: Re: [osg-users] ShadowMap Required OpenGL Extensions We handle card discrepancies like texture size, number of units etc, by querying the the cards cabalilties and setting up our limits in our programs from them. ( now some dang cards can tell out right lies about what they support and drop to s/w mode at times but thats another story ) Gordon Product Manager 3d __ Gordon Tomlinson Email : gtomlinson @ overwatch.textron.com __ From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jason Daly Sent: Monday, March 23, 2009 3:24 PM To: OpenSceneGraph Users Subject: Re: [osg-users] ShadowMap Required OpenGL Extensions Ben Axelrod wrote: Thanks, Do you think that changing the shadow texture size will have any affect here? I have noticed a somewhat similar failure of ShadowMap when I have a very large mesh file, and decreasing the shadow texture size seems to fix that. Oh, possibly. The GeForce 5's might have had a smaller max texture size, too. It's been a while, so I don't remember the numbers exactly. In general, though, they had tighter limits than the modern cards. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] switch between two camera
I try to use nodemask but doesn't work. Id do this : Code: osgViewer::CompositeViewer viewer; osgViewer::GraphicsWindowEmbedded* gw = new osgViewer::GraphicsWindowEmbedded; osgViewer::View* vue2D = new osgViewer::View; osgViewer::View* vue3D = new osgViewer::View; viewer.addView(vue2D); viewer.addView(vue3D); vue2D-getCamera()-setGraphicsContext(gw ); vue2D-getCamera()-setProjectionMatrixAsPerspective(30.0f, width()/(double) height(), 1.0, 1000.0); vue2D-getCamera()-setViewport(new osg::Viewport(0,0,width(),height() )); vue2D-setCameraManipulator(new osgGA::TrackballManipulator); vue3D-getCamera()-setGraphicsContext(gw ); vue3D-getCamera()-setProjectionMatrixAsPerspective(30.0f, width()/(double) height(), 1.0, 1000.0); vue3D-getCamera()-setViewport(new osg::Viewport(0,0,width(),height() )); vue3D-setCameraManipulator(new osgGA::TrackballManipulator); Code: // to switch vue3D OFF and vue2D on vue2D-getCamera()-setNodeMask(0X); vue3D-getCamera()-setNodeMask(0); -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=8852#8852 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] ShadowMap Required OpenGL Extensions
My application checks for the existence of some OpenGL extensions before
allowing ShadowMap to be turned on. So far, I have been using this test:
if (GL_EXT_framebuffer_object
(GL_ARB_fragment_program || GL_EXT_fragment_program)
(GL_ARB_fragment_program_shadow || GL_EXT_fragment_program_shadow))
{
//enable ShadowMap
}
Note that I am using the 'fixed function fallback' by calling clearShaderList()
after init() but before first frame.
However, I have come across a graphics card that passes this test, yet does not
render shadows properly.
This graphics card has these key extensions:
GL_EXT_framebuffer_object
GL_ARB_fragment_program
GL_ARB_fragment_program_shadow
GL_ARB_fragment_shader
As far as I can tell, the only extensions this card does NOT have, that my
other card (which renders shadows fine) does is:
GL_ARB_texture_non_power_of_two
GL_ATI_texture_mirror_once
GL_EXT_clip_volume_hint
GL_EXT_texture_mirror_clamp
Does ShadowMap require any of these extensions?
Also, FYI, the graphics card in question has many more extensions that my
working card does not have:
GL_ARB_fragment_shader
GL_ARB_half_float_pixel
GL_ARB_multisample
GL_ARB_pixel_buffer_object
GL_ARB_shader_objects
GL_ARB_shading_language_100
GL_ARB_texture_rectangle
GL_ARB_transpose_matrix
GL_ARB_vertex_buffer_object
GL_ARB_vertex_shader
GL_S3_s3tc
GL_EXT_compiled_vertex_array
GL_EXT_Cg_shader
GL_EXT_framebuffer_blit
GL_EXT_framebuffer_multisample
GL_EXT_gpu_program_parameters
GL_EXT_packed_depth_stencil
GL_EXT_pixel_buffer_object
GL_EXT_point_parameters
GL_EXT_stencil_two_side
GL_EXT_texture_compression_s3tc
GL_EXT_texture_cube_map
GL_EXT_texture_filter_anisotropic
GL_EXT_texture_lod
GL_EXT_texture_sRGB
GL_EXT_timer_query
GL_IBM_rasterpos_clip
GL_KTX_buffer_region
GL_NV_copy_depth_to_color
GL_NV_depth_clamp
GL_NV_fence
GL_NV_float_buffer
GL_NV_fog_distance
GL_NV_fragment_program
GL_NV_fragment_program_option
GL_NV_framebuffer_multisample_coverage
GL_NV_half_float
GL_NV_multisample_filter_hint
GL_NV_occlusion_query
GL_NV_packed_depth_stencil
GL_NV_pixel_data_range
GL_NV_point_sprite
GL_NV_primitive_restart
GL_NV_register_combiners
GL_NV_register_combiners2
GL_NV_texture_compression_vtc
GL_NV_texture_env_combine4
GL_NV_texture_expand_normal
GL_NV_texture_shader
GL_NV_texture_shader2
GL_NV_texture_shader3
GL_NV_vertex_array_range
GL_NV_vertex_array_range2
GL_NV_vertex_program
GL_NV_vertex_program1_1
GL_NV_vertex_program2
GL_NV_vertex_program2_option
GL_SUN_slice_accum
Thanks,
-Ben
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] VRML Normal Issue
I have noticed a very strange issue regarding VRML file rendering. This issue happens in OSG viewer version 2.6, with openVRML version 0.14.3. Please view the two attached vrml files and observe very different shading on the 2 cubes. The only difference between the files is that in goodbox.vml, the coordinate indices are used only once per triangle. In badbox.wrl, the 8 vertices are reused for multiple triangles. You can see that in goodbox.vml, I duplicated the vertices so that they would be used only once. For example, for index '0', I copied it and made it also index 8 through 12, then used those new indices in the coordIndex[] definition. I think that the vrml parser tries to interpolate vertex vectors from the triangles they belong to. If a vertex belongs to two ore more triangles which are not co-planar then the vertex vector is something in between the different surface normals of the different triangles. And because normal vectors along a triangle surface are interpolated from the vertex normals, this leads to a gradient along the triangle surface (because the vertex normals are not pointing in the same direction). Hence, if only co-planar triangles share their points the problem disappears. Are there some VRML flags to prevent this behavior? Is this a bug in the VRML parser? If so, is this part of OSG or openVRML? Thanks, -Ben goodbox.wrl Description: goodbox.wrl badbox.wrl Description: badbox.wrl ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] question about qt example
Hi, In the osgViewerQt example ther are 2 approaches, one with adapterwidget and one without adapterwidget .what is the differences between this 2 approaches using osg and Qt? What is the best way to use OSG in a widget in a Qt mainwindows application Thanks. Ben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=8713#8713 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenGL EXTENSION support
I just get them right out of OpenGL. But you have to have the current OpenGL context. const char* extensions = (const char*)glGetString(GL_EXTENSIONS); -Ben From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of ami guru Sent: Wednesday, March 18, 2009 5:09 PM To: OpenSceneGraph Users Subject: [osg-users] OpenGL EXTENSION support Hello forum, Is there any class or interface in OSG that can query and print out the supported extensions within the OpenGL driver ? Regards Sajjad ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] switch between two camera
thank's, but I don't see how to use osg::CameraViews, does somebody have a little example?? I will try to specify more what I want to do. I have one scene to render with 2 differents views, one as a FPS 3D vue, and one as 2D vue (the camera is on top with an orthografic vue). Each camera has its own manipulator. only one vue is displayed at once. I thought to make something like schema below, but I don't know how to made it with osg. [Image: http://nsa06.casimages.com/img/2009/03/13/09031302561860352.jpg ] (http://www.casimages.com) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=8446#8446 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] cast ray into scene
I have been using osgUtil::PickVisitor for a while now to pick objects in my tree under the mouse. But now I need to cast a ray into the scene under the mouse and manually intersect it with an imaginary plane. Is there some helper function to do this mouse ray cast for me? Specifically, something that would take as input 2 ints for the position of the mouse, and maybe the camera or projection and view matrices, then output a vector? Thanks, -Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] strange object clipping
Thanks guys, I found the problem. I was not dirtying the bound for all of my ShapeDrawables. I was only calling dirtyBound() on the parent geode. I guess this is not sufficient. -Ben -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Thursday, March 05, 2009 3:48 AM To: OpenSceneGraph Users Subject: Re: [osg-users] strange object clipping HI Ben, On Thu, Mar 5, 2009 at 2:01 AM, Ben Axelrod baxel...@coroware.com wrote: Well, i tried it in osgviewer and there was no clipping. any ideas as to what might cause this in my app? If osgviewer works on the data, so it's only the viewer that is different then it points to your viewer setup as being the problem. However, you've not specified anything about how you have set up the viewer, so pray how might I have the knowledge required to diagnose this problem? Let me ask a similar question and see if you can answer it. Description of problem. I have a box, and inside that box is a ball. Question: I don't know what colour of the is ball is, could you tell me please. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] strange object clipping
Well, i tried it in osgviewer and there was no clipping. any ideas as to what might cause this in my app? Thanks, -Ben From: osg-users-boun...@lists.openscenegraph.org [osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield [robert.osfi...@gmail.com] Sent: Saturday, February 28, 2009 2:49 AM To: OpenSceneGraph Users Subject: Re: [osg-users] strange object clipping Hi Ben, The visuals do look like they suggest a problem with the near/far computation or clamping of near/far. I'm not aware of a bugs in the bounding box calculation of ShapeDrawable, but it could certainly be an area to look into. Could you output the model to .osg, test this in osgviewer to see if the problem still exists and if it does then post this model so others can test against it. Robert. On Fri, Feb 27, 2009 at 9:10 PM, Ben Axelrod baxel...@coroware.com wrote: Hi, We are seeing some strange clipping of objects in OSG 2.6. It happens with large numbers of ShapeDrawable boxes and spheres. What should be displayed in the attached images is a large rectangular grid of small, colored cubes. The structure of our osg tree looks like: osg::Group | \|/ osg::MatricTransform | \|/ osg::Geode ||| \|/ \|/ \|/ Multiple ShapeDrawable () Our camera is an osgViewer. cube1.png demonstrates the clipping we are seeing. the cubes are sliced, as if by the near clipping plane of the camera. cube2.png has the camera and objects in the exact same positions, except a large cone shape is added. You can see that the clipping is gone. We believe this is due to some bounding box miscalculations by OSG. When the other object is added, the bounding box can be calculated properly, so the cubes are not cut. Any ideas on what is causing this issue and what can possibly be done about it? I have heard that ShapeDrawables is not very efficient, and is only meant for fast debugging. Will converting the ShapeDrawables to straight Geometry fix it? Thanks, -Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Multi-colored osgSim::SphereSegment?
Hello, What's the best way to draw a sphere with the ability to color some of the surface's segments differently? What I'm trying to do ... I'd like to change the color of a given segment if it is intersected by a ray (leaving the rest of the sphere color the same). I've used the osgSim::SphereSegment, but I don't think it allows for explicitly coloring a specified segment. It looks like the entire Surface is added as one drawable. Would be easy to change how the way the Surface drawable is added ... creating a different drawable for every segment ... and enabling them to be indexed by azimuth/elevation angle (or range)? I could start from scratch, but I was hoping to leverage osgSim::SphereSegment in some way. Any suggestions will be greatly appreciated! Thanks, Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgCal shader question
Hello, Do you know why a shader might not be affecting osgCal nodes? I apply a black-and-white shader to the scene root, but it isn't affecting the CAL3D characters. Everything else is fine. scene-getOrCreateStateSet()-setAttributeAndModes(prog.get(), osg::StateAttribute::ON); Does osgCal has its own shader? If so, it will override the one that I'm applying at the scene root. What are my options? Thanks, Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osg::View NO_LIGHT bug?
I cannot seem to turn off the light in osg::View. I can change it between headlight and sky light, but when I try NO_LIGHT, I still get the headlight. _viewer-getCamera()-getView()-setLightingMode(osg::View::SKY_LIGHT); //works _viewer-getCamera()-getView()-setLightingMode(osg::View::HEADLIGHT); //works _viewer-getCamera()-getView()-setLightingMode(osg::View::NO_LIGHT); //still get headlight How can I turn off this default light? How is it related to the osg::Lights in the scene? I noticed when I add an osg::Light, then the headlight is overridden. How can I change the light parameters of the SKY_LIGHT or HEADLIGHT? I am using osg version 2.6. Thanks, -Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::View NO_LIGHT bug?
I still don't know why osg::View::NO_LIGHT doesn't work, but to answer my own
questions, to turn off the default light completely:
_viewer-getCamera()-getView()-setLightingMode(osg::View::HEADLIGHT);
osg::Light* light = _viewer-getCamera()-getView()-getLight();
if (light != NULL)
{
light-setAmbient(osg::Vec4(0,0,0,1));
light-setDiffuse(osg::Vec4(0,0,0,1));
light-setSpecular(osg::Vec4(0,0,0,1));
}
-Ben
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Ben Axelrod
Sent: Tuesday, February 17, 2009 11:36 AM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] osg::View NO_LIGHT bug?
I cannot seem to turn off the light in osg::View. I can change it between
headlight and sky light, but when I try NO_LIGHT, I still get the headlight.
_viewer-getCamera()-getView()-setLightingMode(osg::View::SKY_LIGHT); //works
_viewer-getCamera()-getView()-setLightingMode(osg::View::HEADLIGHT); //works
_viewer-getCamera()-getView()-setLightingMode(osg::View::NO_LIGHT); //still
get headlight
How can I turn off this default light? How is it related to the osg::Lights in
the scene? I noticed when I add an osg::Light, then the headlight is
overridden. How can I change the light parameters of the SKY_LIGHT or
HEADLIGHT?
I am using osg version 2.6.
Thanks,
-Ben
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] default lighting
When I don't have any lights in my scene, and my viewer's lighting mode is set to no_light: osgViewer::Viewer() - getCamera()-getView()-setLightingMode(osg::View::NO_LIGHT) there is still some default lighting in the scene. Where does this light come from, and how can I change it to be brighter or darker? Thanks, -Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Is OSG tied to OpenGL?
Cory, Answering the last portion of your question ... OSG is UI toolkit agnostic. But, if your asking a general question of which toolkit is better supported on its own right ... then ... Just my 2 cents (take it for what it's worth), but for strictly C++ development I highly recommend Qt. I sometimes use other toolkits for very simple examples though. And I might use CEGUI for a simple hardware-accelerated UI. You can do your own comparison. I've done GUI programming in one form or another for over 15 years (e.g. Qt, MFC, X/Xt/Motif, Forms, CEGUI, Tcl/Tk, and others) and have found Qt much superior (for C++ anyways). Admittedly, I've not done much with wxWidgets other than a survey and simple examples. Again, just my 2 cents ;) Cheers, Ben -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Cory Riddell Sent: Tuesday, January 13, 2009 9:12 AM To: OpenSceneGraph Users Subject: [osg-users] Is OSG tied to OpenGL? The subject line says it all- if other renderers (in my case DirectX) are available on a system, can they be used? A second question- are some of the UI toolkits better supported than others? I'm specifically thinking about comparing the wx stuff with Qt and MFC. -cr ___ 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: SOLVED
Thanks Robert, for include/osg/Config. Starting with OSG 2.6, the VTP can now check OSG_USE_FLOAT_MATRIX to detect whether OSG was built with float matrices or not. That makes it easy to handle both cases, so the user doesn't need it built one way or the other. It is not so surprising that the VTP prefers float matrices: 1. It is pointless to use the extra RAM (and memory bandwidth, and CPU time) for double matrices, when they aren't needed. 2. The rest of VTP's stack uses single matrices, so having OSG use doubles does not even gain theoretical precision improvement. It would have to be all doubles, top to bottom. 3. OpenGL itself is single-precision, so at best doubles would affect temporary, intermediate computations. 4. In many years, i have never encountered any rare situation that would be improved with double matrices. I'm certain they exist (among the many unusual uses of OSG) but since they are less common, it would make far more sense for single matrices to be the default. The VTP uses double-precision for GIS data, and single-precision for the 3d scenegraph. A design which requires the scenegraph to be double-precision is arguably.. an odd choice. -Ben -Original Message- From: Robert Osfield Sent: Saturday, September 13, 2008 2:29 AM Hi Pascal, I wonder if you could add something to the VTP build system to detect problems with Matrixd being used for Matrix. The other thing one might be able to do is adapt VTP so that it can handle Matrxf and Matrixd versions of Matrix. With OSG 2.6 onward there now is an include/osg/Config which includes details of the which version of Matrix is used, perhaps this might be of some help. As a general note, I've always been surprised by VTP using float Matrices, as GIS related app I would have expect double Matrices as it solves many of the precision problems associated with real world data. Robert. On Sat, Sep 13, 2008 at 9:40 AM, Pascal Rheinert [EMAIL PROTECTED] wrote: Hi, I got exactly the same error when trying to start VTP And I solved it now: The reason is (as expected) a discrepency between what OSG does by default and what VTP expects concerning the Matrix ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] openGL extensions
Hi Jean, Thanks for the list of extensions that you test for in the ShadowMap. However, I have a graphics card that meets those requirements yet still does not render ShadowMap shadows. Can you tell me if any of these extensions look like the 'smoking gun' as to why this card does not display shadows? Here is a list of extensions that ARE NOT supported on this graphics card. This list was extracted from a diff between a working graphics card that does display shadows and the current 'broken' one. I am sure there are more extensions that are not listed here that I am unaware of. GL_ARB_draw_buffers GL_ARB_fragment_shader GL_ARB_multisample GL_ARB_shader_objects GL_ARB_shading_language_100 GL_ARB_transpose_matrix GL_ARB_vertex_buffer_object GL_ARB_vertex_shader GL_ATI_draw_buffers GL_EXT_blend_equation_separate GL_EXT_compiled_vertex_array GL_EXT_Cg_shader GL_EXT_depth_bounds_test GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_gpu_program_parameters GL_EXT_point_parameters GL_EXT_stencil_two_side GL_NV_fence GL_NV_fragment_program GL_NV_framebuffer_multisample_coverage GL_NV_half_float GL_NV_occlusion_query GL_NV_pixel_data_range GL_NV_point_sprite GL_NV_primitive_restart GL_NV_register_combiners GL_NV_register_combiners2 GL_NV_vertex_array_range GL_NV_vertex_array_range2 GL_NV_vertex_program GL_NV_vertex_program1_1 GL_NV_vertex_program2 GL_NVX_conditional_render This is the list of extensions are ARE supported by this 'broken' card that does not display shadows: GL_ARB_color_buffer_float GL_ARB_depth_texture GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_half_float_pixel GL_ARB_imaging GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_shadow GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_dot3 GL_ARB_texture_float GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_vertex_program GL_ARB_window_pos GL_ATI_texture_float GL_ATI_texture_mirror_once GL_S3_s3tc GL_EXT_texture_env_add GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_object GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_pixels GL_EXT_pixel_buffer_object GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_wrap GL_EXT_texture3D GL_EXT_texture_compression_s3tc GL_EXT_texture_cube_map GL_EXT_texture_edge_clamp GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_sRGB GL_EXT_timer_query GL_EXT_vertex_array GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_KTX_buffer_region GL_NV_blend_square GL_NV_copy_depth_to_color GL_NV_depth_clamp GL_NV_float_buffer GL_NV_fog_distance GL_NV_fragment_program_option GL_NV_fragment_program2 GL_NV_light_max_exponent GL_NV_multisample_filter_hint GL_NV_packed_depth_stencil GL_NV_texgen_reflection GL_NV_texture_compression_vtc GL_NV_texture_env_combine4 GL_NV_texture_expand_normal GL_NV_texture_rectangle GL_NV_texture_shader GL_NV_texture_shader2 GL_NV_texture_shader3 GL_NV_vertex_program2_option GL_NV_vertex_program3 GL_SGIS_generate_mipmap GL_SGIS_texture_lod GL_SGIX_depth_texture GL_SGIX_shadow GL_SUN_slice_accum Thanks, -Ben -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean-Sébastien Guay Sent: Monday, September 22, 2008 8:12 PM To: OpenSceneGraph Users Subject: Re: [osg-users] openGL extensions Hi Ben, I would like to detect if the user has the appropriate openGL extensions in order to do shadowing. However, when I do: glGetString(GL_VERSION) glGetString(GL_EXTENSIONS) They return null. How can I get a list of the available extensions? Is there an easy way to get this info from OSG? For the first part of your question, they return NULL if they were called from a thread that does not have a graphics context. The safest way to do this is to create a camera predraw/postdraw/finaldraw callback or a node cull callback or a drawable draw callback. In each of these points you will have a graphics context. What I generally do is assume support is present and start the viewer with a detection callback attached (camera predraw callback on the main camera) which will check extensions and then remove itself from the camera. Then after the first frame, if I see that some feature is not supported, I disable the relevant options. There are other valid strategies of course. As for detecting actual extensions, instead of calling glGetString(GL_EXTENSIONS) and parsing it yourself, you can use #include osg/GLExtensions #include osg/GL2Extensions osg
Re: [osg-users] openGL extensions
Thank you Jean and Gordon. I put those functions in my draw callback and now I get some information. However, the behavior is very strange. It only works the first time through. The rest of the time, they return null. Even weirder is that if I click on another window, they work again for one iteration, then go back to being null. Every time I click off and on again of my OSG application, the info appears. Why is this? FYI: OSG 2.6.0 on Debian Etch with an NVidia 7300 card. Thanks, -Ben -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean-Sébastien Guay Sent: Monday, September 22, 2008 8:12 PM To: OpenSceneGraph Users Subject: Re: [osg-users] openGL extensions Hi Ben, I would like to detect if the user has the appropriate openGL extensions in order to do shadowing. However, when I do: glGetString(GL_VERSION) glGetString(GL_EXTENSIONS) They return null. How can I get a list of the available extensions? Is there an easy way to get this info from OSG? For the first part of your question, they return NULL if they were called from a thread that does not have a graphics context. The safest way to do this is to create a camera predraw/postdraw/finaldraw callback or a node cull callback or a drawable draw callback. In each of these points you will have a graphics context. What I generally do is assume support is present and start the viewer with a detection callback attached (camera predraw callback on the main camera) which will check extensions and then remove itself from the camera. Then after the first frame, if I see that some feature is not supported, I disable the relevant options. There are other valid strategies of course. As for detecting actual extensions, instead of calling glGetString(GL_EXTENSIONS) and parsing it yourself, you can use #include osg/GLExtensions #include osg/GL2Extensions osg::isGLExtensionSupported(contextID, extensionName) Also, how do I know which extensions I need for the different shadow techniques? I'm personally not sure which extensions are required for all of them, perhaps someone else will know (it might be good to add that info to the osgShadow page on the wiki). I can tell you what I test for in the case of osgShadow::ShadowMap: _shadowsSupported = osg::isGLExtensionSupported(contextID, GL_EXT_framebuffer_object) (osg::isGLExtensionSupported(contextID, GL_ARB_fragment_program) || osg::isGLExtensionSupported(contextID, GL_EXT_fragment_program)) (osg::isGLExtensionSupported(contextID, GL_ARB_fragment_program_shadow) || osg::isGLExtensionSupported(contextID, GL_EXT_fragment_program_shadow)); Not sure if that's totally correct, but in most cases where shadow maps were not supported (they fell back to software and so were extremely slow) it was the first (GL_EXT_framebuffer_object) which was not supported. Hope this helps, 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] loading vrml segfault
This page indicates that OpenInventor only supports VRML 1.0 files. (http://www.openscenegraph.org/projects/osg/wiki/Support/UserGuides/Plugins) And from my own experience, OpenVRML only supports VRML 2.0 files. Can OSG handle both of these libraries at the same time? I am a little doubtful since the VRML file must be parsed before it can be determined if it is VRML 1.0 or VRML 2.0. And OpenVRML segfaults when trying to load a VRML 1.0 file. Does anyone have any experience supporting both VRML 1.0 and VRML 2.0 file types? Thanks, -Ben -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Huebert Sent: Thursday, September 18, 2008 6:20 PM To: OpenSceneGraph Users Subject: Re: [osg-users] loading vrml segfault Hi Ben, I tried your wrl files using osg with the coin3d plugin (alternate for some of what openvrml does) and got predictable results, given your post. When bombing on the Bad.wrl file, coin kindly provided the following: % osgviewer Bad.wrl Coin read error: Unknown field mesh in VRMLShape Occurred at line 5 in Bad.wrl osgviewer: No data loaded Maybe this will help? -bob On Thu, 18 Sep 2008, Ben Axelrod wrote: When I try to load a VRML 1.0 file in OpenSceneGraph, it segfaults. I am using OpenSceneGraph 2.6, and OpenVRML 0.14.3. I have attached the file that causes the segfault, as well as the same file with some minor changes to make it run properly. The segfault happens inside: osgDB::readNodeFile(filename). It would be great if OSG could detect the error, and return properly with an invalid node. But I understand if the fault is inside of OpenVRML. Thanks, -Ben ___ 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] strange ShadowMap behavior
I am seeing strange shadow artifacts on my model when I use a ShadowMap. The artifacts get worse as I increase the size of my ground plane. You can see the artifacts get progressively worse in these images: http://www.benaxelrod.com/temp/3x3.png http://www.benaxelrod.com/temp/5x5.png http://www.benaxelrod.com/temp/7x7.png http://www.benaxelrod.com/temp/10x10.png - this is the desired size of ground plane http://www.benaxelrod.com/temp/12x12.png You can see strange gradients on the humanoid's hands and feet. And the shadow gets more and more pixilated. I am using OSG 2.6 on Debian Etch with a NVidia 7300 LE graphics card. This is how I configure the ShadowMap: shadowmap-setTextureSize(osg::Vec2s(1024, 1024)); shadowmap-setPolygonOffset(osg::Vec2(1.1f, 4.0f)); Do I need to tune these parameters? If so, how? Are there more parameters I need? And what do these parameters control exactly? Thanks, -Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] openGL extensions
I would like to detect if the user has the appropriate openGL extensions in order to do shadowing. However, when I do: glGetString(GL_VERSION) glGetString(GL_EXTENSIONS) They return null. How can I get a list of the available extensions? Is there an easy way to get this info from OSG? Also, how do I know which extensions I need for the different shadow techniques? Thanks, -Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] loading vrml segfault
When I try to load a VRML 1.0 file in OpenSceneGraph, it segfaults. I am using OpenSceneGraph 2.6, and OpenVRML 0.14.3. I have attached the file that causes the segfault, as well as the same file with some minor changes to make it run properly. The segfault happens inside: osgDB::readNodeFile(filename). It would be great if OSG could detect the error, and return properly with an invalid node. But I understand if the fault is inside of OpenVRML. Thanks, -Ben vrmltest.tar.bz2 Description: vrmltest.tar.bz2 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] vrml plugin problems
Thank you for the tip. That environment variable flag helped me see that OSG found the osgdb_vrml.so plugin, but then failed when loading the openvrml.so library. I added that dir to my LD_LIBRARY_PATH and all is well! (I don't seem to have the osgdb_wrl.so plugin by the way, but it does not look like I need it). Thanks, -Ben -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean-Sébastien Guay Sent: Wednesday, September 17, 2008 4:34 PM To: OpenSceneGraph Users Subject: Re: [osg-users] vrml plugin problems Hi Ben, I am trying to load a VRML file, but I get the error message: Warning: Could not find plugin to read objects from file foo.wrl. [...] I compiled OSG 2.6.0 from src on Debian Etch. I am using OpenVRML version 0.14.3. Do I need a newer version of OpenVRML? (I set the path to the OpenVRML includes as well as libopenvrml.so during the CMake configuration). Did you verify that the osgdb_wrl.so plugin was compiled and can be found? You can enable verbose debugging messages by setting OSG_NOTIFY_LEVEL=DEBUG before running osgviewer, and that might show if something is wrong there. It will print out where it looks for the plugin, whether it finds it, and whether it loads it correctly or not. If the plugin is there, is loaded (as printed in the debug messages) but it still says that it can't find a plugin, it might mean that the plugin depends on some other dynamic library which isn't being found at runtime. This might depend on where OpenVRML is installed and whether your LD_LIBRARY_PATH includes the right directory to find its dynamic libraries (if any) - note I'm on Windows most of the time so I can't really help more than that. I had VRML files working with OSG 2.4 a long time ago. Back then I also set up the Inventor library during the install. But I forgot what that library does, why it's needed, and even where to get it. Do I need it here too? The Inventor plugin can also read VRML files, so if OSG was using that one to read your VRML files before, it might mean that the OpenVRML plugin never worked for you but you never knew it... :-) Hope this helps, 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Stereo convergence param in OSG?
To the best of my knowledge, to do stereo rendering, you must expose two parameters, which are known by various names, typically: 1. Eye separation, the distance between the two stereo 'eyes'. This is in OSG as osg::DisplaySettings::setEyeSeparation. 2. Convergence, which is like a horizontal offset between the rendered views, or it can be thought of as the distance from the camera at which the two images converge. I cannot find any setting in SceneView or DisplaySettings for this. As the email below agrees, this is a vital parameter for any real stereo use. Perhaps i am just not finding it, is it in OSG somewhere? I did search the list archive, and found no relevant mention of 'convergence'. Thanks, Ben -Original Message- From: Michal Husak [mailto:[EMAIL PROTECTED] Sent: Thursday, March 27, 2008 2:57 AM To: Ben Discoe Hi Ben As far as i can tell, OSG does not expose a factor like convergence (or 'Zero parallax plane position'). I am afraid convergence is related to the use of rotated cameras (toe in). it produce keystone distortion ... ZPP does not use rotated cameras - it use just OpenGL viewport manipulation ... The result is similar for both approaches ... Do you know of anyone using OSG-based software who is doing the kind of stereo needed? Unfortunately i do not ... I cannot imagine anybody uses OSG in stereo without the possibility to adjust the ZPP or at least convergence ... Michal Husak Technical Director GALI-3D, s.r.o. Ceska 32 370 01 Ceske Budejovice Czech Republic mobile phone:+420 776 018 351 mailto:[EMAIL PROTECTED] http://www.gali-3d.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShadowMap uses wrong mask for traversal
- From: Robert Osfield Sent: Tuesday, May 20, 2008 10:47 PM Hi Ben, I've just done a quick review and the code looks correct to me. Now ShadowMap comes along, and the above code computes (0x4 0x2) == 0. A visitor mask of 0 finds nothing. That's not right. No it's perfectly correct I'm sorry, but a node mask of 0 matches no nodes, and that's definitely not correct; this Visitor is supposed to find nodes which are drawn and cast shadows. If it finds no nodes, it's not correct. The question is, how can we fix it? this is how traversal masks are meant to be used. However, if bits being used by the viewer are the same as the ones used by effects like osgShadow then there will be conflict Yes, but they are not the same bits. osgShadow is using bits 0x1 and 0x2. The viewer is using bit 0x4. It specifically is not using the same bits as osgshadow, to avoid the conflict. the only way to solve this is set the appropriate bits. I can see use In your example where the viewers traversal mask is 0x4, this would be a very extreme setting - only accepting one bit for traversal is extremely picky. I used an extreme example only to make a clear example of how the logic is wrong. Consider the same example with a traversal mask of 0xfffc and the problem is the same: (traversalMask CastsShadowMask) == 0. The code: cv.setTraversalMask( traversalMask getShadowedScene()-getCastsShadowTraversalMask() ); Using a binary 'and' here only produces a non-zero result if the view mask and the osgshadow mask are overlapping. In other words, the statement above fails as soon as the view mask is changed from 0x to something else. As i wrote: I can only imagine the ShadowMap author meant, they wanted to traverse nodes with _both_ bits set, both visible and casting. But, AFAIK, NodeVisitor doesn't do AND, it only does OR. That is, a traversal will always proceed when _any_ bit matches, not when _all_ bits match. So the above is a bug from misunderstanding how NodeVisitor works. To replace the code with this, would at least fix the general case: cv.setTraversalMask( getShadowedScene()-getCastsShadowTraversalMask() ); However, that doesn't correctly omit nodes which are casting but not drawn, e.g. mask=0x3 using the values above. Perhaps it's just not possible for node traversal to do the correct thing? Or maybe, there is some more powerful visitor capability in OSG that would save the day here? The question remains, can a NodeVisitor be made to do a logical AND, instead of logical OR? That's one way to make the code work. Maybe there is another way to fix it i'm not seeing? -Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShadowMap is wiping out ambient light; how to fix?
- From: Alejandro Segovia Sent: Wednesday, May 21, 2008 5:50 AM Hey Ben, On Tue, May 20, 2008 at 6:20 AM, Ben Discoe [EMAIL PROTECTED] wrote: I noticed that using osgShadow::ShadowMap in my scene makes everything very dark, even nodes not part of the shadowed scene. Studying the OSG code, i found this in ShadowMap.cpp, in ShadowMap::cull: const_castosg::Light*(selectLight)- setAmbient(osg::Vec4(0.0f,0.0f,0.0f,1.0f); I can't seem to find this in OSG 2.2. It must have been added recently. Maybe the old code can be forward ported? :P I dug into SVN, and found the change, revision 7690, December 15, 2007. Comment is Tweaked the ambient lighting contribution so that the OpenGL vertex lighting has the ambient light source switched off, and use the fragment shader to add this contribution back in. That added the code: // set to ambient on light to black so that the ambient bias uniform can take it's affect const_castosg::Light*(selectLight)-setAmbient(osg::Vec4(0.0f,0.0f,0.0f,1.0f)); Unfortunately that breaks ambient light for the entire rest of the scene, because that light is the same light used to illuminate everything, even outside the shadowed sub-graph. Setting ambient to black has no effect if your materials already have no ambient. But if they have ambient, then osgshadow is wiping it out, resulting in very dark objects. So yes, the code can be 'forward ported' - we can remove that black ambient, or some other solution such as using a separate light. Robert, should i submit the fix to osg-submissions? -Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShadowMap uses wrong mask for traversal
- From: J.P. Delport Sent: Wednesday, May 21, 2008 9:51 PM I've not been following the discussion in detail, have only a single comment below... The code: cv.setTraversalMask( traversalMask getShadowedScene()-getCastsShadowTraversalMask() ); Using a binary 'and' here only produces a non-zero result if the view mask and the osgshadow mask are overlapping. In other words, the statement above fails as soon as the view mask is changed from 0x to something else. You will get resulting non-zero bits for _any_ bits that match in the two input masks. I.e. as long as the traversalMask contains the same pattern as getCastsShadowTraversalMask(). Yes, but only in the case where the traversalMask contains the same pattern as getCastsShadowTraversalMask. As you can see in the example case i presented, this is not the case. Nor should it be the case, because if they have bits in common, then there is a conflict. -Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShadowMap uses wrong mask for traversal
- From: Robert Osfield Sent: Wednesday, May 21, 2008 10:20 PM On Thu, May 22, 2008 at 8:22 AM, Ben Discoe [EMAIL PROTECTED] wrote: I'm sorry, but a node mask of 0 matches no nodes, and that's definitely not correct; this Visitor is supposed to find nodes which are drawn and cast shadows. If it finds no nodes, it's not correct. A node mask/traversal mask of 0 absolutely doesn't match any nodes, that is exactly how things are designed to work. Yes, that's how NodeVisitors are designed to work. But in this case, it produces the wrong result, with how ShadowMap is using it. Let me try to lay it out simply.. 1. The user sets the traversal masks and shadow masks to bit patterns that do not overlap. This is not only useful, and a good idea, because it keeps the logic separate: these bit(s) says whether to draw a node, this bit says whether it should cast a shadow. 2. ShadowMap does a operation, and gets a traversal mask of zero. 3. No nodes are rendered into the Shadow. In this case, the masks are all set appropriately, and a wrong visual results. If you don't want to cull out whole subgraphs this way then you simple set the node mask/traversal masks appropriately. 0xfffc is an appropriate traversal mask. The only reason it doesn't work here is because of the bug in ShadowMap's logic. This is a one-line fix! If you are saying that avoiding conflict between bit values is inappropriate, that there should always be overlap, then what use does this statement serve: cv.setTraversalMask( traversalMask getShadowedScene()-getCastsShadowTraversalMask() ); If there is always overlap, then = with traversalmask is a no-op. That isn't logical. It makes it work in the way you're understanding of node masks/traversal masks, but not how they are intended to be used Traversal masks are surely intended to allow the user to select which nodes are traversed. There is surely not some extra intention, that traversal masks must also overlap with shadow masks, in order to make a no-op operation in ShadowMap.cpp function. -Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShadowMap is wiping out ambient light; how to fix?
Robert, I have found a partial workaround; save the light's Ambient value at the top of cull(), and restore it before the bottom of the function. That seems to retain the desired behavior: .. so that the ambient bias uniform can take it's affect The ambient bias still takes effect. I can smoothly transition ambient bias from (0,1) very light shadows to (1,0) very dark shadows. And, with the workaround, most objects in the scene still get their correct ambient. My scene graph layout is simple: 1. root 1a. ShadowedScene 1a1. Terrain (lit by ambient light) 1a2. A vehicle (casting a shadow on the terrain) 1b. the rest of the scene I hope a separate light is not needed, because that could be really complex. I have attached my changed file, with the workaround which is at least some improvement. -Ben -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Wednesday, May 21, 2008 10:15 PM To: OpenSceneGraph Users Subject: Re: [osg-users] ShadowMap is wiping out ambient light; how to fix? Hi Ben, Thanks for investigating, with my fix I obviously made the assumption that the ShadowedScene contained the whole scene graph. As for using a separate light, this might well be the best route, one would probably need to keep overwriting it's values each frame from the main one. There will probably be issues about having two light sources on the same light number for a single RenderStage... ouch this one could get a bit sticky, this suggests we'd need to make the ShadowedScene its own RenderStage. Could you explain a bit more about your scene graph layout so I can better understand the mechanics of what is going wrong. Adding an extra example scene graph into the osgshadow example that illustrates this problem would be best as this would give us something we can all test and reproduce the problem and make sure fixes work well. Robert. On Thu, May 22, 2008 at 8:39 AM, Ben Discoe [EMAIL PROTECTED] wrote: - From: Alejandro Segovia Sent: Wednesday, May 21, 2008 5:50 AM Hey Ben, On Tue, May 20, 2008 at 6:20 AM, Ben Discoe [EMAIL PROTECTED] wrote: I noticed that using osgShadow::ShadowMap in my scene makes everything very dark, even nodes not part of the shadowed scene. Studying the OSG code, i found this in ShadowMap.cpp, in ShadowMap::cull: const_castosg::Light*(selectLight)- setAmbient(osg::Vec4(0.0f,0.0f,0.0f,1.0f); I can't seem to find this in OSG 2.2. It must have been added recently. Maybe the old code can be forward ported? :P I dug into SVN, and found the change, revision 7690, December 15, 2007. Comment is Tweaked the ambient lighting contribution so that the OpenGL vertex lighting has the ambient light source switched off, and use the fragment shader to add this contribution back in. That added the code: // set to ambient on light to black so that the ambient bias uniform can take it's affect const_castosg::Light*(selectLight)- setAmbient(osg::Vec4(0.0f,0.0f,0.0f,1.0f)); Unfortunately that breaks ambient light for the entire rest of the scene, because that light is the same light used to illuminate everything, even outside the shadowed sub-graph. Setting ambient to black has no effect if your materials already have no ambient. But if they have ambient, then osgshadow is wiping it out, resulting in very dark objects. So yes, the code can be 'forward ported' - we can remove that black ambient, or some other solution such as using a separate light. Robert, should i submit the fix to osg-submissions? -Ben ___ 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 /* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield * * This library is open source and may be redistributed and/or modified under * the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or * (at your option) any later version. The full license is in LICENSE file * included with this distribution, and on the openscenegraph.org website. * * This library is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * OpenSceneGraph Public License for more details. */ #include osgShadow/ShadowMap #include osgShadow/ShadowedScene #include osg/Notify #include osg/ComputeBoundsVisitor #include osg/PolygonOffset #include osg/CullFace #include osg/io_utils using namespace osgShadow; #include iostream //for debug #include osg/LightSource #include osg/PolygonMode #include osg/Geometry
Re: [osg-users] ShadowMap uses wrong mask for traversal
Robert, cv.setTraversalMask( traversalMask getShadowedScene()-getCastsShadowTraversalMask() ); If there is always overlap, then = with traversalmask is a no-op. That isn't logical. The intention is that traversal is restricted to only subgraphs that have the CastShadow bits enabled on them. That intention would be accomplished by this code: cv.setTraversalMask( getShadowedScene()-getCastsShadowTraversalMask() ); ing with the traversalmask does not accomplish anything useful: 1. in the case of overlapping bits it does nothing. 2. in the case of non-overlapping bits it results in a bug. I stand by the code, I believe it is correct. Disabling the CastShadow bits in the viewer should mean that the ShadowScene won't traverse the subgraphs that request the CastShadow bits to be set. Yes, and that logic is preserved by the fix i proposed. I'm know you're very busy, but really this is a simple 1-line fix, applying the fix would keep users with non-default traversalMask from having to fork the OSG code in order to draw shadows. -Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow, node traversal, and node mask
Alejandro, I suspect the most likely explanation is this: 1. You are using ShadowTexture, which AFAIK doesn't support self-shadowing. 2. ShadowTexture is ignoring your ReceivesShadow bit, however: 3. When you turn on CastsShadow for a node, it is then implicitly preventing it from receiving a shadow, because the algorithm can't do both. Try replacing your ShadowTexture with a ShadowMap and see if the behavior changes; ShadowMap does support self-shadowing. -Ben - From: Alejandro Segovia [EMAIL PROTECTED] Sent: Thursday, May 15, 2008 8:20 AM I'm using the ShadowTexture technique on a Software project I'm working on, and I've set the CastsShadowTraversalMask to 0x1, the ReceivesShadowTraversalMask to 0x2, and have set the node masks for my nodes to be 0x3 (0x1|0x2), meaning they cast and receive shadows at the same time, however when I run the application, shadow casting nodes never get other nodes' shadows casted upon. If I just set the node mask to be 0x2 (the receive mask), they receive shadows just fine, but when I set that to be 0x3, they stop receiving them. Am I doing something wrong? I'm under Linux with an nVIDIA graphics card. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow, node traversal, and node mask
- From: Wojciech Lewandowski [EMAIL PROTECTED] Sent: Wednesday, May 14, 2008 10:29 PM Hi Ben, CastsShadow bit _does_ need to be set for every parent along the nodepath. If it's true, then that's a very big consideration in how scene graphs must be constructed to use osgShadow, and i can document it. Yes its true, but defaults for Node mask are 0x and NodeVisitor mask is also 0x. If one changes masks, he does it with deliberate intention to limit traversals to some portions of the scene. Thanks. I understand how it works now, however: For most typical scenario where all parts of the graph cast shadow and can receive shadow, Cast and /Receive masks should be left at default 0x setting. I fear this is not typical. Due to the scale limitations of osgShadow, i suspect that 'most' scenarios involve enabling shadow only for certain nodes. Scenarios where some portion of the scene graph does not cast or receive shadows are unusual and indeed may require careful selection of node masks. I think they are not 'unusual', rather, the case where the shadow flags should be set for every node might only exist in a tiny example like osgshadow. This means that integrating a single shadow-casting node into an existing OSG application involves the entire application changing its node masks, with code throughout. It's unfortunate, but it is at least possible. If one does not want some portion of the scene to cast or receive shadows he may also choose to not attach them to ShadowedScene node. Many (most) nontrivial 3D applications have scene graphs which are already quite structured for reasons such as LOD; moving nodes around to put them under ShadowedScene would break things completely. The only solution seems to be to put ShadowedScene high up in the graph, and change the code all over the place to carefully disable shadows. This is a lot of grief that could be spared if the shadow mask logic was opposite; a bit set to NOT cast a shadow. Then, adding shadow code to an application would involve only small localized code changes. shrug But that's the design, and it can be documented, and i can work with it. -Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] ShadowMap is wiping out ambient light; how to fix?
I noticed that using osgShadow::ShadowMap in my scene makes everything very dark, even nodes not part of the shadowed scene. Studying the OSG code, i found this in ShadowMap.cpp, in ShadowMap::cull: const_castosg::Light*(selectLight)-setAmbient(osg::Vec4(0.0f,0.0f,0.0f,1.0f); The light's ambient is set to black, and never restored! That certainly explains why my whole scene is darker than normal. I thought i might fix it by saving the ambient value, and restoring it later at the bottom of ShadowMap::cull(). And in fact, this does restore the scene's lighting - but, it prevents ShadowMap from drawing a shadow correctly. Apparently, ShadowMap needs this black ambient set later after cull(), probably during render(). But if the light is black during the scene's render(), that's not good. Does anyone see a solution to this? I can only imagine a couple of possibilities: 1. Move the black-ambient from cull() to render pass somehow. I don't see any explicit render() code in ShadowMap so i have no idea how this would work. It seems like it must be possible. 2. Workaround: Make a second light, and set it with ShadowMap::setLight. Then ShadowMap can use that light with black ambient, and leave the real light alone. But, this is messy; we don't actually want 2 lights turned on in the OpenGL pipeline, and we'd have to constantly copy values (like direction) from the real light to the dummy light. -Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] ShadowMap uses wrong mask for traversal
I found what appears to be another bug/limitation in ShadowMap.cpp. When traversing the nodes which cast shadows, it uses this code: cv.setTraversalMask( traversalMask getShadowedScene()-getCastsShadowTraversalMask() ); 'traversalMask' here is the sceneview's draw mask, which defaults to 0x, but can be set to other values depending on the application's needs. Consider the case: ReceivesShadow = 0x1 CastsShadow = 0x2 Scene's DrawMask = 0x4 For a node which is drawn and fully shadowed, such as the default mask, these are all set, so its node mask includes the bits 0x7. Now ShadowMap comes along, and the above code computes (0x4 0x2) == 0. A visitor mask of 0 finds nothing. That's not right. I can only imagine the ShadowMap author meant, they wanted to traverse nodes with _both_ bits set, both visible and casting. But, AFAIK, NodeVisitor doesn't do AND, it only does OR. That is, a traversal will always proceed when _any_ bit matches, not when _all_ bits match. So the above is a bug from misunderstanding how NodeVisitor works. To replace the code with this, would at least fix the general case: cv.setTraversalMask( getShadowedScene()-getCastsShadowTraversalMask() ); However, that doesn't correctly omit nodes which are casting but not drawn, e.g. mask=0x3 using the values above. Perhaps it's just not possible for node traversal to do the correct thing? Or maybe, there is some more powerful visitor capability in OSG that would save the day here? -Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow, node traversal, and node mask
Gordon, thanks, that clears up the first part, a default Camera mask of 0x explains why any non-zero node mask is rendered. I fear that also means, in the second question below, that the CastsShadow bit _does_ need to be set for every parent along the nodepath. Otherwise, a visitor recursive descent of the scene graph will quit as soon as it encounters any node, like a Group or LOD, that does not have the CastsShadow bit set. Can anyone who understands osgShadow's NodeVisitors comment? If it's true, then that's a very big consideration in how scene graphs must be constructed to use osgShadow, and i can document it. -Ben -Original Message- From: Gordon Tomlinson Sent: Wednesday, May 14, 2008 4:56 PM I can answer the Node Mask See http://www.vis-sim.com/imgdp/vp_rendermasks_01.jpg http://www.vis-sim.com/imgdp/vp_rendermasks_01a.jpg So in this case the Camera will have a default mask of 0xfff so a logical AND apart from 0x0 will produce true result, eg 0x0010 0x results in 0x0010 etc while 0x 0x will produce 0x false etc... __ -Original Message- From: Ben Discoe Sent: Wednesday, May 14, 2008 10:35 PM There's something i'm not understanding about osgShadow, and it's probably a basic behavior of OSG. So, the simple question first: The default node mask for all nodes is 0x. It i set the mask to 0, then the node (and its children) is not drawn. If i set the mask to some other value, then it seems to be drawn also. So what is OSG testing for, mask!=0? The NodeVisitor code seem to deal with bit masks. So is there some specific bit (high bit, perhaps?) in the node mask which says draw me? This relates to osgShadow's CastsShadowTraversalMask. Let's say it's set to 1. In the simple case (like example osgshadow) of a ShadowedScene with some children, it's clear how it will behave: nodes with the 0x1 bit set in their mask will cast shadows. But, what if there is a large complex scene graph? Nodes A and B are far apart in the graph. The ShadowedScene node is up at the top of the graph. If we want A to shadow B, then we need to set the appropriate bits in the node mask of A and B, and un-set them for everything else. But, will the node traversal (of the ShadowTechnique) ever reach A and B, to test if they have CastsShadowTraversalMask set? Or does every parent along the nodepath need the flag set also? If that's true, then for this to be useful, we'd need some iteration code (NodeVisitors, presumably) to set up the scene graph, clearing the mask bits everywhere, and then starting with the ShadowCasting nodes, walking upwards setting the CastsShadowTraversalMask bits along the way, until it reaches ShadowedScene? If anyone can answer these, i am happy to add an explanation the osgShadow wiki docs. Thanks, Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] ShadowTexture::setTextureSize?
Thanks to J-S and the others who have filled in the osgshadow documentation, it is really starting to come together. Question of the day: I find a setTextureSize method on ShadowMap and SoftShadowMap, but not on the 3 other techniques (even in SVN head). In particular ShadowTexture has code like this: unsigned int tex_width = 512; unsigned int tex_height = 512; ... But no setTextureSize method. So it seems like it would be very easy to add it. Is there some technical reason it's not there, or just an oversight? If oversight, may i implement and submit it? -Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to document osgShadow?
- From: Wojciech Lewandowski Sent: Tuesday, May 13, 2008 12:35 PM Hi Ben, J-S, and All, I have recently fixed SSM debuging HUD. Its now functional. I think this is quite useful option that is worth some presentation to wider audience. What is this HUD? It sounds very interesting, are you ready to share it, or is it already in the OSG src somewhere? Since I ate my teeth writing SSM derived code Ouch, that sounds painful, my sympathies. I am eager to answer all technical questions regarding SSM internals. Great. 1. Inside SSM src, i see calls to getCastsShadowTraversalMask but not getReceivesShadowTraversalMask. Is this because SSM (like others) does not permit supporting the Receives mask? 2. What do AmbientBias, SoftnessWidth, and JitteringScale do? What are typically useful range of values they could take? When you write your documentation it might be a good moment to review and clean up osgShadow code a bit and discuss some future developments of it. I hope Robert or some other OSG architects can follow up with your suggested changes, because they are well beyond me. :) Thanks, Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] VRML Normals
I noticed that OSG 2.2 does not properly calculate the normals of VRML files. It seems like it points all the normals at (0, -1, 0). This is only when the normals are not explicitly specified in the file. If you open a VRML file like this in osgviewer, you can see that the coloration of the mesh is only accurate when looking at the top of the object. If the normals are specified in the VRML file, then the mesh coloration looks correct in osgviewer. I can supply an example VRML files that demonstrate this bug, and also how to fix it. Has this bug been fixed in version 2.4? Thanks, -Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] TriangleMesh color
Hi, I am trying to use a triangle mesh. And for some reason, it always shows up black. Here is a snipit of code: osg::ref_ptrosg::Geode _geode; _geode = new osg::Geode(); osg::ref_ptrosg::TriangleMesh _trimesh; _trimesh = new osg::TriangleMesh(); osg::ref_ptrosg::ShapeDrawable _SD; _SD = new osg::ShapeDrawable(_trimesh.get()); _SD-setColor(osg::Vec4f(1.0f, 1.0f, 1.0f, 1.0f)); _geode-addDrawable(_SD.get()); osg::Vec3Array* vecs = new osg::Vec3Array(); vecs-push_back(osg::Vec3d(0, 0, 0)); vecs-push_back(osg::Vec3d(1, 0, 0)); vecs-push_back(osg::Vec3d(0, 0, 1)); _trimesh-setVertices(vecs); osg::TemplateIndexArrayunsigned int, osg::Array::UIntArrayType, 1, 1* ind = new osg::TemplateIndexArrayunsigned int, osg::Array::UIntArrayType, 1, 1(); ind-push_back(0); ind-push_back(1); ind-push_back(2); _trimesh-setIndices(ind); As you can see, the TriangleMesh is a child of a ShapeDrawable node, which should set its color to white. This technique has worked great for the other shape primitives. Is there another way to set the color for a TriangleMesh? Or is there another way I should construct my tree? Or is it a bug? Thanks, -Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgShadow, node traversal, and node mask
There's something i'm not understanding about osgShadow, and it's probably a basic behavior of OSG. So, the simple question first: The default node mask for all nodes is 0x. It i set the mask to 0, then the node (and its children) is not drawn. If i set the mask to some other value, then it seems to be drawn also. So what is OSG testing for, mask!=0? The NodeVisitor code seem to deal with bit masks. So is there some specific bit (high bit, perhaps?) in the node mask which says draw me? This relates to osgShadow's CastsShadowTraversalMask. Let's say it's set to 1. In the simple case (like example osgshadow) of a ShadowedScene with some children, it's clear how it will behave: nodes with the 0x1 bit set in their mask will cast shadows. But, what if there is a large complex scene graph? Nodes A and B are far apart in the graph. The ShadowedScene node is up at the top of the graph. If we want A to shadow B, then we need to set the appropriate bits in the node mask of A and B, and un-set them for everything else. But, will the node traversal (of the ShadowTechnique) ever reach A and B, to test if they have CastsShadowTraversalMask set? Or does every parent along the nodepath need the flag set also? If that's true, then for this to be useful, we'd need some iteration code (NodeVisitors, presumably) to set up the scene graph, clearing the mask bits everywhere, and then starting with the ShadowCasting nodes, walking upwards setting the CastsShadowTraversalMask bits along the way, until it reaches ShadowedScene? If anyone can answer these, i am happy to add an explanation the osgShadow wiki docs. Thanks, Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
