Difference between revisions of "Terrain height/slope visualization via autogenerated texture coordinates"

From Web3D.org
Jump to: navigation, search
m (new modes)
(→‎Summary of discussion on geospatial email list in 7/2015)
Line 1: Line 1:
 
== Summary of discussion on geospatial email list in 7/2015 ==
 
== Summary of discussion on geospatial email list in 7/2015 ==
 
<!--
 
<!--
 +
 +
=== new modes proposal ===
 +
 
In data visualization it is often useful to color the y component (height) of a mesh. This is particularly evident for ElevationGrids where contouring is a proven visualization method. Therefore it would be very useful to have a new HEIGHT mode which generates texture coordinates based on the y coordinate. The most useful default would be to automatically scale to the range in height of the mesh. The parameter field could be used to define a custom range in height which corresponds to the 0 to 1 range of the S texture coordinate. T would be set to 0, eg. a 1d texture map would be expected.
 
In data visualization it is often useful to color the y component (height) of a mesh. This is particularly evident for ElevationGrids where contouring is a proven visualization method. Therefore it would be very useful to have a new HEIGHT mode which generates texture coordinates based on the y coordinate. The most useful default would be to automatically scale to the range in height of the mesh. The parameter field could be used to define a custom range in height which corresponds to the 0 to 1 range of the S texture coordinate. T would be set to 0, eg. a 1d texture map would be expected.
  
Line 26: Line 29:
  
 
Finally, geospatially registered meshes would need equivalent modes using height above the geoid and slope relative to the local tangential plane to the geoid.
 
Finally, geospatially registered meshes would need equivalent modes using height above the geoid and slope relative to the local tangential plane to the geoid.
 +
 +
=== initial discussion ===
 +
 +
It is very common to color a DEM by elevation. The recommended solution on the mailing list was to define texture coordinates  as [normalized height, 0] for each grid point and then use a 1d texture to look up the color by height. To me this is a good solution since it allows for easily swapping out the color scale. For example, it is easily possible to limit the number of colors to say four for a contoured appearance.
 +
 +
It is very possible to just do that for a GeoElevationgrid: calculate the texture coordinates and put them in a texture coordinate node. However, since it is such a common situation and since there is a (minor) calculation involved, it would make sense to make this calculation generally available by
 +
introducing a (convenience) boolean option "heightTexCoords" to GeoElevationgrid which automatically generates the texture coordinates based on height.
 +
 +
By default the option would determine min. and max. of the height field and generate texture coordinates (height-min.)/(max.-min.) , 0 for each node.
 +
 +
It would then be also very useful to able to specify min. and max. height directly by a MFDouble field  "height_range" [min., max.] .
 +
 +
Another option may be discretization of the texture coordinates into a limited number of values by a SFInt32 field "height_steps": U_discrete = int(U * hsteps)/hsteps or so where U is the normalized height. This effect can be accomplished by a discretized texture map as well but would be convenient to have. For example, it would be straightforward to generate 100m contours by providing a height_range of [-3000,0] and height_steps of 30. Some more discussion and thought would be required since the contours would not be very accurate due to information loss. It would be probably better to have such a discretization option for the texture map.
 +
 +
If multiple options are provided, texture coordinates are chosen by priority:
 +
 +
1) explicitly defined: TextureCoordinate node
 +
2) heightTexCoords
 +
3) default as in spec.
 +
 +
Looking at x3dom, it turns out that support for the texCoord field is currently missing but could be added based on the Elevationgrid code. Then support for automatically generating texture coordinates based on height as outlined should also be possible. Testing for correctness should be possible by comparing then manually added texture coordinates with automatically generated texture coordinates.
 +
 +
 +
***
 +
 +
these are great ideas, and I had thought about somehow finding a general solution for mesh data such as IndexedFaceSet. The way to do that maybe to define a new mode for TextureCoordinateGenerator. However, one then would have to distinguish between geocentric coordinates and regular coordinates to determine height, making the problem a little complex.
 +
 +
Slope or dip based coloring/texturing could be quite interesting and is something we actually do quite a bit in geosciences. It would be possible to calculate slope (and aspect) for each grid node, for example according to
 +
 +
