[X3D-Public] LOD versus GeoLOD

[Andreas Plesch]

Thanks again for all input and pointers. It looks like the main point of
having a GeoLOD node was to have an efficient way of dealing with large
digital elevation models or a detailed globe which avoids having to load
everything in one step.

In an attempt to learn more about GeoLOD and LOD as it works in x3dom I
went ahead and worked on the GeoLOD Mars example available at
http://www.web3d.org/x3d-resources/content/examples/Basic/GeoSpatial/_pages/page18.html
. It was possible to substitute the GeoLOD nodes with regular LOD nodes and
I found that I could use routed GeoPositionInterpolator nodes (pull request
for this node is submitted at github) to feed the LOD center field with the
correct coordinates transformed from the original geographic coordinates in
the GeoLOD center fields.

Here is the adjusted scene:

https://googledrive.com/host/0BwIhFzkLaQ9XSWh1cGZRdlBZZm8/Mars.xhtml

While this works and can be automated, it turns out that x3dom loads all
nodes at all referenced levels, even the most detailed ones right when it
traverses the scene graph the first time. Inline nodes referenced from
other inline nodes are not a problem but of course this loading behaviour
defeats the idea of using LODs to keep large scenes from using up to much
memory. LODs are still helpful in terms of graphics performance. I think I
will ask on the x3dom developer list if this loading behaviour is intended
or necessary, and if there is way to add unloading of LOD child nodes when
they are out of range.
Since GeoLODs as defined in the spec. may not be efficient in any case, a
GeoLOD implementation based on the LOD implementation in x3dom along the
lines of the modifications in the example may be all what is initially
needed and would be useful in terms of conformance and in some scenarios.
Actually, a modified LOD node which accepts geo-coordinates for the center
field (with a provided geoSystem) but is otherwise functionally equivalent
to a regular LOD node would then make a bit more sense since it reflects
more closely what the node would do. It could be called GeoSimpleLOD or
similar. Would such a node be helpful at all ?
The x3dom BVHRefiner node in x3dom is cool but the javascript code seems
somewhat experimental and unfinished. I may try if it is possible to wrap
it in a GeoLocation node. However, it seem that in the Puget Sound example
the coordinate axis are non-standard: when you press 'U' for upright view,
the scene stands on its side. Since the node works with tiles, I could
envision that a geospatial version of the node could just geolocate each
tile separately after working out the geospatial position of the center of
each tile which should give pretty good but not totally precise locations.
Since the node uses webgl shaders to do the relief on a flat mesh (tile),
it would be difficult to produce a version which registers at each
displayed mesh point precisely with other geospatial nodes.
Any comments much appreciated.
Andreas


On Sat, Nov 22, 2014 at 10:21 AM, Andreas Plesch <andreasplesch at gmail.com>
wrote:

> Thanks, Tom and Doug for your helpful answers. From what I could see in
> the x3dom implementation there is some culling of the scene graph for LOD
> nodes depending on distance, GeoLOD is currently not available. A small but
> important feature of GeoLOD is that the reference (center) point from which
> distances are measured can be provided in geographic coordinates. I think I
> will put together a test scene to find out more on how LOD works  in x3dom.
>  On Nov 21, 2014 3:27 PM, "Andreas Plesch" <andreasplesch at gmail.com>
> wrote:
>
>> Hello,
>>
>> I want to clarify my understanding of the GeoLOD node but I am struggling
>> with how it improves on the regular LOD node. Here is what I currently
>> understand. GeoLOD defines a single level of refinement by providing up to
>> four children nodes (by URLs) which will be substituted for the main root
>> node if the viewer gets closer than a range distance. A progressive tree of
>> refinements can be achieved by making the children nodes themselves GeoLOD
>> nodes. On the contrary, a LOD node defines multiple levels of refinement by
>> providing a child node for each level which is then selected based on
>> viewing distance. The idea is that a single child node covers completely
>> the presented area. The child nodes are not specified by URL but are
>> internal to the node. So there seem to be clear differences between GeoLOD
>> and LOD nodes. However, since the LOD node definition is more general, it
>> seems to me that GeoLOD node could be substituted functionally by a LOD
>> node in this way. Given this GeoLOD node:
>>
>> <GeoLOD range="100"
>>   child1Url="child1url"
>>   child2Url="child2url"
>>   child3Url="child3url"
>>   child4Url="child4url" >
>>
>>    <Group DEF="rootNode">
>>     <GeoElevationGrid />
>>    </Group>
>>
>> </GeoLOD>
>>
>> an equivalent LOD node may look like this:
>>
>> <LOD range="100">
>>
>>  <Group DEF="detail-tiles">
>>   <inline url="child1url"/>
>>   <inline url="child2url"/>
>>   <inline url="child3url"/>
>>   <inline url="child4url"/>
>>  </Group>
>>
>>  <Group DEF="root-tile">
>>   <GeoElevationGrid />
>>  </Group>
>>
>> </LOD>
>>
>> Here the LOD node simply just uses one range level, (instead of
>> multiple), a group to define up to four child nodes and inline nodes to get
>> the equivalent of the GeoLOD childUrl fields. The inlined nodes could
>> include other LOD nodes in order to get a quadtree this way. Inline nodes
>> would need to be able to load contained inline nodes which is something I
>> am not sure x3dom.js at least currently supports although it may. Also the
>> GeoLOD specification language is more specific about loading and unloading
>> tiles. There are probably other differences which I am not seeing, so any
>> comments would be helpful.
>>
>> Thanks, Andreas
>>
>>


-- 
Andreas Plesch
39 Barbara Rd.
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20141125/eb39cb36/attachment.html>