m.nviz.image doesn't produce any output

[guano]

When trying to create some images with m.nviz.image, but all I get as output is a 11 byte ppm...

All I get is an unreadable ppm with 11 bytes. With format=tif, I get an error creating the file (TIFFScanlineSize64: Computed scanline size is zero.).

Opening the ppm file into a text editor, I see that all that was written was the header, and that the image size was 0,0:

P6 0 0 255

navigating trough the code, I see that m.nviz.image calls GS_write_ppm to write the file, which is in lib/ogsf/gsd_img_ppm.c:

int GS_write_ppm(const char *name) {

unsigned int x; int y; unsigned int xsize, ysize; FILE *fp; unsigned char *pixbuf;

gsd_getimage(&pixbuf, &xsize, &ysize);

if (NULL == (fp = fopen(name, "w"))) {

G_warning(_("Unable to open file <%s> for writing"), name); return (1);

}

fprintf(fp, "P6\n%d %d\n255\n", xsize, ysize);

for (y = ysize - 1; y >= 0; y--) {

for (x = 0; x < xsize; x++) {

unsigned char r = pixbuf[(y * xsize + x) * 4 + 0]; unsigned char g = pixbuf[(y * xsize + x) * 4 + 1]; unsigned char b = pixbuf[(y * xsize + x) * 4 + 2];

fputc((int)r, fp); fputc((int)g, fp); fputc((int)b, fp);

}

} G_free(pixbuf); fclose(fp);

return (0);

}

GS_write_ppm calls gsd_getimage to get the actual image data and size.

So it seems to me that gsd_getimage is not getting the image?

[hcho]

Do you have sample data so we can reproduce it? When I worked on this module recently, it worked fine.

[guano]

Sure, I put in on Dropbox, is that ok?

DEM ​https://www.dropbox.com/s/7dgc0v1ilqi3c2l/sample_dem.tif?dl=0

Screen grab of the setup I did manually in 3D view ​https://www.dropbox.com/s/e20r8v9127k72mg/screen_nviz.png?dl=0

command produced by the GUI:

m.nviz.image elevation_map=garopaba_SOLO_bicubic@garopaba_22J -a mode=fine resolution_fine=1 color_map=garopaba_SOLO_bicubic@garopaba_22J \
position=0.50,0.50 height=1719 perspective=28 twist=-95 zexag=1.000000 focus=434,503,30 \
light_position=0.68,-0.68,0.80 light_brightness=80 light_ambient=20 light_color=255:255:255 \
output=nviz_output format=ppm size=500,500 

[hcho]

# assign the projection defined in the sample TIF
g.proj -c epsg=32723

# import the sample TIF
r.in.gdal input=sample_dem.tif output=garopaba_SOLO_bicubic

# change the region
g.region rast=garopaba_SOLO_bicubic

# try your command above
m.nviz.image elevation_map=garopaba_SOLO_bicubic -a mode=fine resolution_fine=1 color_map=garopaba_SOLO_bicubic position=0.50,0.50 height=1719 perspective=28 twist=-95 zexag=1.000000 focus=434,503,30 light_position=0.68,-0.68,0.80 light_brightness=80 light_ambient=20 light_color=255:255:255 output=nviz_output format=ppm size=500,500

produces the attached image (png screenshot because of the size of the original ppm).

Have you tried the latest version of GRASS?

[guano]

I'm running 7.4.0 on MacOS compiled with Homebrew. I tried in a Windows machine (7.4.0 as well) and the output (or lack of one) was the same. Not sure where the problem might be.

[hcho]

Is the output in the attached screenshot expected result BTW? I assumed that your sample TIF is garopaba_SOLO_bicubic in my testing.

[guano]

Yes, it is the expected result.

I just upgraded to 7.4.1 (via homebrew) and the issue persists.

[hcho]

Not sure what's happening. Please make sure that the projection of your mapset is EPSG:32723.

> g.proj -p
-PROJ_INFO-------------------------------------------------
name       : WGS 84 / UTM zone 23S
datum      : wgs84
ellps      : wgs84
proj       : utm
zone       : 23
south      : defined
no_defs    : defined
-PROJ_EPSG-------------------------------------------------
epsg       : 32723
-PROJ_UNITS------------------------------------------------
unit       : meter
units      : meters
meters     : 1

and set the region correctly to the DEM.

[hcho]

Maybe, your OpenGL settings? Please try to add some debug messages in gsd_getimage in lib/ogsf/gsd_prim.c and see what glGetIntegerv returns. Add the following in line 909.

fprintf(stderr, "%d %d, %d %d\n", r, l, t, b);

[hcho]

Or better

fprintf(stderr, "%d %d %d %d\n", tmp[0], tmp[1], tmp[2], tmp[3]);

[guano]

Here is the output with the debug msg: (projection is ok and region as well, I tried with other Location/Mapsets and the error is persistent)

Loading raster map <gsb@garopaba_22J>...
 100%
0 0 0 0
m.nviz.image complete. File <nviz_output.ppm> created.

[neteler]

Posted on behalf of Michael Barton:

I don't know if m.nviz.image depends on wxPython or not. But if it does, you might need to check which version you are using and whether you are compiling 32 or 64 bit.

Also, I've got new binaries posted with updated code you might want to try. They are on the GRASS for Mac web site [grassmac.wikidot.com]

[guano]

Thans Michael, but I got the same results with your binaries

[hcho]

I think that this issue is platform dependent. glGetIntergerv(GL_VIEWPORT, tmp) returns an empty viewport, which should have been defined correctly in Nviz_create_render_window (lib/nviz/render.c). This function has three defined for X11, Aqua, and Windows. I cannot reproduce this issue on X11, but the issue is reported on Aqua and Windows. For Aqua, this routine calls aglCreatePBuffer to create a new rendering area using specified width and height. Maybe, we should check what value this routine returns.

​https://developer.apple.com/documentation/agl/1392693-aglcreatepbuffer

If you can compile yourself, maybe you can try this. In Nviz_create_render_window in lib/nviz/render.c, line 145 (trunk) or find aglCreatePBuffer and print its return value with width and height just in case.

