Re: [osg-users] Prevent Viewer::frame from changing frustum?
On Sat, Dec 13, 2008 at 7:39 AM, Vincent Bourdier vincent.bourd...@gmail.com wrote: Hi, 2008/12/12 Alejandro Segovia aseg...@gmail.com Hi OSG-users, I've noticed calling viewer-frame() seems to be changing my left, right, bottom, top, z near and z far clipping planes when I set the camera's projection matrix as a frustum. Is there some way to prevent it from making these changes? You sould try camera-setComputeNearFarMode(osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR) Next, set your own frustum. Thanks, I'll try it and let you now how it goes :) Alejandro.- -- varr...@linux http://varrojo.linuxuruguay.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Prevent Viewer::frame from changing frustum?
Hi OSG-users, I've noticed calling viewer-frame() seems to be changing my left, right, bottom, top, z near and z far clipping planes when I set the camera's projection matrix as a frustum. Is there some way to prevent it from making these changes? Thanks in advance, Alejandro.- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Linux Dev. Env. Poll
On Sun, Nov 30, 2008 at 10:28 AM, Can T. Oguz [EMAIL PROTECTED] wrote: Sure I'll try if I can get a grip on Eclipse. Hi Can, You can also try NetBeans, which added support for C/C++ a couple of versions ago. I found it easier to use than Eclipse with CDT and you can also just download the C++ 'spin', without having to get all the Java stuff. Hope this helps, Alejandro.- -- [EMAIL PROTECTED] http://varrojo.linuxuruguay.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Videos of DBGS Trian3D
Very cool indeed :) Does it run on other platforms? Are you using wxWidgets or Qt for the UI stuff or calling into win32 directly? Alejandro.- On Thu, Nov 27, 2008 at 7:50 AM, Stephan Kussmaul [EMAIL PROTECTED] wrote: Hi OSG Users, We have created a few new videos about our terrain generation software Trian3D. Maybe some of you like to see what we are doing with OSG. Here is the link to our website: www.triangraphics.de/index.php?1=Download2=Videosl=eng or if you prefer to watch them on YouTube (in modest quality though): www.youtube.com/user/TrianGraphics Any comments or suggestions are welcome. If anyone is interested in meeting me at the I/ITSEC, just let me know. Best regards and thanks to all OSG developers, Stephan -- - Stephan Kussmaul Geschaeftsfuehrender Gesellschafter / Managing Director TrianGraphics GmbH Schoenhauser Allee 45 10435 Berlin Germany Tel: +49 (0)30 48495565 FAX: +49 (0)30 48495581 Email: [EMAIL PROTECTED] Web: www.triangraphics.de - Sitz der Gesellschaft / Corporate Headquarters: TrianGraphics GmbH, Berlin Registereintragung / Registration: Amtsgericht Berlin-Charlottenburg HRB 93807 B Geschaeftsfuehrer / Managing Directors: Stephan Kussmaul, Mirco Nierenz, Volker Walkiewicz ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- [EMAIL PROTECTED] http://varrojo.linuxuruguay.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test SVN of OpenSceneGraph in pre for 2.7.6 dev release
Hi Robert, I'm having trouble building on Debian Etch. I'm getting the following error when configuring within ccmake: IF had incorrect arguments: POLICY CMP0008 (Unknown arguments specified). Perhaps my cmake version is too old, I'm using: cmake version 2.4-patch 5 Alejandro.- On Thu, Nov 27, 2008 at 3:34 PM, Robert Osfield [EMAIL PROTECTED]wrote: Hi All, I'm now pretty well on top of submissions, so am looking towards making a dev release tomorrow morning. Could users check out the latest version of the OSG to see how things build and run on your platform. Thanks, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- [EMAIL PROTECTED] http://varrojo.linuxuruguay.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Linux Dev. Env. Poll
Dear OSG Users, May I Ask which linux distribution and development environment you chose to work on ? Hi, I use Debian Etch with the GNU toolchain (gcc, make, gdb). I edit text mostly on Kate and (sometimes) on vim. Alejandro Segovia.- -- [EMAIL PROTECTED] http://varrojo.linuxuruguay.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] PSSM and Blend
Hello List, it's been a while. I have just a short question regarding the usage of the PSSM shadow technique and alpha blending. For some reason when using both, the shadow casting objects (an sphere, for instance) looks somewhat transparent on some parts. When turning Alpha Blending off, this gets fixed. I was just wondering if this was some sort of known bug or whether it shouldn't be happening to me at all. I'm using OSG 2.6 on Debian GNU/Linux. Thanks in advance, Alejandro.- -- [EMAIL PROTECTED] http://varrojo.linuxuruguay.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Can't have more than one NodeTrackerManipulator?
Hello all, I've been working on an application which can have several windows displaying the same scene. Each one of my windows has a osgUtil::SceneView object which I use to cull and draw onto it. Windows are created one after the other, meaning I'll have several osg::Camera objects as parents to my scene. Everything seems to be working fine until I try to track a node with NodeTrackerManipulator in the window which was created the second. For some reason when the NodeTrackerManipulator collects the nodepath, it always gets the camera that belongs to the first SceneView object instead of finding the camera that belongs to the SceneView we are drawing from. This causes the camera to look really weird, since the wrong matrices are being taken into account when computing the node center and rotation. What's even worse is that if I then close the first window, the SceneView object gets deleted and then computing the node center and rotation segfaults, since the nodepath is no longer valid! Is there some way to prevent NodeTrackerManipulator from getting confused like this? Is this the normal behavior for this manipulator? Thanks in advance, Alejandro.- -- [EMAIL PROTECTED] http://varrojo.linuxuruguay.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Positioning the viewers camera
Hello, On Fri, Jun 6, 2008 at 11:10 AM, Kaiser, Hagen (CT) [EMAIL PROTECTED] wrote: Hello everyone, I am desparately trying to position a viewers camera manually and correctly. My give data give me a Position Vector a RotationAxis and a Rotation Angle. And a float that is named fieldofView. Here is how I implement it: osgGA::TrackballManipulator* man = (osgGA::TrackballManipulator*)this -viewer-getCameraManipulator(); osg::Matrix trans; trans.makeTranslate(osg::Vec3(position.x(),position.y(),position.z())); osg::Matrix rot; rot.makeRotate(Angle,osg::Vec3(Axis.x,Axis.y,Axis.z))); osg::Matrix cam = rot*trans; this-viewer-setByMatrix(cam) } But I never get the right position or rotation. After testing around, I noticed the following: Changing trans.makeTranslate(… to trans.makeTranslate(osg::Vec3(position.x,* -position.z, position.y*)); Have you tried making a translation of (-x, -y, -z) instead? Remember that placing the camera at some point P is actually applying a translation of -P to the whole world. cam = rot*trans seems fine. Let me know how it went. Alejandro.- -- [EMAIL PROTECTED] http://varrojo.linuxuruguay.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Positioning the viewers camera
On Fri, Jun 6, 2008 at 11:45 AM, Kaiser, Hagen (CT) [EMAIL PROTECTED] wrote: It is in radians. But do you know something about those diffent Up-Vectors? I didn't notice those vectors were different since I user SceneView directly, instead of osgViewer::Viewer. You can change the coordinate system for all these objects by creating your own CoordinateFrameCallback class whose getCoordinateFrame method returns a matrix corresponding to whatever you want the Axes to be. The coordinate frame callback can be passed to the MatrixManipulators to change what they think the axes are like. Alejandro.- -- [EMAIL PROTECTED] http://varrojo.linuxuruguay.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PSSM OpenGL Extensions
On Thu, Jun 5, 2008 at 3:38 AM, Adrian Egli OpenSceneGraph (3D) [EMAIL PROTECTED] wrote: Hi Alejandro, the PSSM is based on GLSL shaders and no other specials. how did you fixed it on the NVidia GeForce 7300LE card? it would be important to get more detail in the problem you got. I haven't fixed it yet. I think the problem has to do with some GLSL extension in use by the PSSM shader which is not available in the NVidia GeForce 7300LE card. I've ran my application on both cards (7300LE and 8600GT) with OSG_NOTIFY_LEVEL=DEBUG and found some extensions missing in the 7300LE card which are present in the 8600GT card. These are: GL_EXT_geometry_shader4, GL_EXT_gpu_shader4 and GL_EXT_texture_integer. Is any of these 3 extensions actually needed by the PSSM shader? Thanks, Alejandro.- PS: I haven't been able to get the InfoLog output, it appears to be always empty. -- [EMAIL PROTECTED] http://varrojo.linuxuruguay.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PSSM OpenGL Extensions
Hi Adrian, Thanks for you quick reply. On Thu, Jun 5, 2008 at 3:10 PM, Adrian Egli OpenSceneGraph (3D) [EMAIL PROTECTED] wrote: Hi i don't use any geometrie shader. it works event on my elder card (ATI X1600M) . can you disable in the pssm source code the glsl, just a define to unmark. does shadow map work ? Oh PSSM does work. The problem is that it is painfully slow on the 7300LE cards, eating 100% of the CPU with just 3 SceneView objects. ShadowTexture runs great on these cards, but it doesn't use any shaders, so I was wondering if it could be some GLSL extension those cards were missing or maybe the fact that they are running NVidia driver version 100, instead of 169 (the latest). We're running on Debian Linux. These are (some of) the messages I get from OSG, maybe the can be of help: OpenGL extension '' is not supported. OpenGL extension 'GL_ARB_pixel_buffer_object' is supported. OpenGL extension 'GL_ARB_fragment_program' is supported. OpenGL extension 'GL_EXT_framebuffer_object' is supported. OpenGL extension 'GL_ARB_shader_objects' is supported. OpenGL extension 'GL_ARB_vertex_shader' is supported. OpenGL extension 'GL_ARB_fragment_shader' is supported. OpenGL extension 'GL_ARB_shading_language_100' is supported. OpenGL extension 'GL_EXT_geometry_shader4' is not supported. OpenGL extension 'GL_EXT_gpu_shader4' is not supported. glVersion=2.1, isGlslSupported=YES, glslLanguageVersion=1.2 OpenGL extension 'GL_ARB_vertex_program' is supported. OpenGL extension 'GL_ARB_vertex_program' is supported. OpenGL extension 'GL_EXT_secondary_color' is supported. OpenGL extension 'GL_EXT_fog_coord' is supported. OpenGL extension 'GL_ARB_multitexture' is supported. OpenGL extension 'GL_NV_occlusion_query' is supported. OpenGL extension 'GL_ARB_occlusion_query' is supported. OpenGL extension 'GL_EXT_timer_query' is supported. Setting up osg::Camera::FRAME_BUFFER_OBJECT OpenGL extension 'GL_EXT_texture_filter_anisotropic' is supported. OpenGL extension 'GL_EXT_texture_compression_s3tc' is supported. OpenGL extension 'GL_ARB_shadow' is supported. OpenGL extension 'GL_ARB_shadow_ambient' is not supported. OpenGL extension 'GL_APPLE_client_storage' is not supported. OpenGL extension 'GL_EXT_texture_integer' is not supported. OpenGL extension 'GL_EXT_secondary_color' is supported. OpenGL extension 'GL_EXT_fog_coord' is supported. Thanks, Alejandro.- -- [EMAIL PROTECTED] http://varrojo.linuxuruguay.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] PSSM OpenGL Extensions
Hello list. I wanted to ask if anyone knows what OpenGL extensions are used by the PSSM shadow technique shipped with OSG 2.4. I'm having a hard time using PSSM shadows on low end video cards such as the NVIDIA GeForce 7300LE, while the same code runs great on a GeForce 8600GT. On the low end video cards I sometimes get a warning regarding an extension not being found and the code is really really slow when the shadows are on. Anyone knows which OpenGL extensions PSSM uses? Thanks in advance! Alejandro.- -- [EMAIL PROTECTED] http://varrojo.linuxuruguay.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] 3D Text looks funky under PSSM?
Hi all After much work I've managed to get PSSM working on my application (yay), but I've noticed for some reason 3D text under it looks really strange, as if it had a black background around each letter (af is the transparency was broken). So far the only solution I've found is to add 3D text as a sibling to the ShadowedScene, so shadows are not computed on it and it looks fine. I wanted to ask if this is a known issue and if there happens to be a way to protect a node from receiving shadows other than using the node mask, since PSSM ignores the ReceiveShadowMask. Thanks in advance, Alejandro.- -- [EMAIL PROTECTED] http://varrojo.linuxuruguay.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Adding a shader cancels shadows!
On Fri, May 23, 2008 at 5:08 AM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Mael, As Art and Sebastian have mentioned, since osgShadow implements its own shaders these will replace you own ones. This does make integrating other effects with osgShadow difficult. Shaders are in general difficult to combine, but osgShadow certainly doesn't make it any easier. I think the right way forward for osgShadow is to provide a public interface for getting the uniforms and individual shaders, the allow users to define a main() shader to combine these are their own shaders. Alas this isn't just a little tweak to osgShadow so not something that can be slotted in right away. What if osgShadow could return a string containing the Shadow shader encapsulated in a function and its Uniforms?, something like string s = PSSM-getShaderFuncAndUniforms() so the user can just paste together both shaders. It guess it should work as long as the user called the Shader function from the main() in his Shader (and set the Uniforms), right? Just a thought, not sure it is feasible... Alejandro.- -- [EMAIL PROTECTED] http://varrojo.linuxuruguay.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] NodeTrackedManipulator constantly segfaulting
On Fri, May 23, 2008 at 4:57 AM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Alejandro, On Thu, May 22, 2008 at 9:24 PM, Alejandro Segovia [EMAIL PROTECTED] wrote: Could this problem have something to do with the fact that I never attach my cameras to the Scene Graph? Cameras in a scene graph are used for doing effects like shadows, impostors etc, not for managing the main view, these cameras are at the top and actually contain the scene graph, rather than the other way around. I've only ever seen pulsing in apps which have two places where the view matrix is set, perhaps this is something you're doing. Actually, I am using a TrackballManipulator and replacing its ref_ptr with a new NodeTrackerManupulator when I have to enter node tracking mode. I'm not using the KeySwitchMatrixManipulator, but simply changing back and forth, overwriting the ref_ptr... Maybe sometimes I get one handler and sometimes the other? It shouldn't be the case... Alejandro.- -- [EMAIL PROTECTED] http://varrojo.linuxuruguay.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] NodeTrackedManipulator constantly segfaulting
On Fri, May 23, 2008 at 11:02 AM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Alejandro, On Fri, May 23, 2008 at 2:31 PM, Alejandro Segovia [EMAIL PROTECTED] wrote: Actually, I am using a TrackballManipulator and replacing its ref_ptr with a new NodeTrackerManupulator when I have to enter node tracking mode. I'm not using the KeySwitchMatrixManipulator, but simply changing back and forth, overwriting the ref_ptr... Maybe sometimes I get one handler and sometimes the other? It shouldn't be the case... I'm afraid I can't really help, you. There is plenty of stuff you are doing at your end that I am not party to. You'll need to step through with a debugger and work out yourself what you are doing wrong. Yes, you are absolutely right, I'm sorry if the topic went too much into my own application. I'm trying to understand how the NodeTrackerManipulator works so I can adjust the way I'm using it. Following you advice, I added a couple of printf's to see what the computeNodeCenterAndRotation call was returning (had to make it public in order to call it from my app), and got the following for an non-moving node at 0,0,0: Tracked object is at: (0.00,0.00,7.660254) with rotation: (0.00,0.00,0.00,1.00) Tracked object is at: (0.00,0.00,-8.660254) with rotation: (0.00,0.00,0.00,1.00) for two consecutive frames. Now, thinking about it, I wonder, if the world coordinates are indeed affected by the camera position, then it kind of makes sense to have the object's center changing. The first time the camera is at certain position and the nodetracker determines it has to be moved away in the Z+ direction, then the next frame the center is recalculated and now , since the camera is further away, the Z of the object changed and the tracker determines it has to move closer in the Z- direction. The consecutive application of this steps makes the camera ping-pong back and forth. I guess my question is, does the camera position affect the calculation of the node's center? If so, how can I prevent it? And also, how come the center's Z is never 0? can the tracking step be adjusted somehow? Thanks in advance, Alejandro.- -- [EMAIL PROTECTED] http://varrojo.linuxuruguay.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] NodeTrackedManipulator constantly segfaulting
On Fri, May 23, 2008 at 12:18 PM, Alejandro Segovia [EMAIL PROTECTED] wrote: On Fri, May 23, 2008 at 11:02 AM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Alejandro, On Fri, May 23, 2008 at 2:31 PM, Alejandro Segovia [EMAIL PROTECTED] wrote: Actually, I am using a TrackballManipulator and replacing its ref_ptr with a new NodeTrackerManupulator when I have to enter node tracking mode. I'm not using the KeySwitchMatrixManipulator, but simply changing back and forth, overwriting the ref_ptr... Maybe sometimes I get one handler and sometimes the other? It shouldn't be the case... I'm afraid I can't really help, you. There is plenty of stuff you are doing at your end that I am not party to. You'll need to step through with a debugger and work out yourself what you are doing wrong. Yes, you are absolutely right, I'm sorry if the topic went too much into my own application. I'm trying to understand how the NodeTrackerManipulator works so I can adjust the way I'm using it. Following you advice, I added a couple of printf's to see what the computeNodeCenterAndRotation call was returning (had to make it public in order to call it from my app), and got the following for an non-moving node at 0,0,0: Tracked object is at: (0.00,0.00,7.660254) with rotation: (0.00,0.00,0.00,1.00) Tracked object is at: (0.00,0.00,-8.660254) with rotation: (0.00,0.00,0.00,1.00) for two consecutive frames. Now, thinking about it, I wonder, if the world coordinates are indeed affected by the camera position, then it kind of makes sense to have the object's center changing. The first time the camera is at certain position and the nodetracker determines it has to be moved away in the Z+ direction, then the next frame the center is recalculated and now , since the camera is further away, the Z of the object changed and the tracker determines it has to move closer in the Z- direction. The consecutive application of this steps makes the camera ping-pong back and forth. I guess my question is, does the camera position affect the calculation of the node's center? If so, how can I prevent it? And also, how come the center's Z is never 0? can the tracking step be adjusted somehow? Okay as I was suspecting, the problem had to do with the camera's coordinates affecting the world coordinates of the node I was tracking. Since calculating the world coordinates for the node is done in the getInverseMatrix() method, what I did was just set the camera's view matrix to an identity right before calling the getInverseMatrix() method. This seems more of a hack than a solution, but I guess it's the cost of using SceneView instead of osgViewer, which does not seem to have this problem as the osgsimulation example runs exemplary. Best regards, Alejandro.- -- [EMAIL PROTECTED] http://varrojo.linuxuruguay.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] NodeTrackedManipulator constantly segfaulting
On Mon, May 19, 2008 at 4:23 PM, Alejandro Segovia [EMAIL PROTECTED] wrote: Actually, I've discovered that the tilting effect in NodeTrackerManipulator is actually a pulsing effect. For some reason NodeTrackerManipulator never seems to settle at a position, providing a view matrix for even frames and another one for uneven frames. Here is a printout of two consecutive view matrices (obtained calling getInverseMatrix): [1.00,0.00,0.00,0.00] [0.00,1.00,0.00,0.00] [0.00,0.00,1.00,0.00] [0.00,0.00,-106.750074,1.00] [1.00,0.00,0.00,0.00] [0.00,1.00,0.00,0.00] [0.00,0.00,1.00,0.00] [0.00,0.00,-117.486391,1.00] This pattern just goes on forever and makes the view pulse. I'm sure this is a problem in the way I'm setting up this manipulator, since this problem is not present in the osgsimulation example, but I'm not making too many changes to the default, just setting the node to track, the trackermode to NODE_CENTER and the rotationmode to TRACKBALL. I'm also using a custom coordinate frame callback, which (always) returns an identity with the second and third row exchanged. Any ideas? Could this problem have something to do with the fact that I never attach my cameras to the Scene Graph? Thanks in advanced, Alejandro.- -- [EMAIL PROTECTED] http://varrojo.linuxuruguay.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Set Light for PSSM
Hello all, This may be a trivial question, but how do I set up the light for the PSSM Shadow Technique? I've got a light added at my scene graph's root, which is currently a sibling of the ShadowedScene node, could this be the reason why the technique never finds it? Thanks in advance, Alejandro.- -- [EMAIL PROTECTED] http://varrojo.linuxuruguay.org ___ 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?
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 -- [EMAIL PROTECTED] http://varrojo.linuxuruguay.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PSSM segfaulting in cull()?
Hello Adrian, thanks for your reply,
On Tue, May 20, 2008 at 3:27 AM, Adrian Egli OpenSceneGraph (3D)
[EMAIL PROTECTED] wrote:
Which version are you using the latest SVN, the latest PSSM (see post from
friday to yesterday) ?
I'm actually on OSG 2.2, but I don't think this is a problem with the OSG
version, since the osgshadow example runs without problems.
I think it must have something to do with the viewer the example uses...
somehow it forces the shader to be compiled before rendering, but since I am
using my own viewer, it doesn't seem to get compiled before trying to
render and the cull() call segfaults.
Maybe there is an OpenGL way to flush shader compilation?
Thanks,
Alejandro.-
2008/5/19 Alejandro Segovia [EMAIL PROTECTED]:
On Mon, May 19, 2008 at 6:03 PM, Alejandro Segovia [EMAIL PROTECTED]
wrote:
Hello List,
I'm having a hard time using PSSM (or anything besides ShadowTexture for
that matter) to add shadows to my scene.
I've got some initialization code inspired in the osgshadow example,
which seems to work fine when I pass the --NVidea parameter, but when I try
the very same technique in my code, it just crashes inside the PSSM's cull()
method.
This is the backtrace I get from the core dump:
#0 0xb6f961c9 in osgShadow::ParallelSplitShadowMap::cull ()
from /usr/local/OpenSceneGraph/2.2.0/lib/libosgShadow.so.25
#1 0xb6f87656 in osgShadow::ShadowTechnique::traverse ()
from /usr/local/OpenSceneGraph/2.2.0/lib/libosgShadow.so.25
#2 0xb6f8e7c0 in osgShadow::ShadowedScene::traverse ()
from /usr/local/OpenSceneGraph/2.2.0/lib/libosgShadow.so.25
#3 0xb6d38196 in osgUtil::CullVisitor::apply ()
from /usr/local/OpenSceneGraph/2.2.0/lib/libosgUtil.so.25
#4 0xb6f8eb11 in osgShadow::ShadowedScene::accept ()
from /usr/local/OpenSceneGraph/2.2.0/lib/libosgShadow.so.25
#5 0xb726fa84 in osg::Group::traverse ()
from /usr/local/OpenSceneGraph/2.2.0/lib/libosg.so.25
#6 0xb6d38196 in osgUtil::CullVisitor::apply ()
from /usr/local/OpenSceneGraph/2.2.0/lib/libosgUtil.so.25
#7 0xb727095f in osg::Group::accept ()
from /usr/local/OpenSceneGraph/2.2.0/lib/libosg.so.25
#8 0xb6dc89f7 in osgUtil::SceneView::cullStage ()
from /usr/local/OpenSceneGraph/2.2.0/lib/libosgUtil.so.25
#9 0xb6dc7cd6 in osgUtil::SceneView::cull ()
from /usr/local/OpenSceneGraph/2.2.0/lib/libosgUtil.so.25
#10 0xb6a596ef in Canvas::customEvent (this=0x80c4780,
event=0x80deb60) at Canvas.cpp:200
Canvas is just a custom class derived from QGLWidget.
This is the initialization code I'm using, please note the ShadowedScene
node is not the root of the scene graph.
osg::ref_ptrosgShadow::ParallelSplitShadowMap shadowTech =
new osgShadow::ParallelSplitShadowMap(NULL, 3);
shadowTech-setTextureResolution(1024);
shadowTech-setMinNearDistanceForSplits(0);
shadowTech-setMaxFarDistance(0);
shadowTech-setMoveVCamBehindRCamFactor(0);
double polyoffsetfactor = 10.0f; //-0.02;
double polyoffsetunit = 20.0f; //1.0;
shadowTech-setPolygonOffset(osg::Vec2(polyoffsetfactor,polyoffsetunit));
_shadowNode = new osgShadow::ShadowedScene();
_shadowNode-setShadowTechnique(shadowTech.get());
_shadowNode-setCastsShadowTraversalMask(0x2|0x8);
_shadowNode-setReceivesShadowTraversalMask(0x1|0x8);
I'm also using SceneView objects to hold the camera information such as
the projection and modelview matrices. There are two lights in the scene and
only one object (a floor).
Thanks in advance,
Alejandro Segovia.-
--
[EMAIL PROTECTED]
http://varrojo.linuxuruguay.org
Setting the OSG_NOTIFY_LEVEL variable to DEBUG in order to determine what
could possibly be wrong, I noticed the shader program is never compiled for
PSSM! Is there some way to force program compilation in OSG?
I attach the dump for osgshadow and then for my application. Notice mine
never gets its shader compiled.
Dump for osgshadow:
...
View::init()
ParallelSplitShadowMap : Texture ID=0 Resolution=1024
CullSettings::readEnvironmentalVariables()
Uniform Adding parent
Uniform Adding parent
Uniform Adding parent
Uniform Adding parent
Uniform Adding parent
ParallelSplitShadowMap : Texture ID=1 Resolution=1024
CullSettings::readEnvironmentalVariables()
Uniform Adding parent
Uniform Adding parent
Uniform Adding parent
Uniform Adding parent
Uniform Adding parent
ParallelSplitShadowMap : Texture ID=2 Resolution=1024
CullSettings::readEnvironmentalVariables()
ParallelSplitShadowMap: GLSL shader code:
---
uniform sampler2D baseTexture;
uniform sampler2D randomTexture;
uniform float enableBaseTexture;
uniform sampler2DShadow shadowTexture0;
uniform float zShadow0;
uniform sampler2DShadow shadowTexture1;
uniform float zShadow1;
uniform sampler2DShadow shadowTexture2;
uniform float zShadow2;
void main(void)
{
vec4 coord = gl_FragCoord;
float shadow0 = shadow2DProj
Re: [osg-users] osgShadow, node traversal, and node mask
Hello Ben, thanks for your answer, On Tue, May 20, 2008 at 5:29 AM, Ben Discoe [EMAIL PROTECTED] wrote: 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. You're absolutely right: I am using ShadowTexture. I've tried different shadow techniques, but for some reason ShadowTexture is the only one that works in my application. I bet this is a problem with the shadow's shaders in my application because right now I'm trying to get PSSM to work and after setting the OSG_NOTIFY_LEVEL to DEBUG, I noticed the shader never gets compiled, and thus the app segfaults in the cull() call. Do you know of any way to force the shader to get compiled? I've opened another thread for this problem (PSSM segfaulting in the cull() call). Thanks in advance, Alejandro.- -- [EMAIL PROTECTED] http://varrojo.linuxuruguay.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PSSM segfaulting in cull()?
Well, I've managed to find why the shader never was compiled. Apparently the problem was adding the lights to the scene graph before adding the ShadowedScene node (note the ShadowedScene node is not the root of my scene graph). Conversely, if lights are added to the scene graph before the ShadowedScene node is added, then the shader never gets compiled and the application segfaults when doing in the cull stage. Hope this helps anyone else how comes across the same issue. Alejandro.- On Tue, May 20, 2008 at 10:59 AM, Alejandro Segovia [EMAIL PROTECTED] wrote: Hello Adrian, thanks for your reply, On Tue, May 20, 2008 at 3:27 AM, Adrian Egli OpenSceneGraph (3D) [EMAIL PROTECTED] wrote: Which version are you using the latest SVN, the latest PSSM (see post from friday to yesterday) ? I'm actually on OSG 2.2, but I don't think this is a problem with the OSG version, since the osgshadow example runs without problems. I think it must have something to do with the viewer the example uses... somehow it forces the shader to be compiled before rendering, but since I am using my own viewer, it doesn't seem to get compiled before trying to render and the cull() call segfaults. Maybe there is an OpenGL way to flush shader compilation? Thanks, Alejandro.- 2008/5/19 Alejandro Segovia [EMAIL PROTECTED]: On Mon, May 19, 2008 at 6:03 PM, Alejandro Segovia [EMAIL PROTECTED] wrote: Hello List, I'm having a hard time using PSSM (or anything besides ShadowTexture for that matter) to add shadows to my scene. I've got some initialization code inspired in the osgshadow example, which seems to work fine when I pass the --NVidea parameter, but when I try the very same technique in my code, it just crashes inside the PSSM's cull() method. This is the backtrace I get from the core dump: #0 0xb6f961c9 in osgShadow::ParallelSplitShadowMap::cull () from /usr/local/OpenSceneGraph/2.2.0/lib/libosgShadow.so.25 #1 0xb6f87656 in osgShadow::ShadowTechnique::traverse () from /usr/local/OpenSceneGraph/2.2.0/lib/libosgShadow.so.25 #2 0xb6f8e7c0 in osgShadow::ShadowedScene::traverse () from /usr/local/OpenSceneGraph/2.2.0/lib/libosgShadow.so.25 #3 0xb6d38196 in osgUtil::CullVisitor::apply () from /usr/local/OpenSceneGraph/2.2.0/lib/libosgUtil.so.25 #4 0xb6f8eb11 in osgShadow::ShadowedScene::accept () from /usr/local/OpenSceneGraph/2.2.0/lib/libosgShadow.so.25 #5 0xb726fa84 in osg::Group::traverse () from /usr/local/OpenSceneGraph/2.2.0/lib/libosg.so.25 #6 0xb6d38196 in osgUtil::CullVisitor::apply () from /usr/local/OpenSceneGraph/2.2.0/lib/libosgUtil.so.25 #7 0xb727095f in osg::Group::accept () from /usr/local/OpenSceneGraph/2.2.0/lib/libosg.so.25 #8 0xb6dc89f7 in osgUtil::SceneView::cullStage () from /usr/local/OpenSceneGraph/2.2.0/lib/libosgUtil.so.25 #9 0xb6dc7cd6 in osgUtil::SceneView::cull () from /usr/local/OpenSceneGraph/2.2.0/lib/libosgUtil.so.25 #10 0xb6a596ef in Canvas::customEvent (this=0x80c4780, event=0x80deb60) at Canvas.cpp:200 Canvas is just a custom class derived from QGLWidget. This is the initialization code I'm using, please note the ShadowedScene node is not the root of the scene graph. osg::ref_ptrosgShadow::ParallelSplitShadowMap shadowTech = new osgShadow::ParallelSplitShadowMap(NULL, 3); shadowTech-setTextureResolution(1024); shadowTech-setMinNearDistanceForSplits(0); shadowTech-setMaxFarDistance(0); shadowTech-setMoveVCamBehindRCamFactor(0); double polyoffsetfactor = 10.0f; //-0.02; double polyoffsetunit = 20.0f; //1.0; shadowTech-setPolygonOffset(osg::Vec2(polyoffsetfactor,polyoffsetunit)); _shadowNode = new osgShadow::ShadowedScene(); _shadowNode-setShadowTechnique(shadowTech.get()); _shadowNode-setCastsShadowTraversalMask(0x2|0x8); _shadowNode-setReceivesShadowTraversalMask(0x1|0x8); I'm also using SceneView objects to hold the camera information such as the projection and modelview matrices. There are two lights in the scene and only one object (a floor). Thanks in advance, Alejandro Segovia.- -- [EMAIL PROTECTED] http://varrojo.linuxuruguay.org Setting the OSG_NOTIFY_LEVEL variable to DEBUG in order to determine what could possibly be wrong, I noticed the shader program is never compiled for PSSM! Is there some way to force program compilation in OSG? I attach the dump for osgshadow and then for my application. Notice mine never gets its shader compiled. Dump for osgshadow: ... View::init() ParallelSplitShadowMap : Texture ID=0 Resolution=1024 CullSettings::readEnvironmentalVariables() Uniform Adding parent Uniform Adding parent Uniform Adding parent Uniform Adding parent Uniform Adding parent ParallelSplitShadowMap : Texture ID=1 Resolution=1024 CullSettings::readEnvironmentalVariables() Uniform Adding parent Uniform Adding parent Uniform Adding parent Uniform Adding parent Uniform Adding parent
[osg-users] NodeTrackedManipulator constantly segfaulting
Hello all, I'm trying to use osgGA::NodeTrackerManipulator to try to get a camera to follow a node as it moves around the scene, with very little success. After setting up the manipulator and setting the node it has to track, I get a segmentation fault when I call the getInverseMatrix method on it in order to adjust the camera. The crash is inside the computeNodeCenterAndRotation method in getInverseMatrix. Aside from setting the node to be tracked, I'm using all default values for the NodeTrackerManipulator. Has anybody experienced the same problem or know what I could possibly be doing wrong? I'm running OSG 2.2 on Debian Linux. Thanks in advance, Alejandro.- -- [EMAIL PROTECTED] http://varrojo.linuxuruguay.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] NodeTrackedManipulator constantly segfaulting
Hi Robert, thanks for you quick reply :) I ran the osgsimulation example not only did it run fine, but also gave me an idea of what I was doing wrong. I was calling setNode instead of setTrackNode, so the manipulator was trying to track an invalid node and that caused the segfault. Perhaps a sanity check is missing in the NodeTrackerManipulator to make sure the user called setTrackNode at least once before trying to track the node. Now I'm getting some black tilting when rendering, but the osgsimulator runs fine, so it must be something in the way I do my rendering. Thanks for your help, Alejandro.- On Mon, May 19, 2008 at 1:47 PM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Alejandro, I haven't heard of NodeTrackManipulator sef faulting before, so this is a new one, I'd guess it would most likely be a usage issue, but perhaps you have uncovered a bug in the manipulator. First thing to test would be to run the osgsimulation example to see if that runs stable. Next up provide a stack trace, without there is nothing anybody else can help you with. Robert. On Mon, May 19, 2008 at 5:27 PM, Alejandro Segovia [EMAIL PROTECTED] wrote: Hello all, I'm trying to use osgGA::NodeTrackerManipulator to try to get a camera to follow a node as it moves around the scene, with very little success. After setting up the manipulator and setting the node it has to track, I get a segmentation fault when I call the getInverseMatrix method on it in order to adjust the camera. The crash is inside the computeNodeCenterAndRotation method in getInverseMatrix. Aside from setting the node to be tracked, I'm using all default values for the NodeTrackerManipulator. Has anybody experienced the same problem or know what I could possibly be doing wrong? I'm running OSG 2.2 on Debian Linux. Thanks in advance, Alejandro.- -- [EMAIL PROTECTED] http://varrojo.linuxuruguay.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 -- [EMAIL PROTECTED] http://varrojo.linuxuruguay.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] PSSM segfaulting in cull()?
Hello List, I'm having a hard time using PSSM (or anything besides ShadowTexture for that matter) to add shadows to my scene. I've got some initialization code inspired in the osgshadow example, which seems to work fine when I pass the --NVidea parameter, but when I try the very same technique in my code, it just crashes inside the PSSM's cull() method. This is the backtrace I get from the core dump: #0 0xb6f961c9 in osgShadow::ParallelSplitShadowMap::cull () from /usr/local/OpenSceneGraph/2.2.0/lib/libosgShadow.so.25 #1 0xb6f87656 in osgShadow::ShadowTechnique::traverse () from /usr/local/OpenSceneGraph/2.2.0/lib/libosgShadow.so.25 #2 0xb6f8e7c0 in osgShadow::ShadowedScene::traverse () from /usr/local/OpenSceneGraph/2.2.0/lib/libosgShadow.so.25 #3 0xb6d38196 in osgUtil::CullVisitor::apply () from /usr/local/OpenSceneGraph/2.2.0/lib/libosgUtil.so.25 #4 0xb6f8eb11 in osgShadow::ShadowedScene::accept () from /usr/local/OpenSceneGraph/2.2.0/lib/libosgShadow.so.25 #5 0xb726fa84 in osg::Group::traverse () from /usr/local/OpenSceneGraph/2.2.0/lib/libosg.so.25 #6 0xb6d38196 in osgUtil::CullVisitor::apply () from /usr/local/OpenSceneGraph/2.2.0/lib/libosgUtil.so.25 #7 0xb727095f in osg::Group::accept () from /usr/local/OpenSceneGraph/2.2.0/lib/libosg.so.25 #8 0xb6dc89f7 in osgUtil::SceneView::cullStage () from /usr/local/OpenSceneGraph/2.2.0/lib/libosgUtil.so.25 #9 0xb6dc7cd6 in osgUtil::SceneView::cull () from /usr/local/OpenSceneGraph/2.2.0/lib/libosgUtil.so.25 #10 0xb6a596ef in Canvas::customEvent (this=0x80c4780, event=0x80deb60) at Canvas.cpp:200 Canvas is just a custom class derived from QGLWidget. This is the initialization code I'm using, please note the ShadowedScene node is not the root of the scene graph. osg::ref_ptrosgShadow::ParallelSplitShadowMap shadowTech = new osgShadow::ParallelSplitShadowMap(NULL, 3); shadowTech-setTextureResolution(1024); shadowTech-setMinNearDistanceForSplits(0); shadowTech-setMaxFarDistance(0); shadowTech-setMoveVCamBehindRCamFactor(0); double polyoffsetfactor = 10.0f; //-0.02; double polyoffsetunit = 20.0f; //1.0; shadowTech-setPolygonOffset(osg::Vec2(polyoffsetfactor,polyoffsetunit)); _shadowNode = new osgShadow::ShadowedScene(); _shadowNode-setShadowTechnique(shadowTech.get()); _shadowNode-setCastsShadowTraversalMask(0x2|0x8); _shadowNode-setReceivesShadowTraversalMask(0x1|0x8); I'm also using SceneView objects to hold the camera information such as the projection and modelview matrices. There are two lights in the scene and only one object (a floor). Thanks in advance, Alejandro Segovia.- -- [EMAIL PROTECTED] http://varrojo.linuxuruguay.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PSSM segfaulting in cull()?
On Mon, May 19, 2008 at 6:03 PM, Alejandro Segovia [EMAIL PROTECTED]
wrote:
Hello List,
I'm having a hard time using PSSM (or anything besides ShadowTexture for
that matter) to add shadows to my scene.
I've got some initialization code inspired in the osgshadow example, which
seems to work fine when I pass the --NVidea parameter, but when I try the
very same technique in my code, it just crashes inside the PSSM's cull()
method.
This is the backtrace I get from the core dump:
#0 0xb6f961c9 in osgShadow::ParallelSplitShadowMap::cull ()
from /usr/local/OpenSceneGraph/2.2.0/lib/libosgShadow.so.25
#1 0xb6f87656 in osgShadow::ShadowTechnique::traverse ()
from /usr/local/OpenSceneGraph/2.2.0/lib/libosgShadow.so.25
#2 0xb6f8e7c0 in osgShadow::ShadowedScene::traverse ()
from /usr/local/OpenSceneGraph/2.2.0/lib/libosgShadow.so.25
#3 0xb6d38196 in osgUtil::CullVisitor::apply ()
from /usr/local/OpenSceneGraph/2.2.0/lib/libosgUtil.so.25
#4 0xb6f8eb11 in osgShadow::ShadowedScene::accept ()
from /usr/local/OpenSceneGraph/2.2.0/lib/libosgShadow.so.25
#5 0xb726fa84 in osg::Group::traverse ()
from /usr/local/OpenSceneGraph/2.2.0/lib/libosg.so.25
#6 0xb6d38196 in osgUtil::CullVisitor::apply ()
from /usr/local/OpenSceneGraph/2.2.0/lib/libosgUtil.so.25
#7 0xb727095f in osg::Group::accept ()
from /usr/local/OpenSceneGraph/2.2.0/lib/libosg.so.25
#8 0xb6dc89f7 in osgUtil::SceneView::cullStage ()
from /usr/local/OpenSceneGraph/2.2.0/lib/libosgUtil.so.25
#9 0xb6dc7cd6 in osgUtil::SceneView::cull ()
from /usr/local/OpenSceneGraph/2.2.0/lib/libosgUtil.so.25
#10 0xb6a596ef in Canvas::customEvent (this=0x80c4780,
event=0x80deb60) at Canvas.cpp:200
Canvas is just a custom class derived from QGLWidget.
This is the initialization code I'm using, please note the ShadowedScene
node is not the root of the scene graph.
osg::ref_ptrosgShadow::ParallelSplitShadowMap shadowTech =
new osgShadow::ParallelSplitShadowMap(NULL, 3);
shadowTech-setTextureResolution(1024);
shadowTech-setMinNearDistanceForSplits(0);
shadowTech-setMaxFarDistance(0);
shadowTech-setMoveVCamBehindRCamFactor(0);
double polyoffsetfactor = 10.0f; //-0.02;
double polyoffsetunit = 20.0f; //1.0;
shadowTech-setPolygonOffset(osg::Vec2(polyoffsetfactor,polyoffsetunit));
_shadowNode = new osgShadow::ShadowedScene();
_shadowNode-setShadowTechnique(shadowTech.get());
_shadowNode-setCastsShadowTraversalMask(0x2|0x8);
_shadowNode-setReceivesShadowTraversalMask(0x1|0x8);
I'm also using SceneView objects to hold the camera information such as the
projection and modelview matrices. There are two lights in the scene and
only one object (a floor).
Thanks in advance,
Alejandro Segovia.-
--
[EMAIL PROTECTED]
http://varrojo.linuxuruguay.org
Setting the OSG_NOTIFY_LEVEL variable to DEBUG in order to determine what
could possibly be wrong, I noticed the shader program is never compiled for
PSSM! Is there some way to force program compilation in OSG?
I attach the dump for osgshadow and then for my application. Notice mine
never gets its shader compiled.
Dump for osgshadow:
...
View::init()
ParallelSplitShadowMap : Texture ID=0 Resolution=1024
CullSettings::readEnvironmentalVariables()
Uniform Adding parent
Uniform Adding parent
Uniform Adding parent
Uniform Adding parent
Uniform Adding parent
ParallelSplitShadowMap : Texture ID=1 Resolution=1024
CullSettings::readEnvironmentalVariables()
Uniform Adding parent
Uniform Adding parent
Uniform Adding parent
Uniform Adding parent
Uniform Adding parent
ParallelSplitShadowMap : Texture ID=2 Resolution=1024
CullSettings::readEnvironmentalVariables()
ParallelSplitShadowMap: GLSL shader code:
---
uniform sampler2D baseTexture;
uniform sampler2D randomTexture;
uniform float enableBaseTexture;
uniform sampler2DShadow shadowTexture0;
uniform float zShadow0;
uniform sampler2DShadow shadowTexture1;
uniform float zShadow1;
uniform sampler2DShadow shadowTexture2;
uniform float zShadow2;
void main(void)
{
vec4 coord = gl_FragCoord;
float shadow0 = shadow2DProj( shadowTexture0,gl_TexCoord[1]).r;
vec4 random0 =
0.0012207*coord.z*texture2D(randomTexture,gl_TexCoord[1].st);
float shadow10 = shadow2DProj(
shadowTexture0,gl_TexCoord[1]+random0.r*vec4(-1,-1,0,0)).r;
float shadow20 = shadow2DProj(
shadowTexture0,gl_TexCoord[1]+random0.g*vec4(1,-1,0,0)).r;
float shadow30 = shadow2DProj(
shadowTexture0,gl_TexCoord[1]+random0.b*vec4(1,1,0,0)).r;
float shadow40 = shadow2DProj(
shadowTexture0,gl_TexCoord[1]+random0.a*vec4(-1,1,0,0)).r;
shadow0 = shadow0 + shadow10 + shadow20 + shadow30 + shadow40;
shadow0 = shadow0*0.2;
float shadow1 = shadow2DProj( shadowTexture1,gl_TexCoord[2]).r;
vec4 random1 =
0.0012207*coord.z*texture2D(randomTexture,gl_TexCoord[2].st);
float shadow11 = shadow2DProj
[osg-users] Capsule Picking not working
I'm using LineSegmentIntersector to implement picking in my application. LineSegmentIntersetor works great and I've noticed it's really accurate when picking osg primitives like spheres, boxes and such, except for the Capsule. For some reason picking does not work on the Capsule primitive, it's just as if it wasn't there, but in that case, I shouldn't be able to see it either. Is there some thing I could have done to make picking stop working on the capsule? Does it have to be dealt with as a special case? Thanks in advance, Alejandro.- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Capsule Picking not working
On Fri, May 16, 2008 at 4:41 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: Hello Alejandro, I'm using LineSegmentIntersector to implement picking in my application. LineSegmentIntersetor works great and I've noticed it's really accurate when picking osg primitives like spheres, boxes and such, except for the Capsule. For some reason picking does not work on the Capsule primitive, it's just as if it wasn't there, but in that case, I shouldn't be able to see it either. Is there some thing I could have done to make picking stop working on the capsule? Does it have to be dealt with as a special case? I suppose you're using OSG 2.2 or earlier? Picking on capsules was left out before, and I implemented it during the development phase between 2.2 and 2.4 (I think it was around the 2.3.4 dev release). It was the only ShapeDrawable that couldn't be picked, for some reason. If you upgrade you'll get that as well as lots of other fixes and improvements. Or just get src/osg/ShapeDrawable.cpp from 2.4 and put it into your 2.2 tree and recompile OSG. (that's what we did at work until 2.4 came out - it's bad form to use a dev release for client apps...) This won't work if you're using 1.2 or something like that, because too much has changed, but you can probably backport the changes I made easily enough. Of course I highly recommend you update to 2.4, there's a lot more that was fixed. Thank you both for you quick replies and suggestions. As a matter of fact we are using OSG 2.2, and although backporting the code is not an option at this time, but we may be happily updating to 2.4 soon. Thanks for the help :) Best regards, Alejandro.- -- [EMAIL PROTECTED] http://varrojo.linuxuruguay.org ___ 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
Hello, I'm having a problem somewhat related to node masks and shadows. 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. Thanks in advance, Alejandro.- On Thu, May 15, 2008 at 5:29 AM, Wojciech Lewandowski [EMAIL PROTECTED] wrote: Hi Ben, 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. 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. 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. 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 . 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. ShadowedScene does not have to be root node so its possible to create graph hierarchy where all non shadowing / non shadowed objects are put under one branch and those using and casting shadows are put under ShadowedScene in other branch of the scene graph. Wojtek ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- [EMAIL PROTECTED] http://varrojo.linuxuruguay.org -- [EMAIL PROTECTED] http://varrojo.linuxuruguay.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
