Hi Kristofer, I've just reviewed your changes, and while I'm still need to do another review, my initial reaction is "ooohh that's clever" :-)
You've come up with a solution that I never occurred to me, my first pass review it seems to be the best solution proposed so far. As it's rather novel I do need a bit more time to reflect on it to see if there are any potential problems. In terms of CPU costs, I don't think it should be too expensive as I wouldn't expect that to be a high number of AntiSquish nodes in the scene graph, if it does turn out to be high then we can look at a Transform::dirtyCount() but my hunch is that the cost will be negligible compared to the rest of the CPU overheads. Cheers, Robert. On 10 January 2014 08:34, Kristofer Tingdahl <[email protected]>wrote: > Hi Robert, > > I don't necessarily agree that a way to check if the transforms along a > nodepath using integers is not worthwhile, as you replace hundreds of > double-operations with a few integer ones, and the comparison becomes the > comparison of two ints. That seems useful, especially as there is hardly > any overhead (a few bytes per transform). > > I'll leave that discussion and submit a new update of the AntiSquish. It > now inherits Transform rather than MatrixTransform, so there are no changes > to the object while traversing (apart from one cache). This solves most of > your objections as we rely on the standardness of the Transform. One > question is however what to do when there is no node-path available, such > as the Transform::computeBound(). In those cases I rely on the cache (if > available). But if I do that, I should really dirty the bound when I > re-compute my cache. This is implemented now in the version I'm sending, > but I'm not sure it is necessary. It will create an overload of > computeBound calls. > > I opted to lock the cache as this is the only way to protect from corrupt > cache if there are multiple traversals going on at the same time. We don't > do that, but I thought it's safer. > > Best regards, > > > Kristofer Tingdahl > > _______________________________________________ > osg-submissions mailing list > [email protected] > > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > >
_______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
