Hi Paul, On Thu, Jun 26, 2008 at 7:01 PM, Paul Martz <[EMAIL PROTECTED]> wrote: > Hi Robert -- I'm redirecting this from osg-submissions to osg-users, as it > is now more of a general discussion than a submission. > >> PagedLOD's that don't have children ordered from lowest to >> height res are invalid, > > Okay. I didn't know that, and it's surprising, as I'm under the impression > that the base class "LOD" doesn't have this restriction.
LOD don't have this restriction, but they aren't being populated on the fly, and they don't have an extra fallback mechanism that PagedLOD adds into the mix to handle cases where the required level of detail is not available yet. PagedLOD's have to be ordered in from low res to high res, and without duplicates for the whole paged request and fallback mechanism to function. This constraint on PagedLOD is something that was discussed heavily during its development, but I guess that's a few years back now so easily forgoton/missed. Just checking the doxygen docs I can see that there is no note of this constraint so we really need to fill in these blanks. >> Having multiple children at the >> same range will also break this mechanism. > > To be clear, you are saying that multiple children at the same range breaks > the IntersectionVisitor, but is still valid usage, right? It's not just the orignal IntersectionVisitor::accept(PagedLOD&) that won't behave correctly for PagedLOD's that aren't set up correctly, the CullVisitor and any other visitors that make that assumptions about the structure of a PageLOD will also be broken. > I understand it > breaks the code in question, thus my submission. Would you like me to > resubmit the fix, addressing only the multiple-children shortcoming, and > maintaining the range-ordering assumption? I've merged your changes, as they look safe for correct PagedLOD as well as your rather freeform versions. >> There isn't any >> code to catch erroneous PagedLODs, it's currently assumed >> that the user will set things up appropriately. > > I understand it might be useful to assert ordered children, not sure where > this would go. Yes, a check would be easy to write, but it's not something you'd want to call every traversal, and its not something you can call on each update of the range data as it's not till you have all the data applied can you set that its valid or not. Perhaps if you constrained the ways you could set the ranges, or have a dirty mechanism w.r.t the check then perhaps could do the checks safely. >> How were the files generated? > > I have a client with the multiple-children issue. He has multiple children > at the "max res" range but is only able to pick one using the > IntersectionVisitor (as the case2.osg file demonstrates). With the fix I > submitted, all children at the "max res" range are pickable. For PagedLOD multiple children really should be tackled by placing both children into a single group and then having this group at this range. > The out-of-order test case was hand-generated. This is not an issue for my > client, but would be an issue for anyone using PagedLOD as a normal LOD. > > BTW I note a significant difference between the handling of LOD and PagedLOD > by the IntersectionVisitor, is this intentional? Well PagedLOD has the fallback mechanism, and has strict ordering constraint that's what makes it different. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
