The Light++ Raytracing Library

JAN 2006

Let there be some Light in C++!

© Werner Benger, 1989 - 2002

http://www.photon.at/~werner/light/

The Light of C++

What Light++ is NOT:
- It is not a zillion polygon/sec highspeed renderer. This field is left to other, mostly commercial, raytracers.
- It is not a 3D modeller. Scenery descriptions from 3D modellers are unlikely to be reasonably usefull in the context of Light++, since sceneries are described usually by large amounts of data, wheras Light++ is highly procedurally oriented. E.g. some fractal mountains might require megabytes or gigabytes of data, while the same object is described in Light++ by just a handful of parameters. (This doesn't exclude that a large data object wouldn't work within the context of Light++ - it is just that this is not implemented yet.)
What Light++ is:
- it is an experimental, but nethertheless quite powerfull environment to create photorealistic (though not necessarily photometric correct) images of physical and artificial effects, which can't be created by any other raytracer. This might change, of course, as time passes and other raytracers catch up, but this is the basic goal of Light++. It is not optimized for high-speed rendering (although it surely is quite fast), but for functionality.
See Light++ Copyright License for usage conditions.

Feature Overview (incomplete excerpt)

Scenery description in C++
The 3D object scene is described by the means of C++, and is designed to be easy and simple (see First Steps with Light++ for details and example main program ). The same easyness is available as through a special scenery description language (most of which are oriented on C++ anyway), but the full power of the C++ language is available. This of course implies that the Light++ library is available for recompiling some scenery application code and a new scenery description requires recompilation. However, some runtime parameter control interface is available, too, such that not each simple parameter change requires recompilation.
General relativistic raytracing

The properties of curved space may be taken into account by deriving a Scene object using the according light curves instead of straight lines. This may simply be done in a user program by overloading the virtual function Lux::Scene::intersect().
Astronomical Coordinates
In conjunction with the Astro Library the connection between local raytracing coordinate system and the true astronomical coordinate system may be established. This enables the user to generate natural realistic sceneries with correct positions of the sun, the stars and others on the celestial sphere.
True Celestial Sky

In conjunction with the SAO Library image generation using the true natural star background is featured down to 10th star magnitude (the limiting magnitude of the SAO catalogue) - more than 258.000 stars beeing taken into account.
See also: 3D/demo/night/
Dispersion

Spectral decomposition may be controlled by an arbitrary definable color sensitivity of the RGB band. By default, a Gauss sensitivity distribution at r=650nm, g=550nm, b=450nm with an halfwidth of 80nm is used. Spectral resolution may be as low as 1nm.
Object Light Sources

Spherical Light Sources and Cylindrical Light Sources
Virtual Object Transformation

If one object should appear more than once in a Scenery, it needs not to be copied. Instead a retransformation function may be connected to the object under consideration, therefore one `real' object may appear arbitrary often under different transformations and exist virtually multiple times. See demos vtrans and lsystem .
Object groups
Objects may be grouped together and any type of transformation, including Virtual Object Transformations, may be applied to the whole group. Of course, any group may consist of object groups itself.
Spherical and Cylindrical Object groups
As an extension of Object groups, a group may have some enveloping shape, spherical and cylindrical shape already beeing implemented. This will speed up the raytracing process dramatically, since at first the whole group is tested for possible ray intersection, and if none is determinded, no detailed object intersection test is performed.
2D Objects

As a special surface property some objects may be defined to consist of 'surface-only' and to have no inner structure. Any ray may merely pass trough the surface, but not enter it. Demonstration at the 'Sea-Rose', 3D/demo/bluete/, or example "3" .
Complex planar threedimensional Objects

`Thick Objects' (class Lux::ThickObj) are two dimensional intersection functions which are extended to 3D to create objects of some `thickness'. See also example nradial
Negative Objects
Normally, objects of same surface type build a bigger object in respect to their summarized volume. Negative objects do not exist for themselves, but they 'subtract' (cut off) their volume from another object.
Raytracing of nebular media

Also known as `volume rendering', 'halo raytracing' etc. Here, this is done dynamically depending on the light path.
See also: 3D/demo/atom/
and: demo program 3D/demo/wolke/ and (the famous cloud simulation)
Gradial objects
Instead of defining an object by providing an ray intersection function, a potential function may alternatively be used. As extension to the standard method it is hereby possible to `melt' two or more objects together by shifting the global potential function.
See also: 3D/demo/gradial/
Raytracing of order 2

Radiosity like effects by semisphere-tracing - calculation of second order light effects. Including dispersive caustics, of course ;-)
Animation support & parallel raytracing for each frame
(implementation of pixelwise parallel raytracing is planned)
Motion blur

This is the third rendering mode parameter, or the motion_quality parameter for Lux::Camera::expose(). See EscherTracing for an example.
Ocean Waves

Simulation of ocean waves according to the Pierson Moskowitz spectrum of wave frequency distribution.