[GRASS5] NVIZ updates

GRASS GRASS developer
1

Hello,

I have applied a few updates / bug fixes to the ogsf library and NVIZ. The updates / fixes include the following:

1. I have optimized the surface rendering routine to use a TRIANGLE_FAN along with a few other optimizations. In the tests I ran this improved surface drawing time by about a factor of four. This of course depends upon the surface being renderred and the zoom level.

2. I have added a new wire frame option (now the default) that draws a sub-sampled (coarse) surface instead of the wire. To accomadate this I have re-arranged the surface panel and added the drawing options as pull-down menus. There is now a pull-down menu for the old "Surface Style" and "Shading" options plus the new option for "Grid Style". Under "Grid Style" the user may now select to draw the coarse surface or the old wire surface. In reference to the new coarse surface, the resolution is controlled by the "Grid Resolution" number. This number represents the sub-sampling ratio of the current surface. A Grid Resolution of 1 would draw every (identical) full surface pixel. A Grid Resolution of 2 would draw every second pixel, and so on. This new drawing routine also allows animations to run in this coarse mode.

3. I have added a new "position" panel to the available panels list (under Panel). This new panel allows the user to manually enter the center and eye positions (XYZ) in real coordinates and apply them. There is also an available Range/Bearing section that allows the user to set a range and bearing to either the cente or eye positions.

To use the menu select the Refresh button to update each entry box to the current position. To apply newly entered coordinates and and update the GUI select the Apply button. To use the Range/Bearing options select the Refesh button (if not already selected), and choose the appropriate reference radiobutton. The options are to apply range and bearing to "Eye to Surface" which moves the view center while leaving the eye position unchanged or "Surface to Eye" which changes the eye position while leaving the center position unchanged. The second "Surface to Eye" option is alittle easier to use as you are less likly to move the surface completely out of view. After choosing the appropriate reference enter a new Range, Bearing (in degrees) and Elevation (in degrees). The elevation sets the angle you are looking down at the surface. After entering the new values select Calculate to generate the new coordinates and Apply to the apply new coordinates.

This new menu will probably need further updating / debugging.

4. I have fixed a couple of bugs in the kanimator panel where the new key time was not being set correctly and duplicate key tags were not being weeded out. The duplicate key tags led to unpredictable behavious in the kanimator GUI.

If you have any questions or problems with the above updates please let know.

--
Bob Covill

2

Bob,

I updated my CVS GRASS with your nviz updates and nviz crashes
when I give it an elevation file - either on the command line or
through the interface - when it is computing the normals.
It runs OK if I open it as nviz -q and give it just a constant (plane) surface.
I will try with some other data, but maybe somebody else could try it too
to see whether it is my data or a bug. (the data worked fine with the previous
version of nviz).

Also, how do you have this linked with GRASS5.7 - are you maintaining two separate versions?

thank you,

Helena

Loading Data
translating colors from fp
global-exag = 1.000000
recalculating normals...
100
200
child killed: segmentation violation
     while executing
"exec /home/helena/grasscvs53/grass5/etc/nviz2.2/NVWISH2.2 -f /home/helena/grasscvs53/grass5/etc/nviz2.2/scripts/nviz2.2_script -q -name NVIZ >&@stdout"
     ("eval" body line 1)
     invoked from within
"eval exec $env(GISBASE)/etc/nviz2.2/NVWISH2.2 -f $env(GISBASE)/etc/nviz2.2/scripts/nviz2.2_script $argv -name NVIZ >&@stdout"
     invoked from within
"if {$argv == ""} {
#no arguments
eval exec $env(GISBASE)/etc/nviz2.2/NVWISH2.2 -f $env(GISBASE)/etc/nviz2.2/scripts/nviz2.2_script -name NVIZ >&@stdo..."
     (file "/home/helena/grasscvs53/grass5/bin/nviz" line 16)

  The error message Bob Covill wrote:

Hello,

I have applied a few updates / bug fixes to the ogsf library and NVIZ. The updates / fixes include the following:

1. I have optimized the surface rendering routine to use a TRIANGLE_FAN along with a few other optimizations. In the tests I ran this improved surface drawing time by about a factor of four. This of course depends upon the surface being renderred and the zoom level.

