<div dir="ltr"><div><div><div><div><div><div><div>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.<br> <br>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 <a href="http://www.web3d.org/x3d-resources/content/examples/Basic/GeoSpatial/_pages/page18.html">http://www.web3d.org/x3d-resources/content/examples/Basic/GeoSpatial/_pages/page18.html</a> . 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.<br></div></div><br>Here is the adjusted scene:<br><br><a target="_blank" href="https://googledrive.com/host/0BwIhFzkLaQ9XSWh1cGZRdlBZZm8/Mars.xhtml">https://googledrive.com/host/0BwIhFzkLaQ9XSWh1cGZRdlBZZm8/Mars.xhtml</a><br><br></div>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.<br></div>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 ?<br></div>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.<br></div>Any comments much appreciated.<br></div>Andreas<br><div><div><div><div><div><div><div><div><div><div><div><div><div><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Nov 22, 2014 at 10:21 AM, Andreas Plesch <span dir="ltr"><<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">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.<br>
</p>
<div class="gmail_quote">On Nov 21, 2014 3:27 PM, "Andreas Plesch" <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hello,<br><br></div>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:<br><br><GeoLOD range="100"<br>  <span>child1Url</span>="child1url"
<br>
  <span>child2Url</span>="child2url"<br>
  <span>child3Url</span>="child3url"<br>
  <span>child4Url</span>="child4url" ><br><br>
<div>   <Group DEF="rootNode"><br></div><div>    <GeoElevationGrid /><br></div><div>   </Group><br><br></div></<span>GeoLOD</span>>
  <div><div><div><br></div><div>an equivalent LOD node may look like this:<br><br><LOD range="100"><br><br> <Group DEF="detail-tiles"><br>  <inline url="child1url"/><br>  <inline url="child2url"/><br>  <inline url="child3url"/><br><div>  <inline url="child4url"/><br></div><div> </Group><br><br></div><div> <Group DEF="root-tile"><br></div><div>  <GeoElevationGrid /><br></div><div> </Group><br><br></div></LOD><br><br></div><div>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.<br><br></div><div>Thanks, Andreas<br clear="all"></div><div><br></div></div></div></div>
</blockquote></div>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">Andreas Plesch<br>39 Barbara Rd.<br>Waltham, MA 02453</div>
</div>