NVIZ fails to load vector points without other map

[neteler]

I hoped to load a 2D or a 3D points map into NVIZ (Lidar points). But it crashes:

v.info -t lidar1map3d
nodes=37997
points=38008
lines=0
boundaries=0
centroids=0
areas=0
islands=0
faces=0
kernels=0
primitives=38008
map3d=1

v.out.ascii lidar1map3d |head -3
512743.63|5403547.33|308.68|1
512743.62|5403547.33|308.7|2
512743.61|5403547.33|308.72|3

nviz point=lidar1map3d
WARNING: Adapted sites library used for vector points (module should be
         updated to GRASS 6 vector library).
Site dim: 3
Sites file lidar1map3d loaded.
Error in startup script: can't use non-numeric floating-point value as operand of "*"
    while executing
"expr int($curr * 1)"
    (procedure "Nv_mkFloatScale" line 16)
    invoked from within
"Nv_mkFloatScale $Nv_(HEIGHT_SLIDER) v height $max $min $val update_height 1"
    (procedure "mk_hgt_slider" line 12)
    invoked from within
"mk_hgt_slider $BASE.midf"
    (procedure "mkmainPanel" line 143)
    invoked from within
"mk$name\Panel $path"
    invoked from within
"if [catch {set Nv_($path)}] {
        set file panel_$name.tcl
        set Nv_($path) [mk$name\Panel $path]
        }"
    (procedure "Nv_force_panel" line 8)
    invoked from within
"Nv_force_panel main"
    (procedure "Nv_makeGUI" line 183)
    invoked from within
"Nv_makeGUI .top"
    (file "/home/neteler/grass63/dist.x86_64-unknown-linux-gnu/etc/nviz2.2/scripts/nviz2.2_script" line 1046)

Markus

[hamish]

FWIW, I've been able to plot a vector map in NVIZ which had 1 million faces*, it took some time to render but it worked ok.

• NYC 3D buildings dataset

(but points are treated differently than lines and faces in NVIZ)

see also bug #49: NVIZ displays points (sites) always as thematic

In the past I was able to plot 3D points, but created a new constant surface (so no mapname) from the raster panel and set transparency for it to 100%; a trick I'm sure you know. screenshot:

​http://grass.osgeo.org/wiki/Help_with_3D#Vector_3D_point_data

does it work for you with fewer points or does it work with a surface (constant or raster map)? [what do you mean by "without other map"?]

Error in startup script: can't use non-numeric floating-point value as operand of "*"
    while executing
"expr int($curr * 1)"
    (procedure "Nv_mkFloatScale" line 16)
    invoked from within
"Nv_mkFloatScale   .....

hmmm,

Hamish

[neteler]

Even when applying the patch in #129, the problem persists. The problem is in "widgets.tcl", line 328:

​http://trac.osgeo.org/grass/browser/grass/trunk/visualization/nviz/scripts/widgets.tcl

Markus

[hamish]

Markus:

The problem is in "widgets.tcl", line 328:

trac tip # 1: append #L328 to the end of the URL to automatically go to that line. In the source browser you can click on the line number on the left to get that.

trac tip # 2: (perhaps less useful) link to a source file with

source:grass/trunk/visualization/nviz/scripts/widgets.tcl#L328

see: ​http://trac.osgeo.org/grass/wiki/TracLinks

(I think Paul asked about that help page a while ago)

Hamish

[hamish]

what do you get in the console if you put this line 327:

puts "curr = $curr"

? H

[neteler]

I get:

nviz point=lidar1map3d
Vector file lidar1map3d loaded with 38008 points.
...
curr = 1.0
curr = 1.0
curr = nan
Error in startup script: can't use non-numeric floating-point value as operand of "*"
    while executing
"expr int($curr * 1)"
    (procedure "Nv_mkFloatScale" line 17)
...

[hamish]

working upstream, in nviz/scripts/panel_main.c, before lines 414 and 430, see what $val gets set to by $exag and [lindex $list 0], respectively.

then look at what's coming out of src/exag.c Nget_first_exag_cmd() and Nget_height_cmd().

as you get the nan on the thrird pass, I'd guess look in Nget_height_cmd() first.

Hamish

[neteler]

Unfortunately I don't know how to debug tcl. but you can easily replicate it with Spearfish:

GRASS 6.3.svn (spearfish60):~ > nviz point=archsites
Vector file archsites loaded with 25 points.
curr = 1.0
curr = 1.0
curr = nan
Error in startup script: can't use non-numeric floating-point value as operand of "*"
    while executing
"expr int($curr * 1)"
    (procedure "Nv_mkFloatScale" line 17)
    invoked from within
"Nv_mkFloatScale $Nv_(HEIGHT_SLIDER) v height $max $min $val update_height 1"
...

Markus

[hamish]

In scripts/main_panel.tcl just use puts to see what those variables are:

puts "$foo"

And the same with printf() in src/exag.c.

but you can easily replicate it with Spearfish

('g.region' -d first) for me, nviz loads that ok. But I don't see any points, just a horizontal line when I move the puck: zegag is "-0.0". If I change it to 1.0 I get:

divide by zero
divide by zero
    while executing
"expr $val/floor($val/$res)"
    (procedure "Nv_floatscaleCallback" line 49)
    invoked from within
