|
|
@@ -363,8 +363,6 @@ The rendering operations are divided into passes in the following order:
|
|
|
- Post-opaque or "extra" rendering pass for materials that define that.
|
|
|
- Transparent geometry rendering pass. Transparent, alpha-blended objects are sorted according to distance and rendered back-to-front to ensure correct blending.
|
|
|
|
|
|
-For details on how lighting opaque geometry differs between forward and deferred rendering, see \ref ForwardDeferred "Comparision of forward, light pre-pass and deferred rendering".
|
|
|
-
|
|
|
\section Rendering_Drawable Rendering components
|
|
|
|
|
|
The rendering-related components defined by the %Graphics library are:
|
|
|
@@ -381,7 +379,14 @@ The rendering-related components defined by the %Graphics library are:
|
|
|
- Light: illuminates the scene. Can optionally cast shadows.
|
|
|
- Zone: defines global properties like fogging and background color. The active zone is the one the Camera is currently in.
|
|
|
|
|
|
-\section Rendering_Materials Materials
|
|
|
+\section Rendering_Further Further details
|
|
|
+
|
|
|
+See also \ref Materials "Materials", \ref Lights "Lights and shadows", \ref Particles "Particle systems" and \ref AuxiliaryViews "Auxiliary views".
|
|
|
+
|
|
|
+For details on how lighting opaque geometry differs between forward and deferred rendering, see \ref ForwardDeferred "Comparision of forward, light pre-pass and deferred rendering".
|
|
|
+
|
|
|
+
|
|
|
+\page Materials Materials
|
|
|
|
|
|
Material and Technique resources define how to render 3D scene geometry. On the disk, they are XML data. By default, materials exist in the CoreData/Materials & Data/Materials subdirectories, and techniques exist in the CoreData/Techniques subdirectory.
|
|
|
|
|
|
@@ -441,7 +446,8 @@ The passes are:
|
|
|
|
|
|
Note that the technique does not need to enumerate shaders used for different geometry types (non-skinned, skinned, instanced, billboard) and light types (directional, point and spot, shadowed and non-shadowed.) Instead specific hardcoded shader variations are assumed to exist.
|
|
|
|
|
|
-\section Rendering_Lights Lights
|
|
|
+
|
|
|
+\page Lights Lights and shadows
|
|
|
|
|
|
Lights in Urho3D can be directional, point, or spot lights. Shadow mapping is supported for all light types.
|
|
|
|
|
|
@@ -453,7 +459,17 @@ Spot lights have FOV & aspect ratio values like cameras to define the shape of t
|
|
|
|
|
|
Both point and spot lights use an attenuation ramp texture to determine how the intensity varies with distance. In addition they have a shape texture, 2D for spot lights, and an optional cube texture for point lights. It is important that the spot light's shape texture has black at the borders, and has mipmapping disabled, otherwise there will be "bleeding" artifacts at the edges of the light cone.
|
|
|
|
|
|
-\section Rendering_ShadowedLights Shadowed lights
|
|
|
+\section Lights_LightCulling Light culling
|
|
|
+
|
|
|
+When occlusion is used, a light will automatically be culled if its bounding box is fully behind an occluder. However, directional lights have an infinite bounding box, and can not be culled this way.
|
|
|
+
|
|
|
+In forward rendering, it is possible to limit which objects are affected by each light, by calling \ref Drawable::SetLightMask "SetLightMask()" on both the light and the objects. The lightmasks of the light and objects are ANDed to check whether the light should have effect: the light will only illuminate an object if the result is nonzero. By default objects and lights have all bits set in their lightmask, thus passing this test always.
|
|
|
+
|
|
|
+\ref Zone "Zones" can also be used for light culling in a similar manner. The lightmask of the zone the camera is in will be ANDed with each light's lightmask to see whether the light should be included in rendering. This method of light culling works equally in deferred and forward rendering. By default a zone has all bits set in its lightmask.
|
|
|
+
|
|
|
+Care must be utilized when doing light culling with lightmasks, because they easily create situations where a light's influence is cut off unnaturally. However, they can be a great performance boost: for example if you imagine a multi-store building with lights, lights would normally need to have shadows enabled to not "bleed" into the lower floors, which would cost performance. The bleeding could also be prevented by using unique lightmask bits on the objects and lights of each floor.
|
|
|
+
|
|
|
+\section Lights_ShadowedLights Shadowed lights
|
|
|
|
|
|
Shadow rendering is easily the most complex aspect of using lights, and therefore a wide range of parameters exists for controlling the shadows:
|
|
|
|
|
|
@@ -473,7 +489,7 @@ Additionally, there exist shadow fade distance, shadow intensity, shadow resolut
|
|
|
|
|
|
- The shadow near/far ratio controls shadow camera near clip distance for point & spot lights. The default ratio is 0.002, which means a light with range 100 would have its shadow camera near plane set at the distance of 0.2. Set this as high as you can for better shadow depth resolution, but note that the bias parameters will likely have to be adjusted as well.
|
|
|
|
|
|
-\section Rendering_ShadowMapReuse Shadow map reuse
|
|
|
+\section Lights_ShadowMapReuse Shadow map reuse
|
|
|
|
|
|
The Renderer can be configured to either reuse shadow maps, or not. To reuse is the default, use \ref Renderer::SetReuseShadowMaps "SetReuseShadowMaps()" to change.
|
|
|
|
|
|
@@ -481,17 +497,44 @@ When reuse is enabled, only one shadow texture of each shadow map size (full, ha
|
|
|
|
|
|
When reuse is disabled, all shadow maps are rendered before the actual scene rendering. Now multiple shadow textures need to be reserved based on the desired number of simultaneous shadow casting lights. See the function \ref Renderer::SetNumShadowMaps "SetNumShadowMaps()". If there are not enough shadow textures, they will be assigned to the closest/brightest lights, and the rest will be rendered unshadowed. Now more texture memory is needed, but the advantage is that also transparent objects can receive shadows. The exception is shadowed point lights: they need stencil masking to split into the 6 shadow map sides, which conflicts with the need to render transparent objects back-to-front, instead of rendering per light.
|
|
|
|
|
|
-\section Rendering_LightCulling Light culling
|
|
|
|
|
|
-When occlusion is used, a light will automatically be culled if its bounding box is fully behind an occluder. However, directional lights have an infinite bounding box, and can not be culled this way.
|
|
|
+\page Particles %Particle systems
|
|
|
|
|
|
-In forward rendering, it is possible to limit which objects are affected by each light, by calling \ref Drawable::SetLightMask "SetLightMask()" on both the light and the objects. The lightmasks of the light and objects are ANDed to check whether the light should have effect: the light will only illuminate an object if the result is nonzero. By default objects and lights have all bits set in their lightmask, thus passing this test always.
|
|
|
+The ParticleEmitter class derives from BillboardSet to implement a particle system that updates automatically.
|
|
|
|
|
|
-\ref Zone "Zones" can also be used for light culling in a similar manner. The lightmask of the zone the camera is in will be ANDed with each light's lightmask to see whether the light should be included in rendering. This method of light culling works equally in deferred and forward rendering. By default a zone has all bits set in its lightmask.
|
|
|
+The particle system's properties can be set through a XML description file, see \ref ParticleEmitter::LoadParameters "LoadParameters()".
|
|
|
|
|
|
-Care must be utilized when doing light culling with lightmasks, because they easily create situations where a light's influence is cut off unnaturally. However, they can be a great performance boost: for example if you imagine a multi-store building with lights, lights would normally need to have shadows enabled to not "bleed" into the lower floors, which would cost performance. The bleeding could also be prevented by using unique lightmask bits on the objects and lights of each floor.
|
|
|
+Most of the parameters can take either a single value, or minimum and maximum values to allow for random variation. See below for all supported parameters:s
|
|
|
|
|
|
-\section Rendering_AuxiliaryViews Auxiliary views
|
|
|
+\code
|
|
|
+<particleemitter>
|
|
|
+ <material name="MaterialName" />
|
|
|
+ <sorting enable="true|false" />
|
|
|
+ <updateinvisible enable="true|false" />
|
|
|
+ <relative enable="true|false" />
|
|
|
+ <emittertype value="point|box|sphere" />
|
|
|
+ <emittersize value="x y z" />
|
|
|
+ <direction min="x1 y1 z1" max="x2 y2 z2" />
|
|
|
+ <constantforce value="x y z" />
|
|
|
+ <dampingforce value="x" />
|
|
|
+ <activetime value="t" />
|
|
|
+ <inactivetime value="t" />
|
|
|
+ <interval min="t1" max="t2" />
|
|
|
+ <particlesize min="x1 y1" max="x2 y2" />
|
|
|
+ <timetolive min="t1" max="t2" />
|
|
|
+ <velocity min="x1" max="x2" />
|
|
|
+ <rotation min="x1" max="x2" />
|
|
|
+ <rotationspeed min="x1" max="x2" />
|
|
|
+ <sizedelta add="x" mul="y" />
|
|
|
+ <color value="r g b a" />
|
|
|
+ <colorfade color="r g b a" time="t" />
|
|
|
+</particleemitter>
|
|
|
+\endcode
|
|
|
+
|
|
|
+Note: zero active or inactive time period means infinite. Instead of defining a single color element, several colorfade elements can be defined in time order to describe how the particles change color over time.
|
|
|
+
|
|
|
+
|
|
|
+\page AuxiliaryViews Auxiliary views
|
|
|
|
|
|
Auxiliary views are viewports defined into a RenderSurface. These will be rendered whenever the texture containing the surface is visible, and can be typically used to implement for example reflections. The texture in question must have been created in rendertarget mode, see Texture's \ref Texture2D::SetSize "SetSize()" function.
|
|
|
|
|
|
@@ -1162,7 +1205,5 @@ Note: animations are stored using absolute bone transformations. Therefore only
|
|
|
|
|
|
- Inline functions are defined inside the class definitions where possible, without using the inline keyword.
|
|
|
|
|
|
-- For threading and multi-instance safety, the only allowed form of static data is const static data outside function definitions.
|
|
|
-
|
|
|
|
|
|
*/
|