Conceptual Features

• Pixel Independency
  Each ray is treated independently from its neighbours, and light++, as it is designed according to physics, doesn't allow `easy hacks' to circumvent this property. This constraint forces the objects and algorithms to be implemented in a pixel-independent manner. While this might appear as a disadvantage at the first glimpse, it turns out as a great plus, because pixel-independcy remains supported this way, which by itself enables
  • Fast preview modi (up to 1024 times faster than standard raytracing)
  • Image-adaptive (non-line-based) rendering modi (might be up to 1024 times faster than standard raytracing in some image regions, while still preserving the same detail as in std raytracing)
  • Dynamic antialiasing (number of subsamples per pixel depends on local image properties instead of a constant number of rays per pixel - nearly same speed as standard raytracing, but same quality as with 25rays/pixel antialiasing)
  • Parallel rendering (frame-parallel, stripe-parallel)

• Virtualism
  Nearly each relevant function is called through a virtual, object-oriented interface. Therefore even core parts of the raytracing algorithm can be exchanged by some user-specified routine, therefore still preserving the full power of the raytracing environment even in strange non-standard situations. Examples are:
  • Raytracing with curved light rays (general relativistic raytracing)
  • Object-specific intersection (like shown in the Escher Cube
  • Exotic lighting models, like light emission computed from infalling light on other wavelengths (Excitation Cloud)

• Platonism
  Objects are designed, named, interfaced as it seems to be natural according to the physical world. One may ask: `how real is a simulated sunset?' or `why can an ensemble of bits and bytes produce the same (or similar) output as some natural image, even if nature is not constructed out of bits and bytes?' The answer is that if the structure of nature and the simulation code are sufficiently similar, then the simulation code is actually a reproduction or mapping of the physical space into the virtual space, and the virtual space by itself is as real as the real space is by itself. As the simulation code contains some part of physics, it is some part of physics by itself.
     This paragraph doesn't make any sense, huh? Ok, just forget it and enjoy the nice images...