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

From Web3D.org
Jump to: navigation, search
(→‎Summary of discussion on geospatial email list in 7/2015)
(→‎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.
 
−
 
−
Here is an example of the use a height mode:
 
−
 
−
http://andreasplesch.github.io/x3dom/GeoElevationGrid_texture/terrain_height.xhtml
 
−
 
−
which was tentatively implemented in a forked x3dom (Mesh.js).
 
−
 
−
Similary, it is often useful to visualize the spatial gradient of a surface or the slope. A new SLOPE mode for TextureCoordinateGenerator would generate texture coordinates based on the local slope angle ( implementations could derive the slope on the local normal ). By default slopes from 0 to 90 degrees would be scaled to the 0 to 1 range of the S texture coordinate. The  parameter field could be used to define a custom range. T would be set to 0 and a 1d texture map would be expected.
 
−
 
−
Here are two examples:
 
−
 
−
http://andreasplesch.github.io/x3dom/GeoElevationGrid_texture/puddle_slope.xhtml
 
−
 
−
and
 
−
 
−
http://andreasplesch.github.io/x3dom/GeoElevationGrid_texture/face_slope.xhtml
 
−
 
−
using a tentative implementation in a forked x3dom (Mesh.js).
 
−
 
−
One could also imagine (and quite easily implement) another mode "HEIGHT-SLOPE" which uses both attributes as S and T respectively  and a 2d texture map as suggested by Simon Thum on the geospatial list.
 
−
 
−
These modes would be somewhat similar to the existing VERTEX and SPHERE-LOCAL modes but aimed at 1d texture maps.
 
−
 
−
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 ===
 
=== 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 common to color a DEM by elevation. A recommended solution on the x3dom-user mailing list was to define texture coordinates as [normalized height, 0] for each grid point and then use a 1d texture to colors to height. 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 for a striped, 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
+
It is very possible to use this solution for a (Geo)Elevationgrid: calculate the texture coordinates from the height field 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 procedure much more accessible in some way. At first, introducing a (convenience) boolean option "heightTexCoords" to GeoElevationgrid which automatically generates the texture coordinates based on height was considered.
−
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.
 
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.
Line 41: Line 11:
 
It would then be also very useful to able to specify min. and max. height directly by a MFDouble field  "height_range" [min., max.] .
 
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.
+
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 achieved with higher fidelity 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:
+
If multiple options are provided, the source for texture coordinates would need to be prioritized:
  
 
1) explicitly defined: TextureCoordinate node
 
1) explicitly defined: TextureCoordinate node
Line 49: Line 19:
 
3) default as in spec.
 
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.
+
Testing for correctness should be possible by comparing manually added texture coordinates with automatically generated texture coordinates.
  
 +
Other considerations from an application perspective are:
  
−
***
+
1. It would be nice if technique could be applied to mesh data as well as grid data;
  
−
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.
+
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.)
 +
 
 +
Finding a general solution for mesh data such as IndexedFaceSet leads to the suggestion to define a new mode for TextureCoordinateGenerator. Then it would be necessary 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
 
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
Line 62: Line 37:
 
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.
 
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.
+
Another approach would be using normals which are calculated or provided for mesh vertices. Since geocentric positions are used, it would be necessary to use a reference vertical direction.
  
−
I do not see an advantage using colors especially since X3d only has rgb colors, not palleted colors.
+
The advantage of using colors would be that a color node may be a bit more user friendly than textures. However, X3D only has rgb colors, not palleted colors, and pixel textures effectively allow for using color values similar to color nodes.
−
 
+
−
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.)
+
  
 +
=== discussion on how to use the TextureCoordinateGenerator node ===
 +
...
 +
=== first concrete examples ===
 +
...
 +
=== new modes proposal ===
 +
...
 +
=== shaded relief effects ===
 +
...
 +
<!--
 
***
 
***
  
Line 197: Line 158:
  
 
to have quick way to look at all of them.
 
to have quick way to look at all of them.
 +
 +
 +
=== 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.
 +
 +
Here is an example of the use a height mode:
 +
 +
http://andreasplesch.github.io/x3dom/GeoElevationGrid_texture/terrain_height.xhtml
 +
 +
which was tentatively implemented in a forked x3dom (Mesh.js).
 +
 +
Similary, it is often useful to visualize the spatial gradient of a surface or the slope. A new SLOPE mode for TextureCoordinateGenerator would generate texture coordinates based on the local slope angle ( implementations could derive the slope on the local normal ). By default slopes from 0 to 90 degrees would be scaled to the 0 to 1 range of the S texture coordinate. The  parameter field could be used to define a custom range. T would be set to 0 and a 1d texture map would be expected.
 +
 +
Here are two examples:
 +
 +
http://andreasplesch.github.io/x3dom/GeoElevationGrid_texture/puddle_slope.xhtml
 +
 +
and
 +
 +
http://andreasplesch.github.io/x3dom/GeoElevationGrid_texture/face_slope.xhtml
 +
 +
using a tentative implementation in a forked x3dom (Mesh.js).
 +
 +
One could also imagine (and quite easily implement) another mode "HEIGHT-SLOPE" which uses both attributes as S and T respectively  and a 2d texture map as suggested by Simon Thum on the geospatial list.
 +
 +
These modes would be somewhat similar to the existing VERTEX and SPHERE-LOCAL modes but aimed at 1d texture maps.
 +
 +
Finally, geospatially registered meshes would need equivalent modes using height above the geoid and slope relative to the local tangential plane to the geoid.
  
  

Revision as of 03:25, 25 July 2015

Summary of discussion on geospatial email list in 7/2015

initial discussion

It is very common to color a DEM by elevation. A recommended solution on the x3dom-user mailing list was to define texture coordinates as [normalized height, 0] for each grid point and then use a 1d texture to colors to height. 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 for a striped, contoured appearance.

It is very possible to use this solution for a (Geo)Elevationgrid: calculate the texture coordinates from the height field 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 procedure much more accessible in some way. At first, introducing a (convenience) boolean option "heightTexCoords" to GeoElevationgrid which automatically generates the texture coordinates based on height was considered.

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 achieved with higher fidelity 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, the source for texture coordinates would need to be prioritized:

1) explicitly defined: TextureCoordinate node 2) heightTexCoords 3) default as in spec.

Testing for correctness should be possible by comparing manually added texture coordinates with automatically generated texture coordinates.

Other considerations from an application perspective are:

1. It would be nice if technique could be applied to mesh data as well as grid data;

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.)

Finding a general solution for mesh data such as IndexedFaceSet leads to the suggestion to define a new mode for TextureCoordinateGenerator. Then it would be necessary 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 normals which are calculated or provided for mesh vertices. Since geocentric positions are used, it would be necessary to use a reference vertical direction.

The advantage of using colors would be that a color node may be a bit more user friendly than textures. However, X3D only has rgb colors, not palleted colors, and pixel textures effectively allow for using color values similar to color nodes.

discussion on how to use the TextureCoordinateGenerator node

...

first concrete examples

...

new modes proposal

...

shaded relief effects

...

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