r_light.c File Reference
#include "r_local.h"#include "r_light.h"#include "r_entity.h"#include "r_state.h"
Go to the source code of this file.
Defines | |
| #define | LIGHT_RADIUS_FACTOR 80.0 |
Functions | |
| void | R_AddLight (const vec3_t origin, float radius, const vec3_t color) |
| void | R_AddSustainedLight (const vec3_t org, float radius, const vec3_t color, float sustain) |
| static void | R_AddSustainedLights (void) |
| void | R_ShiftLights (const vec3_t offset) |
| void | R_EnableLights (void) |
| void | R_AddLightsource (const r_light_t *source) |
| void | R_ClearActiveLights (void) |
| static int | R_LightDistCompare (const void *a, const void *b) |
| static void | R_SortLightList_qsort (r_light_t **list) |
| static void | R_SortLightList (r_light_t **list, vec3_t v) |
| void | R_UpdateLightList (entity_t *ent) |
Variables | |
| static light_t | r_lightsArray [MAX_GL_LIGHTS] |
| static sustain_t | r_sustainArray [MAX_GL_LIGHTS] |
| static vec3_t | lights_offset |
| static vec3_t | origin |
Detailed Description
Definition in file r_light.c.
Define Documentation
| #define LIGHT_RADIUS_FACTOR 80.0 |
Definition at line 30 of file r_light.c.
Referenced by R_EnableLights().
Function Documentation
- Todo:
- integrate the particle-based lights into the new dynamic light system
Definition at line 37 of file r_light.c.
References i, cvar_s::integer, MAX_GL_LIGHTS, rendererData_t::numLights, r_lights, light_t::radius, refdef, and VectorCopy.
Referenced by CL_ParticleRun2(), and R_AddSustainedLights().
| void R_AddLightsource | ( | const r_light_t * | source | ) |
Definition at line 141 of file r_light.c.
References r_light_s::ambientColor, Com_Printf(), rstate_t::dynamicLights, MAX_DYNAMIC_LIGHTS, rstate_t::numActiveLights, and r_state.
Referenced by CL_SpawnParseEntitystring(), and SP_light().
- See also:
- R_AddSustainedLights
Definition at line 57 of file r_light.c.
References light_t::color, i, cvar_s::integer, sustain_s::light, MAX_GL_LIGHTS, light_t::origin, r_lights, light_t::radius, refdef, sustain_s::sustain, rendererData_t::time, sustain_s::time, and VectorCopy.
Referenced by CL_ParticleRun2().
| static void R_AddSustainedLights | ( | void | ) | [static] |
- See also:
- R_EnableLights
- R_AddSustainedLight
Definition at line 86 of file r_light.c.
References light_t::color, i, sustain_s::light, MAX_GL_LIGHTS, light_t::origin, R_AddLight(), light_t::radius, refdef, sustain_s::sustain, sustain_s::time, rendererData_t::time, and VectorScale.
Referenced by R_EnableLights().
| void R_ClearActiveLights | ( | void | ) |
Definition at line 153 of file r_light.c.
References i, cvar_s::integer, rstate_t::numActiveLights, r_dynamic_lights, and r_state.
Referenced by R_ModBeginLoading(), and R_SetDefaultState().
| void R_EnableLights | ( | void | ) |
Definition at line 118 of file r_light.c.
References light_t::color, i, LIGHT_RADIUS_FACTOR, lights_offset, MAX_GL_LIGHTS, rendererData_t::numLights, light_t::origin, R_AddSustainedLights(), light_t::radius, refdef, VectorCopy, and VectorSubtract.
Referenced by R_RenderFrame().
| static int R_LightDistCompare | ( | const void * | a, | |
| const void * | b | |||
| ) | [inline, static] |
Definition at line 212 of file r_light.c.
References r_light_s::loc, and VectorDistSqr.
Referenced by R_SortLightList_qsort().
| void R_ShiftLights | ( | const vec3_t | offset | ) |
Light sources must be translated for bsp submodel entities.
Definition at line 113 of file r_light.c.
References lights_offset, and VectorCopy.
Referenced by R_DrawBrushModel().
- Todo:
- qsort may not be the best thing to use here, given that the ordering of the list usually won't change much (if at all) between calls. Something like bubble-sort might actually be more efficient in practice.
Definition at line 233 of file r_light.c.
References R_SortLightList_qsort(), and VectorCopy.
Referenced by R_UpdateLightList().
| static void R_SortLightList_qsort | ( | r_light_t ** | list | ) | [inline, static] |
Definition at line 222 of file r_light.c.
References rstate_t::numActiveLights, R_LightDistCompare(), and r_state.
Referenced by R_SortLightList().
| void R_UpdateLightList | ( | entity_t * | ent | ) |
Definition at line 239 of file r_light.c.
References rstate_t::dynamicLights, rstate_t::numActiveLights, entity_t::origin, R_SortLightList(), and r_state.
Variable Documentation
vec3_t lights_offset [static] |
Definition at line 108 of file r_light.c.
Referenced by R_EnableLights(), and R_ShiftLights().
- Todo:
- the updating of the per-entity list of nearest lights doesn't necessarily need to be updated before every frame; if the list is a few frames (or even a few seconds) out of date, it would still probably look just fine. Ideally, this updating could be done in the background by a separate, low-priority thread that constantly looped through all the entities and updated their light lists, while the high-priority rendering thread just used the most up to date version available. The current version isn't really thread-safe because it uses a global variable, which is needed due to the way that the standard qsort() function works, but this would be easy to fix if we used our own sorting algorithm, which we should probably do anyway, since qsort() isn't actually likely to be very efficient given that the ordering of the list isn't likely to change very much between calls. Bubble sort would probably be faster on average.
In the long run, it would probably be highly beneficial to separate the rendering of the world from the updating of the world. Having a "rendering" thread that was separate from a "thinking" thread (that was responsible for updating the sorted light list, updating models and textures based on animations or material properties, updating the state of the world based on user input, etc.). It would require that care to be taken to ensure proper synchronization and avoid race-conditions, but it would allow us to decouple the framerate of the renderer from the speed at which we can compute all the other stuff which isn't directly linked to the frame-by-frame rendering process (this includes anything that is supposed to change at a fixed rate of time, like animations; we don't want the animation speed to be linked to the framerate).
Obviously, we would need to maintain compatibility with single-core systems, but multi-core systems are becoming so common that it would make sense to take advantage of that extra power when it exists. Additionally, this type of threaded structure can be effective even on a single processor system by allowing us to prioritize things which must be done in real-time (ie. rendering) from things which won't be noticable to the user if they happen a bit slower, or are updated a bit less often.
light_t r_lightsArray[MAX_GL_LIGHTS] [static] |
sustain_t r_sustainArray[MAX_GL_LIGHTS] [static] |
