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
#2175: m.nviz.image: adding transparency_value= changes raster layer stacking
order
----------------------------------------+-----------------------------------
Reporter: hamish | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 6.4.4
Component: Default | Version: svn-trunk
Keywords: m.nviz.image, transparency | Platform: Linux
Cpu: x86-64 |
----------------------------------------+-----------------------------------
Comment(by 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.
#2175: m.nviz.image: adding transparency_value= changes raster layer stacking
order
----------------------------------------+-----------------------------------
Reporter: hamish | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 6.4.4
Component: Default | Version: svn-trunk
Keywords: m.nviz.image, transparency | Platform: Linux
Cpu: x86-64 |
----------------------------------------+-----------------------------------
Comment(by hamish):
Replying to [comment:1 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) ?
#2175: m.nviz.image: adding transparency_value= changes raster layer stacking
order
----------------------------------------+-----------------------------------
Reporter: hamish | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 6.4.4
Component: Default | Version: svn-trunk
Keywords: m.nviz.image, transparency | Platform: Linux
Cpu: x86-64 |
----------------------------------------+-----------------------------------
Comment(by 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?)
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?
#2175: m.nviz.image: adding transparency_value= changes raster layer stacking
order
----------------------------------------+-----------------------------------
Reporter: hamish | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 6.4.4
Component: Default | Version: svn-trunk
Keywords: m.nviz.image, transparency | Platform: Linux
Cpu: x86-64 |
----------------------------------------+-----------------------------------
Comment(by annakrat):
Replying to [comment:5 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).
#2175: m.nviz.image: adding transparency_value= changes raster layer stacking
order
----------------------------------------+-----------------------------------
Reporter: hamish | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 6.4.4
Component: Default | Version: svn-trunk
Keywords: m.nviz.image, transparency | Platform: Linux
Cpu: x86-64 |
----------------------------------------+-----------------------------------
Comment(by hamish):
Replying to [comment:6 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.