[GRASS-dev] strange NVIZ behavior

GRASS GIS GRASS GIS developer
1

One of my students recently install GRASS 7.0 svn for Windows. Today we tried to display a raster DEM in NVIZ, overlaid by a couple contour lines with values for walking distance from a site (from r.walk). The lines displayed but are floating above the surface at about the level of their contour values (3600 and 7200), in spite of all my attempts to bring them down to earth.

Related to this are a couple other NVIZ issues I’ve seen

  1. making a line width greater than 1 creates a line made up of many many ++++ symbols at the size of the line width
  2. coloring a line only colors the first segment (cat=1) of a multisegment line.

I can do a ticket but perhaps these are already fixed in GRASS 7.1? I don’t use Windows regularly so I’m not up on what works and does not work.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671(SHESC), 480-727-0709 (CSDC)
www: http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton

2

On Tue, Dec 2, 2014 at 7:12 PM, Michael Barton <Michael.Barton@asu.edu>
wrote:

One of my students recently install GRASS 7.0 svn for Windows. Today we
tried to display a raster DEM in NVIZ, overlaid by a couple contour lines
with values for walking distance from a site (from r.walk). The lines
displayed but are floating above the surface at about the level of their
contour values (3600 and 7200), in spite of all my attempts to bring them
down to earth.

I see, these are 3D lines. I will look at it, hopefully during the next
week.

Related to this are a couple other NVIZ issues I’ve seen

1) making a line width greater than 1 creates a line made up of many
many ++++ symbols at the size of the line width

I wonder if this happens only when the line is draped over a surface, then
it's drawn as many lines. I don't think there is a simple way to set line
caps in openGL, so I doubt I could fix it.

2) coloring a line only colors the first segment (cat=1) of a multisegment
line.

does this happens with recent grass? I thought I fixed something similar
to what you describe sometime in summer, but it might be a different
problem. If it happens with recent GRASS, could you send me the data (or
show the problem on nc_spm)?

Anna

I can do a ticket but perhaps these are already fixed in GRASS 7.1? I
don’t use Windows regularly so I’m not up on what works and does not work.

Michael
            ______________________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671(SHESC), 480-727-0709 (CSDC)
www: http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

3

On Tue, Dec 2, 2014 at 7:12 PM, Michael Barton <Michael.Barton@asu.edu>
wrote:

1) making a line width greater than 1 creates a line made up of many many
++++ symbols at the size of the line width

Now, I actually prefer d.to.rast for this, although it might be sometimes
harder to prepare because it is hard to match extents. I'm not sure how
much it was tested on MS Windows or Mac OS.

http://grass.osgeo.org/grass70/manuals/d.to.rast.html

4

Forgot to mention. As I moved and zoomed, the NVIZ scene became slower and slower. Eventually it crashed. With no vector overlaid, it is fast. I wonder if somehow vector lines are rendered as points now, with a lot of points for a long, irregular line like a stream or contour line. Trying to render hundreds or thousands of points is slowing it down??

Anyway, here is the error in case someone can make something of it.

“<NSAutoresizingMaskLayoutConstraint:0x7de6f920 h=-&- v=-&- H:|-(0)-[NSView:0x7de5f880] (Names: ‘|’:FIFinderView:0x7ded1930 )>”,
“<NSAutoresizingMaskLayoutConstraint:0x7db1ba30 h=-&- v=-&- H:[NSView:0x7de5f880]-(0)-| (Names: ‘|’:FIFinderView:0x7ded1930 )>”,
“<NSAutoresizingMaskLayoutConstraint:0x7de6fc20 h=-&- v=-&- H:|-(0)-[FIFinderView:0x7ded1930] (Names: ‘|’:NSNavFinderViewFileBrowser:0x7dedb850 )>”,
“<NSAutoresizingMaskLayoutConstraint:0x7de6fc60 h=-&- v=-&- H:[FIFinderView:0x7ded1930]-(0)-| (Names: ‘|’:NSNavFinderViewFileBrowser:0x7dedb850 )>”,
“<NSAutoresizingMaskLayoutConstraint:0x7dbb88c0 h=–& v=–& H:[NSNavFinderViewFileBrowser:0x7dedb850(585)]>”,
“<NSLayoutConstraint:0x7db2b370 H:|-(0)-[NSView:0x7dbe2770] (Names: ‘|’:NSView:0x7de5f880 )>”,
“<NSLayoutConstraint:0x7dfe70a0 H:[NSView:0x7dbe2770]-(0)-| (Names: ‘|’:NSView:0x7de5f880 )>”,
“<NSLayoutConstraint:0x7db141d0 H:[FILocationPopUp:0x7db0a160’Documents’(207)]>”,
“<NSLayoutConstraint:0x7dfe7ba0 NSView:0x7dbe2770.centerX == FILocationPopUp:0x7db0a160’Documents’.centerX>”,
“<NSLayoutConstraint:0x7dbf17a0 H:[FILocationPopUp:0x7db0a160’Documents’]-(>=10)-[SGTSearchField:0x7dea33b0]>”,
“<NSLayoutConstraint:0x7db1fbd0 H:[SGTSearchField:0x7dea33b0]-(11)-| (Names: ‘|’:NSView:0x7dbe2770 )>”,
“<NSLayoutConstraint:0x7db2e6d0 H:[SGTSearchField:0x7dea33b0(>=218)]>”
)