http://resources.arcgis.com/en/help/main/10.1/index.html#//009z000000vz000000
 +
 +
using the 3x3 grid around a node. At the borders, one could just use the closest values to fill in. It should also be possible to use the calculated mesh normals.
 +
 +
Another approach would be using shaders since in a shader the normal at each drawn fragment is already calculated. Since geocentric positions are used, it would be necessary to use a reference vertical direction, for smaller scenes. It maybe fruitful asking on the x3dom list how to do this but it will be complicated since then the shader is responsible for the complete rendering.
 +
 +
I do not see an advantage using colors especially since X3d only has rgb colors, not palleted colors.
 +
 +
Andreas
 +
 +
 +
 +
On Thu, Jul 16, 2015 at 12:12 PM, Mike McCann <mccann@mbari.org> wrote:
 +
 +
Hello Andreas,
 +
 +
 +
That posting on x3dom-user intrigued me too. I'm glad that you are considering implementing a height color texture feature in GeoElevationGrid.
 +
 +
 +
Here are considerations that come to mind:
 +
 +
 +
1. It would be nice if technique could be applied to mesh data as well as grid data; my limited understanding is that the main difference would be calculating the texture coordinates.
 +
 +
 +
2. Marine geologists and geophysicists like to shade the color according to slope magnitude or synthetic illumination (see the man page for mbm_grdtiff). With X3D we can add a light to the scene and get synthetic illumination, but shading by slope magnitude would have to be done some other way. The mbm_grdtiff tool has several options that serve to distill decades of use case capture – maybe some of these are optional attributes that could go along with a new heightTexCoords attribute.
 +
 +
 +
3. If a color node is used there should be a way to pass in a color lookup table. (An advantage of using the more general texture approach is that the x3d author specifies the color lookup with the texture.)
 +
 +
***
 +
 +
I was looking around a bit more and found the function which deals with TextureCoordinateGenerator modes if they are not directly handled in shaders such as "SPHERE":
 +
 +
https://github.com/x3dom/x3dom/blob/master/src/Mesh.js#L342
 +
 +
This is probably called from all geometry nodes which generate meshes and I believe would be the place to calculate texture coordinates based on height or slope. As an experiment, I might just add a "slope" mode which would be quite similar to the implemented "sphere-local" mode and would use the (asin of the) z component of the normal for U and 0 for V. This should would work for non-geospatial meshes where the XZ plane is horizontal. I start to like this idea more. Similarly, it should be possible to add a "height" mode which uses normalized Y for U.
 +
 +
One presumably could do this somewhere in the shader code as well although I am unsure about touching it. Where would I start looking ? Follow the spheremapping ?
 +
 +
There is a "COORD" mode in the spec.
 +
 +
