Physical lights

Physical lights each have their own dedicated interface. An application wishing to be 'physically correct' should ONLY use lights of the following types:

Light type	Description	Snapshot
Physical light	This is a general purpose physically correct light. It can use any mesh based geometry as an emitting light source. The physical light renders on the CPU and is approximated on the GPU by a point light source. If the mesh geometry used to emit light is a rectangle, the GPU approximation of the physical light source will use rectangular GPU area lights that provide a very accurate rendering of the light source. It can be rendered using Monte-Carlo sampled shadows on the CPU. It can be rendered using ray-traced shadows (point light shadows) on the GPU. It can display IES profiles: See at the end of the page for details. Main interface is RED::IPhysicalLightShape. Setup a physical light.
Sunlight	This is a physical sunlight. Unless you're not on earth, you'll want only one of those in your scene graph at a time! The sunlight renders on the CPU and is approximated on the GPU by a directional light source. It can be rendered using Monte-Carlo sampled shadows on the CPU. It can be rendered using ray-traced shadows (directional light shadows) on the GPU. Main interface is RED::ISunLightShape. Setup a physical sun light.
Skylight	This is a physical skylight. Only one skylight should be set in a scene graph at a time. The skylight renders on the CPU and on the GPU. It can be rendered using Monte-Carlo sampled shadows on the CPU. It can be rendered using soft ray-traced shadows on the GPU, using the hardware ray-tracer soft shadowing method. The skylight can use portals that greatly reduce the noise in rendered images when set. See the documentation below: Portal setup for skylights and the tutorial here: Using skylight portals. Main interface is RED::ISkyLightShape. Setup a physical sky light.

Shadowing methods for physical lights

All physically correct lights have an emitting surface, unlike Real-time lights that have only one direction or point from which light is emitted. This implies a lot of differences for the resolution of the lighting and shadowing of these lights.

Consequently, on the CPU, REDsdk uses Monte-Carlo based sampling techniques for the resolution of the lighting and shadows reaching a point in space to be illuminated. The shadow and lighting quality is mainly controlled using the RED::OPTIONS_RAY_LIGHTS_SAMPLING_RATE. However, each light has an internal samples counter that will be used whenever the RED::OPTIONS_RAY_LIGHTS_SAMPLING_RATE is set to zero:

• RED::IPhysicalLightShape::SetSamplesCount,
• RED::ISunLightShape::SetSamplesCount,
• RED::ISkyLightShape::SetSamplesCount.

REDsdk GPU rendering uses different approaches, because GPUs are not flexible enough to implement rendering solutions similar to those used by REDsdk on the CPU. Each physical light has a GPU equivalent light used to represent it approximatively:

• Physical lights are turned into point lights (with the noticeable exception of rectangular physical lights turned into rectangular area lights),
• Sun lights are turned into directional lights,
• Sky lights are turned into...sky lights, but GPU version. The GPU skylight has a good lighting approximation of the CPU skylight, and uses the soft shadowing technique of REDsdk to produce approximated soft shadows on the GPU. The result runs at an interactive - not real-time - performance.

Portal setup for skylights

Portals are significantly helping the rendering of indoor images that contain openings toward the outside. A portal is a mesh in the scene that is declared as a "portal" for the skylight. When declared as a portal for the skylight, the skylight will fire rays through the portal rather than through the hemisphere as it would do without portals. This is illustrated below:

The effect of portals over skylight sampling.

Consequently, if portals are placed through openings of the scene, all the rays fired for the skylight illumination will effectively reach an opening in the model. So all the rays will be meaningful as no rays will be wasted hitting walls.

When portals are set in a scene, all openings must be covered by portals, otherwise openings not covered won't be sampled and will be considered as occluded regions of the model, which could lead to unwanted effects in the image.

See the tutorial on portal setup here: Using skylight portals.

Note that portals of a skylight are approximated on the GPU:

• Rectangular portals made of 2 triangles are rendered using rectangular GPU area lights, with an average intensity calculated from the source skylight skymap.
• Non rectangular portals are turned into point lights in the model, using the same intensity approximation.

IES profiles support

The physical light can use LM-63-02 format IES profiles. The RED::IPhysicalLightShape::SetIES method can be used to associate an IES profile to a given physical light.

IES profiles are rendered on the CPU and on the GPU.

Real-time lights

Decay equations