m.nviz.image: adding transparency_value= changes raster layer stacking order

[hamish]

Hi,

adding the m.nviz.image transparency_value= option changes the layer stacking order, making constant surface overlays not-very-useful. Tested in trunk and devbr6, & I assume relbr64 has the same trouble.

North Carolina example:

g.region rast=elevation

m.nviz.image \
  output=test_img \
  size=650,600 \
  height=2000 \
  zexag=7 \
  perspective=30 \
  position=0.24,0.16 \
  elevation_map=elevation \
  color_map=elevation \
  elevation_value=100 \
  color=red \
  resolution_fine=1,10 \
  resolution_coarse=100,1000 \
  mode=fine,fine \
  style=surface,surface \
  wire_color=grey,grey \
  shading=gouraud,gouraud \
#  transparency_value=0,50

Attached to the ticket are screenshots with and without the transparency option.

thanks, Hamish

[hamish]

constant surface without transparency

[hamish]

constant surface with transparency

[annakrat]

This is a duplicate of #2117. You get the same effect in TclTk Nviz when you click on Draw button instead of Draw current. I haven't looked into this yet what's the difference between those two buttons.

[hamish]

Replying to annakrat:

This is a duplicate of #2117. You get the same effect in TclTk Nviz when you click on Draw button instead of Draw current. I haven't looked into this yet what's the difference between those two buttons.

thanks. in tcl/tk nviz the 'Draw' button at the top re-renders the entire scene, i.e. all layers of all types. The 'Draw Current' button in the Raster Surfaces panel just renders the current raster layer (from the drop down list). So to produce the effect there I usually select the transparent planar surface, then click the main Clear and Draw buttons, then click the lower 'Draw current' button to overlay any planar surfaces, then take a screenshot.

There seems to be a slight difference in behaviour between what Richard reported for wx #2117 and what happens from the command line: In #2117 setting the transparency to 0 (i.e. opaque) had the rendering order go back to normal. On the command line that doesn't work, if you use the transparency_value= option at all (even with 0,0) the rendering order gets mixed up. In order to get a cutting plane effect from a constant surface you need to leave off the transparency_value= option altogether. I'd note that the tcl/tk NVIZ settings allow unset,0-255, with the default as unset. Perhaps unset != 0, and some test needs to be changed from if(unset) to if(unset

value == 0) ?

Hamish

[hamish]

ps- was m.nviz.script ever updated for wxNVIZ, or does it still produce tcl/tk code as its output? (i.e. should we disable it from the Makefile module list in trunk?)

[hamish]

btw, while we're here, a couple of compiler warnings in trunk/misc/m.nviz.image/volume.c:

volume.c: In function 'load_rasters3d':
volume.c:40: warning: assignment discards qualifiers from pointer target type

volume.c: In function 'add_isosurfs':
volume.c:80: warning: unused parameter 'data'

volume.c: In function 'add_slices':
volume.c:243: warning: unused parameter 'data'

[hamish]

Some progress, and a workaround:

sort_surfs_max() in lib/nviz/draw.c seems working as expected and to return the same result both with and without the transparency_value= option.

and yet, bypassing the sort with the following patch seems to fix(bypass) the problem:

Index: lib/nviz/draw.c
===================================================================
--- lib/nviz/draw.c	(revision 58790)
+++ lib/nviz/draw.c	(working copy)
@@ -107,7 +107,8 @@
 	}
 
 	maxvals[indices[i]] = max + 1;
-	id_sort[i] = surf[indices[i]];
+//	id_sort[i] = surf[indices[i]];
+	id_sort[i] = surf[i];
     }
 
     return 1;

The sort returns layers ordered lowest to highest maximum value, and thus for a planar surface cutting through a DEM the DEM will always be higher, so the constant surface will always be rendered first, since it has a lower maximum (& so will be sorted to first in the list of surfaces to render).

proof:

by changing the constant surface from elevation_value=100 to 160 (slightly more than the max of NC's elevation map), it renders correctly. By lowering it slightly to 150 (just below elevation's max) the semi-transparent constant surface gets overwritten by the DEM.

The question then becomes do we try and come up with a better sorting strategy or render in the order the layers were added, and why does it work correctly when transparency_value= is left unset even though the layers are sorted with the DEM rendering last? Is there a second bug which was masking the first?

cheers, Hamish

[hamish]

by short-circuiting sort_surfs_max() in lib/nviz/draw.c it renders as expected

[annakrat]

Replying to hamish:

Some progress, and a workaround:

The question then becomes do we try and come up with a better sorting strategy or render in the order the layers were added, and why does it work correctly when transparency_value= is left unset even though the layers are sorted with the DEM rendering last? Is there a second bug which was masking the first?

It works in wxNVIZ, too, with some limitations. It depends on the layer order (as you are explaining) so if you set transparency for the last loaded layer, it works, otherwise you get weird results. It's better than before (we can achieve what we need) but it's even more confusing for users (now it would be working only sometimes instead of not at all). Could we have the transparent layers as the last ones? Perhaps using GS_get_att we can identify them?

The transparency_value=0 causes setting the transparency attribute. We can probably just add another condition (to test specifically 0) to m.nviz.image/surface.c (line 145).

[hamish]

Replying to annakrat:

Could we have the transparent layers as the last ones? Perhaps using GS_get_att we can identify them?

Hi,

it's not specifically transparent surfaces, or even constant surfaces that cut through.

for example instead of null areas (which leave jagged triangles at their edge) to mask off below sea level areas you can have a constant opaque white surface at 0.0 to do the same, while the real DEM surface plunges below. with that trick you get a nice crisp edge at the water's edge.

you might also want a dynamic surface which breaks but does not exceed the max elevation of the main DEM, transparent or not. (e.g. a raster building [are semi-transparent 3D vector surfaces possible?])

I guess the question is if allowing a user definable layer order is the way around all this?

I'm also having trouble with sub-integer constant elevation values, even after changing TYPE_INTEGER to TYPE_DOUBLE in m.nviz.image/args.c for those options which are later parsed with atof(), so theoretically should accept floating point values. e.g. 11.0-11.4 see reasonable but 11.5 and 11.7 drop down to near 11.0 again. it's all a bit weird but probably a matter for another ticket.

Hamish