Hi Judson, On 18 June 2013 16:17, Judson Weissert <[email protected]> wrote: > I looked at the implementations now (the Geometry.cpp changes were not > included in the online diff). Correct me if I am wrong, outside of the > optimizer, there is no code path that will call checkForDeprecatedData(). > Therefore, it is quite likely that drawImplementation() and other functions > will be called before checkForDeprecatedData() is called. Thus, I am > wondering if the _containsDeprecatedData flag should be taken out entirely.
Currently the Geometry::set*Indices() and set*Binding() methods set _containsDeprecatedData directly. The checkDeprecatedData() is there as a fallback in case this method isn't reliable. Please remember this code is still rather experimental, once it starts getting tested out it may or may not need to change. It might be that we'll be able to remove the checkDeprecateData() and perhaps even the _containsDeprecateData member, but until we are a bit further in I won't commit any particular way, it's really up to the community now to start testing and shake it down. One thing I am thinking about doing is making these methods and associated via all optional compiled in, which will be on by default. Making this element optionally compiled in will allow developers that need to keep the OSG small and won't ever have deprecated data to deal with can just go withe clean and pure osg::Geometry. Longer term I'd these methods in what ever form they end up will be deprecated and eventually removed completely. > Perhaps the member functions could be replaced with two free functions: > > bool > CheckForDeprecatedData (const osg::Geometry *geometry); > > and > > void > FixDeprecatedData (osg::Geometry *geometry); > > and they would be part of the osg::Geometry API, but they would not be as > tightly coupled to the same source files. i.e., you could move them wherever > you want. That is, assuming they do not require access to the non-Public > osg::Geometry API. > > I realize it is expensive to call CheckForDeprecatedData(), but in theory, > FixDeprecatedData() is going to be called afterwards anyhow, so you end up > with the same end result (at least from what I have observed so far). > > I am basing this logic on the fact that the _containsDeprecatedData flag is > already not guaranteed to be correct in the places where it is being used as > a guard. The _containsDeprecatedData flag is there to avoid the drawImplementation() from having to check to see whether it's safe to run or not, calling the checkForDeprecatedData() is just too expensive to call on call drawImplementation(). Attempting a drawImplementation() whilst it contains BIND_PER_PRIMITIVE or indices will likey result in a seg fault so worth guarding against. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
