pellucid

VRML 2.0 shading model applet
by Eric Haines, erich@acm.org, copyright (c) 1997
EAI Additions by Mark Callow, msc@meer.net
version 1.2 6/17/97

{You may freely use and redistribute this code as long as you keep intact the author and copyright information in pellucid.java}

This applet simulates the VRML illumination model given a default view of a sphere, a default directional light with direction [ -1 -1 -1 ], and a default material. Also, we have set the ambientIntensity to 1 for the light (by default it is 0) so that the Material's ambientIntensity immediately has an effect. The lighting and material fields can be modified, as well as the background color. Shading is computed on a pixel by pixel basis (so, for example, the specular highlights will be tighter and more precise than those normally seen using Gouraud interpolation, which is what all VRML browsers currently use).

Using the EAI, the applet is connected to a corresponding VRML scene described in the file pellucid.wrl. Any changes to lighting, material or background are reflected in the VRML scene as soon as the Compute button is pressed. Nota Bene: this applet/wrl/EAI combination is known to work only with NetscapeCommunicator 4.0/CosmoPlayer 2.0. With earlier versions of Netscape, a VRML browser embedded in a table is never found by the EAI's Browser.getBrowser(). If the wrl is not embedded in a table, I can't guarantee that applet and wrl will be arranged side-by-side. This applet/wrl combination is very useful. For example, two problems were immediately apparent in CosmoPlayer 1.0 beta 5: the specular highlight is in the wrong place (believed to be a RenderWare bug) and the player is not applying its simulated gamma correction to the background node colors. The latter would probably never have been noticed without pellucid.

If you have troubles with this version of pellucid, try the original version.

No error checking is done by this application; the short answer is "read the spec" for the range of values, but in actuality it's pretty easy to characterize: except for the light's direction and gamma, all values should be in the 0.0 to 1.0 range. Even with this limitation it is easy to create scenes where the computed color is outside the 0.0 to 1.0 display range; this applet clamps each individual RGB channel (vs. uniformly scaling each channel by the largest value) so that the values are within this range. When "show clamp" is set, all pixel results which had to be clamped are instead turned red for easy identification.

Note that the view in the applet is "from infinity", while in the corresponding VRML scene, the viewpoint simply moves the eye back and tightens the field of view, so the views will not be identical. Also, the sphere here is not tessellated, while spheres in VRML browsers are turned into polygons. Therefore, do not expect to do a pixel by pixel comparison with your VRML browser - the major goal of this program is to help browser writers using APIs which are different than OpenGL to be able to see how their approximation of the VRML illumination fares under various parameter combinations. This should help us all reach some level of convergence in rendering similar materials and lighting conditions similarly.

The applet provides a control to set the gamma compensation factor for the monitor. This control must be used with care. The control is intended to demonstrate that gamma matters. See the Color Fidelity Working Group's paper It may be Gamma to You, but it's Greek to Me or the International Color Consortium page for some notes on gamma correction, especially the sRGB paper (near the bottom of their page), also see Poynton's page. The gamma value of interest is the display gamma, the product of the monitor gamma and the lookup-table (LUT) gamma. Most PC's do not have, or the software does not use, a gamma compensation LUT so the display gamma is equal to the monitor gamma. Most PC monitors (CRT's), in fact, most monitors, have an average gamma of 2.2 (according to the sRGB white paper). VRML is concerned with how the users perceive worlds viewed on the screen, so I give a default value of 2.2 in order to show how the results should look on a gamma-corrected browser on a PC. Just to hit you over the head: gamma matters, and the sooner browser writers and authoring systems deal with it the better we'll all be. End of agenda.

Note that CosmoPlayer 1.0, and it's precursor Live3D, are the only PC browsers which attempt to simulate gamma correction (they do this by boosting the material contributions on the front end; gamma should be corrected on the back end but most rendering APIs do not support this; it's usually done by the aforementioned LUT). When comparing a VRML browser's output to pellucid's on a non-LUT system, you must enter the gamma compensation factor used by the VRML browser. For CosmoPlayer 1.0/Live3D this value is 1.7 for 16-bit systems and 1.6 for 8-bit systems. CosmoPlayer 2.0 does not do any gamma compensation. This is in keeping with the direction being pursued by the Color Fidelity Working Group to adopt sRGB. If CosmoPlayer 2.0 is your browser, you should set the applet's gamma compensation factor to 1.0. On a system with an LUT, you must also enter a value of 1.0 because the LUT compensation is being applied to the output of both pellucid and the VRML browser. Entering a value of other than 1.0 ends up applying a double dose of gamma compensation.

Note that gamma is important: if you design your world so that it looks good on a PC browser which does no gamma correction, your materials will tend to look washed out on a SGI or Mac, which do some gamma correction. Play around with the gamma compensation control to demonstrate to yourself the enormous difference that different values of gamma makes to the appearance of a scene. This is a long term issue which is being addressed by the Color Fidelity working group (contact: Maureen Stone, stone@parc.xerox.com), but is something to keep in mind.

An interesting idea is for each browser company to put into Java code their approximation model and so have their own pellucid application which shows how they render a given scene. All they would have to do is edit the code to show their simplifications or translations of various fields, assuming they know their API's illumination algorithm.

There is a white paper by Alan Norton about how he used Renderware to approximate the VRML illumination model.

code history:
3/6/97 - created 1.0
3/13/97 - released 1.1: added clamping, erased sphere during recompute, changed defaults to be more interesting and useful.