Opened 6 years ago

Closed 6 years ago

#3600 closed defect (fixed)

m.nviz.image doesn't produce any output

Reported by: guano Owned by: grass-dev@…
Priority: normal Milestone:
Component: Default Version: 7.2.0
Keywords: Cc:
CPU: Unspecified Platform: MacOSX

Description

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?

Change History (117)

comment:1 by hcho, 6 years ago

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

comment:2 by guano, 6 years ago

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 

by hcho, 6 years ago

Attachment: nviz_output.png added

comment:3 by hcho, 6 years ago

# 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?

comment:4 by guano, 6 years ago

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.

comment:5 by hcho, 6 years ago

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

comment:6 by guano, 6 years ago

Yes, it is the expected result.

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

comment:7 by hcho, 6 years ago

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.

comment:8 by hcho, 6 years ago

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);

comment:9 by hcho, 6 years ago

Or better

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

comment:10 by guano, 6 years ago

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.

comment:11 by neteler, 6 years ago

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]

comment:12 by guano, 6 years ago

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

comment:13 by hcho, 6 years ago

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());

comment:14 by guano, 6 years ago

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

the output is this one:

aglCreatePBuffer failed: 500 500 10005

comment:15 by hcho, 6 years ago

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.

comment:16 by hcho, 6 years ago

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

comment:17 by hcho, 6 years ago

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.

in reply to:  13 ; comment:18 by hellik, 6 years ago

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

by hellik, 6 years ago

Attachment: mnviz_ppm.txt added

winGRASS DEBUG=3 ppm

by hellik, 6 years ago

Attachment: mnviz_tif.txt added

winGRASS DEBUG=3 tif

in reply to:  18 comment:19 by hellik, 6 years ago

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

comment:20 by hcho, 6 years ago

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.

Last edited 6 years ago by hcho (previous) (diff)

comment:21 by hcho, 6 years ago

Please try r72948.

in reply to:  20 comment:22 by hellik, 6 years ago

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.

comment:23 by hcho, 6 years ago

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);
}

in reply to:  16 ; comment:24 by cmbarton, 6 years ago

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.

in reply to:  24 comment:25 by hcho, 6 years ago

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?

comment:26 by cmbarton, 6 years ago

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.

comment:27 by guano, 6 years ago

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

in reply to:  21 ; comment:28 by hellik, 6 years ago

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

by hellik, 6 years ago

by hellik, 6 years ago

by hellik, 6 years ago

Attachment: elev_winGRASS.ppm added

by hellik, 6 years ago

Attachment: elev_winGRASS.tif added

in reply to:  28 ; comment:29 by hcho, 6 years ago

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).

by hcho, 6 years ago

Attachment: lib-nviz-render.c.diff added

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

in reply to:  29 comment:30 by hellik, 6 years ago

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?

comment:31 by cmbarton, 6 years ago

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.

comment:32 by hcho, 6 years ago

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.

comment:33 by hcho, 6 years ago

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.

comment:34 by cmbarton, 6 years ago

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

in reply to:  34 ; comment:35 by hcho, 6 years ago

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

in reply to:  35 comment:36 by hcho, 6 years ago

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.

comment:37 by cmbarton, 6 years ago

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

in reply to:  37 comment:38 by hcho, 6 years ago

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.

comment:39 by cmbarton, 6 years ago

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

in reply to:  39 comment:40 by hcho, 6 years ago

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 ;-).

Last edited 6 years ago by hcho (previous) (diff)

comment:41 by hcho, 6 years ago

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".

by cmbarton, 6 years ago

Attachment: elevation.tif.zip added

test of m.nviz.image on Mac

comment:42 by cmbarton, 6 years ago

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.

in reply to:  42 comment:43 by hcho, 6 years ago

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.

comment:44 by cmbarton, 6 years ago

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

in reply to:  44 comment:45 by hcho, 6 years ago

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?

by cmbarton, 6 years ago

Attachment: elevation.ppm added

Mac test with line 221 commented out.

comment:46 by hcho, 6 years ago

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...

by cmbarton, 6 years ago

Attachment: elevation.ppm.zip added

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

comment:47 by cmbarton, 6 years ago

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.

in reply to:  47 comment:48 by hcho, 6 years ago

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.

Last edited 6 years ago by hcho (previous) (diff)

comment:49 by cmbarton, 6 years ago

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?

comment:50 by cmbarton, 6 years ago

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

in reply to:  49 ; comment:51 by hcho, 6 years ago

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.

comment:52 by hcho, 6 years ago

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.

