Darkplaces lighting/Introduction

Latest revision as of 12:46, 15 February 2013

Darkplaces lighting

Contents 1 What is a light 1.1 Static lightsources 1.2 Dynamic lightsources 1.3 Fake lightsources 2 Key Concepts 2.1 Power has a price 2.2 RGB color 2.3 Static vs Dynamic

Darkplaces lighting is a quite complex system that have connections with many other engine systems (such as gamecode, clientcode, materials, maps etc.). Each effect (normalmapping, specular, fog, cubemap filter, style etc.) are optional and can be customized on per-object base. This gives an very huge amount of options and rendering tricks.

[edit] What is a light

In Darkplaces engine, light is entity that engine or compiler use to illuminate objects around. Light's entity keys are options. There is three type of light sources: static, dynamic and fake.

[edit] Static lightsources

Entity which classname begins with "light" is static lightsource. Usually its just classname "light", the differences between classnames are used to attach some additional functionality (in Quake there was light_torch, light_globe etc., Blood Omnicide dont use this). For map compiler, all "light*" entities are same and using same property set.

Q3map2 generates static lighting data when map is compiled. Depending on map size, it could last from few seconds to a hours of compilation. Generated textures and attributes are very fast to render and dont have any hit from lights count and radius (can have thousands of lights on a map, its just affects the compile time, not gameplay).

[edit] Dynamic lightsources

Dynamic lightsources are entities that get illumination generated and rendered by engine. All dynamic lights are omnidirectional, spot lights can be simulated with cubemap filter effects. Dynamic lights can illuminate moving, rotating and animating objects. There cant be many dynamic lights because they are costly to render. Too many dynlights in a scene will cause FPS drop and game slowdown.

[edit] Fake lightsources

A special kind of lightsources used for render tricks. They are not real lights, but just make some effects that looks like a light. This is quite grude, but also very fast (since it ignores generic lighting math). Coronas and glares are "fake" lightsources.

[edit] Key Concepts

[edit] Power has a price

Darkplaces lighting system gives the designer, artist and programmer a great deal of easily accessible power over the appearance and potential special effects. This power comes with price tag attached - more light effects you use, more CPU/GPU time it takes to render. Each light effect makes your videocard to process more shader instructions, some effects are very heavy shader-wise. When working with lighting, be sure to not abuse maps with lots of dynamic lightsources and effects seen at same time as this may overwhelm your videocard and significatly drop FPS. Use the static lighting as much as possible - lightmaps with deluxemaps have the same look as realtime lightsources.

[edit] RGB color

This is just like material system's RGB, with several exceptions and additions. RGB means "Red, Green, Blue". Mixing red, green and blue light in differing intensities creates the colors in computers and television monitors. This is called additive color (as opposed to the mixing of pigments in paint or colored ink in the printing process, which is subtractive color). In Darkplaces engine and most higher-end computer art programs (and the color selector in Windows), the intensities of the individual Red, Green and Blue components are expressed as number values. When mixed together on a screen, number values of equal intensity in each component color create a completely neutral (gray) color. The lower the number value (towards 0), the darker the shade. Unlike art programs, which shows color values between 0 and 255, Darkplaces have color mapped between 0 - 1 ('1 1 1' is white). Values lesser than 0 means negative color (assigning it to light source make it cast darkness). Values greater than 1 (overbright color) is supported too.

[edit] Static vs Dynamic

Darkplaces lighting is not unified. It combines several techniques in order to get best performance and visual quality. There is no need to light up whole level with hi-quality realtime lighting, as it will take too much CPU and GPU time. Small objects should receive a grude and fast lighting, while important objects should have best quality. To reach this goal, Darkplaces lighting have two parts - static lighting and dynamic lighting.

For static lighting illumination data is generated when map is being compiled. All objects that is not moving, rotating, animating, transforming in any way, by default, should be illuminated with static lighting. Also any light that is not moving, switching, animating, should be static too. The trick is that both of previous rules should be used synchronously. If there is some dynamic object with many static objects, and it cannot be lit well with static lighting, should make all scene illuminated with dynamic light.

Map compiler (for Blood Omnicide it is Q3Map2) is a tool that generates static lighting data. It is a full featured raytracer able to render non-point sources, area sources, spot lights, alpha shadows, can store light vectors in deluxemaps (in order to get normalmapping and specular working for lightmapped surfaces) etc. All this features makes static lighting to look same as dynamic, but render alot faster. There is 3 techniques available:

• Vertex lighting - lighting sampled at vertexes, most faster lighting storing only low frequency data (~2 times faster than lightmap)
• Lightmaps - light textures, can store high frequency data and fast to render
• Lightgrid - generated 3d grid storing lighting for moving entities (lighting are sampled at entity position)

Dynamic lighting comes from dynamic lightsources and can illuminate objects that is moving, rotating, animating, transforming in any way. It is very flexible and time consuming as it get computed in realtime, each frame. At other features like simulation of non-point sources, spotlights is less efficient with dynamic lighting because of limited computation time (it should be less than several milliseconds).

Here is the table showing features of different techniques:

Next chapter: Lighting model
Back to index | Top of the page