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 uses wrong mask for traversal
Hi, I've not been following the discussion in detail, have only a single comment below... Ben Discoe wrote: - 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. 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(). I don't see why you say only 0x would work. jp 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 -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShadowMap uses wrong mask for traversal
Hi Ben, 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. The question is, how can we fix it? A node mask/traversal mask of 0 absolutely doesn't match any nodes, that is exactly how things are designed to work. If you don't want to cull out whole subgraphs this way then you simple set the node mask/traversal masks appropriately. I can't help but feel that you've got the wrong end of the stick w.r.t traversal masks and node masks. 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. We the viewer shouldn't be setting th 0x1 and 0x2 to 0, it's really that simple - a 0x4 traversal mask at the viewer level is not at all appropriate in this instance. 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? It makes it work in the way you're understanding of node masks/traversal masks, but not how they are intended to be used, you're solution would break how they are intended to be used... If you don't want to switch off the traversal mask complete then you don't switch the bits off at the viewer level. Robert. Robert. ___ 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 uses wrong mask for traversal
Hi Ben, 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. The intention is that traversal is restricted to only subgraphs that have the CastShadow bits enabled on them. I stand by the code, I believe it is correct. Disabling the the CastShadow bits in the viewer should mean that the ShadowScene won't traverse the subgraphs that request the CastShadow bits to be set. I'm personally pulling back from this discussion right now as I have many other tasks to complete, and this discussion is going nowhere. Robert ___ 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 [Roger James] This seems to revolve around a conceptual design issue. Who controls the usage of bits in the node mask? In the simple non ShadowMap case and from reading the documentation a programmer might assume the process which constructs the scene graph is the controller and it can assume that it can use any bit in the mask to control traversal. However with advent of ShadowMap (and maybe elsewhere as well) a lower level entity which is part of the implementation of the graph itself has hijacked some bits in the mask for it's own use. This means the scene graph constructor has to know this to ensure that those bits are not used for other purposes and to that they are included in any traversal masks etc. which may be in force during relevant traversals of the graph. The simplest way to address this is probably better documentation. Other ways might include. i. Partioning the node mask into user and system bits. Ugly and wasteful. ii. Requiring the user to tell the ShadowMap etc. which bits it can use. Roger ___ 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
Hi Ben, On Thu, May 22, 2008 at 10:38 AM, Ben Discoe [EMAIL PROTECTED] wrote: 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. For christ sake this would introduce a bug. If someone switches of a bit in the viewer he's switched off that bit in the viewer and doesn't intended for that value to be discarded by code underneath that knows better. If you don't want to switch it off, leave the bit set, end of story. Robert. ___ 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
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] ShadowMap uses wrong mask for traversal
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, 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 their will be conflict, the only way to solve this is set the appropriate bits. I can see use traversal masks in the osgstereoimage example conflicting with osgShadow. 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. Robert. On Tue, May 20, 2008 at 8:30 PM, Ben Discoe [EMAIL PROTECTED] wrote: 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 ___ 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
