Opened 11 years ago
Last modified 8 years ago
#2175 new defect
m.nviz.image: adding transparency_value= changes raster layer stacking order
Reported by: | hamish | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | 6.4.6 |
Component: | Default | Version: | svn-trunk |
Keywords: | m.nviz.image, transparency | Cc: | |
CPU: | x86-64 | Platform: | Linux |
Description
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
Attachments (3)
Change History (11)
by , 11 years ago
Attachment: | no_transp.jpg added |
---|
follow-up: 2 comment:1 by , 11 years ago
comment:2 by , 11 years ago
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.
value == 0) ? |
Hamish
comment:3 by , 11 years ago
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?)
comment:4 by , 11 years ago
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'
follow-up: 6 comment:5 by , 11 years ago
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
by , 11 years ago
Attachment: | unsorted_surfs.jpg added |
---|
by short-circuiting sort_surfs_max() in lib/nviz/draw.c it renders as expected
follow-up: 7 comment:6 by , 11 years ago
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).
comment:7 by , 11 years ago
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
comment:8 by , 8 years ago
Milestone: | 6.4.4 → 6.4.6 |
---|
constant surface without transparency