Note: the newest version of this document is always available at http://www.iicm.edu/vrweb.FAQ.UNIX
Recently added or updated questions/answers are marked with *.
Did you follow the instructions on the installation page? Make sure to use binary ftp transfer mode. The binaries are distributed as gzipped executables (no tar necessary); some browsers cut off the extension. Compare the file size with the one listed in README-Unix.
If you download via your Web browser and you get the decompressed binary as text use the option "save link as" (typically available with the right mouse button).
If it is not listed on the VRweb home page: not as precompiled binary. However, you can compile the source yourself for your system (see Q&A's below if you have problems). These include also systems like Solaris x86, SCO UNIX, Novell Unixware. There were made some source code patches for the latter two, however the config files have not yet been upgraded.
Dec/Ultrix and Linux/Aout (upgrade to Linux/ELF) have been discontinued in version 1.5; there is now a BSDI version instead of FreeBSD. For further information see the VRweb home page and the table of supported platforms.
The User interface was translated into German, French, Italian, Spanish, Korean, and Japanese so far. Use the appropriate commandline argument -lang german|french|italian|spanish|korean|japanese. Up to now we did not have persons for translations into other languages or keeping Web pages and Help files up to date in other languages than English.
Please send mails to the VRweb mailing list in English only. Mails to the developers may be sent in either English or German.
Just VRweb, neither VRWeb, nor VR-web, nor VR-WEB, nor ... :-)
Follow the instructions on the installation page. Make sure to use the full file name in your ~/.mailcap, e.g. vrweb-1.0BetaX-SystemY when you did not rename the binary to a shorter name. The binary must have execution rights and must be found in your PATH or you have to include the full path of the binary. Yes, with your Web browser you need the vrweb... binary; no, you cannot use harscened without Harmony, it will just wait forever.
Copy the newest harscened version into $HARMONY_HOME/bin and rename it to harscened. Next time you start harmony it will use the new VRweb version.
Hyper-G servers support VRML scenes as integral document type. For other web servers you have to create a VRML mime type. It must declare VRML files as x-world/x-vrml. See also next question.
Again, Hyper-G servers are automatically prepared for this: gzipped VRML files are recognized as such. Be aware that there is no special mime-type for gzipped VRML data, instead the normal type x-world/x-vrml is used and the compression method x-gzip is reported as such. Look into the installation guide (part of the online help) for example mime type entries for different servers.
See also the VRML
FAQ for further information.
Both the UNIX and the Windows version of VRweb are able to gunzip
compressed VRML data themselves.
You are trying to run an OpenGL version on a non-OpenGL capable display. See also Question "What is Mesa?".
This occurs mainly for the Linux version (see also next question), where system header files change quite often. The error message looks like "using incompatible library '/lib/libm.so.4.5.XX' Desire minor version >= 6 and found 5" or: "Undefined C library function: light C shared image". You must either upgrade your OS or compile VRweb yourself. If you have problem finding the appropriate shared libraries, you can also contact us.
The Linux binary of VRweb 1.5 is distributed in ELF format; support for Aout has been discontinued (last binary: VRweb 1.3.2). If the Linux/ELF binary crashes on your machine, it is probably a shared library problem - see next question.
Old: Running AOUT versions under Linux ELF requires the X11 libraries in AOUT format (when they're missing you get the error message "can't load library '/usr/X11/lib/libXt.so.6' -- Exec format error"). If there is no libXt.so.6 (you can check which libs VRweb needs with the ldd command) in directory /usr/i486-linuxaout/lib, you should download the libs from ftp://sunsite.unc.edu/pub/Linux/X11/XFree86-3.1.2/a.out/X312lib.tgz (or your nearest sunsite mirror) and gunzip/untar them in /usr/i486-linuxaout.
Unfortunately, there seem to be compatibility problems (bugs?) among
different Linux shared library and kernel versions. Run
uname -a to get system information and
ldd vrweb to see resolved shared library references.
VRweb 1.5 was developed on a machine running kernel version 2.0.27 with the following shared library versions (crucial: libg++ and libc):
libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6.0 libXext.so.6 => /usr/X11R6/lib/libXext.so.6.1 libX11.so.6 => /usr/X11R6/lib/libX11.so.6.1 libg++.so.27 => /usr/lib/libg++.so.27.2.1 libstdc++.so.27 => /usr/lib/libstdc++.so.27.2.1 libm.so.5 => /lib/libm.so.5.0.6 libc.so.5 => /lib/libc.so.5.4.13 libXt.so.6 => /usr/X11R6/lib/libXt.so.6.0 libSM.so.6 => /usr/X11R6/lib/libSM.so.6.0 libICE.so.6 => /usr/X11R6/lib/libICE.so.6.0
VRweb 1.3.x had to be compiled with libg++-2.7.2.1 because of troubles with older libg++ / libc combinations. This libg++ version requires libc-5.4.7 or above, so please upgrade your shared libraries to that versions. If that is not possible for you, you may use the Linux/AOUT version of VRweb 1.3.2 (provided you have installed the X11 libs in AOUT format; see above) or compile the source code yourself.
On HPUX 9.01/9.05 machines you probably need to install system patch
number PHCO_7747 for the libc library. The error occurs
first on loading the icon images, you can turn them off with the
Xattribute Harmony.Scene*icons: off. (Other HPUX patches
we have installed are PHCO_5791, PHCO_6425, PHCO_7155).
Fetching of VRML worlds is done by your webbrowser which passes the document to VRweb. For Inline scenes and texture images, VRweb tries to connect directly via HTTP to the server, which is not possible behind firewalls.
Proxy support is implemented in VRweb 1.3. So you are able to get inlines/textures via a WWW proxy running on a firewall. Use option -proxy host:port for configuration (for details see the online help). Direct support for SOCKS in VRweb is not planned for the near future. See Options/Networks/Proxies for your configuration in netscape.
Korean strings require different encodings in the InterViews library, which is not fully implemented for all platforms yet: it is not yet supported on SunOS (however for Solaris); for PC/Unix platforms (Linux/FreeBSD) you need to download one of the binaries named vrweb-1.3-mesa-korean-* (which in turn do not support other 8bit languages).
To make it work, use vrweb -lang korean, set the LANG environment variable appropriately, and define appropriate font sets as indicated in SceneViewer.ad. Please note that we could make only few tests, because most of our machines do not have the necessary configurations.
For the above reasons, the new encodings are not yet part of the source code release. A Japanese GUI will probably follow in a future version.
This bug present in release 1.3 should be fixed in 1.3.1 now.
A bug slipped into the InterViews GUI library on supporting
international font sets, causing a crash when the default fonts are
not found. First try if vrweb -motif -font fixed
works. As you wont be happy with the fixed font, set Xattributes for
Harmony.Scene*font, Harmony*MenuBar.font,
Harmony*MenuItem.font, and optionally
Harmony*Button.font (see SceneViewer.ad).
Also this bug should be fixed in 1.3.1.
Implementation of Printing has relatively low priority, sorry. Making a screendump with xv and printing it is relatively simple (see also the question about screen dumps in the rendering questions at the bottom). A better approach would be an off-screen rendering which can be done at higher resolution and/or color depth. Direct generation of PostScript (true vector graphics, resolution independent) whould also be feasible, although harder.
Editing facilities are part of VRweb 1.5 (implemented by Alexander Nußbaumer). See the online help for features and limitations.
Here it is: it is included in the VRweb distribution as file help.tar.gz. Unpack it as described in README-Unix or the Installation page and browse install.html for installation instructions, and the main page vrwebhlp.html as user-guide when VRweb is running.
This is the X11 imake config file. We assume them to be installed in directory /usr/lib/X11/config. If it is on another place on your system, change this path in bin/scripts/hgmkmf (and on further occurances in the configuration files). When you have root access, you could also make a symbolic link from your X11 installation directory to /usr/lib/X11. Future VRweb config environments may no longer need this file.
This means you could eventually run into problems, because you have another OS release than we developed on (although there should be no troubles to expect). bin/scripts/hgimake will make the specific defines for the platform we compiled on, you may need to slightly modify them. Be sure to run hgmkmf -a again after any changes in configuration files or scripts to make changes take effect.
You will need to use GNU make to compile VRweb 1.2. Make sure it precedes your machine's native make command in the PATH. (We make use of some features of GNU make for proper RCS handling of our sources.)
Lets assume you have properly installed g++ and gcc-lib - you can test this by compiling a simple test program like
#include <iostream.h>
void main () { cout << "hello world"; }
The config environment of VRweb 1.2 did include the switch -V2.6.3 to eliminate problems specific to various gcc releases. If you never have installed gcc 2.6.3 you must remove this switch from config/gcc.def. VRweb 1.3 sources do no longer include the switch and were successfully compiled with g++ 2.7.2.
Note: this question only applies to releases before 1.2. If not handled properly by X11 config environment, define the X11 include directory (to be accurate, the parent of the X11 subdir) in config/params.h (somewhere at the beginning); e.g. on SUNs:
#define XIncDir /usr/openwin/include
This is a g++ bug. g++ seems to be confused about multiple level virtual base classes and protected member functions etc. The simplest workaround we found, is to insert a line "public:" into g++-include/streambuf.h to make the init function of class ios accessible to derived classes (very near to the end of class ios).
Newer releases of g++ have predefined constants for true and false. Go into vrweb/include/hyperg/utils/types.h and reactivate true and false definitons for g++ (should be near line 45).
This very strange error occured on a SUN, producing a lots of successive errors like "makedepend: [mM]akefile is not present". It happened that cpp was called in a wrong way or was not found by SUN's native make command. Try to use GNU make instead by having the path of it (`which gcc`) before /usr/ccs/bin.
An example for this may be "EXTRA_CCFLAGS = -Aa +ESlit" on HPUX machines. Such flags may come from X11 configuration files like /usr/lib/X11/config/[sys].cf or xparams.cf.
You can override it by defining the appropriate mixed-case definition for the preprocessor, e.g. #define ExtraCCFlags /**/ for the example above, in vrweb/config/iv-[sys].cf (append it at the end).
This error should no longer occur with the configuration environment introduced with VRweb 1.2.
These errors come from a #define accept naccept in sys/socket.h on AIX. If you have root access you may wish to remove this define in socket.h entirely. If not, add a line #undefine accept at the places the compiler reports the errors (rpcbuf, Socket, INETSocket).
This bug occurs when compiling Interviews with g++ 2.7.2 on Dec Alpha or Linux Alpha machines.
To fix it, go into directory vrweb/iicmviews/lib/IV/ALPHA_GNU,
remove file xcanvas.o and compile it without -O2. Therefore
either call make -n xcanvas.o and copy the g++ line without
the -O2 flag or remove the -O2 flag from CCDRIVER = g++ -O2
in the Makefile.
Then make libIV.a and link vrweb* in vrweb/scene/ALPHA_GNU.
We observed this occasionally, e.g. Mesa-2.1/src/readpix.c on Dec
Alpha. If there is no other specific error message, the error may go
away when compiling the appropriate source file without optimization.
Therefore change into the according directory (.../$CPU) and call
make. Copy and paste the failing compiler command line without any
-O flag and see if it works. Then run the makeall script
again to finish compilation.
Motif would imply a runtime licence and we like you to use VRweb for free. Also we made quite a lot changes and extensions to the original Interviews library, so we call it from now "IICM-Views". Also Interviews includes a very good and stable Dispatcher (at least since our adaptions :-). If you really hate Interviews you are invited to replace the user interface with another library - this is at least possible, as the Windows version of VRweb uses the MS window classes for the interface.
As they apply to both the Windows and UNIX version of VRweb they have
been moved to a "VRweb
VRML Rendering FAQ".
(See http://hyperg.iicm.tu-graz.ac.at/vrweb.FAQ.rendering.)
Mesa is a library that maps OpenGL graphic calls to the X-protocol. You need it to get VRweb displayed on a non-OpenGL capable machine. Mesa neither needs nor benefits from any special graphics hardware. Do not expect the mesa version to run at speed of a hardware acceleated OpenGL version (see also below how to "tune" the Mesa version to your environment).
We have compiled VRweb with OpenGL for SGI and Dec Alpha. (Almost) all SGI machines include OpenGL support. On Dec Alpha, OpenGL is part of the Open3D package. Run xdpyinfo on your display; it must list the extension "GLX" to be OpenGL capable. If you have OpenGL support on another platform and want to use it for VRweb, you will have to compile the source code yourself.
It means that Mesa is unable to allocate all colors it would like to. However these colors are approximated by the next available one, to get the best possible output - this is a very user-friendly behaviour as opposed to other programs.
To work against this, you can close other color intensive application before starting VRweb or starting VRweb first. See also the question dealing with visual selection below. If you wonder why you get this message twice, see about "tuning" for Mesa below.
VRweb does not change the color map between the main window (menus, buttons) and the OpenGL window to avoid color-map flashing. The drawback is that you may have to select an appropriate visual for the main window by hand when the buttons/menus look right, but the scene window shows up as "technicolor" or completely black. Most SGIs are able to manage multiple color maps, so this error rarely occurs there. On DEC Alpha 8bit displays you will need the argument -viusal TrueColor (having 3+3+2 bits for RGB).
Some SGI entry systems however only support a double buffered RGB visual with 4 bits (1+2+1 for RGB, with Z buffer in software), no multiple colormaps. In this case you must either select the appropriate visual for VRweb (-visual_id 0x..), or use single buffering, or use the slower mesa version, or upgrade graphics HW, or ...
You can use xglinfo to get more information about your configuration (available in source from ftp://sgigate.sgi.com/pub/opengl/contrib and as precompiled binary in the VRweb distribution, subdir utils). It is an extended version of xdpyinfo telling OpenGL Xvisual information. Then you can compare it to the visual selection of VRweb (run vrweb -verbose or vrweb -singlebuf -verbose).
For OpenGL, VRweb relies on the visual selection mechanism of OpenGL. It requires a double buffered TrueColor RGB visual with depth buffer. You may get a visual with greater color depth by using command line option -singlebuf (turns of double buffering).
For Mesa, VRweb always uses the default visual of your Xserver (it is listed with the xdpyinfo command). The advantage is that no color map flashing ("technicolor") occurs this way on 8 bit displays.
If you want VRweb to use another visual you can give the type with argument -visual (available: PseudoColor, TrueColor, DirectColor) or the exact visual id with argument -visual_id (e.g. 0x31, see xdpyinfo). Future versions may include an option for installing a private colormap. The MESA* environment variables used by other applications based on Mesa are not supported in this release (they are not part of the Mesa GL/GLU core libraries).
If scenes are too dark, the Mesa version offers a gamma correction (many scenes are originally designed for SGIs where Xservers do gamma correction). Set enironment variable MESA_GAMMA as described in the on-line help under "Display Settings". You may alternatively try to turn on the headlight and adjust its color.
If you have upgraded from earlier versions, you will have noticed that Mesa gets improved from version to version (VRweb 1.5 uses Mesa 2.1). However, of course, it cannot compete with hardware accelerated graphics systems. There are several aspects that determine how fast Mesa will be:
The default settings should give you almost the fastest display under most circumstances. For special situation however, you can experiment with the settings. By default, VRweb switches to wireframe while navigating through the scene.
A bit. With vrweb -getRemoteID you get the Xwindow ID of
a running VRweb instance on your screen, which you can pass to
xwd (X window dump; convertable with xv and netpbm
package) or to other X11 utility programs (e.g. xwininfo). Example:
#!/bin/sh for f do vrweb -remote $f & sleep 5 xwd -id `vrweb -getRemoteID` > $f.xwd done
Last updated: Michael Pichler, May 28, 1997.