2. I have added a new wire frame option (now the default) that draws a sub-sampled (coarse) surface instead of the wire. To accomadate this I have re-arranged the surface panel and added the drawing options as pull-down menus. There is now a pull-down menu for the old "Surface Style" and "Shading" options plus the new option for "Grid Style". Under "Grid Style" the user may now select to draw the coarse surface or the old wire surface. In reference to the new coarse surface, the resolution is controlled by the "Grid Resolution" number. This number represents the sub-sampling ratio of the current surface. A Grid Resolution of 1 would draw every (identical) full surface pixel. A Grid Resolution of 2 would draw every second pixel, and so on. This new drawing routine also allows animations to run in this coarse mode.

3. I have added a new "position" panel to the available panels list (under Panel). This new panel allows the user to manually enter the center and eye positions (XYZ) in real coordinates and apply them. There is also an available Range/Bearing section that allows the user to set a range and bearing to either the cente or eye positions.

To use the menu select the Refresh button to update each entry box to the current position. To apply newly entered coordinates and and update the GUI select the Apply button. To use the Range/Bearing options select the Refesh button (if not already selected), and choose the appropriate reference radiobutton. The options are to apply range and bearing to "Eye to Surface" which moves the view center while leaving the eye position unchanged or "Surface to Eye" which changes the eye position while leaving the center position unchanged. The second "Surface to Eye" option is alittle easier to use as you are less likly to move the surface completely out of view. After choosing the appropriate reference enter a new Range, Bearing (in degrees) and Elevation (in degrees). The elevation sets the angle you are looking down at the surface. After entering the new values select Calculate to generate the new coordinates and Apply to the apply new coordinates.

This new menu will probably need further updating / debugging.

4. I have fixed a couple of bugs in the kanimator panel where the new key time was not being set correctly and duplicate key tags were not being weeded out. The duplicate key tags led to unpredictable behavious in the kanimator GUI.

If you have any questions or problems with the above updates please let know.

3

I should have done more before writing - it runs OK with Spearfish
and the new option with coarse rendered grid is realy,realy nice.
So I will try to find out why it crashes with the other data, maybe others can try too.

Helena

Helena wrote:

Bob,

I updated my CVS GRASS with your nviz updates and nviz crashes
when I give it an elevation file - either on the command line or
through the interface - when it is computing the normals.
It runs OK if I open it as nviz -q and give it just a constant (plane) surface.
I will try with some other data, but maybe somebody else could try it too
to see whether it is my data or a bug. (the data worked fine with the previous
version of nviz).

Also, how do you have this linked with GRASS5.7 - are you maintaining two separate versions?

thank you,

Helena

Loading Data
translating colors from fp
global-exag = 1.000000
recalculating normals...
100
200
child killed: segmentation violation
    while executing
"exec /home/helena/grasscvs53/grass5/etc/nviz2.2/NVWISH2.2 -f /home/helena/grasscvs53/grass5/etc/nviz2.2/scripts/nviz2.2_script -q -name NVIZ >&@stdout"
    ("eval" body line 1)
    invoked from within
"eval exec $env(GISBASE)/etc/nviz2.2/NVWISH2.2 -f $env(GISBASE)/etc/nviz2.2/scripts/nviz2.2_script $argv -name NVIZ >&@stdout"
    invoked from within
"if {$argv == ""} {
#no arguments
eval exec $env(GISBASE)/etc/nviz2.2/NVWISH2.2 -f $env(GISBASE)/etc/nviz2.2/scripts/nviz2.2_script -name NVIZ >&@stdo..."
    (file "/home/helena/grasscvs53/grass5/bin/nviz" line 16)

The error message Bob Covill wrote:

Hello,

I have applied a few updates / bug fixes to the ogsf library and NVIZ. The updates / fixes include the following:

1. I have optimized the surface rendering routine to use a TRIANGLE_FAN along with a few other optimizations. In the tests I ran this improved surface drawing time by about a factor of four. This of course depends upon the surface being renderred and the zoom level.

2. I have added a new wire frame option (now the default) that draws a sub-sampled (coarse) surface instead of the wire. To accomadate this I have re-arranged the surface panel and added the drawing options as pull-down menus. There is now a pull-down menu for the old "Surface Style" and "Shading" options plus the new option for "Grid Style". Under "Grid Style" the user may now select to draw the coarse surface or the old wire surface. In reference to the new coarse surface, the resolution is controlled by the "Grid Resolution" number. This number represents the sub-sampling ratio of the current surface. A Grid Resolution of 1 would draw every (identical) full surface pixel. A Grid Resolution of 2 would draw every second pixel, and so on. This new drawing routine also allows animations to run in this coarse mode.

