Hi, thanks for you reply.I'm afraid my knowledge of osg internals is quite limited but I will look into it and see if I can understand renderbins and what ever else. I'm currently trying to implement the my second method.I looked at the source for CullVisitor I was wondering is there any reason to subclass my BSPTreeNode from osg::Group instead of osg::Node?Node already has a virtual traverse method and doesn't implement any sort of list to store its children in, so I wouldn't have redundant references to all the children.
micah On Mon, 2007-12-17 at 09:56 -0600, Thrall, Bryan wrote: > Micah Heyer wrote on Saturday, December 15, 2007 12:25 PM: > > Hi every one, > > This may be stupid n00b question but, how would you recommend > > implementing a bsp tree in OSG?The three ways I thought of were: > > > > 1) use standard osg::Groups for each node and Geodes for leaf nodes. > > > > 2) subclass osg::Group for just the entire tree and instead of storing > > nodes in a std::list store in a custom bsp structure in which leaf > > nodes have a pointer to a geode. > > > > 3)subclass osg::Drawable and have it do all rendering independent of > > osg. > > > > The first option would seem to me to have a lot of overhead for a bsp. > > the second would be my preferred route,though I'm not sure I could > > implement it in a very elegant fasion. > > The third option would seem to reinvent the wheel but if that's the > > only drawback then maybe thats ok I don't know. > > Anyway I just thought I ask all you smart and experienced people out > > there if you have any advice for me. > > thanks, > > Micah > > You can probably implement (1) with the least amount of custom code, but > it also requires some knowledge of how OSG actually handles rendering > (RenderBins and the like). Basically, you can subclass osg::Group to > create a SeparatingPlane Node that calls setBinNumber() on the StateSets > of its 2 children. Based on the results of the plane test, the child > closer to the eye should get bin number 0 and the farther child should > get bin 1 (this gets more complicated if you've got transparent objects > in addition to opaque objects, since transparent objects go in different > RenderBins). > > That approach basically gets OSG to do a lot of the work for you, but > your option (2) and (3) could work as well. Actually, (3) sound better > than (2) because you wouldn't have to duplicate what the > osgUtil::CullVisitor does with RenderLeafs, and it feels more natural > since you're basically rendering what is a black box from OSG's > perspective either way. > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
