[GRASS5] Voxel progress

[Sören Gebbert]

On Saturday 11 March 2006 13:48, benducke at compuserve.de wrote:
> As I hear, GRASS-based voxel modelling and its use in
> archaeology were a topic at the last GRASS user meeting.
> It certainly is a hot topic in archaeology and I am trying
> to write some GRASS modules to this end.
> 
> It seems that volume visualization in NVIZ still needs some bugfixing.
> I would like to use GRASS voxels to represent stratigraphic layers.
> For this, I am working on a module that builds a voxel model from a series
> of DEMs (each representing a stratigraphic layer surface). 
> It uses a sort of 3D flood filling algorithm.
> 
> Each DEM is taken as the upper surface of 0 to n input layers.
> The module will fill down voxels from each surface and assign each
> voxel the number of that surface until it hits the next, underlying surface.
> 
> So far, things work fine and if I use r3.out.vtk, I get nice models
> that I can visualise in paraview - no problems.
> Also, using r3.cross.rast for sampling slices seems to give correct
> results.
> Also, the output from r3.info is perfectly sane, so it seems the
> algorithm is working.
> 
> My 3D region settings are:
> 
> projection: 0 (x,y)
> zone:       0
> north:      60.85
> south:      58.85
> west:       14.9
> east:       16.95
> top:        12.00000000
> bottom:     9.00000000
> nsres:      0.05
> nsres3:     0.05
> ewres:      0.05
> ewres3:     0.05
> tbres:      0.05
> rows:       40
> rows3:      40
> cols:       41
> cols3:      41
> depths:     60
> 
> The same extents apply to my layer model.
> 
> HOWEVER, I fail to visualise such a layer model in NVIZ.
> The first problem is that NVIZ seems to be unable to correctly
> position volumes that have a bottom > 0.0.
> 
> You can test this even with a very primitive volume
> (use the 3d region settings as shown above):
> 
> r3.mapcalc test=1.0
> 
> If you load this into NVIZ (and set the bottom of the 3d region > 0.0), 
> it will not display the extents of the volume as it should.
> If you start rotating the view around a bit and increase
> height enough, the extents will be temporarily visible and you will see 
> that the whole model has been
> displaced from its original z-range 9.0 to 12.0 and is displayed
> at 0.0 to 3.0!
> 
> Obviously, it is not possible to display slices or isosurfaces in such a
> model, as the NVIZ extent and the real data extent do not match. 
> So this seems to be a bug in NVIZ(?).
> 
> But here is what really puzzles me: if I adjust 3d region settings and
> set the bottom to 0.0, NVIZ shows the correct extent, but has the same
> problems!
> I.e. I only get a display of the extent as wireframe for as long as
> rotate the view, change the height or whatever.
> 
> Everything disappears after that and I cannot display slices or isosurfaces.
> 
> is it possible that NVIZ has trouble with small 3d regions or high 3d
> resolution?
> Am I doing something totally silly?

Sorry i have no clue of NVIZ.

> 
> Finally, some points that I could not figure out from any documentation
> and am still a bit unsure about. Maybe someone could reaffirm my
> conclusions about these:
> 
> 1. GRASS Z coordinates increase towards the top of the region

This question bothers me too, since some time!!
I was thinking the count is from top to bottom, because the output of r3.out.ascii suggest
that the first voxel is in the upper left corner of the exported region cube.

But i got confused, because r3.out.vtk, r3.to.rast and r.to.rast3 suggest the count is
from top to bottom -> depth 0 ==top and depth n ==  bottom,
but r3.cross.rast is doing this the other way!?! I was thinking this is a bug in r3.cross.rast
which i have fixed in my current version. 
But maybe all the other modules are wrong with there suggestions?

If this is consistently implemented, the order is irrelevant i think,
but the implementation of r3.out.ascii adn r3.in.ascii still confuses me! 

> 2. r3.in.ascii expects the bottom slice first in the ASCII input file
I thought it expects the top slice first???
> 
> I would so much like to get this working. It would be tremendously
> useful for archaeological applications of GRASS GIS!

After some thinking, i am not sure anymore about the order of the depths.
But i think now the internal g3d order is:
z -> from bottom to top
y -> from south to the north
x -> from west to east

If i have confirmation of this, i will rewrite my modules (r3.out.vtk, r.to.rast3 and r3.to.rast)
to support this counting.
Also, to reduce confusing this should be dokumented and r3.out.ascii and r3.in.ascii should
be rewritten so the first slice is the top, the last slice is the bottom 
and the upper left edge should be realy the upper left edge. (y -- coordinate!!)

Best regards
Soeren

> 
> Best,
> 
> Benjamin
> 
> _______________________________________________
> grass5 mailing list
> grass5 at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5
> 
>