3. I have added a new "position" panel to the available panels list (under Panel). This new panel allows the user to manually enter the center and eye positions (XYZ) in real coordinates and apply them. There is also an available Range/Bearing section that allows the user to set a range and bearing to either the cente or eye positions.

To use the menu select the Refresh button to update each entry box to the current position. To apply newly entered coordinates and and update the GUI select the Apply button. To use the Range/Bearing options select the Refesh button (if not already selected), and choose the appropriate reference radiobutton. The options are to apply range and bearing to "Eye to Surface" which moves the view center while leaving the eye position unchanged or "Surface to Eye" which changes the eye position while leaving the center position unchanged. The second "Surface to Eye" option is alittle easier to use as you are less likly to move the surface completely out of view. After choosing the appropriate reference enter a new Range, Bearing (in degrees) and Elevation (in degrees). The elevation sets the angle you are looking down at the surface. After entering the new values select Calculate to generate the new coordinates and Apply to the apply new coordinates.

This new menu will probably need further updating / debugging.

4. I have fixed a couple of bugs in the kanimator panel where the new key time was not being set correctly and duplicate key tags were not being weeded out. The duplicate key tags led to unpredictable behavious in the kanimator GUI.

If you have any questions or problems with the above updates please let know.

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

4

Helena,

This seems to be a bit of a mystery. There is nothing new with the calculation of normals in the new release. The only thing I changed (removed) was the forced recalculation of normals if the z-exag. was changed. This was not necessary as the z-exag. is not used in the calculation.

The new coarse surface is simply a sub-sampling of the full resolution surface. It simply goes through the current full res. surface picking up the elevation and associated normal at the specified interval (mesh resolution).

I am wondering if the problem you are experiencing is in the actual coarse surface drawing loop? Some sort of mathmatical overrun with a certain combination of surface and mesh resolutions?

Would it be possible to get a bit more information on the projection, current region, and map type. A sample of the problem data would also be quite helpful.

--

Bob Covill

Helena wrote:

Bob,

It crashes at 1m and 2m resolution, it runs fine with the same file with 10m resolution,
it starts OK with 5m or 3m resolution but crashes when I change the grid size parameter from 1 to 4.
It will run OK if I increase the grid parameter and change to mesh - so it seems that the problem
is with computation of normals for the coarse surface.

I hope that this helps to find the fix,

Helena

menubar made
bgerror failed to handle background error.
    Original error: too many nested calls to Tcl_Eval (infinite loop?)
    Error in bgerror: too many nested calls to Tcl_EvalObj (infinite loop?)
bgerror failed to handle background error.
    Original error: too many nested calls to Tcl_Eval (infinite loop?)
    Error in bgerror: too many nested calls to Tcl_EvalObj (infinite loop?)
child killed: segmentation violation
    while executing
"exec /home/helena/grasscvs53/grass5/etc/nviz2.2/NVWISH2.2 -f /home/helena/grasscvs53/grass5/etc/nviz2.2/scripts/nviz2.2_script lidar99 -name NVIZ >&@s..."
    ("eval" body line 1)
    invoked from within
"eval exec $env(GISBASE)/etc/nviz2.2/NVWISH2.2 -f $env(GISBASE)/etc/nviz2.2/scripts/nviz2.2_script $argv -name NVIZ >&@stdout"
    invoked from within
"if {$argv == ""} {
#no arguments
eval exec $env(GISBASE)/etc/nviz2.2/NVWISH2.2 -f $env(GISBASE)/etc/nviz2.2/scripts/nviz2.2_script -name NVIZ >&@stdo..."
    (file "/home/helena/grasscvs53/grass5/bin/nviz" line 16)

bgerror failed to handle background error.
    Original error: too many nested calls to Tcl_Eval (infinite loop?)
    Error in bgerror: too many nested calls to Tcl_EvalObj (infinite loop?)
bgerror failed to handle background error.
    Original error: too many nested calls to Tcl_Eval (infinite loop?)
    Error in bgerror: too many nested calls to Tcl_EvalObj (infinite loop?)
bgerror failed to handle background error.
    Original error: too many nested calls to Tcl_EvalObj (infinite loop?)
    Error in bgerror: too many nested calls to Tcl_Eval (infinite loop?)

Helena wrote:

I should have done more before writing - it runs OK with Spearfish
and the new option with coarse rendered grid is realy,realy nice.
So I will try to find out why it crashes with the other data, maybe others can try too.

Helena

Helena wrote:

Bob,

I updated my CVS GRASS with your nviz updates and nviz crashes
when I give it an elevation file - either on the command line or
through the interface - when it is computing the normals.
It runs OK if I open it as nviz -q and give it just a constant (plane) surface.
I will try with some other data, but maybe somebody else could try it too
to see whether it is my data or a bug. (the data worked fine with the previous
version of nviz).

Also, how do you have this linked with GRASS5.7 - are you maintaining two separate versions?

thank you,

Helena

Loading Data
translating colors from fp
global-exag = 1.000000
recalculating normals...
100
200
child killed: segmentation violation
    while executing
"exec /home/helena/grasscvs53/grass5/etc/nviz2.2/NVWISH2.2 -f /home/helena/grasscvs53/grass5/etc/nviz2.2/scripts/nviz2.2_script -q -name NVIZ >&@stdout"
    ("eval" body line 1)
    invoked from within
"eval exec $env(GISBASE)/etc/nviz2.2/NVWISH2.2 -f $env(GISBASE)/etc/nviz2.2/scripts/nviz2.2_script $argv -name NVIZ >&@stdout"
    invoked from within
"if {$argv == ""} {
#no arguments
eval exec $env(GISBASE)/etc/nviz2.2/NVWISH2.2 -f $env(GISBASE)/etc/nviz2.2/scripts/nviz2.2_script -name NVIZ >&@stdo..."
    (file "/home/helena/grasscvs53/grass5/bin/nviz" line 16)

The error message Bob Covill wrote:

Hello,

I have applied a few updates / bug fixes to the ogsf library and NVIZ. The updates / fixes include the following:

1. I have optimized the surface rendering routine to use a TRIANGLE_FAN along with a few other optimizations. In the tests I ran this improved surface drawing time by about a factor of four. This of course depends upon the surface being renderred and the zoom level.

2. I have added a new wire frame option (now the default) that draws a sub-sampled (coarse) surface instead of the wire. To accomadate this I have re-arranged the surface panel and added the drawing options as pull-down menus. There is now a pull-down menu for the old "Surface Style" and "Shading" options plus the new option for "Grid Style". Under "Grid Style" the user may now select to draw the coarse surface or the old wire surface. In reference to the new coarse surface, the resolution is controlled by the "Grid Resolution" number. This number represents the sub-sampling ratio of the current surface. A Grid Resolution of 1 would draw every (identical) full surface pixel. A Grid Resolution of 2 would draw every second pixel, and so on. This new drawing routine also allows animations to run in this coarse mode.

3. I have added a new "position" panel to the available panels list (under Panel). This new panel allows the user to manually enter the center and eye positions (XYZ) in real coordinates and apply them. There is also an available Range/Bearing section that allows the user to set a range and bearing to either the cente or eye positions.

To use the menu select the Refresh button to update each entry box to the current position. To apply newly entered coordinates and and update the GUI select the Apply button. To use the Range/Bearing options select the Refesh button (if not already selected), and choose the appropriate reference radiobutton. The options are to apply range and bearing to "Eye to Surface" which moves the view center while leaving the eye position unchanged or "Surface to Eye" which changes the eye position while leaving the center position unchanged. The second "Surface to Eye" option is alittle easier to use as you are less likly to move the surface completely out of view. After choosing the appropriate reference enter a new Range, Bearing (in degrees) and Elevation (in degrees). The elevation sets the angle you are looking down at the surface. After entering the new values select Calculate to generate the new coordinates and Apply to the apply new coordinates.

This new menu will probably need further updating / debugging.

4. I have fixed a couple of bugs in the kanimator panel where the new key time was not being set correctly and duplicate key tags were not being weeded out. The duplicate key tags led to unpredictable behavious in the kanimator GUI.

If you have any questions or problems with the above updates please let know.

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

5

Helena,

I have applied a fix to CVS that corrects (hopefully) the NVIZ bug you reported.

The problem was with surfaces being loaded that contained no null values . The new coarse surface (wire) routine was causing a crash. Apparently if a null mask is created it is much more forgiving if one isn't (i.e. no nulls).

The fixed gsd_wire.c in src/libes/ogsf should correct the bug.

To test update your ogsf and rebuild NVIZ.

Let me know if you encounter any more problems, etc.

Thanks for catching this.

--
Bob Covill

6

Bob,

it seems to be only partially fixed.
There is still a problem when increasing the Grid for the coarse surface.
If you take Spearfish and zoom in (e.g. into an area such as below)
it starts with Grid=1, when I change Grid to 2 I get artificial extremely high
spikes at the north edge of the surface when I move the surface around,
then I increase Grid to 3
and I get again spikes, just a little bit different because of resolution,
it does the same until at Grid 6 it crashes. These spikes were not there before -
it just crashed right away. It almost looks like it is not getting the right
number of rows or something related to that.

Helena

north: 4923630
south: 4915200
west: 597360
east: 604350
nsres: 30
ewres: 30
rows: 281
cols: 233

Bob Covill wrote:

Helena,

I have applied a fix to CVS that corrects (hopefully) the NVIZ bug you reported.

The problem was with surfaces being loaded that contained no null values . The new coarse surface (wire) routine was causing a crash. Apparently if a null mask is created it is much more forgiving if one isn't (i.e. no nulls).

The fixed gsd_wire.c in src/libes/ogsf should correct the bug.

To test update your ogsf and rebuild NVIZ.

Let me know if you encounter any more problems, etc.

Thanks for catching this.

--
Bob Covill

7

Hello Bob
Before the 5.3.0 release it will be good to get NVIZ back so that it
compiles under Cygwin. There are some glX functions used that appear to be
non-standard. I mentioned this before I think but here are the actual
compile errors:

/cygdrive/g/release/530/grass/bin.i686-pc-cygwin/gmake5 /cygdrive/g/release/530/grass/src.contrib/GMSL/NVIZ2.2/src
  SRC = /cygdrive/g/release/530/grass/src
  CMD = /cygdrive/g/release/530/grass/src/CMD
  UNUSED = /cygdrive/g/release/530/grass/unused
  HEADER = head.i686-pc-cygwin
  ARCH = i686-pc-cygwin
  GISBASE = /cygdrive/g/release/530/grass/dist.i686-pc-cygwin
  VERSION = 5.3-cvs 2003
#################################################################
/cygdrive/g/release/530/grass/src.contrib/GMSL/NVIZ2.2/src
  make -f OBJ.i686-pc-cygwin/make.rules

make[1]: Entering directory `/cygdrive/g/release/530/grass/src.contrib/GMSL/NVIZ2.2/src'
gcc -L/cygdrive/g/release/530/grass/src/libes/LIB.i686-pc-cygwin -o nvwish OBJ.i686-pc-cygwin/nvizAppInit.o OBJ.i686-pc-cygwin/change_view.o OBJ.i686-pc-cygwin/draw.o OBJ.i686-pc-cygwin/exag.o OBJ.i686-pc-cygwin/glwrappers.o OBJ.i686-pc-cygwin/init_commands.o OBJ.i686-pc-cygwin/lights.o OBJ.i686-pc-cygwin/map_obj.o OBJ.i686-pc-cygwin/misc.o OBJ.i686-pc-cygwin/nviz_init.o OBJ.i686-pc-cygwin/position.o OBJ.i686-pc-cygwin/quick_draw.o OBJ.i686-pc-cygwin/anim_support.o OBJ.i686-pc-cygwin/cutplane_obj.o OBJ.i686-pc-cygwin/script_support.o OBJ.i686-pc-cygwin/do_zoom.o OBJ.i686-pc-cygwin/label.o OBJ.i686-pc-cygwin/nvizMain.o OBJ.i686-pc-cygwin/togl.o OBJ.i686-pc-cygwin/togl_cb.o OBJ.i686-pc-cygwin/query_postgr.o OBJ.i686-pc-cygwin/openvect.o OBJ.i686-pc-cygwin/getCat.o OBJ.i686-pc-cygwin/buildPg.o OBJ.i686-pc-cygwin/runPg.o /cygdrive/g/release/530/grass/src/libes/ogsf/LIB.i686-pc-cygwin/libgsf.a /cygdrive/g/release/530/grass/src/libes/libimage/LIB.i686-pc-cygwin/libimage.a \
-lbitmap -llinkm -lvect -ldig2 \
-lgis -lintl -lrpclib -lz \
-ldatetime -ltk -ltcl -lGLU -lGL -lSM -lICE -lX11 -lXmu -lXext -lrpclib -lz -L/usr/X11R6/lib -ltiff -lSM -lICE -lX11
OBJ.i686-pc-cygwin/do_zoom.o: In function `Create_OS_Ctx':
/cygdrive/g/release/530/grass/src.contrib/GMSL/NVIZ2.2/src/do_zoom.c:275: undefined reference to `glXChooseFBConfig'
/cygdrive/g/release/530/grass/src.contrib/GMSL/NVIZ2.2/src/do_zoom.c:287: undefined reference to `glXCreatePbuffer'
/cygdrive/g/release/530/grass/src.contrib/GMSL/NVIZ2.2/src/do_zoom.c:288: undefined reference to `glXMakeContextCurrent'
OBJ.i686-pc-cygwin/do_zoom.o: In function `Destroy_OS_Ctx':
/cygdrive/g/release/530/grass/src.contrib/GMSL/NVIZ2.2/src/do_zoom.c:351: undefined reference to `glXDestroyPbuffer'
collect2: ld returned 1 exit status
make[1]: *** [nvwish] Error 1
make[1]: Leaving directory `/cygdrive/g/release/530/grass/src.contrib/GMSL/NVIZ2.2/src'
make: *** [nvwish] Error 2