Will attempt to recover by breaking constraint
<NSLayoutConstraint:0x7db2e6d0 H:[SGTSearchField:0x7dea33b0(>=218)]>

Set the NSUserDefault NSConstraintBasedLayoutVisualizeMutuallyExclusiveConstraints to YES to have -[NSWindow visualizeConstraints:] automatically called when this happens. And/or, break on objc_exception_throw to catch this in the debugger.

Michael

···

On Tue, Dec 2, 2014 at 7:12 PM, Michael Barton <Michael.Barton@asu.edu> wrote:

One of my students recently install GRASS 7.0 svn for Windows. Today we tried to display a raster DEM in NVIZ, overlaid by a couple contour lines with values for walking distance from a site (from r.walk). The lines displayed but are floating above the surface at about the level of their contour values (3600 and 7200), in spite of all my attempts to bring them down to earth.

I see, these are 3D lines. I will look at it, hopefully during the next week.

Related to this are a couple other NVIZ issues I’ve seen

  1. making a line width greater than 1 creates a line made up of many many ++++ symbols at the size of the line width

I wonder if this happens only when the line is draped over a surface, then it’s drawn as many lines. I don’t think there is a simple way to set line caps in openGL, so I doubt I could fix it.

  1. coloring a line only colors the first segment (cat=1) of a multisegment line.

does this happens with recent grass? I thought I fixed something similar to what you describe sometime in summer, but it might be a different problem. If it happens with recent GRASS, could you send me the data (or show the problem on nc_spm)?

Anna

I can do a ticket but perhaps these are already fixed in GRASS 7.1? I don’t use Windows regularly so I’m not up on what works and does not work.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671(SHESC), 480-727-0709 (CSDC)
www: http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

5

Anna,

I just tested on my Mac with GRASS 7.1 r61575.

The color issue seems OK. All of a vector line is the same, selected color rather than just cat=1.

The other issues are still there though:

  1. lines with width>1 look weird, almost as if they are composed of individual characters instead of lines. I’ve attached an image with line width set to 20.
  2. I did an r.walk cost map and created contours at intervals of 3600 seconds (=1hr). The contours float far above the landscape, no inconsistent with a height = the contour value. I’ve attached images of NVIZ 3D and regular 2D for the same scene.

Michael

lines_2D.jpg603×541 55.3 KB
nviz_lines_width.jpg798×546 100 KB

···

On Tue, Dec 2, 2014 at 7:12 PM, Michael Barton <Michael.Barton@asu.edu> wrote:

One of my students recently install GRASS 7.0 svn for Windows. Today we tried to display a raster DEM in NVIZ, overlaid by a couple contour lines with values for walking distance from a site (from r.walk). The lines displayed but are floating above the surface at about the level of their contour values (3600 and 7200), in spite of all my attempts to bring them down to earth.

I see, these are 3D lines. I will look at it, hopefully during the next week.

Related to this are a couple other NVIZ issues I’ve seen

  1. making a line width greater than 1 creates a line made up of many many ++++ symbols at the size of the line width

I wonder if this happens only when the line is draped over a surface, then it’s drawn as many lines. I don’t think there is a simple way to set line caps in openGL, so I doubt I could fix it.

  1. coloring a line only colors the first segment (cat=1) of a multisegment line.

does this happens with recent grass? I thought I fixed something similar to what you describe sometime in summer, but it might be a different problem. If it happens with recent GRASS, could you send me the data (or show the problem on nc_spm)?

Anna

I can do a ticket but perhaps these are already fixed in GRASS 7.1? I don’t use Windows regularly so I’m not up on what works and does not work.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671(SHESC), 480-727-0709 (CSDC)
www: http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev