Context Navigation

← Previous Ticket
Next Ticket →

#3606 closed defect (fixed)

m.nviz.image produces a screenshot

Reported by:	epifanio	Owned by:	grass-dev@…
Priority:	major	Milestone:	7.4.2
Component:	Display	Version:	svn-trunk
Keywords:		Cc:
CPU:	x86-64	Platform:	Linux

Description

Platform: Linux Ubuntu 18.04, 64 bit GRASS version: 7.5 trunk revision #72985

Trying to run 'm.nviz.image' from sample location "nc_basic_spm_grass7"

returns a screenshot of the active window from whre I ran the command ... I got a black ppm when running the above command from the terminal and I got the attached image when running the same command from the WX gui console.

Attachments (3)

m.nviz.image.png (21.5 KB ) - added by epifanio 6 years ago.: This image (converted to png because of attachment size, original format: ppm) has been generated by m.nviz.image by running the following command ' m.nviz.image elevation_map=elevation output=elev perspective=15' from the WX Gui console.
lib-ogsf-gsd_prim.c.diff (1.1 KB ) - added by hcho 6 years ago.
screenshot.png (412.8 KB ) - added by hcho 6 years ago.

Download all attachments as: .zip

Change History (27)

by epifanio, 6 years ago

Attachment:	m.nviz.image.png added

This image (converted to png because of attachment size, original format: ppm) has been generated by m.nviz.image by running the following command ' m.nviz.image elevation_map=elevation output=elev perspective=15' from the WX Gui console.

in reply to: description comment:1 by hellik, 6 years ago

Replying to epifanio:

Platform: Linux Ubuntu 18.04, 64 bit GRASS version: 7.5 trunk revision #72985

Trying to run 'm.nviz.image' from sample location "nc_basic_spm_grass7"

returns a screenshot of the active window from whre I ran the command ... I got a black ppm when running the above command from the terminal and I got the attached image when running the same command from the WX gui console.

see #3600

this ticket seems to be a duplication? right?

comment:2 by epifanio, 6 years ago

Hi, In my case, 'm.nviz.image' does produce a proper ppm file as output, which I can open with an image viewer (e.g. gimp) but what is rendered in that ppm is a screen grab of the software window from where the command was issued. It seems that 'm.nviz.image' is acting like a software to make screenshots ... (weird). In #606 the user experienced a non-readable ppm output, the bug can be related, of course.

comment:3 by hcho, 6 years ago

If I remove line 480 in lib/ogsf/gsd_prim.c glXSwapBuffers, I'm getting a similar result. Nviz draws to the back buffer and OGSF copies the back buffer to the front before saving an image. You might be doing double swapping for some reason. Please try the following patch and let me know what output you get from stderr.

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

by hcho, 6 years ago

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

follow-up: 5 comment:4 by epifanio, 6 years ago

Applied the patch on latest trunk rev. num.: 72990

print out the following output:

GRASS 7.5.svn (nc_basic_spm_grass7):~ > m.nviz.image elevation_map=elevation output=elev perspective=15 --o
Loading raster map <elevation@PERMANENT>...
 100%
Loading raster map <elevation@PERMANENT>...
 100%
Translating colors from raster map <elevation@PERMANENT>...
 100%
buffer: both
buffer: both
buffer: both
buffer: both
buffer: both
buffer: both
buffer: both
buffer: swap
buffer: both
m.nviz.image complete. File <elev.ppm> created.

My grass_trunk is configured without X11 support:

GRASS is now configured for:  x86_64-pc-linux-gnu

  Source directory:           /home/epinux/dev/grass7_trunk
  Build directory:            /home/epinux/dev/grass7_trunk
  Installation directory:     ${prefix}/grass-7.5.svn
  Startup script in directory:${exec_prefix}/bin
  C compiler:                 gcc -g -O2 
  C++ compiler:               c++ -g -O2
  Building shared libraries:  yes
  OpenGL platform:            X11

  MacOSX application:         no
  MacOSX architectures:       
  MacOSX SDK:                 

  BLAS support:               yes
  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:             yes
  Large File support (LFS):   yes
  libLAS support:             yes
  MySQL support:              no
  NetCDF support:             yes
  NLS support:                no
  ODBC support:               yes
  OGR support:                yes
  OpenCL support:             no
  OpenGL support:             yes
  OpenMP support:             yes
  PDAL support:               yes
  PNG support:                yes
  POSIX thread support:       yes
  PostgreSQL support:         yes
  Readline support:           yes
  Regex support:              yes
  SQLite support:             yes
  TIFF support:               yes
  X11 support:                no
  Zstandard support:          yes

  using old PROJ 4 API

in reply to: 4 comment:5 by hcho, 6 years ago

Replying to epifanio:

Applied the patch on latest trunk rev. num.: 72990

print out the following output:

