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] 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
[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] 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
Re: [osg-users] How to document osgShadow?
Alright. I have created a wiki page here, with my best attempt at documenting what i've learned so far: http://www.openscenegraph.org/projects/osg/wiki/Support/ProgrammingGuide/osgShadow It would be really great if someone who actually /knows/ the code could fill in things like: * How do the various ShadowTechniques differ? * What specific card capabilities (geometry shaders, ?) does each ShadowTechnique require? * Which ShadowTechniques respect which CastsShadow/ReceivesShadow bits? * What do those PSSM options do? J-S, Wojtek, Adrian, Robert, Mihai, Raymond, Paul, others... can you take a minute to help? Or if you prefer, you could answer any of the blanks from the wiki page here on the list, and i'll be happy to paste them into the wiki for you. Thanks, Ben -Original Message- From: Jean-Sébastien Guay Hi Ben, First of all, thanks for your willingness to contribute to documenting parts of the OSG which are still pretty bleeding-edge! It's great to see this kind of involvement. About where to put documentation: 1. The wiki has a page: http://www.openscenegraph.org/projects/osg/wiki/Community/Tasks/osgSha dow but that is an old page from before osgshadow joined the OSG source, it seems like not the place for documentation. The page is under the tasks section, so it's not the right place for documentation on how to use the nodekit. 2. We could make a new Wiki page, perhaps linked from: http://www.openscenegraph.org/projects/osg/wiki/Support/ProgrammingGuides under 'Programming the NodeKit libraries' 3. The source-doxygen docs, which end up here: http://www.openscenegraph.org/documentation/OpenSceneGraphReferenceDoc s/a02211.html I could submit modifications to the osgshadow source code with appropriate comment paragraphs explaining how to use each class. But, that appears to not be OSG's design, source docs seem to be deliberately minimal, so perhaps extensive documentation with text formatting, charts etc. belongs outside the source. I think a combination of these two will give good documentation. In the past, most of the documentation for OSG was in the doxycomments, but I think a balanced approach will yield better overall documentation from a user-developer point of view (users of the API, as opposed to developers of OSG or contributors). Of course, this is just my opinion, others might have other comments. Thanks again for wanting to contribute, I look forward to reading your work! 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] How to document osgShadow?
I've started working with osgShadow recently, and although i haven't found any actual documentation, by studying the osgshadow example and by reading hundreds of shadow-related messages in the archive, i've begun to understand it, although many things remain mysterious. I'd like to contribute back my new understanding to the OSG documentation. My question it, where and how? Here are some options.. 1. The wiki has a page: http://www.openscenegraph.org/projects/osg/wiki/Community/Tasks/osgShadow but that is an old page from before osgshadow joined the OSG source, it seems like not the place for documentation. 2. We could make a new Wiki page, perhaps linked from: http://www.openscenegraph.org/projects/osg/wiki/Support/ProgrammingGuides under 'Programming the NodeKit libraries' 3. The source-doxygen docs, which end up here: http://www.openscenegraph.org/documentation/OpenSceneGraphReferenceDocs/a02211.html I could submit modifications to the osgshadow source code with appropriate comment paragraphs explaining how to use each class. But, that appears to not be OSG's design, source docs seem to be deliberately minimal, so perhaps extensive documentation with text formatting, charts etc. belongs outside the source. Or, perhaps there is: 4. Some existing osgShadow docs i didn't find yet, which i could extend? Thanks, Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Can't build OSG 2.4 on Windows following GettingStarted guide
Mike, Thanks very much for all you do with putting up the dependencies. um ok. On Dependencies the second paragraph (_before_ mention of the almost 3 year old .zip archive) clearly informs: [..] required for OpenSceneGraph-2.3 and later, is maintained by Mike Weiblen, and can be download/browsed via svn at: Uh, having people log into source control to grab some headers/libs is mighty strange; nigh unheard of. (IMHO Libs are binaries and should never go into source control in any case.) Like many people, i skipped over the strange mention of SVN to find the actual downloadable header/libs. The very first mention of them is: 3rdParty_Win32binaries_2005_05_10.zip This is the zip that people are effectively directed to. Also, for the convenience of folks that have difficulty access svn, I recently posted a .zip snapshot of the current 3rdParty. I annouced it on this list a day or two ago. Yes, but that's vc8 only. I have to build both vc71 and vc8. Not sure why you feel you're not able to build 2.4.0. Ultimately, by doing detective work, i was able to get closer: I grabbed the new freetype and built it myself. But IMHO there's really no good reason to require people to do that. That old 2005 .zip was preserved to support folks building older OSGversions, but since that audience is steadily shrinking, it should be marked deprecated or removed. I wouldn't take it away quite yet, as it's the only option available for vc71 people. But you should explain about how they need to go find the freetype source and build it themselves. Thanks, Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Can't build OSG 2.4 on Windows following GettingStarted guide
Following the links from the main OSG site, it leads to the 'downloads' page: http://www.openscenegraph.org/projects/osg/wiki/Downloads which leads to the 'dependencies' page: http://www.openscenegraph.org/projects/osg/wiki/Downloads/Dependencies This instructs us to download 3rdParty_Win32binaries_2005_05_10.zip, which contains freetype 2.19, which OSG 2.4.0 will not build with. Ref: recent thread below. It is pretty bad to have the official wiki page pointing us to files that will not build. Is there a wiki update coming soon? I would really like to be able to build 2.4.0 and am wondering when a link to functional dependencies will appear. Thanks, Ben - Subject: Re: [osg-users] Unresolved symbol in FreeType plugin From: Jean-Sébastien Guay Sent: Wed, 12 Dec 2007 07:28:29 -0800 2FreeTypeFont3D.obj : error LNK2019: unresolved external symbol _FT_Outline_Get_BBox referenced in function protected: void __thiscall FreeTypeFont3D::init(void) I'm getting this with current SVN and VS2005. Do I need to update my 3rd party dependencies? After updating yesterday I got that same problem, and updating the dependencies to Mike's latest on his SVN (which is freetype235 instead of freetype219) fixed it. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to open file with Unicode name using osgDB::readNodeFile?
Reed, OSG on Windows passes your strings directly to fopen, or the C++ stream equivalent. File paths are assumed to be in the local OS's filesystem character set. This means that e.g. Chinese filenames can be opened on computers with Chinese version of Windows, and Western filenames can be opened on computer with Western version of Windows. So, to do exactly what you describe below, OSG already does it. However, it is true that if a Chinese user sent you a file with a Chinese filename, you could not open it with OSG on your non-Chinese OS. To do that, OSG would indeed have to add Unicode filename support. Unicode means that any file can be opened on any machine. To support Unicode ,with the C standard lib on Windows, it is quite easy to replace usage of fopen with _wfopen. However, there are many places in OSG's code base where the C++ stream IO is used instead of fopen. AFAIK, there is no _w version of those methods, so OSG is stuck. Just as a note, this whole thing is delightfully a non-issue on Mac OS X, and (some?) flavors of Linux, in which UTF-8 is the filesystem charset, so plain old fopen() handles everything. -Ben -- From: Reed McKenna Sent: Tuesday, April 22, 2008 4:00 PM We build an application for Windows XP using OpenSceneGraph. We have more and more users from Asian countries who want to read in files that have names with Asian characters. Windows’ NTFS file system stores file names in Unicode. How can I have osgDB::readNodeFile (and writeNodeFile, etc.) read from and write to these files, using the full NTFS Unicode file name? If it is not currently possible, are there any plans in the works to make it possible? Reed ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OpenThreads doc?
I got OSG 2.0 building and moved my community up to it, thanks for the help on that. Next question: does OpenThreads have any documentation, at all? I have looked all over the web and the wiki, and not found a bit, not even minimal doxygen docs. I am hoping to port some code from pthreads to OpenThreads, and definitely need to know how OpenThreads works in order to do that. -Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] CMake instructions for OSG 2.0 don't work on Windows
Figuring that 2.0 has been out long enough now that it must be time to upgrade from 1.2, i tried to build OSG 2.0 this evening. The file VisualStudio/MUST_READ_ME.txt says to follow the instructions at http://www.openscenegraph.org/osgwiki/pmwiki.php/PlatformSpecifics/VisualStudio Those instructions say: 1. Install CMake. (I installed the current version, 2.4.) 2. Start the CMake GUI, and open the CMakeLists.txt from the root OpenSceneGraph directory in the Where is the source code field. However, the 'Browse' button in the CMake GUI selects a directory, not a file. So, selecting CMakeLists.txt is not possible. If one does directly paste the full path to CMakeLists.txt into the 'Where is the source' field, then CMake reports this error on Configure: Error: CMake Error: The source directory C:/OpenSceneGraph-2.0/CMakeList.txt is a file, not a directory. I can only guess that either the CMake GUI has changed since OSG 2.0 was released (?) or the OSG build instructions are just wrong. Has anyone else gotten 2.0 to build? I realize that it is a relatively fresh release. Thanks, Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CMake instructions for OSG 2.0 don't work on Windows
- From: Robert Osfield To: osg-users@lists.openscenegraph.org Hi Ben, I don't know if it'll help but your link is to the old wiki, you could try: http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/ VisualStudio Aha. I guess what happened is this: 1. OSG-2.0 is released, with MUST_READ_ME.txt directing users to the Wiki for instructions. The instructions in the Wiki are wrong (but perhaps people don't read them?) 2. Some time later, a new Wiki is made. But (unfortunately..) the old Wiki remains online as well, with largely duplicate and (in this example) wrong information. 3. Someone corrects the information in the new wiki. 4. The OSG-2.0 zip is not patched, so it stills points to the old wiki, so anyone trying to build 2.0 today is still directed to the wrong information. It seems fairly incredible that i am the first to report this, unless every other person to build 2.0 on Windows has ignored the README and just fiddled with it until they made it work. I'd highly recommend fixing it, by pointing the 2.0 zipped README to point to the correct Wiki (or making the old Wiki URL redirect to the right Wiki) as well as taking the old Wiki offline if it is just causing trouble like this. -Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
