$Id: BUGS,v 1.7.2.1 2003/03/16 12:25:20 glynn Exp $

                           G3D bugs list
                  ---> Call for assistance <------

History:
 - There has been a former grid3d library written by Roman Waupotitsch,
   with input from Mike Shapiro, Helena Mitasova, Bill Brown 
   et al. 
 - Later Mark Astley ported grid3d to g3d library which is now widely used
   for g3d modules.

Current situation:

Currently there are severe G3D inconsistencies: 
The basic problem is that the "for" loops are different. 
I would prefer if G3D orders the data from
 - north to south (like 2D GRASS)
 - west to east   (like 2D GRASS)
 - top to bottom

[Note from Helena Mitasova: One of the fundamental requirements was that     
 it is consistent with GRASS2d]

I can't find anything documented except what's in the GRASS Programmer's
manual: http://www.geog.uni-hannover.de/grass/grassdevel.html#prog

See
src/libes/g3d/doc/*
for emails from Roman Waupotitsch during the implementation period.

--------------------------------------------------------------------
Somehow the migration from grid3d to g3d got confused.
Check these modules:


 - s.vol.rst: does not use G3D to read/write data, but seems to
   read as described above (N->S, W->E, T->B)
   Looks good.
   (Ported from s.surf.3d to s.vol.rst by Jaro Hofierka)

 - src/libes/g3d/writeascii.c (unused sample application):
   G3d_writeAscii()
     for (z = 0; z < depths; z++) 
       for (y = 0; y < rows; y++) {
         for (x = 0; x < cols; x++) {
 
 - but in r3.out.ascii/main.c:
     for (z = 0; z < depths; z++) 
       for (y = rows-1; y >= 0; y--) {    /* north to south */
         for (x = 0; x < cols; x++) {

   y is read reverted, indicates that the g3d-storage is not consistent
   with 2D GRASS.

 - r3.in.ascii/main.c
     for (z = 0; z < region->depths; z++) {
       for (y = region->rows-1; y >= 0; y--)    /* go north to south */
        for (x = 0; x < region->cols; x++) {

   y reverted, but at least consistent with r3.out.ascii

 - r3.out.v5d/main.c

     for (z = 0; z < depths; z++) {
       for (x = 0; x < cols; x++) {
         for (y = rows-1; y >= 0; y--) {  /* north to south */

   x and y changed (I have done this to get consistency with 2D GRASS and
   to avoid problems with Vis5D)


- BUT: the consistency of r3.in.ascii and r3.out.ascii results looks like it
  might be due to a double reversal, not correctness.  The fact that
  r3.out.v5d and r3.mk/showdspf result in consistent displays may also only
  be confirming the consistency of bugs in the two codes :-)

 - s.vol.idw/main.c
     for (lev = 0; lev < Nl; lev++)
      for (row = 0; row < Nr; row++)
        for (col = 0; col < Nc; col++)
   the output of s.vol.idw does not match s.vol.rst (somewhat flipped)


 - r3.mkdspf/r3_data.c | r3.showdspf.openGL/r3_data.c
    no for loops but:
      G3d_getBlock ()
    is used
   Is G3d_getBlock () consistent with "for" loops used in other modules?

- r3.mkdspf: problem to find dspf file in r3.showdspf
  Eric Miller wrote:
   There's a bug in the naming of the output file from r3.mkdspf.  It'll be
   there, just not named as you specified (has some extra junk added).  If
   I'm remembering correctly, if you go into the grid3 directory under the
   mapset and move the dsp<semi-random junk> directory to "dsp", everything
   will function normally thereafter (including creation of new dspf files). 
   I may have misremembered, but it's something like that...
   -> bug does not appear on all platforms!

 - r3.to.sites/main.c

     for (z = 0; z < depths; z++) {
       for (y = rows-1; y >= 0; y--) {    /* north to south */
         for (x = 0; x < cols; x++) {

   derived from r3.out.ascii, same story

 - r3.mapcalc
    ?


 - r3.null/main.c

    for (z = 0; z < region.depths; z++) {
     for (y = 0; y < region.cols; y++)
      for (x = 0; x < region.rows; x++) {

This confusion needs to be fixed.

-------------------------------------------------------------------
General bug:

 If you generate a volume with small region settings and enlarge the
 region later, all modules will crash with a "error in G3d_getTilePtr" 
 from:
 src/libes/g3d/tileio.c

 However, in 2D GRASS this region enlargement is allowed. It would be
 definitly an improvement to get rid of this bug.

 To follow this bug, the new "g3.setregion" script can be used:
 In CVS at:
 http://freegis.org/cgi-bin/viewcvs.cgi/~checkout~/grass/src.contrib/GMSL/g3d/src3d/scripts/g3.setregion

-------------------------------------------------------------------
Specific bugs:

 - see individual BUGS files
 - r3.showdspf.opengl bugs:
    no solids, no "p", no fences available...
    It seems that the port is not yet complete.
 - r3.out.v5d: only works with rows=cols (square area), otherwise
   nonsense output. Seems to be related to g3d lib confusion.

Regards

 Markus Neteler
 neteler@geog.uni-hannover.de

------------------------------------------------
Contact addresses of (former) G3D Developers:

 Roman Waupotitsch: http://www.geometrixinc.com/aboutus_management.htm
 Bill Brown: brown@gis.uiuc.edu
 Helena Mitasova: helena@gis.uiuc.edu
 Jaro Hofierka: hofierka@geomodel.sk
 Peter Paudits: paudits@gssr.sk
