[GRASS5] g3d notes and possible bugs

[John Harrop]

Hello and Happy New Year,

I've been away from the g3d work for a while on less interesting stuff 
(grant applications, hiring co-op students etc ;-) but I've now had a 
chance to try out the revisions made by AV - particularly in r3.out.v5d

We have been running production data through the system partly for a 
presentation tomorrow, but also to get ready for a trade show (Mineral 
Exploration and Mining) later this month in Vancouver, Canada.  We will 
be high-lighting Grass and related tools at our booth.  The block of 
(real) data I've been working with unfortunately has topographical 
features that as as close to N-S as makes no difference!  This resulted 
in lots of fun :-) trying to check if the N-S axis was being reversed!

1)  We can confirm that work done by AV in r3.out.v5d  has fixed the 
problem with non-square (x dim = y dim) grid3s being exported 
incorrectly.  r3.showdspf and vis5d now have equivalent display.

2)  The Gmakefile for r3.showdspf.openGL in 5.0.0 exp is missing -lGLw 
and -lXm in the OGLLIB line.  This has been fixed in the release source, 
but not in the exp.

3)  Importing 2d elevation data does not result in the same display as 
importing equivalent data with a 3d site approach.  I'm fairly sure the 
fault lies in s.vol.idw - (yes, I know it was recommended that we use 
s.vol.rst, but I have yet to get the 3d one to run without crashing.) 
 For a smooth 3d block model the idw approach is good enough for 
testing.  Both Z (elevation) and Y (northing) are reversed when 
displayed after importing.  With the storage order being the reverse of 
physical coordinates for Y and Z its not hard to accidentally reverse 
the storage in a loop.  I think AV may have done two fixes in the code 
that cancelled each other ;-)  I'll check that in more detail and report 
later.

4)  r3.mask is crashing as follows:

> r3.mask maskvalues=-1 grid3=test.20-t
> FATAL ERROR: G3d_getDoubleRegion: error in G3d_getTilePtr

I have not had a chance to start exploring the error message.  It may be 
a bug in the operator.  Since I have not been able to create a 3d mask, 
so that may be why s.vol.rst is failing and complaining about too few 
points?


I have not entered any of these as bug reports because I'm actively 
working on them, and in the spirit of Open Source hopefully I'll have a 
fix to post with the bug!

Cheers,

John Harrop