5.0.3 compiles OK.

Paul

8

Paul Kelly wrote:

Before the 5.3.0 release it will be good to get NVIZ back so that it
compiles under Cygwin. There are some glX functions used that appear to be
non-standard. I mentioned this before I think but here are the actual
compile errors:

OBJ.i686-pc-cygwin/do_zoom.o: In function `Create_OS_Ctx':
/cygdrive/g/release/530/grass/src.contrib/GMSL/NVIZ2.2/src/do_zoom.c:275: undefined reference to `glXChooseFBConfig'
/cygdrive/g/release/530/grass/src.contrib/GMSL/NVIZ2.2/src/do_zoom.c:287: undefined reference to `glXCreatePbuffer'
/cygdrive/g/release/530/grass/src.contrib/GMSL/NVIZ2.2/src/do_zoom.c:288: undefined reference to `glXMakeContextCurrent'
OBJ.i686-pc-cygwin/do_zoom.o: In function `Destroy_OS_Ctx':
/cygdrive/g/release/530/grass/src.contrib/GMSL/NVIZ2.2/src/do_zoom.c:351: undefined reference to `glXDestroyPbuffer'

In my copy of GL/glx.h, those functions are preceded by the comment:

  /* New for GLX 1.3 */

So, any code which uses those functions should probably be
conditionalised upon GLX_VERSION_1_3.

However, all of the lines which produce errors *are* conditionalised
upon GLX_PBUFFER_WIDTH. That macro is also specific to GLX 1.3.

This suggests that the GL headers don't match the GL libraries (GLX
1.3 headers with pre-1.3 libraries). In which case, even if the code
was conditionalised upon the correct macro, it would probably still
fail for you.

It may be an installation problem, or it may be that you have multiple
OpenGL packages installed (e.g. both Mesa and XFree86) and the build
is using the headers from one and the libraries from another. [Your
output only shows the link command, and not the compilation commands,
so I don't know which -I switches were being used.]

If it's the latter, I'm not sure whether there is a realistic fix, in
the sense of changes which could be made to the configure script or
the build system.

A generic workaround for problems caused by having multiple versions
of a package is to create private header and library directories which
include symlinks to the actual files which should be used, then
specify those directories when configuring.

--
Glynn Clements <glynn.clements@virgin.net>

9

On Tue, Nov 18, 2003 at 05:49:21PM +0000, Glynn Clements wrote:

Paul Kelly wrote:

> Before the 5.3.0 release it will be good to get NVIZ back so that it
> compiles under Cygwin. There are some glX functions used that appear to be
> non-standard. I mentioned this before I think but here are the actual
> compile errors:

> OBJ.i686-pc-cygwin/do_zoom.o: In function `Create_OS_Ctx':
> /cygdrive/g/release/530/grass/src.contrib/GMSL/NVIZ2.2/src/do_zoom.c:275: undefined reference to `glXChooseFBConfig'
> /cygdrive/g/release/530/grass/src.contrib/GMSL/NVIZ2.2/src/do_zoom.c:287: undefined reference to `glXCreatePbuffer'
> /cygdrive/g/release/530/grass/src.contrib/GMSL/NVIZ2.2/src/do_zoom.c:288: undefined reference to `glXMakeContextCurrent'
> OBJ.i686-pc-cygwin/do_zoom.o: In function `Destroy_OS_Ctx':
> /cygdrive/g/release/530/grass/src.contrib/GMSL/NVIZ2.2/src/do_zoom.c:351: undefined reference to `glXDestroyPbuffer'

In my copy of GL/glx.h, those functions are preceded by the comment:

  /* New for GLX 1.3 */

So, any code which uses those functions should probably be
conditionalised upon GLX_VERSION_1_3.

However, all of the lines which produce errors *are* conditionalised
upon GLX_PBUFFER_WIDTH. That macro is also specific to GLX 1.3.

This suggests that the GL headers don't match the GL libraries (GLX
1.3 headers with pre-1.3 libraries). In which case, even if the code
was conditionalised upon the correct macro, it would probably still
fail for you.