if (aglCreatePBuffer(width, height, GL_TEXTURE_2D, GL_RGBA, 0, &(rwin->windo    wId)) == GL_FALSE)
    fprintf(stderr, "aglCreatePBuffer failed: %d %d %d\n", width, height, aglGetError());

[guano]

Ok, I added the lines you suggested and compiled it again.

the output is this one:

aglCreatePBuffer failed: 500 500 10005

[hcho]

Hmm... 10005 is AGL_BAD_DRAWABLE: (# exit 10005 #); (* invalid drawable specified *). ​https://developer.apple.com/documentation/agl/agl_bad_drawable

Maybe, I'm wrong, but GL_TEXTURE_2D is for textures whose dimensions are a power of two. Whatever that means, width=500 and height=500 are not a power of two. Please try again after replacing GL_TEXTURE_2D with GL_TEXTURE_RECTANGLE_EXT.

[hcho]

Or in your m.nviz.image command, change size=500,500 to size=512,512.

[hcho]

If you can, please try both (GL_TEXTURE_RECTANGLE_EXT and size=512,512). GL_TEXTURE_2D and GL_TEXTURE_RECTANGLE_EXT use different coordinates, so we need to know if the rest of code works with which type of texture. Thanks.

[hellik]

Replying to hcho:

I think that this issue is platform dependent.

what I get in winGRASS

GRASS version: 7.5.svn                                                          
GRASS SVN revision: r72944                                                      
Build date: 2018-07-03                                                          
Build platform: x86_64-w64-mingw32                                              
GDAL: 2.2.4                                                                     
PROJ.4: 4.9.3                                                                   
GEOS: 3.5.0                                                                     
SQLite: 3.17.0                                                                  
Python: 2.7.14                                                                  
wxPython: 2.8.12.1                                                              
Platform: Windows-10-10.0.17134 (OSGeo4W)    

{{{C:\>m.nviz.image elevation_map=elevation output=D:\temp\mnviz\test\elev perspective=15 Loading raster map <elevation@PERMANENT>...

100%

Loading raster map <elevation@PERMANENT>...

100%

Translating colors from raster map <elevation@PERMANENT>...

100%

WARNING: Unable to open file <D:\temp\mnviz\test\elev.ppm> for writing m.nviz.image complete. File <D:\temp\mnviz\test\elev.ppm> created. }}}

C:\>m.nviz.image elevation_map=elevation output=D:\temp\mnviz\test\elev perspective=15 format=tif
Loading raster map <elevation@PERMANENT>...
 100%
Loading raster map <elevation@PERMANENT>...
 100%
Translating colors from raster map <elevation@PERMANENT>...
 100%
TIFFOpen: D:\temp\mnviz\test\elev.tif: No such file or directory.
WARNING: Unable to open file <D:\temp\mnviz\test\elev.tif> for writing
m.nviz.image complete. File <D:\temp\mnviz\test\elev.tif> created.

will attach the output of set DEBUG=3

[hellik]

winGRASS DEBUG=3 ppm

[hellik]

winGRASS DEBUG=3 tif

[hellik]

Replying to hellik:

Replying to hcho:

I think that this issue is platform dependent.

what I get in winGRASS

some other (maybe) related tickets:

#2114 #2175 #2175 #2998 #3041

[hcho]

Hmm...

TIFFOpen: D:\temp\mnviz\test\elev.tif: No such file or directory.

TIFFOpen cannot create a new file? Permission or that folder doesn't exist?

[hcho]

Please try r72948.

[hellik]

Replying to hcho:

Hmm...

TIFFOpen: D:\temp\mnviz\test\elev.tif: No such file or directory.

TIFFOpen cannot create a new file? Permission or that folder doesn't exist?

I think this issue is different from the original one. He was able to write out an output file with just the header. I think you'll be able to see the original issue once you fix this TIFFOpen issue.

there is no permission issue as other winGRASS modules are able to write to this folder.

[hcho]

Interesting... What is errno after fopen in lib/ogsf/gsd_img_ppm.c?

In GS_write_zoom,

#include <errno.h>

...

if (NULL == (fp = fopen(name, "w"))) {
   fprintf(stderr, "errno %d\n", errno);
   G_warning(...);
   return (1);
}

[cmbarton]

Replying to hcho:

Or in your m.nviz.image command, change size=500,500 to size=512,512.

I just did this and it gives the same result, an image file with header but no content. Same output message too.

[hcho]

Replying to cmbarton:

Replying to hcho:

Or in your m.nviz.image command, change size=500,500 to size=512,512.

I just did this and it gives the same result, an image file with header but no content. Same output message too.

What about changing GL_TEXTURE_2D to GL_TEXTURE_RECTANGLE_EXT in lib/nviz/render.c? You're on MacOS, right?

[cmbarton]

If I do that, I'll need to recompile. I'm at home today due to the holiday. I could try this once I'm back in my office.

[guano]

I made the changes to render.c:

aglCreatePBuffer(width, height, GL_TEXTURE_RECTANGLE_EXT, GL_RGBA, 0, &(rwin->windowId));
if (aglCreatePBuffer(width, height, GL_TEXTURE_RECTANGLE_EXT, GL_RGBA, 0, &(rwin->windowId)) == GL_FALSE)
fprintf(stderr, "aglCreatePBuffer failed: %d %d %d\n", width, height, aglGetError());

and tried to run with size=500,500 and size=512,512

the result is the same, as well as the error message:

aglCreatePBuffer failed: 500 500 10005

[hellik]

Replying to hcho:

Please try r72948.

tested with

GRASS version: 7.5.svn                                                          
GRASS SVN revision: r72959                                                      
Build date: 2018-07-06                                                          
Build platform: x86_64-w64-mingw32                                              
GDAL: 2.2.4                                                                     
PROJ.4: 4.9.3                                                                   
GEOS: 3.5.0                                                                     
SQLite: 3.17.0                                                                  
Python: 2.7.14                                                                  
wxPython: 2.8.12.1                                                              
Platform: Windows-10-10.0.17134 (OSGeo4W)

ppm and tif can't be opened.

DEBUG=3 output of the cmd, tif and ppm attached

[hcho]

Replying to hellik:

Replying to hcho:

Please try r72948.

tested with

GRASS version: 7.5.svn                                                          
GRASS SVN revision: r72959                                                      
Build date: 2018-07-06                                                          
Build platform: x86_64-w64-mingw32                                              
GDAL: 2.2.4                                                                     
PROJ.4: 4.9.3                                                                   
GEOS: 3.5.0                                                                     
SQLite: 3.17.0                                                                  
Python: 2.7.14                                                                  
wxPython: 2.8.12.1                                                              
Platform: Windows-10-10.0.17134 (OSGeo4W)

ppm and tif can't be opened.

DEBUG=3 output of the cmd, tif and ppm attached

Hmm... The size of the ppm is 6618224*0. OK, glViewport never gets called unless you resize the viewport. I think omitting glViewport is implementation dependent. Please try the attached patch (lib/nviz/render.c).

[hcho]

Test patch for lib/nviz/render.c (call glViewport)

[hellik]

Replying to hcho:

Replying to hellik:

Replying to hcho:

Please try r72948.

tested with

GRASS version: 7.5.svn                                                          
GRASS SVN revision: r72959                                                      
Build date: 2018-07-06                                                          
Build platform: x86_64-w64-mingw32                                              
GDAL: 2.2.4                                                                     
PROJ.4: 4.9.3                                                                   
GEOS: 3.5.0                                                                     
SQLite: 3.17.0                                                                  
Python: 2.7.14                                                                  
wxPython: 2.8.12.1                                                              
Platform: Windows-10-10.0.17134 (OSGeo4W)

ppm and tif can't be opened.

DEBUG=3 output of the cmd, tif and ppm attached

Hmm... The size of the ppm is 6618224*0. OK, glViewport never gets called unless you resize the viewport. I think omitting glViewport is implementation dependent. Please try the attached patch (lib/nviz/render.c).

No chance to build winGRASS here in the next days; submitting to trunk?

[cmbarton]

I'd like to test on the Mac if I can get trunk to compile without errors. I'll try again with a fresh checkout when I'm back at my office computers this coming week.

[hcho]

I didn't commit it to trunk because ideally I would have to add width and height to render_window struct if calling glViewport helps. I believe this is it, but I wanted to be sure. I don't think that all GPU vendors and drivers assume the full size without explicitly calling this function.

[hcho]

Just committed it to r72966 because glViewport (from GS_set_viewport) needs to be called anyway. ​https://gamedev.stackexchange.com/questions/147522/what-is-glviewport-for-and-why-it-is-not-necessary-sometimes

Please test r72966 on Windows and MacOS. Linux works fine.

[cmbarton]

This breaks nviz compiling on the Mac (see #3603)

[hcho]

Replying to cmbarton:

This breaks nviz compiling on the Mac (see #3603)

Please copy the latest include/nviz.h to your distribution/include/grass/nviz.h

[hcho]

Replying to hcho:

Replying to cmbarton:

This breaks nviz compiling on the Mac (see #3603)

Please copy the latest include/nviz.h to your distribution/include/grass/nviz.h

Or simply rebuild from scratch.

[cmbarton]

copy from where? I just did a complete checkout of trunk from the svn.

[hcho]

Replying to cmbarton:

copy from where? I just did a complete checkout of trunk from the svn.

from trunk/include/nviz.h (from trunk) to dist.x86_64-pc-linux-gnu/include/grass/nviz.h (in my case, this distribution copy is NOT part of the trunk repository). The easiest way is make clean; make.

[cmbarton]

It was a different, weird problem that is now resolved. Compiles now. I just tested and it makes a solid black image.

[hcho]

Replying to cmbarton:

It was a different, weird problem that is now resolved. Compiles now. I just tested and it makes a solid black image.

Please attach the output file. Also, were you getting the same 0*0 image before my patch (original issue)?

I think a solid black image of the correct size is better than a 0*0 image ;-).

[hcho]

You can remove my patch by commenting out line 221 GS_set_viewport from lib/nviz/render.c and try the original issue. Because of my another patch, you should get a warning "Unable to get image of current GL screen".

[cmbarton]

test of m.nviz.image on Mac

[cmbarton]

I attached the file as requested. Also, here is the command I used:

m.nviz.image elevation_map=elevation@PERMANENT color_map=elevation@PERMANENT resolution_fine=1 height=800 perspective=20 output=elevation format=tif size=640,480

I'll comment out line 221, recompile and let you know.

[hcho]

Replying to cmbarton:

I attached the file as requested. Also, here is the command I used:

m.nviz.image elevation_map=elevation@PERMANENT color_map=elevation@PERMANENT resolution_fine=1 height=800 perspective=20 output=elevation format=tif size=640,480

I'll comment out line 221, recompile and let you know.

FYI, ppm would be better because it directly prints out size in plaintext. Thanks for testing.

[cmbarton]

Without line 221, it prints out an empty file, as before.

[hcho]

Replying to cmbarton:

Without line 221, it prints out an empty file, as before.

Please attach that file as well. By empty, do you mean 0*0? or blank 640*480?

[cmbarton]

Mac test with line 221 commented out.

[hcho]

OK, at least, the viewport issue is fixed with line 221. BTW, have you tried g.region rast=elevation? Not sure if that'll do anything here, but...

Maybe, MacOS requires additional OpenGL settings or something...

[cmbarton]

Mac test with line 221 of lib/nviz/render.c enabled. File is all black

[cmbarton]

I've attached the output in ppm form after re-enabling line 221. I reset g.region (g.region rast=elevation) and it is the same.

[hcho]

Replying to cmbarton:

I've attached the output in ppm form after re-enabling line 221. I reset g.region (g.region rast=elevation) and it is the same.

Hmm.. Please enable line 221 (this line works as expected. reporting the correct viewport size).

Test 1: change size=640,480 to size=512,512 (power of 2 for GL_TEXTURE_2D in line 148 in lib/nviz/render.c).

Test 2: lib/nviz/render.c line 148. change GL_TEXTURE_2D to GL_TEXTURE_RECTANGLE_EXT (to support non-power of 2 size)

I know the original reporter already tried these, but without line 221.

[cmbarton]

I will try this. However, we know that nviz, using OpenGL works fine and that the nviz interface can save an OpenGL image to a file. Can't the code for m.nviz.image just be lifted from the main nviz code?

[cmbarton]

I tried changing GL_TEXTURE_2D to GL_TEXTURE_RECTANGLE_EXT on line 148. No change in output. A black square.

[hcho]

Replying to cmbarton:

I will try this. However, we know that nviz, using OpenGL works fine and that the nviz interface can save an OpenGL image to a file. Can't the code for m.nviz.image just be lifted from the main nviz code?

Yeah.. maybe, it's better to rewrite m.nviz.image in Python because nviz uses wx.glcanvas internally. Not sure about that.

[hcho]

One thing I found interesting is that in lib/nviz/draw.c, Nviz_draw_all() calls Nviz_draw_all_(surf, vect, site, vol) after switching the draw buffer to GL_BACK. Nviz_draw_all_(vect, site, vol) again switch the draw buffer to GL_FRONT_AND_BACK, draw stuff, and switch back to GL_BACK, but Nviz_draw_all_surf doesn't do that and seems to draw in the GL_BACK buffer that Nviz_draw_all initially set.

Now, since we're still in the GL_BACK buffer (because the other Nviz_draw_all_* switch back to the GL_BACK buffer at the end), GS_done_draw() in Nviz_draw_all tries to swap the front and back buffers using a user-defined function, which is a void function in m.nviz.image. So the back buffer with an image is never swapped with the front buffer, but gsd_getimage() reads the front buffer anyway to write the output, which is blank.

How does it work in Linux? I don't know. I tried to draw to GL_FRONT, GL_BACK, GL_FRONT_AND_BACK in Nviz_draw_all_surf, they all worked! I was able to produce a white blank image by drawing to GL_NONE though...

Since I cannot reproduce this issue myself, someone may want to try this.

• Draw the surface on the front buffer. lib/nviz/draw.c line 223. Change GSD_BACK to GSD_FRONT.

OR (NOT both at the same time)

• Read the back buffer. lib/ogsf/gsd_prim.c line 921. Change GSD_FRONT to GSD_BACK.

[cmbarton]

Replying to hcho:

Replying to cmbarton:

I will try this. However, we know that nviz, using OpenGL works fine and that the nviz interface can save an OpenGL image to a file. Can't the code for m.nviz.image just be lifted from the main nviz code?

Yeah.. maybe, it's better to rewrite m.nviz.image in Python because nviz uses wx.glcanvas internally. Not sure about that.

Maybe a good idea. Then there would not be as much separate software maintenance needed to keep the interactive and command line versions functional and in sync across multiple platforms

[hcho]

Only Windows defines double buffering; that's why Linux works without buffer swapping because it has only one buffer. BUT, glGetError() still returns GL_INVALID_OPERATION according to ​https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glReadBuffer.xhtml. Probably, that's why some Linux drivers and MacOS don't work at all.

Windows is also broken because nviz draws to the back buffer, but it reads from the front buffer without buffer swapping.

[hcho]

Please try these patches. They implement buffer swapping. I tested on Linux and got no errors.

> m.nviz.image elevation_map=elevation@PERMANENT color_map=elevation@PERMANENT resolution_fine=1 height=800 perspective=20 output=elevation format=tif size=640,480
Loading raster map <elevation@PERMANENT>...
 100%
Loading raster map <elevation@PERMANENT>...
 100%
Translating colors from raster map <elevation@PERMANENT>...
 100%
GL Error 1: 0  <------------------------------------------ before glReadBuffer
GL Error 2: 0  <------------------------------------------ after  glReadBuffer
m.nviz.image complete. File <elevation.tif> created.

[hcho]

Double buffering for Linux and MacOS

[hcho]

Buffer swapping for Linux, MacOS and Windows

[cmbarton]

This breaks compiling /lib/ogsf in Mac OSX. This in turn breaks /lib/nviz. Errors are attached.

[cmbarton]

r72973 breaks Mac compiling. /lib/ogsf error

[cmbarton]

r72973 breaks Mac compiling. /lib/nviz error

[hcho]

Renamed bool to shade in r72974. Please try again.

[hellik]

Replying to hcho:

Only Windows defines double buffering; that's why Linux works without buffer swapping because it has only one buffer. BUT, glGetError() still returns GL_INVALID_OPERATION according to ​https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glReadBuffer.xhtml. Probably, that's why some Linux drivers and MacOS don't work at all.

Windows is also broken because nviz draws to the back buffer, but it reads from the front buffer without buffer swapping.

tested with

GRASS version: 7.5.svn                                                          
GRASS SVN revision: r72969                                                      
Build date: 2018-07-10                                                          
Build platform: x86_64-w64-mingw32                                              
GDAL: 2.2.4                                                                     
PROJ.4: 4.9.3                                                                   
GEOS: 3.5.0                                                                     
SQLite: 3.17.0                                                                  
Python: 2.7.14                                                                  
wxPython: 2.8.12.1                                                              
Platform: Windows-10-10.0.17134 (OSGeo4W) 

C:\>m.nviz.image elevation_map=elevation output=D:\temp\mnviz\elev perspective=15
Loading raster map <elevation@PERMANENT>...
 100%
Loading raster map <elevation@PERMANENT>...
 100%
Translating colors from raster map <elevation@PERMANENT>...
 100%
WARNING: Unable to get image of current GL screen
ERROR: Failed to write image

C:\>m.nviz.image elevation_map=elevation output=D:\temp\mnviz\elev perspective=15 format=tif
Loading raster map <elevation@PERMANENT>...
 100%
Loading raster map <elevation@PERMANENT>...
 100%
Translating colors from raster map <elevation@PERMANENT>...
 100%
WARNING: Unable to get image of current GL screen
ERROR: Failed to write image

[cmbarton]

Just tested this morning with the Mac r72978. It compiles now but still creates a solid black output, as before. No errors. Even with --verbose, this is all I get for messages:

Loading raster map <elevation@PERMANENT>...

100%

Loading raster map <elevation@PERMANENT>...

100%

Translating colors from raster map <elevation@PERMANENT>...

100%

Vertical exaggeration not given, using calculated value 10 m.nviz.image complete. File <elevation.ppm> created. [1]+ Done(1) m.nviz.image

[hcho]

Replying to hellik:

Replying to hcho:

Only Windows defines double buffering; that's why Linux works without buffer swapping because it has only one buffer. BUT, glGetError() still returns GL_INVALID_OPERATION according to ​https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glReadBuffer.xhtml. Probably, that's why some Linux drivers and MacOS don't work at all.

Windows is also broken because nviz draws to the back buffer, but it reads from the front buffer without buffer swapping.

tested with

GRASS version: 7.5.svn                                                          
GRASS SVN revision: r72969                                                      
Build date: 2018-07-10                                                          
Build platform: x86_64-w64-mingw32                                              
GDAL: 2.2.4                                                                     
PROJ.4: 4.9.3                                                                   
GEOS: 3.5.0                                                                     
SQLite: 3.17.0                                                                  
Python: 2.7.14                                                                  
wxPython: 2.8.12.1                                                              
Platform: Windows-10-10.0.17134 (OSGeo4W) 

r72974+ has double buffering. Earlier version was incomplete without buffer swapping for Windows. Please try r72974+ later.

[hellik]

Replying to hcho:

Replying to hellik:

Replying to hcho:

Only Windows defines double buffering; that's why Linux works without buffer swapping because it has only one buffer. BUT, glGetError() still returns GL_INVALID_OPERATION according to ​https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glReadBuffer.xhtml. Probably, that's why some Linux drivers and MacOS don't work at all.

Windows is also broken because nviz draws to the back buffer, but it reads from the front buffer without buffer swapping.

tested with

GRASS version: 7.5.svn                                                          
GRASS SVN revision: r72969                                                      
Build date: 2018-07-10                                                          
Build platform: x86_64-w64-mingw32                                              
GDAL: 2.2.4                                                                     
PROJ.4: 4.9.3                                                                   
GEOS: 3.5.0                                                                     
SQLite: 3.17.0                                                                  
Python: 2.7.14                                                                  
wxPython: 2.8.12.1                                                              
Platform: Windows-10-10.0.17134 (OSGeo4W) 

r72974+ has double buffering. Earlier version was incomplete without buffer swapping for Windows. Please try r72974+ later.

winGRASS building is broken:

see ​error.log

GRASS GIS 7.5.svn r72978 compilation log
--------------------------------------------------
Started compilation: Wed Jul 11 15:02:16     2018
--
Errors in:
/c/msys64/usr/src/grass_trunk/lib/ogsf
/c/msys64/usr/src/grass_trunk/lib/nviz
/c/msys64/usr/src/grass_trunk/misc/m.nviz.image
--
In case of errors please change into the directory with error and run 'make'.
If you get multiple errors, you need to deal with them in the order they
appear in the error log. If you get an error building a library, you will
also get errors from anything which uses the library.
--
Finished compilation: Wed Jul 11 15:35:12     2018

and ​compiling log

[hcho]

Replying to hellik:

Replying to hcho:

Replying to hellik:

Replying to hcho:

Only Windows defines double buffering; that's why Linux works without buffer swapping because it has only one buffer. BUT, glGetError() still returns GL_INVALID_OPERATION according to ​https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glReadBuffer.xhtml. Probably, that's why some Linux drivers and MacOS don't work at all.

Windows is also broken because nviz draws to the back buffer, but it reads from the front buffer without buffer swapping.

tested with

GRASS version: 7.5.svn                                                          
GRASS SVN revision: r72969                                                      
Build date: 2018-07-10                                                          
Build platform: x86_64-w64-mingw32                                              
GDAL: 2.2.4                                                                     
PROJ.4: 4.9.3                                                                   
GEOS: 3.5.0                                                                     
SQLite: 3.17.0                                                                  
Python: 2.7.14                                                                  
wxPython: 2.8.12.1                                                              
Platform: Windows-10-10.0.17134 (OSGeo4W) 

r72974+ has double buffering. Earlier version was incomplete without buffer swapping for Windows. Please try r72974+ later.

winGRASS building is broken:

see ​error.log

GRASS GIS 7.5.svn r72978 compilation log
--------------------------------------------------
Started compilation: Wed Jul 11 15:02:16     2018
--
Errors in:
/c/msys64/usr/src/grass_trunk/lib/ogsf
/c/msys64/usr/src/grass_trunk/lib/nviz
/c/msys64/usr/src/grass_trunk/misc/m.nviz.image
--
In case of errors please change into the directory with error and run 'make'.
If you get multiple errors, you need to deal with them in the order they
appear in the error log. If you get an error building a library, you will
also get errors from anything which uses the library.
--
Finished compilation: Wed Jul 11 15:35:12     2018

and ​compiling log

Replaced wingdi.h with windows.h in r72980. Copied from nviz.h. Weird, according to ​https://docs.microsoft.com/en-us/windows/desktop/api/wingdi/nf-wingdi-swapbuffers, SwapBuffer is defined in wingdi.h.

[hellik]

Replying to hcho:

Replaced wingdi.h with windows.h in r72980. Copied from nviz.h. Weird, according to ​https://docs.microsoft.com/en-us/windows/desktop/api/wingdi/nf-wingdi-swapbuffers, SwapBuffer is defined in wingdi.h.

see

​https://wingrass.fsv.cvut.cz/grass75/x86_64/logs/log-r72984-191/error.log

GRASS GIS 7.5.svn r72984 compilation log
--------------------------------------------------
Started compilation: Fri Jul 13 15:43:43     2018
--
Errors in:
/c/msys64/usr/src/grass_trunk/lib/ogsf
/c/msys64/usr/src/grass_trunk/lib/nviz
/c/msys64/usr/src/grass_trunk/misc/m.nviz.image
--
In case of errors please change into the directory with error and run 'make'.
If you get multiple errors, you need to deal with them in the order they
appear in the error log. If you get an error building a library, you will
also get errors from anything which uses the library.
--
Finished compilation: Fri Jul 13 16:35:26     2018

and the ​compilation log

[hcho]

Commented out that line in r72986 until I can figure out what's going on. I'll try to compile it myself on Windows. I think -lgdi32 is missing there.

Replying to hellik:

Replying to hcho:

Replaced wingdi.h with windows.h in r72980. Copied from nviz.h. Weird, according to ​https://docs.microsoft.com/en-us/windows/desktop/api/wingdi/nf-wingdi-swapbuffers, SwapBuffer is defined in wingdi.h.

see

​https://wingrass.fsv.cvut.cz/grass75/x86_64/logs/log-r72984-191/error.log

GRASS GIS 7.5.svn r72984 compilation log
--------------------------------------------------
Started compilation: Fri Jul 13 15:43:43     2018
--
Errors in:
/c/msys64/usr/src/grass_trunk/lib/ogsf
/c/msys64/usr/src/grass_trunk/lib/nviz
/c/msys64/usr/src/grass_trunk/misc/m.nviz.image
--
In case of errors please change into the directory with error and run 'make'.
If you get multiple errors, you need to deal with them in the order they
appear in the error log. If you get an error building a library, you will
also get errors from anything which uses the library.
--
Finished compilation: Fri Jul 13 16:35:26     2018

and the ​compilation log

[hcho]

In include/Make/Grass.make, add this line below line 251:

OGSFDEPS += -lgdi32

Going to try it in my VM.

[hellik]

Replying to hcho:

In include/Make/Grass.make, add this line below line 251:

OGSFDEPS += -lgdi32

Going to try it in my VM.

With or without: Revision: 72986

?

[hcho]

Without r72986.

or with SwapBuffers and OGSFDEPS += -lgdi32

Replying to hellik:

Replying to hcho:

In include/Make/Grass.make, add this line below line 251:

OGSFDEPS += -lgdi32

Going to try it in my VM.

With or without: Revision: 72986

?

[hellik]

Replying to hcho:

Without r72986.

or with SwapBuffers and OGSFDEPS += -lgdi32

Replying to hellik:

Replying to hcho:

In include/Make/Grass.make, add this line below line 251:

OGSFDEPS += -lgdi32

Going to try it in my VM.

With or without: Revision: 72986

?

reverting locally r72986 and adding

OGSFDEPS += -lgdi32

In include/Make/Grass.make, add this line below line 251.

GRASS GIS 7.5.svn r72986M compilation log
--------------------------------------------------
Started compilation: Sat Jul 14 16:15:39 CEST 2018
--
Errors in:
No errors detected.
--
Finished compilation: Sat Jul 14 16:30:37 CEST 2018

it compiles here without any error by

GRASS is now configured for:  x86_64-w64-mingw32

  Source directory:           /usr/src/grass_trunk
  Build directory:            /usr/src/grass_trunk
  Installation directory:     ${prefix}/grass-7.5.svn
  Startup script in directory:/c/OSGeo4W64/bin
  C compiler:                 gcc -g -O2 
  C++ compiler:               c++ -g -O2
  Building shared libraries:  yes
  OpenGL platform:            Windows

  MacOSX application:         no
  MacOSX architectures:       
  MacOSX SDK:                 

  BLAS support:               no
  BZIP2 support:              yes
  C++ support:                yes
  Cairo support:              yes
  DWG support:                no
  FFTW support:               yes
  FreeType support:           yes
  GDAL support:               yes
  GEOS support:               yes
  LAPACK support:             no
  Large File support (LFS):   yes
  libLAS support:             yes
  MySQL support:              no
  NetCDF support:             no
  NLS support:                yes
  ODBC support:               yes
  OGR support:                yes
  OpenCL support:             no
  OpenGL support:             yes
  OpenMP support:             no
  PDAL support:               no
  PNG support:                yes
  POSIX thread support:       no
  PostgreSQL support:         yes
  Readline support:           no
  Regex support:              yes
  SQLite support:             yes
  TIFF support:               yes
  X11 support:                no
  Zstandard support:          yes

  using old PROJ 4 API

[hellik]

see related #3606

[hcho]

Replying to hellik:

Replying to hcho:

Without r72986.

or with SwapBuffers and OGSFDEPS += -lgdi32

Replying to hellik:

Replying to hcho:

In include/Make/Grass.make, add this line below line 251:

OGSFDEPS += -lgdi32

Going to try it in my VM.

With or without: Revision: 72986

?

reverting locally r72986 and adding

OGSFDEPS += -lgdi32

In include/Make/Grass.make, add this line below line 251.

GRASS GIS 7.5.svn r72986M compilation log
--------------------------------------------------
Started compilation: Sat Jul 14 16:15:39 CEST 2018
--
Errors in:
No errors detected.
--
Finished compilation: Sat Jul 14 16:30:37 CEST 2018

it compiles here without any error by

GRASS is now configured for:  x86_64-w64-mingw32

  Source directory:           /usr/src/grass_trunk
  Build directory:            /usr/src/grass_trunk
  Installation directory:     ${prefix}/grass-7.5.svn
  Startup script in directory:/c/OSGeo4W64/bin
  C compiler:                 gcc -g -O2 
  C++ compiler:               c++ -g -O2
  Building shared libraries:  yes
  OpenGL platform:            Windows

  MacOSX application:         no
  MacOSX architectures:       
  MacOSX SDK:                 

  BLAS support:               no
  BZIP2 support:              yes
  C++ support:                yes
  Cairo support:              yes
  DWG support:                no
  FFTW support:               yes
  FreeType support:           yes
  GDAL support:               yes
  GEOS support:               yes
  LAPACK support:             no
  Large File support (LFS):   yes
  libLAS support:             yes
  MySQL support:              no
  NetCDF support:             no
  NLS support:                yes
  ODBC support:               yes
  OGR support:                yes
  OpenCL support:             no
  OpenGL support:             yes
  OpenMP support:             no
  PDAL support:               no
  PNG support:                yes
  POSIX thread support:       no
  PostgreSQL support:         yes
  Readline support:           no
  Regex support:              yes
  SQLite support:             yes
  TIFF support:               yes
  X11 support:                no
  Zstandard support:          yes

  using old PROJ 4 API

Great! I wanted to try one more thing. Reverting r72980: Replacing

#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#undef WIN32_LEAN_AND_MEAN

with

#include <wingdi.h>

because SwapBuffers is defined in wingdi.h.

[hellik]

Replying to hcho:

Great! I wanted to try one more thing. Reverting r72980: Replacing

#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#undef WIN32_LEAN_AND_MEAN

with

#include <wingdi.h>

because SwapBuffers is defined in wingdi.h.

could you prepare a diff/patch to see what should be tested as I'm lost the overview what is changed where/should be reverted etc :-)

[hcho]

Confirmed that wingdi.h compiles fine on my VM. r72987 has wingdi.h and OGSFDEPS. Thanks for testing. Could you try to run m.nviz.image with your current build (reverted r72986 and added OGSFDEPS)?

[hellik]

Replying to hcho:

Confirmed that wingdi.h compiles fine on my VM. r72987 has wingdi.h and OGSFDEPS. Thanks for testing. Could you try to run m.nviz.image with your current build (reverted r72986 and added OGSFDEPS)?

can't test it cause test build already deleted.

[hellik]

Replying to hcho:

Confirmed that wingdi.h compiles fine on my VM. r72987 has wingdi.h and OGSFDEPS. Thanks for testing. Could you try to run m.nviz.image with your current build (reverted r72986 and added OGSFDEPS)?

see winGRASS compilation at r72990 ​log

GRASS GIS 7.5.svn r72990 compilation log
--------------------------------------------------
Started compilation: Sun Jul 15 14:58:56     2018
--
Errors in:
No errors detected.
--
Finished compilation: Sun Jul 15 15:34:00     2018

compilation works now; output can be tested now in winGRASS

[hellik]

Replying to hellik:

Replying to hcho:

Confirmed that wingdi.h compiles fine on my VM. r72987 has wingdi.h and OGSFDEPS. Thanks for testing. Could you try to run m.nviz.image with your current build (reverted r72986 and added OGSFDEPS)?

see winGRASS compilation at r72990 ​log

GRASS GIS 7.5.svn r72990 compilation log
--------------------------------------------------
Started compilation: Sun Jul 15 14:58:56     2018
--
Errors in:
No errors detected.
--
Finished compilation: Sun Jul 15 15:34:00     2018

compilation works now; output can be tested now in winGRASS

now tested with

System Info                                                                     
GRASS version: 7.5.svn                                                          
GRASS SVN revision: r72990                                                      
Build date: 2018-07-15                                                          
Build platform: x86_64-w64-mingw32                                              
GDAL: 2.2.4                                                                     
PROJ.4: 4.9.3                                                                   
GEOS: 3.5.0                                                                     
SQLite: 3.17.0                                                                  
Python: 2.7.14                                                                  
wxPython: 2.8.12.1                                                              
Platform: Windows-10-10.0.17134 (OSGeo4W)  

C:\>m.nviz.image elevation_map=elevation output=D:\temp\mnviz\elev perspective=15
Loading raster map <elevation@PERMANENT>...
 100%
Loading raster map <elevation@PERMANENT>...
 100%
Translating colors from raster map <elevation@PERMANENT>...
 100%
WARNING: Unable to get image of current GL screen
ERROR: Failed to write image

C:\>m.nviz.image elevation_map=elevation output=D:\temp\mnviz\elev perspective=15 format=tif
Loading raster map <elevation@PERMANENT>...
 100%
Loading raster map <elevation@PERMANENT>...
 100%
Translating colors from raster map <elevation@PERMANENT>...
 100%
WARNING: Unable to get image of current GL screen
ERROR: Failed to write image

g.gisenv set=DEBUG=3 log attached

[hellik]

log r72990 debug=3

[hcho]

Please test r72997 on Windows.

[hellik]

Replying to hcho:

Please test r72997 on Windows.

tested with

GRASS version: 7.5.svn                                                          
GRASS SVN revision: r72999                                                      
Build date: 2018-07-20                                                          
Build platform: x86_64-w64-mingw32                                              
GDAL: 2.2.4                                                                     
PROJ.4: 4.9.3                                                                   
GEOS: 3.5.0                                                                     
SQLite: 3.17.0                                                                  
Python: 2.7.14                                                                  
wxPython: 2.8.12.1                                                              
Platform: Windows-10-10.0.17134 (OSGeo4W)

C:\>m.nviz.image elevation_map=elevation output=D:\temp\mnviz\elev perspective=15
Loading raster map <elevation@PERMANENT>...
 100%
Loading raster map <elevation@PERMANENT>...
 100%
Translating colors from raster map <elevation@PERMANENT>...
 100%
m.nviz.image complete. File <D:\temp\mnviz\elev.ppm> created.

C:\>m.nviz.image elevation_map=elevation output=D:\temp\mnviz\elev perspective=15 format=tif
Loading raster map <elevation@PERMANENT>...
 100%
Loading raster map <elevation@PERMANENT>...
 100%
Translating colors from raster map <elevation@PERMANENT>...
 100%
m.nviz.image complete. File <D:\temp\mnviz\elev.tif> created.

seems to work now; ppm and tif of winGRASS added

[hcho]

Replying to hellik:

Replying to hcho:

Please test r72997 on Windows.

tested with

GRASS version: 7.5.svn                                                          
GRASS SVN revision: r72999                                                      
Build date: 2018-07-20                                                          
Build platform: x86_64-w64-mingw32                                              
GDAL: 2.2.4                                                                     
PROJ.4: 4.9.3                                                                   
GEOS: 3.5.0                                                                     
SQLite: 3.17.0                                                                  
Python: 2.7.14                                                                  
wxPython: 2.8.12.1                                                              
Platform: Windows-10-10.0.17134 (OSGeo4W)

C:\>m.nviz.image elevation_map=elevation output=D:\temp\mnviz\elev perspective=15
Loading raster map <elevation@PERMANENT>...
 100%
Loading raster map <elevation@PERMANENT>...
 100%
Translating colors from raster map <elevation@PERMANENT>...
 100%
m.nviz.image complete. File <D:\temp\mnviz\elev.ppm> created.

C:\>m.nviz.image elevation_map=elevation output=D:\temp\mnviz\elev perspective=15 format=tif
Loading raster map <elevation@PERMANENT>...
 100%
Loading raster map <elevation@PERMANENT>...
 100%
Translating colors from raster map <elevation@PERMANENT>...
 100%
m.nviz.image complete. File <D:\temp\mnviz\elev.tif> created.

seems to work now; ppm and tif of winGRASS added

Good. Now it's the macOS only that doesn't work.

[cmbarton]

Indeed. Hope it will be easier to get it to work on the Mac.

[guano]

static noise (mac)

[guano]

I just tested SVN r73002 on my Mac. This time I get a 1.5 MB image (both as ppm and tif) but it looks like static noise on a TV:

[hcho]

Replying to guano:

I just tested SVN r73002 on my Mac. This time I get a 1.5 MB image (both as ppm and tif) but it looks like static noise on a TV:

That's interesting because I didn't make any changes to the Mac code in trunk other than moving aglSetPBuffer. Is the size correct BTW?

FYI, Michael and I are testing CGL and framebuffer objects in Mac.

[hcho]

Replying to hcho:

Replying to guano:

I just tested SVN r73002 on my Mac. This time I get a 1.5 MB image (both as ppm and tif) but it looks like static noise on a TV:

That's interesting because I didn't make any changes to the Mac code in trunk other than moving aglSetPBuffer. Is the size correct BTW?

FYI, Michael and I are testing CGL and framebuffer objects in Mac.

Please try these files.

1. Overwrite include/nviz.h, lib/nviz/render.c, lib/ogsf/gsd_prim.c and lib/ogsf/gsd_view.c
2. ./configure
3. make clean && make

Thanks.

[hcho]

CGL & FBO

[hcho]

CGL & FBO

[hcho]

CGL & FBO

[hcho]

CGL & FBO

[guano]

screenshot of DEM

[guano]

output

[guano]

It works!

The attachments I just added (Screenshot.jog and nviz_output_working.jpg​) show the 3D image setup and the output.

Many thanks for the work on this!

[hcho]

Replying to guano:

It works!

The attachments I just added (Screenshot.jog and nviz_output_working.jpg​) show the 3D image setup and the output.

Many thanks for the work on this!

Yay! Thanks for testing. Could you please test other cases too just to make sure that only this setup works?

1. AGL without FBO: current trunk, doesn't work
2. AGL with FBO: Add #define OPENGL_AGL 1 in those four files (OPENGL_AGL & OPENGL_FBO); ./configure; make clean && make
3. CGL without FBO: Remove #define OPENGL_FBO 1 from the above files (no OPENGL_FBO, no OPENGL_AGL); ./configure; make clean && make
4. CGL with FBO: (OPENGL_FBO, no OPENGL_AGL) You just confirmed that it works.

Since AGL is deprecated and only supports 32bit, we should go with case 4 at least for the Mac. The only problem with FBO is that the nviz and ogsf libraries will be offscreen rendering only without direct rendering to application windows (default framebuffer provided by a windowing system like X11, Aqua, and GDI32). Right now, no other modules use nviz & ogsf for direct rendering and wxGUI & wxPython provide that capability, so I don't see any major issues at this moment.

[hcho]

FYI, on my VM, all cases except CGL without FBO work. Based on my research, CGL doesn't provide the default framebuffer, so we need to bind a framebuffer object (FBO) to render to. So I know why that combination doesn't work. The only case I cannot understand is that AGL without FBO works on my 64bit VM, but not on the real hardware. Cases 2 & 3 were never tested on the Mac yet.

[hcho]

Replying to hcho:

Replying to guano:

It works!

The attachments I just added (Screenshot.jog and nviz_output_working.jpg​) show the 3D image setup and the output.

Many thanks for the work on this!

Yay! Thanks for testing. Could you please test other cases too just to make sure that only this setup works?

1. AGL without FBO: current trunk, doesn't work
2. AGL with FBO: Add #define OPENGL_AGL 1 in those four files (OPENGL_AGL & OPENGL_FBO); ./configure; make clean && make
3. CGL without FBO: Remove #define OPENGL_FBO 1 from the above files (no OPENGL_FBO, no OPENGL_AGL); ./configure; make clean && make
4. CGL with FBO: (OPENGL_FBO, no OPENGL_AGL) You just confirmed that it works.

Since AGL is deprecated and only supports 32bit, we should go with case 4 at least for the Mac. The only problem with FBO is that the nviz and ogsf libraries will be offscreen rendering only without direct rendering to application windows (default framebuffer provided by a windowing system like X11, Aqua, and GDI32). Right now, no other modules use nviz & ogsf for direct rendering and wxGUI & wxPython provide that capability, so I don't see any major issues at this moment.

For this testing, please make sure to #define at the very beginning of each file before any #if defined().

[guano]

testing the other cases:

with this in the four files:

#define OPENGL_FBO 1
#define OPENGL_AGL 1

doesn't work. Image is like static noise.

without the defines in the four files doesn't work as well. Image is just static noise.

[hcho]

Replying to guano:

testing the other cases:

with this in the four files:

#define OPENGL_FBO 1
#define OPENGL_AGL 1

doesn't work. Image is like static noise.

without the defines in the four files doesn't work as well. Image is just static noise.

Ok, cases 2 (both defined) and 3 (both undefined) don't work on the real Mac.

1. AGL & no FBO: Mac (X), VM (O)
2. AGL & ....FBO: Mac (X), VM (O)
3. CGL & no FBO: Mac (X), VM (X)
4. CGL & ....FBO: Mac (O), VM (O)

Maybe, cases 1 & 2 are a bug in VM ;-).

[hcho]

Test files for Mac

[hcho]

test files 2

[hcho]

In 73006:

nviz, ogsf: Use framebuffer objects for off-screen GL rendering; Use Core OpenGL (CGL) for the MacOS instead of deprecated 32-bit only AGL (Fix #3600, #2114, #3606)

[martinl]

Re-opening since milestone is set to 7.0.4.

a) do backport (probably 7.4 branch + change milestone to 7.4.2 would be enough)

b) change milestone to 7.6 and close issue again

[hcho]

Backported to 7.2 & 7.4.