in reply to:  51 comment:53 by cmbarton, 6 years ago

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

comment:54 by hcho, 6 years ago

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.

comment:55 by hcho, 6 years ago

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.

by hcho, 6 years ago

Attachment: lib-nviz-render.c.2.diff added

Double buffering for Linux and MacOS

by hcho, 6 years ago

Attachment: lib-ogsf-gsd_prim.c.diff added

Buffer swapping for Linux, MacOS and Windows

comment:56 by cmbarton, 6 years ago

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

by cmbarton, 6 years ago

Attachment: lib_ogsf_error.txt added

r72973 breaks Mac compiling. /lib/ogsf error

by cmbarton, 6 years ago

Attachment: lib_nviz_error.txt added

r72973 breaks Mac compiling. /lib/nviz error

comment:57 by hcho, 6 years ago

Renamed bool to shade in r72974. Please try again.

in reply to:  54 ; comment:58 by hellik, 6 years ago

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

comment:59 by cmbarton, 6 years ago

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

in reply to:  58 ; comment:60 by hcho, 6 years ago

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.

in reply to:  60 ; comment:61 by hellik, 6 years ago

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

in reply to:  61 ; comment:62 by hcho, 6 years ago

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.

in reply to:  62 ; comment:63 by hellik, 6 years ago

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

in reply to:  63 comment:64 by hcho, 6 years ago

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

comment:65 by hcho, 6 years ago

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

OGSFDEPS += -lgdi32

Going to try it in my VM.

Last edited 6 years ago by hcho (previous) (diff)

in reply to:  65 ; comment:66 by hellik, 6 years ago

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

?

in reply to:  66 ; comment:67 by hcho, 6 years ago

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

?

in reply to:  67 ; comment:68 by hellik, 6 years ago

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

comment:69 by hellik, 6 years ago

see related #3606

in reply to:  68 ; comment:70 by hcho, 6 years ago

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.

in reply to:  70 comment:71 by hellik, 6 years ago

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 :-)

comment:72 by hcho, 6 years ago

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)?

in reply to:  72 comment:73 by hellik, 6 years ago

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.

in reply to:  72 ; comment:74 by hellik, 6 years ago

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

in reply to:  74 ; comment:75 by hellik, 6 years ago

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

by hellik, 6 years ago

Attachment: log_r72990.txt added

log r72990 debug=3

in reply to:  75 ; comment:76 by hcho, 6 years ago

Please test r72997 on Windows.

in reply to:  76 ; comment:77 by hellik, 6 years ago

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

by hellik, 6 years ago

in reply to:  77 comment:78 by hcho, 6 years ago

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.

comment:79 by cmbarton, 6 years ago

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

by guano, 6 years ago

Attachment: nviz_output.jpg added

static noise (mac)

comment:80 by guano, 6 years ago

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:

static noise (mac)

in reply to:  80 ; comment:81 by hcho, 6 years ago

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:

static noise (mac)

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.

in reply to:  81 comment:82 by hcho, 6 years ago

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:

static noise (mac)

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.

by hcho, 6 years ago

Attachment: nviz.h added

CGL & FBO

by hcho, 6 years ago

Attachment: render.c added

CGL & FBO

by hcho, 6 years ago

Attachment: gsd_prim.c added

CGL & FBO

by hcho, 6 years ago

Attachment: gsd_views.c added

CGL & FBO

by guano, 6 years ago

Attachment: Screenshot.jpg added

screenshot of DEM

by guano, 6 years ago

Attachment: nviz_output_working.jpg added

output

comment:83 by guano, 6 years ago

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!

in reply to:  83 ; comment:84 by hcho, 6 years ago

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.

comment:85 by hcho, 6 years ago

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.

Last edited 6 years ago by hcho (previous) (diff)

in reply to:  84 comment:86 by hcho, 6 years ago

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().

comment:87 by guano, 6 years ago

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.

in reply to:  87 comment:88 by hcho, 6 years ago

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 ;-).

by hcho, 6 years ago

Attachment: nviz_tests.zip added

Test files for Mac

by hcho, 6 years ago

Attachment: nviz_tests2.zip added

test files 2

comment:89 by hcho, 6 years ago

Resolution: fixed
Status: newclosed

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)

comment:90 by martinl, 6 years ago

Resolution: fixed
Status: closedreopened

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

Last edited 6 years ago by martinl (previous) (diff)

comment:91 by hcho, 6 years ago

Resolution: fixed
Status: reopenedclosed
Version: 7.0.47.2.0

Backported to 7.2 & 7.4.

Note: See TracTickets for help on using tickets.