(http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/texturing.html#t-Texturecoordgeneration)
 +
 +
which uses vertex coordinates in some way but how is it supposed to work ? I do not think it is implemented.
 +
 +
For geospatial meshes, for a "geoheight" mode, it would be first necessary to (re-)derive the heights from the geocentric mesh coordinates (potentially taking into account GeoOrigin transformations). This should be doable. The other option would be to look into the parent node, and use the height field in case of GeoElevationGrid, or the z-component of GeoCoordinates (would not work for geocentric geosystem).
 +
 +
Then U would be normalized height, and V would be zero. One could use the parameter field of the TextureCoordinateGenerator node to specify a custom height range and perhaps a discretization as outlined earlier. This could work.
 +
 +
For a "geoslope" mode, it would be necessary to calculate the angle between the provided normal and the local Up (or Down) direction. For rotateYUp scenes presumably one could just use the normal.
 +
 +
That brings up the question if it is acceptable to introduce geo-modes to TextureCoordinateGenerator in terms of x3d components and profiles. It may be necessary to introduce a GeoTextureCoordinateGenerator node.
 +
 +
Leaning towards using new TextureCoordinateGenerator modes instead of new GeoElevationGrid fields  would cover more use cases. However, it requires some more processing to deal with the geocentric coordinates, eg. may be a bit harder to implement. Also it would touch Mesh.js which is used by a lot of nodes.
 +
 +
 +
****
 +
 +
A 2d "height-slope" mode would be easy enough to add since all pieces are already there. The main application I see would be to use a color map with increasing intensity or saturation or darkness of color in the V (T) direction to emphasize steep slopes but still have elevation contouring. Not sure how it looks together with shading but probably worth trying.
 +
 +
Another standard but not very common use of a 2d color map is to visualize slope and aspect - the direction of slope - together. However, this gets quite far into GIS processing and may be better handled outside of X3D, eg. by customized texture coordinates.
 +
 +
Another idea using a 2d texture map with increasing darkness in T would be to add standard relief shading based on custom sun location and slope but this may be inconsistent and strange looking together with the regular (light defined) shading. It would be a sort of baked in shading. It often helps to bring out subtle features. In most cases it would be probably preferable to have a lower resolution mesh, and a higher resolution image texture showing the relief shading draped on top.
 +
 +
-Andreas
 +
 +
On Mon, Jul 20, 2015 at 2:53 AM, Simon Thum <simon.thum@igd.fraunhofer.de> wrote:
 +
 +
Hi,
 +
this looks great! Have you thought about using slope and height together to address a 2D Texture? Could be another mode, and allow for funny things like snow not covering steep spots. Just an idea.
 +
 +
=== first concrete examples ===
 +
 +
Here is an example of slope based texturing of an IndexedFaceSet using the "slope" mode of TextureCoordinateGenerator:
 +
 +
http://andreasplesch.github.io/x3dom/GeoElevationGrid_texture/face_slope.xhtml
 +
 +
It is possible to use the parameter field to define a data range (min. and max. color) to map to the texture in degrees. By default the range is 0 to 90.
 +
 +
Following the same approach I also added a "height" mode for TextureCoordinateGenerator:
 +
 +
http://andreasplesch.github.io/x3dom/GeoElevationGrid_texture/terrain_height.xhtml
 +
 +
It works as expected. By default, the whole range of heights (Y component of positions) is used but the parameter field can be used to define a custom data range.
 +
 +
 +
 +
****
 +
 +
Since I am slowly working towards something that I may be able to use or get help with for my potential  application, that is exactly point: trying to make it easy to add contours with a reasonable default setting. I think it would even be advantageous to have a few standard color bars, eg. 1d texture maps provided with x3d(om). But that likely exceeds the scope of x3d or x3dom as it is perceived, and could be a sort of add-on. I can see a standard x3d file that just has bunch of named pixeltextures or imagetextures with a dataurl that can be inlined and then be used. With javascript one could update the url field or replace the whole imagetexture node.
 +
 +
I am not sure if currently changing the texture map url field or the parameter field (or an additional TextureTransform node) triggers the appropriate updates but it may or should be doable once the new modes are working.
 +
 +
The x3d way of shaded relief is probably a (few) potentially directional light(s) which can be moved around. It should be possible to GeoLocate a light. This way one could use geographic coordinates and some elevation although this is probably not the best way to specify a sun position.
 +
 +
I made some progress on the "geo-height" mode which now works with non-geoOrigin meshes:
 +
 +
http://andreasplesch.github.io/x3dom/GeoElevationGrid_texture/globe_geo-height.xhtml
 +
 +
and
 +
 +
http://andreasplesch.github.io/x3dom/GeoElevationGrid_texture/terrain_geoOrigin_geo-height.xhtml
 +
 +
(uses UTM coordinates and does not currently use a geoOrigin)
 +
 +
Next, I want to take into account a geoOrigin if it is given with the parent node or with a parent's geoCoordinate node in order to derive proper heights from the mesh vertex positions.
 +
 +
Also, I need to make sure that Mesh.js otherwise still works without a loaded geospatial component, and perhaps add a note in the log that geo-height is requested but needs the geospatial component.
 +
 +
 +
****
 +
 +
Having gone through GeoTransform helped in relatively painlessly adding support for a provided GeoOrigin when deriving heights for the "GEO-HEIGHT" mode for TextureCoordinateGenerator:
 +
 +
http://andreasplesch.github.io/x3dom/GeoElevationGrid_texture/terrain_geoOrigin_geo-height.xhtml
 +
 +
It appears to work correctly.
 +
 +
I also added a warning and falling back to default texture coordinates in the case that somebody tries out the geo-height mode without having the geospatial component available.
 +
 +
I do not believe that any transformations by parent transform, geolocation or geotransform nodes were applied to the mesh coordinates at the stage when the texture coordinates are generated. I think this is what works best in most cases but important to keep in mind when using the parameters field to define a custom height range.
 +
 +
 +
 +
****
 +
 +
Since I had a pretty good idea of how to go about slope calculation from the normal and the local vertical orientation given by the geocentric position of a vertex, I added the "GEO-SLOPE" mode to Mesh.js. Here is an example without and with GeoOrigin use:
 +
 +
http://andreasplesch.github.io/x3dom/GeoElevationGrid_texture/terrain_geo-slope.xhtml
 +
 +
http://andreasplesch.github.io/x3dom/GeoElevationGrid_texture/terrain_geoOrigin_geo-slope.xhtml
 +
 +
I also added all the test scenes to the examples list on
 +
 +
http://andreasplesch.github.io/x3dom/
 +
 +
to have quick way to look at all of them.
 +
 +
 +
=== shaded relief effects ===
 +
 +
http://www.reliefshading.com/
 +
 +
For shaded relief purposes, let's think about using a directional light since the sun's rays are effectively parallel.
 +
 +
http://suncalc.net/ shows the sun's position in the sky anywhere, anytime. It uses https://github.com/mourner/suncalc to calculate the sun's position in the sky. It could be fun to use this with geospatial x3dom to predict/reconstruct the lighting situation at some time, perhaps for accident reconstruction and such.
 +
 +
Shaded relief shading should be simpler. Since azimuth and elevation of the sun for shaded relief purposes is defined with respect to local north and the local horizontal, it should be possible use a GeoLocation node with a location close the geoelevationgrid in order to rotate the directional light orientation properly with respect to the orientation of the local tangential plane. The directional light orientation would be just azimuth and elevation as a vector.
 +
 +
One could use the NormalInterpolator node to vary the sun light orientation. The node uses a spherical interpolation. Interpolating say from horizontal NE towards SW orientation (-1, 0, -1) to vertical downwards (0, -1, 0) to horizontal SW to NE (1, 0, 1) and routing to the orientation field of the light should produce a nice variation of shading to explore. I may try that.
 +
 +
[Alternatively, it should be also possible to use an OrientationInterpolator node routed to a transform node.]
 +
 +
Another important option for shaded relief purposes is to exaggerate the vertical for more pronounced shading. So it would be nice to have option to do this without actually vertically exaggerating the vertex positions. I suspect the shaders in x3dom use the mesh normals to produce the default shading based on the lights in the scene. If not provided as is often the case, the normals are calculated from the vertex positions. It would be possible to manipulate the normal calculation to use a scaled up Y coordinate of a vertex. However, this would not work for geocentric coordinates. For GeoElevationGrid it may be possible to calculate exaggerated normals, then non-exaggerated normals and positions, and texMode based texcoords, and finally replace the normals with exaggerated normals.
 +
 +
 +
The idea of using a geolocated directional light worked quite well. Here is an animated example along the lines I had described:
 +
 +
http://andreasplesch.github.io/x3dom/GeoElevationGrid_texture/terrain_sun.xhtml
 +
 +
Shaded relief in 3d looks pretty good. It should be possible to restrict lights to certain objects, eg. lights are supposed to be only applied to the objects in their parent group. This way one could have shaded relief on terrain but "normal" lighting for all other objects.
 +
 +
Since this works well, I do not think it is very advantageous to do much about vertical exaggeration for shading purposes.
 +
 +
The last item would be to see if it is possible to use a PixelTexture to define a stepwise color function, eg. to have a limited number of color bands for a striped appearance mimicking actual contour lines. This probably requires the "NEAREST" magFilter of the TextureProperty node.
  
 
-->
 
-->

Revision as of 18:37, 24 July 2015

Summary of discussion on geospatial email list in 7/2015

Retrieved from "http://web3dconsortium.org/wiki/index.php?title=Terrain_height/slope_visualization_via_autogenerated_texture_coordinates&oldid=8954"