Notes on
VRML1, VRML2, and X3D files
including notes
on viewers,
converters,
test/demo files
'whitedune' VRML2 viewer
and editor - GUI interface
Notes on
|
'whitedune' VRML2 viewer and editor - GUI interface |
! Note !
More notes on VRML1 , VRML2, and X3D files
may be added --- including notes on software
(viewers, converters, editors) and notes on
the file formats and features ---
if/when I re-visit this page.
< Go to Table of Contents, below. >
(Skip Introduction)
|
INTRODUCTION : This page is meant to be a collection place for notes on the VRML1 and VRML2 (and SGI Inventor) file formats --- and the follow-on X3D file format, based on XML. For a nice introduction to the history of the VRML1 and VRML2 (= VRML97) file formats, you can see the Wikipedia page on VRML.
My background on 3D viewers and converters : I spent about 10 years (about 1995 to 2004) working on SGI (Silicon Graphics) Unix workstations, installing and supporting software for engineering purposes --- especially Finite Element Analysis and for Large Scale Visualization. About 1993 to 1998 were the 'boom years' for SGI. During that time, their talented people had come out with the Inventor file format for 3D models --- with lighting and some built-in animation capabilities included in the format specification. VRML 1 was a subset of the Inventor specification. In those years working on SGI workstations, I had a few opportunities to try out the SGI Cosmoplayer plug-in for the Netscape web browser --- to see some of the VRML2 file capabilities, including animated files and the ability to 'grab' VRML objects with the mouse and drag them along 'constraint lines'. I was in a position to get to try out the SGI 'ivview' and 'Cosmoplayer' programs on various demo Inventor and VRML files. It seemed like there was a lot of potential there --- in the advertising and presentations world, as well as in the engineering world. Fizzling Out Unfortunately, that potential seems to have fizzled out. I think it is partly due to mistakes made in implementing the 'Cosmoplayer' viewer --- only as a web browser plug-in and not as a stand-alone viewer. One reason the PDF document format 'took off' is because Adobe provided (for free) a stand-alone viewer of PDF files --- as well as PDF-reader plug-ins for web browsers. SGI should have done the same. It would have been pretty easy for SGI to 'fork' the Cosmoplayer plug-in to a stand-alone VRML file player program. Another mistake SGI made is that VRML1 and VRML2 were different --- that is, VRML1 was not a subset of VRML2. So a VRML2 'player' could not 'play' VRML1 files. There was a lot of confusion generated because SGI would often use the term VRML when sometimes it was referring to VRML1 format and other times it was referring to the VRML2 format. People would often use the same file suffix for VRML1 and VRML2 files. SGI should have made the distinction clearer instead of muddying the waters. SAD!
In any case: Instead of using the 'Table of Contents', you can use a 'Find Text in Page' option of your web browser to look for keywords on this page --- such as 'vrml' or 'vrml1' or 'vrml2' or vrml97' or 'wrl'. |
|
VRML1 vs. VRML2 : < Go to Table of Contents, above. > There is a site of VRML info, 'VRMLworks', by Bob Crispen, that has been in existence for over 10 years. It has many dead links to old archival sites of VRML info and files. Just in case the Crispen site goes dead, I extract and present here a few notes of interest from that site. Here is a table, from Crispen, summarizing the differing features of the VRML1 and VRML2 file formats. As Crispen says, ... "Briefly, VRML 1.0 worlds are static. VRML 2.0 worlds can move and interact with the visitor to those worlds. Here's a summary:"
Although file suffixes for VRML1 and VRML2 files may vary, the first line of VRML1 files will usually look like #VRML V1.0 ascii and the first line of VRML2 files will usually look like #VRML V2.0 utf8 |
|
VRML viewers, on Linux < Go to Table of Contents, above. > Here are some of my notes on 3D VRML viewers that I have installed on Linux (Ubuntu 9.10 or thereafter) :
I generally stay away from Java-based code --- especially for 3D, not only for performance reasons but because I cannot find any Debian or Ubuntu-Debian packages for 3D viewers based on Java. Java 3D viewers seem to be problematic. But I provide links to such Java-based VRML viewers here --- if only as a reminder that they exist. Besides 'freeWRL' (mentioned above), here is another --- but it does not seem to have Debian or Ubuntu install packages either --- nor have I run across any screenshots of it.
The Java 'write-once, run anywhere' IDEA is a nice one --- in theory. One of the problems, however, is getting Java-engines [byte-code interpreters] that run with no problems on your particular machine --- with its windowing system and its 3D video card. Java is basically taking a very, very complex area --- and 3D graphics programming adds another layer of complexity --- another layer of things that can go wrong --- to that already complex situation. One thing that may 'push Java along' is the fact that Google seems to do a lot of code developement in Java --- especially for their Android operating system for cell phones. On 3D viewer source code : You will find that 3D viewer programs are usually written in C++ rather than C --- probably because of the GUI routines and 3D graphics routines being done with C++. Often one sees that programs that do not need GUI libraries or 3D graphics libraries (such as number-cruncher programs) are written in C, rather than C++. There are a few 3D viewer programs done in Java. But it seems that they are problematic and end up being dropped out of Debian and Ubuntu package libraries --- or never make it into their libraries. Examples: freeWRL and Xj3D. Source code and binary executables for 3D viewers : For more detail on source and binaries for these and other 3D viewers that are available for Linux, there are source and binary files (and links to sources of those files) on my separate Notes on 3D viewers page. |
|
The 'ivview' installation, < Go to Table of Contents, above. > When I looked for 'inventor' and 'ivview' in the keyword search facility of the Ubuntu Software Center of my Ubuntu 9.10 (Karmic) installation, I got no hits. But I was able to install from linuxappfinder.com/package/inventor-clients. On that web page, I clicked on the Ubuntu 32-bit Karmic link ('2.1.5-10-12ubuntu2') and the 'Gdebi' utility came up as the default 'opener' program. The 'Gdebi' install went smoothly (I simply watched messages in the installer GUI), and 'ivview' worked on sample '.iv' files, such as ones provided via my 3D TEST/DEMO FILES page. I was able to run 'ivview' at the command line, and I set up 'ivview' in the Nautilus file-manager to be the default 'opener' of '.iv' files. |
|
The 'whitedune' installation, < Go to Table of Contents, above. > When I looked for 'whitedune' in the keyword search facility of the Ubuntu Software Center of my Ubuntu 9.10 (Karmic) installation, I got no hits. For the heck of it, I tried typing 'whitedune' at the command prompt in a gnome-terminal window. Although messages indicated 'whitedune' was not found, there was a message that suggested using the command sudo apt-get install whitedune I pasted that string at the command prompt, answered the prompt for a password, and simply sat back and watched the installation messages. 'whitedune' worked on sample '.wrl' files, such as ones provided via my 3D TEST/DEMO FILES page. Furthermore, I was able to set up 'whitedune' as a 'helper application' for '.wrl' files in the Seamonkey web browser that I use almost exclusively, rather than Firefox. At first, to try to set up 'whitedune' as the reader for '.wrl' files when they occur as links in web pages that I am reading with Seamonkey, I went to 'Edit > Preferences > Browser > Helper Applications' in Seamonkey. That gave me a list of file types and their associated actions. Unfortunately, VRML files were not in the list of about 30 types of files. And there was no 'Add' button to use. But I found that if I clicked on a '.wrl' file link on a web page, I got a prompt for whether to save the file or open it with an application. I chose to open it with an application. I was presented with a 'Browse...' option which I used to specify '/usr/bin/whitedune' as the application to use for that particular '.wrl' file. There was a check button labelled 'Do this automatically for files like this from now on.' I checked that. The VRML file type did not appear in the 'Helper Applications' panel in that Seamonkey session. But, it turned out that after I exited Seamonkey, an underlying Seamonkey 'Helper Applications' file was apparently updated with the VRML reader information. In subsquent Seamonkey sessions, I could simply click on a '.wrl' file link and 'whitedune' would startup and show the '.wrl' file --- almost immediately for small '.wrl' files. Furthermore, when I checked 'Edit > Preferences > Browser > Helper Applications', 'VRM file' now appeared in the files list. The 'Action' was set to 'Always ask'. In the 'Always ask' drop down menu, 'Use whitedune' showed as an option. Apparently, I could force whitedune to be used, avoiding a prompt for what application to use, if I wished. (Actually, there seems to be a bit of a bug in Seamonkey here. It should be asking me what I want to do when I click on a '.wrl' link, but Seamonkey starts up 'whitedune' right away. In any case, I have set 'Use whitedune' as the 'Action' for WRL files.) |
|
Paraview installation, < Go to Table of Contents, above. > I installed 'paraview' via packages.ubuntu.com/karmic/paraview. The 'paraview' File-Open dialog indicates that paraview will read and view VRML files, but I found the following problems. Although the 'File > Open' option indicates that Paraview will read VRML2 '.wrl' files, with the version I have installed, it fails frequently on VRML2 files like b_fly.wrl, ball.wrl, basic-shapes-5V.wrl, basics-text-2.wrl, blockada.wrl, boink.wrl, btnproto.wrl ... on my 3D test/demo files page yet these files read into 'whitedune' with no problem. This build of Paraview may have an error in a routine that reads VRML2 file data. Below is the error message that I usually see, in a Paraview error message window, immediately after clicking the 'Apply' button in Paraview --- to render the opened file into the display window. A PolyData connections problem? Perhaps 'paraview' is not as forgiving as 'whitedune'. |
ERROR: In /build/buildd/paraview-3.4.0/VTK/Filtering/vtkDemandDrivenPipeline.cxx, line 722
vtkStreamingDemandDrivenPipeline (0xa973518): Input port 0 of algorithm
vtkAppendPolyData(0xa4b0ea0) has 0 connections but is not optional.
|
On a little more testing, I found that after an error like this occurs, to make it less likely to happen on the next '.wrl' file read, one needs to close 'paraview' and start fresh. But then a file that was read successfully at one time may fail to read at another time. The inconsistency of the errors (sometimes a file that was read OK will fail to be read another time) almost suggests a memory management error. Furthermore, I had a crash of Paraview on trying 'Apply' on a VRML2 file --- not just an error message while the GUI 'stays up'. The following error message appeared at the command line, instead of in a 'paraview' error message window, which could not appear because of the crash. |
Error: Node's of type Anchor do not have fields/eventIn/eventOut named Link
Error near line 21: parse error
Error near line 21: Unknown node type 'a'
|
And I had a crash of 'paraview', with a different error message (below), on trying 'Apply' on another VRML2 file. The following error message appeared at the command line. ('Apply' loads the model into the display area, after you have done a File-Open to get the model data into the paraview program.) |
Error near line 188: parse error
Segmentation fault
|
Furthermore, 'paraview' does not seem to successfully read compressed '.wrl.gz' files, but 'whitedune' will. The bottom line is it is better to view VRML2 files with 'whitedune' than with 'paraview'. I found 'paraview' to be a lot more stable in reading in '.ply' files and '.stl' files, including binary '.stl' files --- than in reading VRML2 files. |
|
Summary of the installed VRML viewers : 'ivview' is a very nice little viewer for Inventor and VRML1 files. 'whitedune' seems to read VRML2 files quite reliably, but there are no '.x3d' files that I have come across (all version 3.1 X3D) that 'whitedune' would read. Summary of my preferences :
|
|
Some notes on SGI packages of < Go to Table of Contents, above. >
|
|
non-SGI 3D VRML converters
< Go to Table of Contents, above. > In addition to 3D VRML *viewers*, this page of VRML1-VRML2 notes also includes notes on finding and installing 3D VRML *converter* programs, like
I was able to compile a circa 2004 version of the 'ivcon' 3D file converter program of John Burkhardt (at FSU in 2010), using the 'gcc' compiler, on Ubuntu Linux 9.10. I was also able to compile a circa 2002 version of his 'ivread' fortran90 3D file converter program, using the 'gfortran' compiler, on Ubuntu Linux 9.10. Furthermore, I was also able to compile the 'admesh' program (version 0.95) with 'gcc', on Ubuntu Linux 9.10. For more detail on source and binaries for these and other 3D converters that are available for Linux, there are source and binary files (and links to those files on this site) on my separate 'Notes on 3D converters' web page. On that page, I report, in a little more detail, how the 'ivcon' and 'ivread' program builds were done. And I report results of 'ivcon' tests on a few test 3D files, like the files referenced in the next section, on 3D test files. In the 'Notes on 3D converters' page (link above), you can see some of the other 3D converter source codes (ones that do not involve VRML) that one could try compiling on Linux. A few of the 3D converters are perl (or awk) scripts that could be tested --- or converted to another language (interpreted or compiled language). Examples: perl to awk, or perl to C. |
|
Some 'Limited Formats'
< Go to Table of Contents, above. > There is source code, on the Internet, for many VRML and SGI-Inventor file converters which may be portable to Linux systems --- converters with names such as (in numero-alphabetic order) :
A few of these translators are scripts (Perl or awk). They will generally not be usable on huge model files. Some of the translators based on compilable source code (C, C++, Fortran) may be relatively easy to compile, since some of these may not have complex libraries, like graphics and GUI libraries, as dependencies. Typically you will find that converters for VRML or Inventor (SGI) files are written in C++ rather than C --- although 'ivcon' (2004) seems to be an exception. You are more likely to find C used for translators not involved with the VRML or Inventor formats --- for example, obj-to-ply or STL converters. Limitations of converters Note that many of these converters may translate only a subset of the input file --- and many of these converters may crash on certain input files. Some of these converters were developed and tested on input files that did not represent the more complex forms of the 3D format for that file type. So some of these converters may work on simpler input files, but the converters may fail on more complex input files. You often get what you pay for in the open source world --- but, if you have the time and talent, you may be able to fix the code yourself. If two translators reportedly translate format A to format B, they could offer alternatives (backups) to each other. If one translator does not give a good translation to format B (or crashes), then the other translator may provide a better translation. Note that most of the translators --- like 'ivread' and 'ivcon' --- have hard-coded limits on the number of points or polygons they will handle. |
|
VRML test/demo files : < Go to Table of Contents, above. > For some sample VRML1 and VRML2 files, with suffixes such as '_vrml1.whatever' and '_vrml2.whatever' (and maybe '.wrl.gz' and '.wrz'), see my page on 3D test/demo files. |
|
VRML1 and VRML2 and X3D - a RANT, or two :
< Go to Table of Contents, above. > A subset of the Inventor 2.x specification became VRML 1. VRML 1 seemed to be on track to becoming a standard for putting out viewable 3D data --- somewhat like Adobe's PDF format became a standard for quality presentation of text-and-2D-graphics documents --- especially when Adobe provided a free reader for those documents --- the reader being easily available from the internet. Although a few free readers for VRML files became available (like 'Cosmoplayer' from SGI), unfortunately some mistakes were made. I think that two main mistakes were made :
I am not the only one who feels that VRML 2 was a mistake. At robmyers.org is a 2008 Jun 20 posting titled 'How VRML 2 Destroyed Internet VR For A Decade'. Just in case that posting disappears, I put a copy of Myers' words here :
"In the mid-1990s there were four problems with internet-based Virtual Reality (VR). I think people underestimate the Mac angle. Apple had a miniscule market share but Macs were disproportionately represented on the Internet --- and, within that, there were a disproportionate number of the kinds of people you need making and consuming your new medium if you want it to succeed. But I digress. Reading the VRML 2 standard when it first came out I was struck by its complexity and by the naivete of some of the implementation notes. I couldn't see how to implement it without much more work than the notes seemed to suggest was needed. Events showed my concerns to be well founded. Cosmo, SGI's VR outfit, was spun off and failed before they managed to finish implementing VRML 2. Intervista also failed to implement it and got bought out. A trend was emerging. Try to implement VRML 2, fail, lose your company. VRML 1 had been OK. Black Sun had based a multi-user VR system on it. It would have been better for VRML 2 not to have been specified and for VRML 1 to remain the standard with external animation added by the likes of Black Sun than for VRML 2 to destroy the industry. A couple of years ago the corpse of VRML 2 was exhumed and wrapped in XML to produce X3D. The problem with VRML 2 was not that it wasn't verbose enough, and wrapping it in an extra layer of verbosity in the form of XML tackled the wrong problem. As a comparison, SVG is basically PDF in XML but it is easier to parse than PDF and better suited to inline web graphics because of the choices that were made when considering which bits of PDF should be included or left out. VRML 2 played a unique part in the failure of the first wave of Internet virtual reality. It wasn't until the mid-2000s that a second wave arrived with less powerful scene description than VRML 1 and a walled-garden, service-based approach that is at odds with the freedom of the hypertext internet that VRML sought to extend. I long for the return of internet virtual reality based on open standards, distributed client-server systems, and text-file-hackability. With meshes." A responder to Meyers' post (Russel Campbell) said "You took the words right out of my mouth." Meyers' conjectures for why VRML2 was a mistake are slightly different from mine, and the truth may be somewhere between our views or outside of them. But I think we can agree that the end result was not good --- and the ill effects have lingered for more than 8 years. You would have thought that the Web3D consortium could have sorted things out by now --- more than 10 years later. But the 'x3d' format that they have tried to promote --- which is essentially VRML2 wrapped in XML tags --- has gone essentially nowhere --- mostly because they have not provided a reader for it (a la Acrobat Reader) --- cross platform. They may claim to have, in 'Xj3D' --- but where are Debian, Ubuntu, or other packages for it? In fact, the Web3D consortium does not even seem to have provided a lot of nice demo '.x3d' files, along with a player --- like SGI did with sample VRML files and the Cosmoplayer program. It's no wonder that the '.x3d' format seems to be an even bigger failure than VRML. Ten years later and we still find many more '.wrl' files than '.x3d' files around the internet. And a lot of 3D modelers still have export options for the VRML1 or VRML2 file format. There seems to be more 'remainders' of activity on VRML1 or VRML2 than there seems to be on X3D. During that time (approx. 2001 to 2010), the 3D game industry has been making a pile of money, comparable to or exceeding the Hollywood movie industry. The game-creators seem to have found THE way to make money, in this decade, off of 3D graphics. It involved a mix of story-line, dynamic 3D graphics, characters/avatars, and good-quality accompanying sound. Microsoft, unlike SGI and others, seems to have found a way to make money off of 3D graphics, via their development of the X-box and the software that goes with it. And, of course, there's Pixar and 3D graphics effects in movies, as another way to make a living off of 3D graphics. I.e., the entertainment industry (and the less glamorous CAD industry) is the main way enough money is made with 3D graphics to keep it improving by leaps and bounds. Perhaps VRML and X3D are solutions to an as-yet undefined problem. In other words, they are not solutions at all --- just a novelty that has grown old. Still there seems to be this sense of potential there. Maybe it is a gut feeling, on the part of many of us, with no solid reason behind it. It may be that a missing element has to be added --- and the implementation and programming has to be made much easier. Perhaps a somewhat simpler file format (sacrifice some 'bells and whistles') --- and make a ton of 'readers' (viewers) available --- could be 'the ticket'. The complexities, for the developers as well as the users, need to be eliminated (or at least hidden) to a great extent. |
|
VRML REFERENCES : VRML Books : There are not many comprehensive sources of information on the variety of 3D file formats, but there has been at least one attempt to put that kind of information into book form in
'3D Graphics File Formats, A Programmer's Reference', A few VRML books that I have accumulated over the years (as they went on clearance sale) are
Note that there was a lot of enthusiasm for VRML in the mid 1990's. |
|
EXTERNAL LINKS on VRML viewers/converters/files : Some links on 3D VRML viewers :
Some links on 3D VRML exporters :
Some links on VRML converters :
Some 'EXTERNAL' links on sources of sample 3D files :
|
|
More of my notes on 3D files, including VRML files : For more info on 3D files, including VRML1 and VRML2 files, see my web pages
|
Cosmoplayer VRML viewer - screenshot
(Rest in Peace. You could have been so much more,
if confusion in VRML implementations in web browsers
--- and lack of a stand-alone Cosmoplayer, early on
--- and poor choices by committees
--- and poor-to-non-existent implementation of
the X3D 'fork' --- had not doomed you.)
|
Bottom of this page of
To return to a previously visited web page location, click on
the Back button of your web browser, a sufficient number of times.
OR, use the History-list option of your web browser.
< Go to TOP of this page, above. >
Page history:
Page was created 2011 Jan 27.
|