GRASS 7.5.svn (nc_basic_spm_grass7):~ > m.nviz.image elevation_map=elevation output=elev perspective=15 --o
Loading raster map <elevation@PERMANENT>...
 100%
Loading raster map <elevation@PERMANENT>...
 100%
Translating colors from raster map <elevation@PERMANENT>...
 100%
buffer: both
buffer: both
buffer: both
buffer: both
buffer: both
buffer: both
buffer: both
buffer: swap
buffer: both
m.nviz.image complete. File <elev.ppm> created.

My grass_trunk is configured without X11 support:

This is my output:

buffer: back
buffer: both
buffer: back
buffer: both
buffer: back
buffer: both
buffer: back
buffer: swap
buffer: back

In your case, GS_set_draw(GSD_BACK) never worked. That's weird. Please add fprintf(stderr, "draw where: %d\n", where); in line 2465 in lib/ogsf/gs2.c. GSD_FRONT 1, GSD_BACK 2, and GSD_BOTH 3 are defined in include/ogsf.h. There are 10 calls to GS_set_draw with all these numbers in lib/nviz/draw.c, but you only got GSD_BOTH 3. Even in that case, swapping shouldn't affect anything in the front buffer because you draw to both buffers anyway.

Anyway, I think you need X11 support because Nviz requires some Xlib functions (XOpenDisplay, XCreatePixmap, XFree, ...) in lib/nviz/render.c. Please try it again with X11 support enabled. Is there any specific reason why you disabled it?

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

follow-up: 7 comment:6 by epifanio, 6 years ago

Rebuilding with X support enabled didn't change the m.nviz.image output. Adding fprintf(stderr, "draw where: %d\n", where);, as you instructed, produce the following output:

(Mon Jul 16 14:19:48 2018)                                                      
m.nviz.image elevation_map=elevation output=elev perspective=15 --o             
WARNING: File <elev.ppm> already exists and will be overwritten
Loading raster map <elevation@PERMANENT>...
Loading raster map <elevation@PERMANENT>...
Translating colors from raster map <elevation@PERMANENT>...
draw where: 2
buffer: both
draw where: 3
buffer: both
draw where: 2
buffer: both
draw where: 3
buffer: both
draw where: 2
buffer: both
draw where: 3
buffer: both
draw where: 2
buffer: both
buffer: swap
draw where: 2
buffer: both
m.nviz.image complete. File <elev.ppm> created.
(Mon Jul 16 14:19:48 2018) Command finished (0 sec)

in reply to: 6 comment:7 by hcho, 6 years ago

Replying to epifanio:

Rebuilding with X support enabled didn't change the m.nviz.image output. Adding fprintf(stderr, "draw where: %d\n", where);, as you instructed, produce the following output:

(Mon Jul 16 14:19:48 2018)                                                      
m.nviz.image elevation_map=elevation output=elev perspective=15 --o             
WARNING: File <elev.ppm> already exists and will be overwritten
Loading raster map <elevation@PERMANENT>...
Loading raster map <elevation@PERMANENT>...
Translating colors from raster map <elevation@PERMANENT>...
draw where: 2
buffer: both
draw where: 3
buffer: both
draw where: 2
buffer: both
draw where: 3
buffer: both
draw where: 2
buffer: both
draw where: 3
buffer: both
draw where: 2
buffer: both
buffer: swap
draw where: 2
buffer: both
m.nviz.image complete. File <elev.ppm> created.
(Mon Jul 16 14:19:48 2018) Command finished (0 sec)

Could you please attach your lib/ogsf/gs2.c, lib/ogsf/gsd_prim.c, and include/ogsf.h? I know they must be the same as my trunk, but looks like switch doesn't work at all? I'm confused.

follow-up: 9 comment:8 by epifanio, 6 years ago

I made a gist of lib/ogsf/gs2.c, lib/ogsf/gsd_prim.c, and include/ogsf.h

https://gist.github.com/0a22197af301f2f64678efa408ea997f

in reply to: 8 comment:9 by hcho, 6 years ago

Replying to epifanio:

I made a gist of lib/ogsf/gs2.c, lib/ogsf/gsd_prim.c, and include/ogsf.h

https://gist.github.com/0a22197af301f2f64678efa408ea997f

I think I know what happened. In gsd_prim.c, all gsd_bothbuffers, gsd_frontbuffer, and gsd_backbuffer have "buffer: both\n". That's why I was confused. Anyway, that's not the reason for your problem.

comment:10 by hcho, 6 years ago

Maybe try size=100,100 and see what the output size is.

Not sure what it is, but you can also try to directly draw to the front buffer without buffer swapping

Change line 223 in lib/nviz/draw.c to GS_set_draw(GSD_FRONT);
Comment out line 480 glXSwapBuffers from lib/ogsf/gsd_prim.c.

