TODO’s

TODO Items

The Bathymetry Display:

  1. Allow to set the thickness depending on the height of the grid. The height of the grid can be retrieved by
    	RefPtr BBox = getBoundingBall(Context);

    in the function addRepresentionProperties() or mayReuseAnemone(). The bounding box contains information about the height of the grid (see Class BoundingBox).

  2. Document the behavior of non-linear height mapping:
    1. Show how different values of thickness and power affect the display
    2. For power smaller than zero, we get compression of height layers around sea level
    3. For power larger than zero, we get stretching of height layers around sea level, compensating the behavior of the arcus tangens, and compression of layers at a height which is larger than the sea level, as well at the same height on a negative scale
    4. Determine at which level, for power larger than one, the maximum compression occurs
  3. Reverse the formula and use more intuitive values as inputs:
    1. allow to specify the thickness of the first height layer, and compute the power and (internal) thickness parameter from this value (creating power smaller than one)
    2. allow to specify the height level where we want maximal compression, and allow to specify a value for the intensity of this compression such as the thickness of the height layer at this level of maximal compression
    3. try to make the cases for power <1.0 and power >1.0 similar in parameters
  4. Allow to use different power values for negative and positive regions
  5. Use 10 colors in each direction, which each of them is clearly distinguished (http://en.wikipedia.org/wiki/Hypsometric_tints), http://en.wikipedia.org/wiki/Cartographic_relief_depiction
  6. Add contour lines similar to images such as the followings. The height lines would be black, in different properties, such as small for each 100m, thick for 500m, thick red for 1000m (but with adjustable scaling value of course, to be possibly 10/50/100m instead). In our case, height lines wouldn’t not be exact lines, but having some spatial extension.
  7. Try to implement height lines without using if-conditions, but rather GLSL step()/smooth()/modulo() etc. functions. This would be much faster but also more elegant.
  8. Maybe it is possible compensate for the “broadening” of height lines if we take the gradient into account, which is available through the normal vector field of the surface. Need to think about this.
  9. Allow for some scaling which is relative to non-zero sea level. This will need to be done via OpenGL matrix transformations:
    1. translate
    2. scale
    3. translate back

    Currently it is only doing the scaling part, but not the translation. This requires parameter support for translations in the VGLRenderContext, and setting the three parameter with different tentacle order such that their execution order is defined (insertTentacle() instead of insert().

  10. Further Inspiration: http://www.ssg-surfer.com/html/surfer_details.html

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Ocean Waves:

  1. Load wind vector field as data set – code similar to loading normal vectors
  2. Support time dependent vector fields, as analytic example use a vector field of type (-y, x,0), which is a swirl, and let it move around a running center, like 
  3. Compute normal vectors of the waves, depending on analytic formula for the waves
  4. Refine large triangles into smaller ones for higher resolution using a geometry shader (see next item)

Vector Display

  1. Create a module to display vector arrows at each vertex of a surface, using geometry shader
  2. Two display modules:
    1. One very simple one, only drawing arrows as lines, similar to the current vector arrow module
    2. One more advanced which displays arrows as three-dimensional objects, find inspiration on options at google image search for ‘vector arrows’
    3. 3D arrows should be general to work just on any kind of vertex information, but maybe we want to have some vector arrow display that is specifically for surfaces; above google image search yields a couple of vector arrows that are ‘flattened’ in 3D, which means they have some preferred direction encoded in addition to the vector direction. Such direction can be a surface’s normal. Eg: 
  3. More advanced vector arrow module displaying curved arrows, making use of an additional vector field describing the curvature of the vector field. This requires also a module to compute the curvature of a vector field on a surface. Currently we have curvature computation only on lines.

 

Waves on  triangular Grid

Possible ideas to implement:

 

 

 

more…?

 

 

 

 

RSS feed for comments on this post. TrackBack URI

Leave a Reply

You must be logged in to post a comment.