[GRASS-user] r.colors -e for G3d?

[Hamish]

Soeren wrote:
> I currently rework the g3d library and the related modules to use the
> correct coordinate system (x, y, z -> right hand side cube). So all
> modules which convert raster to raster3d and vis versa are implemented
> in a wrong way. The r3.out.vtk export module is wrong too, it flips
> the y coordinate so the result looks reasonable in Paraview. :/

whatever it does internally, the result in Paraview seems ok currently :)

good news that the r3.* modules are getting some needed care!


> While doing this i plan to implement two more modules:
> r3.retile and r3.colors. r3.colors can be used to assign a color table
> to a raster3d map (its an enhancement to r.colors to support 3d raster
> too, like r.univar and r3.univar). Because g3d uses the same color
> table and functions as the raster library these color tables can be
> exchanged between raster and raster3d maps. Maybe this is the
> function you are looking for?

yes, exactly.

(one day we need to generalize to use the colr/ format for vectors too)


> Nice to hear that you plan to write a convert tool to use grass color
> tables in VTK too. Can you please provide your code when its finished,
> because this functionality is still missing in the vtk-grass-bridge.

done:
  (well almost: except for a help page & porting to python for gr7, but
   it's quite simple)

https://trac.osgeo.org/grass/browser/grass-addons/raster/r.colors.out_vtk/


together with r.cpt2grass we can now translate GMT<->GRASS<->VTK color
tables too. (although a direct GMT<->VTK would be less lossy for HSV)

I added a -n flag to normalize the range, so if you like to convert all
standard GRASS rules to a standard set for general Paraview use, you can
do that.


the results (for the top z-layer) thanks to 'r.colors -e' are quite
stunning. I'll send you a screenshot off-list. Can't wait to see what
the 3D 'r.colors -e' version looks like, but I need to figure out how to
do isosurfaces in Paraview, or how to automatically assign color rules to
isosurfaces in NVIZ before I can take full advantage of that.

Importing the 1000 entry ColorMap into Paraview once selected is rather
slow, but we should be able to optimize that by removing the middle rule(s)
of >3 the-same-in-a-row RGB with the same rendering result. Once loaded,
the 3D view seems as fast as ever, so maybe it's just a minor inconvenience.
(maybe grass7 already does that?)


cheers,
Hamish