Question about FeatureNode

classic Classic list List threaded Threaded
3 messages Options
Blanky Blanky
Reply | Threaded
Open this post in threaded view
|

Question about FeatureNode

Hey,

So my colleague and I have been stretching as much performance out of osgEarth as possible, but have still hit some snags and may have to end up making our own custom implementation of a more dyanmic custom FeatureNode-like object.

We were looking into the FeatureNode::build() function and noticed that a deep copy of FeatureList is being used for the eventual internal node compilation done by the GeometryCompiler. Is there a reason why there needed to be a DEEP_COPY_ALL instead of just using the current state of the FeatureList? (A change done before it's done processing perhaps?)

We've essentially ruled out resetting an entire FeatureNode and attempted to just "update" a single Feature, but we used a MultiGeometry to pack many different lines together.

So that implementation won't be viable because the single Feature would still need to be completely recompiled. I wish there was an on demand one-to-one update just for the dirtied Feature when using a FeatureList. Is this implementation ever going to be possible?

From what I saw, if there were no deep copying done, you would just need to clean up the map clamper and bounding sphere and update them to include the same Feature address' new state. I'm unsure how to do the above or if it's even possible without "hard" resetting the FeatureNode like it is done with build().

- Blanky
gwaldron gwaldron
Reply | Threaded
Open this post in threaded view
|

Re: Question about FeatureNode

Blanky,

We clone each feature become compiling it because the compiler can alter the input feature geometry (and sometimes even the attributes).

What's the extent of your feature updates? Are you just moving existing verts, or are you completely replacing the geometry?
Glenn Waldron / Pelican Mapping
Blanky Blanky
Reply | Threaded
Open this post in threaded view
|

Re: Question about FeatureNode

We're essentially creating a new geometry since when a translation in position occurs, we need the translated geometry to reflect the deformation caused by different types of projections (like in a projected mercator SRS). We've been creating two scene graphs that mirror each other, one for a 3D geocentric and a 2D projected map, so the implementation hasn't been identical between the two. Hence my previous posts about stripping away an osgEarth's vec3Array and converting the points to mercator myself.