"Nv_floatscaleCallback .middle.panelarea.panels.main.midf.zexag e 0 update_exag"
    ("uplevel" body line 2)
    invoked from within
"uplevel \#0 $cmd"
    (procedure "Entry::invoke" line 3)
    invoked from within
"Entry::invoke .middle.panelarea.panels.main.midf.zexag.f.entry"
    (command bound to event)

Hamish

[hamish]

g.region -d
nviz points=archsites
# change z-exag from -0.0 to 1.0
divide by zero
    while executing
"expr $val/floor($val/$res)"
    (procedure "Nv_floatscaleCallback" line 49)

AFAICT this is because the value $res is set from is used uninitiated.

"$res" there is -0.0, set a few lines above with:

set res [lindex [$S.scale configure -resolution] 4]

if there is a raster (or vol?) surface given from the command line it calcs $res ok. If not it doesn't. Even if you add in a new raster surface after starting with "nviz points=" it doesn't set $res and then gets quickly stuck in some infinite loop.

So how does $res get set for raster maps? If there is no raster map can a starting value be derived from the current region settings?

Hamish

[cmbarton]

I tried load 3D points without a surface and it worked.

nviz -q load 3D points click the 3D radio button (won't display if not in 3D) points display

Used 1000 3D points randomly generated from Spearfish DEM.

[marisn]

This bug still is NOT fixed. Reproduceable with recent 6.4 release branch. Michael: You are using wrong steps to reproduce this issue. Please use following steps:

v.random -z output=point3d n=100 zmin=1000 zmax=2000 
nviz points=point3d
Vector map <point3d@vectdel> loaded (100 points)
Failed to initialize TTM buffer manager.  Falling back to classic.
Error in startup script: integer value too large to represent
    while executing
"expr int($curr * 1)"
    (procedure "Nv_mkFloatScale" line 16)
    invoked from within
"Nv_mkFloatScale $Nv_(HEIGHT_SLIDER) v height $max $min $val update_height 1"
    (procedure "mk_hgt_slider" line 12)
    invoked from within
"mk_hgt_slider $BASE.midf"
    (procedure "mkmainPanel" line 144)
    invoked from within
"mk$name\Panel $path"
    invoked from within
"if [catch {set Nv_($path)}] {
        set file panel_$name.tcl
        set Nv_($path) [mk$name\Panel $path]
        }"
    (procedure "Nv_force_panel" line 8)
    invoked from within
"Nv_force_panel main"
    (procedure "Nv_makeGUI" line 194)
    invoked from within
"Nv_makeGUI $Nv_(AREA)"
    (file "/home/marisn/soft/grass64_release/dist.i686-pc-linux-gnu/etc/nviz2.2/scripts/nviz2.2_script" line 1052)

[cmbarton]

Fixed r35144 develbranch_6, r35145 release branch, and r35146 trunk

[marisn]

Fix r35144 is just nonportable hack. Still when this place is fixed, nviz will fail in other places. I have created patches which would fix starting nviz without raster base map by taking into accound vector 3D extent, still they need a review (as nviz and ogsf are hairy). IMHO it's safe to fix this issue in GRASS 7, still I have no idea if it's right thing to fix in GRASS 6.4, as it changes one of (internal) OGSF functions.

[marisn]

A better fix for nviz start without raster

[hamish]

if (exag < 0.1) 
    exag = 1.0;

probably that will break lat/lon where x,y units do not match z units.

Try not to make assumptions about what the data is or contains, it is not necessarily describing earth in familiar units. (think raster maps containing chemical concentrations etc. made into a surface by v.surf.rst)

Hamish

ps- it is much easier to review if cosmetic (whitespace) changes are kept to separate patches from bugfixes. signal to noise ratios and all that. thanks

[marisn]

Replying to hamish:

if (exag < 0.1) 
    exag = 1.0;

You are right. It needs to be changed to GRASS_EPSILON test, as previous code read (exag == 0.0) which isn't the best idea for float comparison. Still IMHO some code might break if exag is 0 or less.

ps- it is much easier to review if cosmetic (whitespace) changes are kept to separate patches from bugfixes. signal to noise ratios and all that. thanks

I allways run grass_indent.sh after codding FTW. I will prepeare new patches with ignored whitespace changes (thouse where prepeared in 3 AM).

[marisn]

Recreated trunk patch with: svn diff --diff-cmd diff -x -wuBE

[neteler]

attachment trunk_nviz_start_3d.patch added Recreated trunk patch with: svn diff --diff-cmd diff -x -wuBE

Please consider to apply the patch to G6.5.svn.

[neteler]

Replying to neteler:

attachment trunk_nviz_start_3d.patch added Recreated trunk patch with: svn diff --diff-cmd diff -x -wuBE

Please consider to apply the patch to G6.5.svn.

The attached patch needs to get refreshed.

[wenzeslaus]

I was able to show result of

v.random -z output=point3d n=100 zmin=1000 zmax=2000 

in the wxGUI 3D view (wxNVIZ) in 7.1/trunk (r68301) with point size 30, height 2500, perspective 120, and no zexag without adding any surface. I'm not sure what would be still applicable from the proposed patch (I'm not sure what it does), but I suggest to close this ticket (also, Tcl/Tk NVIZ was dropped for 7.0).