comment:11 by epifanio, 6 years ago

@hco The two changes you proposed fixed the issue. I didn't test all the m.nviz.image options, but I can now render a proper elevation map with no errors.

follow-up: 13 comment:12 by epifanio, 6 years ago

forgot to say, ... Thanks for your help!!!

in reply to: 12 comment:13 by hcho, 6 years ago

Replying to epifanio:

forgot to say, ... Thanks for your help!!!

You're welcome and thanks for testing, but it only solves your specific problem. I still don't understand why drawing to the back buffer and swapping it to the front doesn't work for you. Could you please try one more thing?

Change line 223 in lib/nviz/draw.c to GS_set_draw(GSD_BOTH);
Uncomment line 480 glXSwapBuffers in lib/ogsf/gsd_prim.c

So the only difference from trunk is GS_set_draw(GSD_BOTH); vs GS_set_draw(GSD_BACK);.

Also this:

Change line 223 in lib/nviz/draw.c to GS_set_draw(GSD_BOTH);
Comment out line 480 glXSwapBuffers in lib/ogsf/gsd_prim.c

Thanks.

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

follow-up: 17 comment:14 by cmbarton, 6 years ago

When this is at a point where it seems to be working on Windows, let me know and I'll recompile it for the Mac and test some more.

follow-up: 16 comment:15 by epifanio, 6 years ago

Double checking I've the right changes applied to the right files, here is a gist of the previous files:

https://gist.github.com/c6a7cb6019f2347add44f2dc6b35f4c7

With this configuration, I do have a proper PPM rendering the elevation surface correctly.

in reply to: 15 comment:16 by hcho, 6 years ago

Replying to epifanio:

Double checking I've the right changes applied to the right files, here is a gist of the previous files:

https://gist.github.com/c6a7cb6019f2347add44f2dc6b35f4c7

With this configuration, I do have a proper PPM rendering the elevation surface correctly.

I'm confused. Do you mean that the files in the gist work for you? That's basically trunk + debug outputs.

In your last test, you drew to the front buffer without swapping (different from your gist). Did they both work for you?

in reply to: 14 ; follow-up: 18 comment:17 by hcho, 6 years ago

Replying to cmbarton:

When this is at a point where it seems to be working on Windows, let me know and I'll recompile it for the Mac and test some more.

r72997 works on Windows at least for me, but no changes to the Mac code.

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

in reply to: 17 comment:18 by hcho, 6 years ago

Replying to hcho:

Replying to cmbarton:

When this is at a point where it seems to be working on Windows, let me know and I'll recompile it for the Mac and test some more.

r72997 works on Windows at least for me, but no changes to the Mac code.

Check this code from https://www.panda3d.org/reference/1.7.2/cxx/osxGraphicsBuffer.cxx_source.php

if (_pbuffer == NULL) {
     GLenum target = GL_TEXTURE_RECTANGLE_ARB;
     if (_x_size == Texture::up_to_power_2(_x_size) && 
         _y_size == Texture::up_to_power_2(_x_size)) {
       // It's a power-of-two size, so we can use GL_TEXTURE_2D as the
       // target.  Dunno, but maybe this will be more likely to work on
       // some hardware.
       target = GL_TEXTURE_2D;
     }
     if (!aglCreatePBuffer(_x_size, _y_size, target, GL_RGBA, 0, &_pbuffer)) {
       report_agl_error("aglCreatePBuffer");
       close_buffer();
       return false;
     }

They use GL_TEXTURE_RECTANGLE_ARB for non-powers of 2 size and GL_TEXTURE_2D for powers of 2. Probably, you can try GL_TEXTURE_RECTANGLE_ARB in line 146 in lib/nviz/render.c. Wish I had a Mac. :-(

follow-up: 20 comment:19 by cmbarton, 6 years ago

Just compiled and tested on Mac with trunk r72998. It creates a solid black image in both PPM and TIF.

in reply to: 19 comment:20 by hcho, 6 years ago

Replying to cmbarton:

Just compiled and tested on Mac with trunk r72998. It creates a solid black image in both PPM and TIF.

Used Homebrew to install dependencies and compiled trunk r72999 on macOS 10.12 Sierra. It worked for me (attached).

Version 0, edited 6 years ago by hcho (next)

by hcho, 6 years ago

Attachment:	screenshot.png added

comment:21 by hcho, 6 years ago

Resolution:	→ fixed
Status:	new → closed

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:22 by martinl, 6 years ago

Milestone:	→ 7.6.0

comment:23 by martinl, 6 years ago

Milestone set to 7.6. Please consider changing to 7.4 and do backport (see related issues).

comment:24 by hcho, 6 years ago

Milestone:	7.6.0 → 7.4.2

Backported to 7.2 & 7.4.

Note: See TracTickets for help on using tickets.

Download in other formats: