[GRASS5] working on g3d

[Helena]

> .    visualization - NVIZ - support of 3D raster
>      (integration of sg4d or r3.showdspf functionality?)
>      (Tomas Paudits has started on this)
>      (porting sg4d to i686-pc?)

a small clarification here: sg4d is just a rather crude linkage of SG3d
and showdspf
which was the GL version of r3.showdspf. So there is no point of
integrating 
or porting sg4d as SG3d has already been replaced by NVIZ (which is much
more powerfull now)
and showdspf was ported as r3.showdspf. So to make it work there are
several options:

1. integrate r3.showdspf with NVIZ (that was our original intention, but
Bill had troubles with that)
also, r3.showdspf has disabled an important functionality that allowed
to create solids and 
crossections (this was probably due to the bug in g3d library which
should be fixed by now
so it may be worth revisiting). 

2. Forget r3.showdpsf and write support for 3D raster for NVIZ from
scratch

3. Use vis5d

> .    xganim - support of 3d data animation?

do you mean here something like slicing through the volume (equivalent
to transforming the 3d raster to seriers of 2d rasters and then running
them
through xganim) ? We did 3d data animation either through showdspf or
through scripting
in sg4d (using the SG3d scripting capability). Nviz already has lots of
scripting/animation
tools but they are not particularly easy to use. 
 
> .    add the possibility to define in the volume "boundaries surfaces"
>      (support to regionally restricted interpolation/analysis)
>      [keeping soil horizon boundaries or stratifications]

isn't this supported by r3.mask? But the tools to create such mask could
be
expanded by the r3.mapcalc extensions as suggested below

> .    hist files
> .    r3.mapcalc add the capability to use also 2d-raster
> .    r3.mapcalc add absolute cell reference
> .    temporal series and 4D data format, compression...
> .    export to netcdf format
>      (a 2D version already exist, written by Alessandro Frigeri,
>      Generic Mapping Tools and Explorer-OpenDX are supported)
> 
> g3d libraries
> -------------
> 
> two tipe of functions can be defined:
> tiles-functions and no-tile-functions
> 
> .    now (I hope) all the parameters in the no-tile-functions are called
>      in the order:
>      rows, cols, levels
>                  iven if sometimes the notation
>                  y, x, z
>                  is used
> .    the parameters in the tile-functions are called in the order:
>      x, y, z
>      iven if sometimes the notation
>      cols, rows, levels
>      is used

would it be difficult to unify this ? 
> 
> known bugs
> ----------
> 
> .    r3.mapcalc crash increasing the number of levels (error in
>      G3d_getTilePtr)
> .    r3.mask crash (error in G3d_getTilePtr)
> .    r3.showdspf some parameters don't work
> .    r3.out.v5d always/sometimes(?) it reverses t-b, n-s order

is there still a problem with s.vol.rst? (John was reporting some
segmentation faults)
> 
> discussion
> ----------
> 
> .    extend the new r.mapcalc to a third dimension and replace the
>      current r3.mapcalc
> .    for loops: levels, rows, cols
>      (once for all, let's define them)
> .    do the tile-functions (see above) have to use x,y,z notation or
>      could/should it be
>      moved to rows,cols,levs?

I would suggest rows, cols levs to minimize the confusion

> .    tiles support/use/performance
> .    update docs, bugs, todo files in src.contrib/GMSL/g3d
> 
> Alfonso
> 
> _______________________________________________
> grass5 mailing list
> grass5 at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5