Dirk Reiners wrote: > Hi Patrick, > > On Sun, 2006-03-12 at 11:38 -0600, Patrick Hartling wrote: >> I recently updated to the latest CVS version of OpenSG, and my application >> stopped functioning correctly. As far as I can tell, the problem is caused >> by a change to OSG::Group made in the following commit (Revision 1.4 of >> OpenSG/Source/System/NodeCores/Group/Base/OSGGroup.cpp): >> >> http://sourceforge.net/mailarchive/message.php?msg_id=14799881 >> >> What I cannot figure out is if this change has exposed a bug in my >> application and if so, what that bug would be. >> >> The behavior that I see is related to dynamic activating and deactivating of >> scene graph nodes. My application starts up with nodes being deactivated >> through calls to OSG::Node::setActive() made during a traversal before any >> frame is rendered. Later, I activate nodes selectively. If I use a build of >> OpenSG with the above change to OSG::Group, then only some of the nodes get >> rendered when all are active. I have verified that all the nodes are >> activated correctly, so I do not understand why they are not being rendered. >> The call to OSG::Node::setActive() occurs in a separate thread from the one >> doing the rendering, but I thought I had worked out all the kinks related to >> doing that. >> >> The nodes that do not get rendered are always the same, but so far, I have >> not been able to identify any pattern as to why some nodes are rendered and >> others are not. Updating to Revision 1.5 of OSGGroup.cpp does change the >> behavior. Does anyone have any suggestions about what might be going wrong? > > That sounds a little fishy. The change does not affect the active/mask > behavior as far as I can see. It does make view volume culling work on > leaf nodes, which didn't work before. Can you tuen on volume drawing to > make sure that your leaf bounding volumes are ok?
I know that it's been a long time since I posted my original question, but I
finally had time to get back to this. I am still having this problem using
OpenSG source pulled from the anonymous CVS server a little less than 72
hours ago. I do not know how far behind the developer CVS server that puts
this code.
Turning on volume drawing leads me to believe that leaf bounding volumes are
not working correctly. I am not exactly sure how to describe what I am
seeing now, but I did notice a pattern that I did not see before. Here is an
example of the basic structure that I have right now:
Node[Group]
/ \
/ \
/ \
Node[Transform] Node[Transform]
| |
Node[Group] Node[LOD]
/ \ |
Node[Transform] Node[Transform] Node[Group]
| | |
Node[LOD] Node[LOD] Node[Geometry]
| |
Node[Group] Node[Group]
| |
Node[Geometry](*) Node[Geometry]
As I explained in my original post, nodes are deactivated before any frame
is rendered. The nodes that are deactivated always have a group core, but it
is not all nodes with group cores that are deactivated. The exact algorithm
for determining which nodes are deactivated (more or less) has to do with
how the data was loaded from disk.
The pattern that I observed is that only the geometry from the node with the
(*) by it gets rendered even when every node is activated. In all cases, it
is the first *activated* node with a geometry core under a group that gets
rendered. It does not have to be the first such node under the group, and
once that first node is activated, it is the only one that ever gets
rendered. (In other words, if I activate the children one by one, whichever
I choose first is the one that gets rendered until I restart the
application.) The geometry from siblings of that first activated node does
not get rendered, and it does not appear that the volume for any of the
siblings is drawn.
Note that I could have made my diagram above more complicated by adding
another child of the root that has the same structure as the leftmost child
in my diagram. In that case, the rendering behavior would be the same as the
leftmost child. As such, it is not that only the first node with a geometry
core is rendered but the first in each group.
I hope that my explanations make sense. So far, the problem definitely seems
to be tied to the use of OSG::Group, but I still cannot tell if it is
something in OpenSG or something in my application.
-Patrick
--
Patrick L. Hartling | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2msw3 | http://www.infiscape.com/
signature.asc
Description: OpenPGP digital signature