Instead of checking the GL version, couldn't we check if
glXDestroyPbuffer()
exists in the library with 'configure' (no idea how to do that, though)?

Markus

10

Markus Neteler wrote:

> > Before the 5.3.0 release it will be good to get NVIZ back so that it
> > compiles under Cygwin. There are some glX functions used that appear to be
> > non-standard. I mentioned this before I think but here are the actual
> > compile errors:
>
> > OBJ.i686-pc-cygwin/do_zoom.o: In function `Create_OS_Ctx':
> > /cygdrive/g/release/530/grass/src.contrib/GMSL/NVIZ2.2/src/do_zoom.c:275: undefined reference to `glXChooseFBConfig'
> > /cygdrive/g/release/530/grass/src.contrib/GMSL/NVIZ2.2/src/do_zoom.c:287: undefined reference to `glXCreatePbuffer'
> > /cygdrive/g/release/530/grass/src.contrib/GMSL/NVIZ2.2/src/do_zoom.c:288: undefined reference to `glXMakeContextCurrent'
> > OBJ.i686-pc-cygwin/do_zoom.o: In function `Destroy_OS_Ctx':
> > /cygdrive/g/release/530/grass/src.contrib/GMSL/NVIZ2.2/src/do_zoom.c:351: undefined reference to `glXDestroyPbuffer'
>
> In my copy of GL/glx.h, those functions are preceded by the comment:
>
> /* New for GLX 1.3 */
>
> So, any code which uses those functions should probably be
> conditionalised upon GLX_VERSION_1_3.
>
> However, all of the lines which produce errors *are* conditionalised
> upon GLX_PBUFFER_WIDTH. That macro is also specific to GLX 1.3.
>
> This suggests that the GL headers don't match the GL libraries (GLX
> 1.3 headers with pre-1.3 libraries). In which case, even if the code
> was conditionalised upon the correct macro, it would probably still
> fail for you.

Instead of checking the GL version, couldn't we check if
glXDestroyPbuffer()
exists in the library with 'configure' (no idea how to do that, though)?

1. A mismatch between library and headers should really be considered
fatal. We shouldn't be saying "well, the headers say it's GLX 1.3, but
the library says that it isn't, so we'll just continue as if you have
a valid GLX 1.2 setup". If configure checks this, it should only be so
that it can abort if a mismatch is detected.

2. Even if these functions exist within the library, any given X
server may or may not provide the necessary support. NVIZ shouldn't be
using GLX 1.3 features unless glXQueryVersion() indicates that the X
server suports GLX 1.3.

3. Binary releases shouldn't have a dependency upon GLX 1.3, even if
the build system supports it. Unfortunately, glXGetProcAddressARB()
isn't universally supported, so using that instead of calling
glXCreatePbuffer() etc directly doesn't really help; that would just
exchange one dependency for another.

For the time being, the safest solution is simply not to include the
do_zoom.c changes in any released version.

--
Glynn Clements <glynn.clements@virgin.net>

11

Markus,

I am no configure expert but this could be a route to follow.

I assume with configure you can build and execute a small program?
If so a program could be built that executes glXQueryVersion which returns the major and minor versions of the GLX server. The outcome of this would then be used to set the appropriate #ifdef flag.

This method should be much more accurate because it does not rely potentially misleading header files.

If this can be built into configure it will first have to check that OpenGL and GLX (and X) are installed. This may already be done?

--
Bob

Markus Neteler wrote:

On Tue, Nov 18, 2003 at 05:49:21PM +0000, Glynn Clements wrote:

Paul Kelly wrote:

Before the 5.3.0 release it will be good to get NVIZ back so that it
compiles under Cygwin. There are some glX functions used that appear to be
non-standard. I mentioned this before I think but here are the actual
compile errors:

OBJ.i686-pc-cygwin/do_zoom.o: In function `Create_OS_Ctx':
/cygdrive/g/release/530/grass/src.contrib/GMSL/NVIZ2.2/src/do_zoom.c:275: undefined reference to `glXChooseFBConfig'
/cygdrive/g/release/530/grass/src.contrib/GMSL/NVIZ2.2/src/do_zoom.c:287: undefined reference to `glXCreatePbuffer'
/cygdrive/g/release/530/grass/src.contrib/GMSL/NVIZ2.2/src/do_zoom.c:288: undefined reference to `glXMakeContextCurrent'
OBJ.i686-pc-cygwin/do_zoom.o: In function `Destroy_OS_Ctx':
/cygdrive/g/release/530/grass/src.contrib/GMSL/NVIZ2.2/src/do_zoom.c:351: undefined reference to `glXDestroyPbuffer'

In my copy of GL/glx.h, those functions are preceded by the comment:

/* New for GLX 1.3 */

So, any code which uses those functions should probably be
conditionalised upon GLX_VERSION_1_3.

However, all of the lines which produce errors *are* conditionalised
upon GLX_PBUFFER_WIDTH. That macro is also specific to GLX 1.3.

This suggests that the GL headers don't match the GL libraries (GLX
1.3 headers with pre-1.3 libraries). In which case, even if the code
was conditionalised upon the correct macro, it would probably still
fail for you.

Instead of checking the GL version, couldn't we check if
glXDestroyPbuffer()
exists in the library with 'configure' (no idea how to do that, though)?

Markus

12

On Wed, 19 Nov 2003, Markus Neteler wrote:

On Tue, Nov 18, 2003 at 05:49:21PM +0000, Glynn Clements wrote:
>

[...]

> So, any code which uses those functions should probably be
> conditionalised upon GLX_VERSION_1_3.
>
> However, all of the lines which produce errors *are* conditionalised
> upon GLX_PBUFFER_WIDTH. That macro is also specific to GLX 1.3.
>
> This suggests that the GL headers don't match the GL libraries (GLX
> 1.3 headers with pre-1.3 libraries). In which case, even if the code
> was conditionalised upon the correct macro, it would probably still
> fail for you.

Instead of checking the GL version, couldn't we check if
glXDestroyPbuffer()
exists in the library with 'configure' (no idea how to do that, though)?

We talked about all this before and decided checking GLX_PBUFFER_WIDTH was
the best idea, as that means the PBuffer functions are definitely there.
And that missing function *is* there in the header files on my Cygwin
system; there must be some other problem as Glynn suggested that I'll have
to look into.

Paul

13

Bob Covill wrote:

I am no configure expert but this could be a route to follow.

It isn't.

I assume with configure you can build and execute a small program?
If so a program could be built that executes glXQueryVersion which
returns the major and minor versions of the GLX server.

That only tells you about the X server which was available at build
time. If there even was one available.

glXQueryVersion *has* to be used at run-time. The same executable may
be used with multiple different X servers with differing versions of
the GLX extension.

The outcome of
this would then be used to set the appropriate #ifdef flag.

This method should be much more accurate because it does not rely
potentially misleading header files.

Configure checks aren't performed for their own sake; they're
performed in order to determine whether or not we can actually build
the programs.

Compiling the program depends upon having matching libraries and
header files. If the two don't match, we lose.

If this can be built into configure it will first have to check that
OpenGL and GLX (and X) are installed. This may already be done?

Configure already checks for X and OpenGL. Given some of the MacOSX
issues, it may be worth adding an additional check that the OpenGL
library is an X version rather than a Mac (agl*) version.

However, actually calling glXQueryVersion (etc) not only requires that
the relevant libraries are installed; it would require that an X
server was running and available at build time. The resulting binary
would then be based upon the specifics of that particular X server,
which may not be the one used at run-time.

There are two separate sets of dependencies here: a build-time
dependency upon the libraries and a run-time dependency upon the X
server. Both dependencies need to be checked at the proper times: the
build-time dependencies in the configure script and the run-time
dependencies within the program.

The other issue is that, just because the system on which NVIZ was
built happens to support GLX 1.3, it doesn't automatically follow that
the builder actually wants a version of NVIZ which won't run on
anything which doesn't support GLX 1.3.

--
Glynn Clements <glynn.clements@virgin.net>