EEVEE-Next: Update Documentation #104816
@ -34,5 +34,5 @@ Viewport Display
|
|||||||
These settings control the curve rendering settings used when the 3D viewport is set to
|
These settings control the curve rendering settings used when the 3D viewport is set to
|
||||||
:ref:`Material Preview <3dview-material-preview>`
|
:ref:`Material Preview <3dview-material-preview>`
|
||||||
|
|
||||||
.. include:: /render/eevee/render_settings/hair.rst
|
.. include:: /render/eevee/render_settings/curves.rst
|
||||||
:start-after: .. --- copy below this line ---
|
:start-after: .. --- copy below this line ---
|
||||||
|
@ -10,8 +10,10 @@
|
|||||||
|
|
||||||
introduction.rst
|
introduction.rst
|
||||||
render_settings/index.rst
|
render_settings/index.rst
|
||||||
materials/index.rst
|
scene_settings.rst
|
||||||
world.rst
|
world_settings.rst
|
||||||
lighting.rst
|
object_settings/index.rst
|
||||||
|
material_settings.rst
|
||||||
|
light_settings.rst
|
||||||
light_probes/index.rst
|
light_probes/index.rst
|
||||||
limitations.rst
|
limitations/index.rst
|
||||||
|
@ -3,23 +3,23 @@
|
|||||||
Introduction
|
Introduction
|
||||||
************
|
************
|
||||||
|
|
||||||
EEVEE is Blender's realtime render engine built using :term:`OpenGL` focused on
|
EEVEE is Blender's realtime render engine focused on speed and interactivity while achieving the
|
||||||
speed and interactivity while achieving the goal of rendering :abbr:`PBR (Physically Based Rendering)` materials.
|
goal of rendering :abbr:`PBR (Physically Based Rendering)` materials.
|
||||||
EEVEE can be used interactively in the 3D Viewport but also produce high quality final renders.
|
EEVEE can be used interactively in the 3D Viewport but also produce high quality final renders.
|
||||||
|
|
||||||
.. figure:: /images/render_eevee_introduction_viewport.png
|
.. figure:: /images/render_eevee_introduction_viewport.png
|
||||||
|
|
||||||
EEVEE in the 3D Viewport -- "Tiger" by Daniel Bystedt.
|
EEVEE in the 3D Viewport -- "Tiger" by Daniel Bystedt.
|
||||||
|
|
||||||
EEVEE materials are created using the same shader nodes as Cycles, making it easy to render existing scenes.
|
EEVEE materials are created using the same shader nodes as Cycles, making it easy to render existing
|
||||||
For Cycles users, this makes EEVEE work great for previewing materials in realtime.
|
scenes. For Cycles users, this makes EEVEE work great for previewing materials in realtime.
|
||||||
|
|
||||||
Unlike Cycles, EEVEE is not a raytrace render engine.
|
EEVEE is based on rasterization and is not a path tracer.
|
||||||
fclem marked this conversation as resolved
Outdated
|
|||||||
Instead of computing each ray of light, EEVEE uses a process called rasterization.
|
Instead of computing each ray of light, rasterization determines what surface is visible from the camera.
|
||||||
fclem marked this conversation as resolved
Outdated
Hans Goudey
commented
Can delete Can delete `EEVEE uses a process called` since the previous sentence that EEVEE uses it.
|
|||||||
Rasterization estimates the way light interacts with objects and materials using numerous algorithms.
|
It then estimates the way light interacts with these surfaces and materials using numerous algorithms.
|
||||||
While EEVEE is designed to use :abbr:`PBR (Physically Based Rendering)` principles,
|
While EEVEE is designed to use :abbr:`PBR (Physically Based Rendering)` principles,
|
||||||
it is not perfect and Cycles will always provide more physically accurate renders.
|
it is not perfect and Cycles will always provide more physically accurate renders.
|
||||||
Because EEVEE uses rasterization it has a large set of :doc:`limitations </render/eevee/limitations>`.
|
For these reasons, EEVEE has a set of :doc:`limitations </render/eevee/limitations/index>`.
|
||||||
|
|
||||||
fclem marked this conversation as resolved
Outdated
Hans Goudey
commented
`a lot of` -> `many` (just a more professional style)
|
|||||||
.. figure:: /images/render_eevee_introduction_final-render.png
|
.. figure:: /images/render_eevee_introduction_final-render.png
|
||||||
|
|
||||||
|
@ -9,6 +9,6 @@
|
|||||||
:maxdepth: 2
|
:maxdepth: 2
|
||||||
|
|
||||||
introduction.rst
|
introduction.rst
|
||||||
irradiance_volumes.rst
|
volume.rst
|
||||||
reflection_cubemaps.rst
|
sphere.rst
|
||||||
reflection_planes.rst
|
plane.rst
|
||||||
|
@ -3,10 +3,10 @@
|
|||||||
Introduction
|
Introduction
|
||||||
************
|
************
|
||||||
|
|
||||||
Probe objects are used by EEVEE as support objects.
|
Light probe objects are used by EEVEE as support objects.
|
||||||
They record lighting information locally in order to light the scene using indirect lighting.
|
|
||||||
|
|
||||||
There are three different probe types. One for diffuse lighting, two for specular lighting.
|
There are three different types of light probes.
|
||||||
|
Each type of light probe records the lighting at a different resolution and frequency.
|
||||||
fclem marked this conversation as resolved
Outdated
Hans Goudey
commented
`record` -> `records`
`at different resolution` -> `at a different resolution`
|
|||||||
|
Probes are used together to recover incoming light information when using ray tracing is not possible (either for performance or for technical limitations).
|
||||||
fclem marked this conversation as resolved
Outdated
Hans Goudey
commented
`They` -> `Probes`
|
|||||||
|
|
||||||
These types of objects are only useful for EEVEE (and by extension, the Material Preview mode).
|
These types of objects are only useful for EEVEE (and by extension, the Material Preview mode).
|
||||||
They are meant to guide the engine to compute better lighting quickly.
|
|
||||||
|
@ -1,110 +0,0 @@
|
|||||||
|
|
||||||
******************
|
|
||||||
Irradiance Volumes
|
|
||||||
******************
|
|
||||||
|
|
||||||
Diffuse indirect lighting is stored in volumetric arrays.
|
|
||||||
These arrays are defined by the user using Irradiance Volume objects.
|
|
||||||
They control how arrays are placed in the world as well as their resolution.
|
|
||||||
|
|
||||||
Lighting is computed at the dot positions visible when the Irradiance Volume object is selected.
|
|
||||||
|
|
||||||
.. seealso::
|
|
||||||
|
|
||||||
:doc:`Indirect Lighting </render/eevee/render_settings/indirect_lighting>`.
|
|
||||||
|
|
||||||
If Ambient Occlusion is enabled, it will be applied onto diffuse indirect lighting.
|
|
||||||
If both Ambient Occlusion and "Bent Normals" are enabled
|
|
||||||
the indirect lighting will be sampled from the least occluded direction and appear more correct.
|
|
||||||
|
|
||||||
.. reference::
|
|
||||||
|
|
||||||
:Panel: :menuselection:`Object Data --> Probe`
|
|
||||||
|
|
||||||
Distance
|
|
||||||
A probe object only influences the lighting of nearby surfaces.
|
|
||||||
This influence zone is defined by the Distance parameter and object scaling.
|
|
||||||
The influence distance varies a bit, depending on the probe type.
|
|
||||||
|
|
||||||
For Irradiance Volumes, the influence inside the volume is always 100%.
|
|
||||||
The influence decays only outside of the volume until
|
|
||||||
the distance to the volume reaches the Distance parameter value (in local space).
|
|
||||||
|
|
||||||
Falloff
|
|
||||||
Percentage of the influence distance during which the influence of a probe fades linearly.
|
|
||||||
|
|
||||||
Intensity
|
|
||||||
Intensity factor of the recorded lighting.
|
|
||||||
Making this parameter anything other than 1.0 is not physically correct. Use it for tweaking or artistic purposes.
|
|
||||||
|
|
||||||
Resolution
|
|
||||||
Spatial resolution for Irradiance Volumes is determined per probe.
|
|
||||||
The local volume is divided into a regular grid of the specified dimensions.
|
|
||||||
One irradiance sample will be computed for each cell in this grid.
|
|
||||||
|
|
||||||
Clipping
|
|
||||||
Defines the near and far clip distances when capturing the scene.
|
|
||||||
|
|
||||||
.. warning::
|
|
||||||
|
|
||||||
Clipping distances are applied at the samples positions and *not* at the grid origin.
|
|
||||||
|
|
||||||
Visibility Collection
|
|
||||||
In some cases, it is useful to limit which objects appear in the light probe's captured lighting.
|
|
||||||
For instance, an object that is too close to a capture point might be better excluded.
|
|
||||||
This is what the visibility collection does.
|
|
||||||
Only objects that are in this collection will be visible when this probes captures the scene.
|
|
||||||
|
|
||||||
There is also an option to invert this behavior and effectively hide the objects in this collection.
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
This is only a filtering option. That means that if an object is not visible at render time
|
|
||||||
it won't be visible during the probe render.
|
|
||||||
|
|
||||||
|
|
||||||
Visibility
|
|
||||||
==========
|
|
||||||
|
|
||||||
For every grid point a small Variance Shadow Map is rendered.
|
|
||||||
This visibility cubemap is used to reduce light leaking behind occluders.
|
|
||||||
You can tweak the size of this map inside the render settings and
|
|
||||||
tweak the bias and blur factors per grid inside the Probe Properties tab.
|
|
||||||
|
|
||||||
Bias
|
|
||||||
Reduces self-shadowing.
|
|
||||||
|
|
||||||
Bleed Bias
|
|
||||||
Increases the "contrast" of the depth test result.
|
|
||||||
|
|
||||||
Blur
|
|
||||||
Amount of blur to apply when filtering the visibility shadow map.
|
|
||||||
Does not increase runtime cost but has a small effect on baking time.
|
|
||||||
|
|
||||||
|
|
||||||
Blending
|
|
||||||
========
|
|
||||||
|
|
||||||
The lighting values from an Irradiance Volume will fade outwards until the volume bounds are reached.
|
|
||||||
They will fade into the world's lighting or another Irradiance Volume's lighting.
|
|
||||||
|
|
||||||
If multiple Irradiance Volumes overlap, smaller (in volume) ones will always have more priority.
|
|
||||||
|
|
||||||
If an object is not inside any Irradiance Volume, or if the indirect lighting has not been baked,
|
|
||||||
the world's diffuse lighting will be used to shade it.
|
|
||||||
|
|
||||||
.. tip::
|
|
||||||
|
|
||||||
- When lighting indoor environments, try to align grids with the room shape.
|
|
||||||
- Try not to put too much resolution in empty areas or areas with a low amount of lighting variation.
|
|
||||||
- You can fix bad samples by adding a smaller grid near the problematic area.
|
|
||||||
|
|
||||||
|
|
||||||
Viewport Display
|
|
||||||
================
|
|
||||||
|
|
||||||
Influence
|
|
||||||
Show the influence bounds in the 3D Viewport. The inner sphere is where the falloff starts.
|
|
||||||
|
|
||||||
Clipping
|
|
||||||
Show the clipping distance in the 3D Viewport.
|
|
65
manual/render/eevee/light_probes/plane.rst
Normal file
@ -0,0 +1,65 @@
|
|||||||
|
|
||||||
|
*****************
|
||||||
|
Light Probe Plane
|
||||||
|
*****************
|
||||||
|
|
||||||
|
A light probe plane records the light incoming from a single direction for all visible points on a plane.
|
||||||
|
The specular reflection direction is the only one currently available.
|
||||||
|
|
||||||
|
This type of light probe is suited to smooth planar surfaces.
|
||||||
|
|
||||||
|
Each visible planar light probe increases the render time as the scene needs to be rendered for
|
||||||
fclem marked this conversation as resolved
Outdated
Hans Goudey
commented
`probes increases` -> `probe increases`
|
|||||||
|
each of them.
|
||||||
|
|
||||||
|
Light probe planes only work when the ray tracing method is set to `Screen-Trace`. When enabled, they
|
||||||
fclem marked this conversation as resolved
Outdated
Hans Goudey
commented
`when ray tracing method` -> `when the ray tracing method`
|
|||||||
|
accelerate the tracing process and complete the missing data from the screen space ray tracing.
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
|
||||||
|
Reflections and volumetrics are not supported inside Light probe planes.
|
||||||
fclem marked this conversation as resolved
Outdated
Hans Goudey
commented
Maybe Maybe `Volumetrics` shouldn't be capitalized?
|
|||||||
|
|
||||||
|
|
||||||
|
Placement
|
||||||
|
=========
|
||||||
|
|
||||||
|
If Backface Culling is not enabled, snapping the light probe plane to the planar surface
|
||||||
|
will effectively capture the underside of the surface.
|
||||||
|
|
||||||
|
You can manually move the light probe plane above the surface enough for it to not appear in the capture.
|
||||||
|
Alternatively you can disable the light probe visibility in the object visibility panel.
|
||||||
|
|
||||||
|
.. reference::
|
||||||
|
|
||||||
|
:Panel: :menuselection:`Object Data --> Probe`
|
||||||
|
|
||||||
|
Distance
|
||||||
|
A probe object only influences the lighting of surfaces inside its influence zone.
|
||||||
|
This influence zone is defined by the distance parameter and the object's scale.
|
||||||
fclem marked this conversation as resolved
Outdated
Hans Goudey
commented
`Distance` -> `distance`
`object scaling` -> `the object's scale`
|
|||||||
|
|
||||||
|
For light probe planes, the influence distance is the distance from the plane.
|
||||||
fclem marked this conversation as resolved
Outdated
Hans Goudey
commented
`For light probe planes` -> `For light probe planes,`
|
|||||||
|
Only surfaces whose normals are aligned with the Reflection Plane will receive the captured reflection.
|
||||||
|
|
||||||
|
|
||||||
|
Capture
|
||||||
|
=======
|
||||||
|
|
||||||
|
Clipping Offset
|
||||||
|
Define how far below the plane the near clip is when capturing the scene.
|
||||||
fclem marked this conversation as resolved
Outdated
Hans Goudey
commented
`how much below` -> `how far below`
|
|||||||
|
Increasing this can fix reflection contact problems.
|
||||||
|
|
||||||
|
|
||||||
|
Viewport Display
|
||||||
|
================
|
||||||
|
|
||||||
|
.. reference::
|
||||||
|
|
||||||
|
:Panel: :menuselection:`Object Data --> Viewport Display`
|
||||||
|
|
||||||
|
Arrow Size
|
||||||
|
Size of the arrow showing the reflection plane normal.
|
||||||
|
|
||||||
|
Capture
|
||||||
|
Show the captured reflected image onto a fully reflective plane in the 3D Viewport.
|
||||||
|
|
||||||
|
Influence
|
||||||
|
Show the influence bounds in the 3D Viewport.
|
@ -1,94 +0,0 @@
|
|||||||
|
|
||||||
*******************
|
|
||||||
Reflection Cubemaps
|
|
||||||
*******************
|
|
||||||
|
|
||||||
Specular Indirect Lighting is stored in an array of cubemaps. These are defined by the Reflection Cubemap objects.
|
|
||||||
They specify where to sample the scene's lighting and where to apply it.
|
|
||||||
|
|
||||||
.. seealso::
|
|
||||||
|
|
||||||
:doc:`Indirect Lighting </render/eevee/render_settings/indirect_lighting>`.
|
|
||||||
|
|
||||||
*Screen Space Reflections* are much more precise than reflection cubemaps.
|
|
||||||
If enabled, they have priority and cubemaps are used as a fall back if a ray misses.
|
|
||||||
|
|
||||||
If *Ambient Occlusion* is enabled, it will be applied in a physically plausible manner to specular indirect lighting.
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
The cube probes are encoded into tetrahedral maps. Some distortions may occur on the negative Z hemisphere.
|
|
||||||
Those are more visible with higher roughness values.
|
|
||||||
|
|
||||||
|
|
||||||
Blending
|
|
||||||
========
|
|
||||||
|
|
||||||
The lighting values from a Reflection Cubemap will fade outwards until the volume bounds are reached.
|
|
||||||
They will fade into the world's lighting or another Reflection Cubemap's lighting.
|
|
||||||
If multiple Reflection Cubemaps overlap, smaller (in volume) ones will always have more priority.
|
|
||||||
If an object is not inside any Reflection Cubemap influence,
|
|
||||||
or if the indirect lighting has not been baked, the world's cubemap will be used to shade it.
|
|
||||||
|
|
||||||
.. reference::
|
|
||||||
|
|
||||||
:Panel: :menuselection:`Object Data --> Probe`
|
|
||||||
|
|
||||||
Distance
|
|
||||||
A probe object only influences the lighting of nearby surfaces.
|
|
||||||
This influence zone is defined by the Distance parameter and object scaling.
|
|
||||||
The influence distance varies is a bit, depending on the probe type.
|
|
||||||
|
|
||||||
For Reflection Cubemaps the influence volume can either be a box or a sphere centered on the probe's origin.
|
|
||||||
|
|
||||||
Falloff
|
|
||||||
Percentage of the influence distance during which the influence of a probe fades linearly.
|
|
||||||
|
|
||||||
Intensity
|
|
||||||
Intensity factor of the recorded lighting.
|
|
||||||
Making this parameter anything other than 1.0 is not physically correct.
|
|
||||||
Use it for tweaking or artistic purposes.
|
|
||||||
|
|
||||||
Clipping
|
|
||||||
Define the near and far clip distances when capturing the scene.
|
|
||||||
|
|
||||||
Visibility Collection
|
|
||||||
Sometimes, it is useful to limit which objects appear in the light probe's captured lighting.
|
|
||||||
For instance, an object that is too close to a capture point might be better excluded.
|
|
||||||
This is what the visibility collection does.
|
|
||||||
Only objects that are in this collection will be visible when this probe will capture the scene.
|
|
||||||
|
|
||||||
There is also an option to invert this behavior and effectively hide the objects inside this collection.
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
This is only a filtering option.
|
|
||||||
That means if an object is not visible at render time it won't be visible during the probe render.
|
|
||||||
|
|
||||||
|
|
||||||
Custom Parallax
|
|
||||||
===============
|
|
||||||
|
|
||||||
.. reference::
|
|
||||||
|
|
||||||
:Panel: :menuselection:`Object Data --> Custom Parallax`
|
|
||||||
|
|
||||||
By default, the influence volume is also the parallax volume.
|
|
||||||
The parallax volume is a volume on which is projected the recorded lighting.
|
|
||||||
It should roughly fit it surrounding area. In some cases it may be better to
|
|
||||||
adjust the parallax volume without touching the influence parameters.
|
|
||||||
In this case, just enable the *Custom Parallax* and
|
|
||||||
change the shape and distance of the parallax volume independently.
|
|
||||||
|
|
||||||
|
|
||||||
Viewport Display
|
|
||||||
================
|
|
||||||
|
|
||||||
Influence
|
|
||||||
Show the influence bounds in the 3D Viewport. The inner sphere is where the falloff starts.
|
|
||||||
|
|
||||||
Clipping
|
|
||||||
Show the clipping distance in the 3D Viewport.
|
|
||||||
|
|
||||||
Parallax
|
|
||||||
Show the *Custom Parallax* shape in the 3D Viewport.
|
|
@ -1,88 +0,0 @@
|
|||||||
|
|
||||||
*****************
|
|
||||||
Reflection Planes
|
|
||||||
*****************
|
|
||||||
|
|
||||||
These special types of Probe object are suited to smooth planar surfaces.
|
|
||||||
They basically capture the whole scene with a flipped camera.
|
|
||||||
|
|
||||||
Using reflection planes is really heavy on the render time
|
|
||||||
because the scene needs to be rendered as many times as there is Reflection Planes in the view.
|
|
||||||
|
|
||||||
Unless Screen Space Reflection is enabled,
|
|
||||||
Reflection Planes only work on specular surfaces that have their roughness around 0.
|
|
||||||
|
|
||||||
If Screen Space Reflection is enabled, Reflection Planes will serve as support buffers.
|
|
||||||
This accelerates the tracing process and completes the missing data from the view space.
|
|
||||||
This also make reflection more correct for the affected surfaces that have medium roughness and
|
|
||||||
disturbed normals (i.e. normal maps).
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
Subsurface Scattering, Screen Space Reflections and
|
|
||||||
Volumetrics are not supported inside Reflection Plane's reflection.
|
|
||||||
|
|
||||||
|
|
||||||
Placement
|
|
||||||
=========
|
|
||||||
|
|
||||||
If Backface Culling is not enabled, snapping the Reflection Plane to the planar surface
|
|
||||||
will effectively capture the underside of the surface.
|
|
||||||
|
|
||||||
You can manually move the Reflection Plane above the surface enough for it to not appear in the capture.
|
|
||||||
Alternatively you can put a floor object inside a collection and
|
|
||||||
use this collection as a Visibility Collection (inverted) inside the Reflection Plane's probe settings.
|
|
||||||
|
|
||||||
.. reference::
|
|
||||||
|
|
||||||
:Panel: :menuselection:`Object Data --> Probe`
|
|
||||||
|
|
||||||
Distance
|
|
||||||
A probe object only influences the lighting of nearby surfaces.
|
|
||||||
This influence zone is defined by the Distance parameter and object scaling.
|
|
||||||
The influence distance varies is a bit, depending on the probe type.
|
|
||||||
|
|
||||||
For Reflection Planes the influence distance is the distance from the plane.
|
|
||||||
Only surfaces whose normals are aligned with the Reflection Plane will receive the captured reflection.
|
|
||||||
|
|
||||||
Falloff
|
|
||||||
Percentage of the influence distance during which the influence of a probe fades linearly.
|
|
||||||
Also defines how much shading normals needs to be aligned with the plane to receive reflections.
|
|
||||||
|
|
||||||
Clipping Offset
|
|
||||||
Define how much below the plane the near clip is when capturing the scene.
|
|
||||||
Increasing this can fix reflection contact problems.
|
|
||||||
|
|
||||||
Visibility Collection
|
|
||||||
In some cases, it is useful to limit which objects appear in the light probe's captured lighting.
|
|
||||||
For instance, an object that is too close to a capture point might be better excluded.
|
|
||||||
This is what the visibility collection does.
|
|
||||||
Only objects that are in this collection will be visible when this probe will capture the scene.
|
|
||||||
|
|
||||||
There is also an option to invert this behavior and effectively hide the objects inside this collection.
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
This is only a filtering option.
|
|
||||||
That means that if an object is not visible at render time it won't be visible during the probe render.
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
Due to a limitation, dupli-objects cannot be hidden by using this option.
|
|
||||||
|
|
||||||
|
|
||||||
Viewport Display
|
|
||||||
================
|
|
||||||
|
|
||||||
.. reference::
|
|
||||||
|
|
||||||
:Panel: :menuselection:`Object Data --> Viewport Display`
|
|
||||||
|
|
||||||
Influence
|
|
||||||
Show the influence bounds in the 3D Viewport.
|
|
||||||
|
|
||||||
Arrow Size
|
|
||||||
Size of the arrow showing the reflection plane normal.
|
|
||||||
|
|
||||||
Show Preview Plane
|
|
||||||
Show the captured reflected image onto a fully reflective plane in the 3D Viewport.
|
|
79
manual/render/eevee/light_probes/sphere.rst
Normal file
@ -0,0 +1,79 @@
|
|||||||
|
|
||||||
|
******************
|
||||||
|
Light Probe Sphere
|
||||||
|
******************
|
||||||
|
|
||||||
|
A light probe sphere records the light incomming from many directions at a single location.
|
||||||
|
|
||||||
|
They are used for smooth and semi-rough reflections.
|
||||||
|
Sphere probes smoothly blend to light probe volume lighting for completely diffuse reflections.
|
||||||
fclem marked this conversation as resolved
Outdated
Hans Goudey
commented
`They then` -> `Sphere probes`
|
|||||||
|
|
||||||
|
If *Raytracing* is turned on, they are used as a fallback if a ray misses.
|
||||||
fclem marked this conversation as resolved
Outdated
Hans Goudey
commented
`fall back` -> `fallback`
|
|||||||
|
|
||||||
|
.. note::
|
||||||
|
|
||||||
|
In both usages, the light probe spheres are shadowed by light probe volume.
|
||||||
fclem marked this conversation as resolved
Outdated
Hans Goudey
commented
`In both usage` -> `In both usages`
`This is to...` (missing text here)
|
|||||||
|
This is done in order to reduce light leaking in shadowed areas and reduce the need to
|
||||||
|
setup more light probe spheres.
|
||||||
|
|
||||||
|
Adjusting their resolution is done inside the :doc:`Scene data </render/eevee/scene_settings>` panel.
|
||||||
|
|
||||||
|
The world also has an internal light probe sphere with a resolution that can be adjusted
|
||||||
|
in the :doc:`World data </render/eevee/world_settings>` panel.
|
||||||
|
|
||||||
fclem marked this conversation as resolved
Outdated
Hans Goudey
commented
`The world also have` -> `The world also has`
`which resolution` -> `with a resolution that`
|
|||||||
|
.. reference::
|
||||||
|
|
||||||
|
:Panel: :menuselection:`Object Data --> Probe`
|
||||||
|
|
||||||
|
Type
|
||||||
|
Shape of the influence volume. Can be set to Sphere or Box.
|
||||||
|
|
||||||
|
Radius
|
||||||
|
A probe object only influences the lighting of nearby surfaces.
|
||||||
|
This influence zone is defined by the size parameter and object scaling.
|
||||||
|
|
||||||
fclem marked this conversation as resolved
Hans Goudey
commented
Delete Delete `Select the`, this can just describe what the property does
|
|||||||
|
Falloff
|
||||||
|
Percentage of the influence distance in which the influence of a probe fades linearly.
|
||||||
|
|
||||||
|
|
||||||
|
Capture
|
||||||
|
=======
|
||||||
|
|
||||||
fclem marked this conversation as resolved
Outdated
Hans Goudey
commented
`during` -> `in` (during is for time)
|
|||||||
|
.. note::
|
||||||
|
|
||||||
|
In the viewport, capture only happens if an update is detected on the light probe data or position.
|
||||||
|
For renders, the capture happens at the start of each frame.
|
||||||
|
|
||||||
|
Clipping
|
||||||
|
Define the near and far clip distances when capturing the scene.
|
||||||
|
|
||||||
|
|
||||||
|
Custom Parallax
|
||||||
|
===============
|
||||||
|
|
||||||
|
.. reference::
|
||||||
|
|
||||||
|
:Panel: :menuselection:`Object Data --> Custom Parallax`
|
||||||
|
|
||||||
|
By default, the influence volume is also the parallax volume.
|
||||||
|
The parallax volume is a volume on which the recorded light is projected.
|
||||||
|
It should roughly fit it surrounding area. In some cases it may be better to
|
||||||
|
adjust the parallax volume without touching the influence parameters.
|
||||||
|
In this case, enable the *Custom Parallax* and
|
||||||
fclem marked this conversation as resolved
Outdated
Hans Goudey
commented
`volume on which` -> `volume in which`
Clément Foucault
commented
I think this one is correct. The problem is more that we call it volume when it is actually just a shape onto which we project the lighting. I think this one is correct. The problem is more that we call it volume when it is actually just a shape onto which we project the lighting.
|
|||||||
|
change the shape and radius of the parallax volume independently.
|
||||||
|
|
||||||
|
|
||||||
fclem marked this conversation as resolved
Hans Goudey
commented
Remove Remove `just` (doesn't really help, a bit informal/odd sounding)
|
|||||||
|
Viewport Display
|
||||||
|
================
|
||||||
|
|
||||||
|
Data
|
||||||
|
Show the captured light using a reflective sphere of the given size.
|
||||||
|
|
||||||
|
Clipping
|
||||||
|
Show the clipping distance in the 3D Viewport.
|
||||||
|
|
||||||
|
Influence
|
||||||
|
Show the influence bounds in the 3D Viewport. The inner sphere is where the falloff starts.
|
||||||
|
|
||||||
|
Parallax
|
||||||
|
Show the *Custom Parallax* shape in the 3D Viewport.
|
172
manual/render/eevee/light_probes/volume.rst
Normal file
@ -0,0 +1,172 @@
|
|||||||
|
|
||||||
|
******************
|
||||||
|
Light Probe Volume
|
||||||
|
******************
|
||||||
|
|
||||||
|
A volume probe records the light incomming from all directions at many locations inside a volume.
|
||||||
fclem marked this conversation as resolved
Outdated
Hans Goudey
commented
`at a many` -> `at many`
|
|||||||
|
|
||||||
|
The light is then filtered and only the diffuse light is recorded.
|
||||||
|
The capture point positions are visible as an overlay when the Irradiance Volume object is selected.
|
||||||
|
|
||||||
|
If an object is not inside any Irradiance Volume, or if the indirect lighting has not been baked,
|
||||||
|
the world's diffuse lighting will be used to shade it.
|
||||||
|
|
||||||
|
.. tip::
|
||||||
|
|
||||||
|
- When lighting indoor environments, try to align grids with the room shape.
|
||||||
|
- Try not to put too much resolution in empty areas or areas with a low amount of lighting variation.
|
||||||
|
- Bad samples can be fixed by adding a smaller grid near the problematic area.
|
||||||
|
- Large scenes may require using many volumes with different level of details.
|
||||||
|
|
||||||
|
|
||||||
|
.. reference::
|
||||||
|
|
||||||
|
:Panel: :menuselection:`Object Data --> Probe`
|
||||||
|
|
||||||
|
Intensity
|
||||||
|
Intensity factor of the recorded lighting.
|
||||||
|
Making this parameter anything other than 1.0 is not physically correct.
|
||||||
|
To be used for tweaking, animating or artistic purposes.
|
||||||
|
|
||||||
|
|
||||||
|
Sampling Bias
|
||||||
|
=============
|
||||||
|
|
||||||
|
Normal Bias
|
||||||
|
Offset sampling of the irradiance grid in the surface normal direction to reduce light bleeding.
|
||||||
|
Can lead to specular appearance of diffuse surface if set too high.
|
||||||
|
|
||||||
|
View Bias
|
||||||
|
Offset sampling of the irradiance grid in the viewing direction to reduce light bleeding.
|
||||||
|
Can lead to view dependant result if set too high. Prefer this if camera is static.
|
||||||
|
|
||||||
|
Facing Bias
|
||||||
|
When set to zero, avoids capturing points behind the shaded surface to bleed light onto
|
||||||
fclem marked this conversation as resolved
Outdated
Hans Goudey
commented
`avoids capture points` -> `avoids capturing points`
|
|||||||
|
the shaded surface. This produces non-smooth interpolation when the capture resolution is high.
|
||||||
fclem marked this conversation as resolved
Outdated
Hans Goudey
commented
`surface, but this` -> `surface. This`
|
|||||||
|
Increasing this bias will make the interpolation smoother but also introduce some light bleeding.
|
||||||
|
|
||||||
|
|
||||||
|
Validity & Dilation
|
||||||
|
===================
|
||||||
|
|
||||||
|
During the baking process, a validity score is assigned to each capture point.
|
||||||
|
This score is based on the number of back-faces hit when capturing the incoming lighting.
|
||||||
fclem marked this conversation as resolved
Outdated
Hans Goudey
commented
`number of back-face was hit` -> `number of back-faces hit`
|
|||||||
|
Only materials with *Single Sided* turned on for Light Probe Volumes will reduce the validity score.
|
||||||
|
|
||||||
|
Validity Threshold
|
||||||
|
Capture points with validity below this threshold will be ignored during lighting interpolation.
|
||||||
|
This remove the influence of capture points trapped inside closed geometry, reducing the artifacts they produced.
|
||||||
|
|
||||||
|
Dilation Threshold
|
||||||
|
Capture points with validity below this threshold will have their data replaced using valid neighbors.
|
||||||
|
|
||||||
|
Dilation radius
|
||||||
|
Radius in capture points in which to search for a valid neighbor.
|
||||||
|
|
||||||
|
|
||||||
|
.. _eevee-lightprobe-volume-bake:
|
||||||
|
|
||||||
|
Bake
|
||||||
|
====
|
||||||
|
|
||||||
|
Light probe volume light data is static and needs to be manually baked.
|
||||||
|
Once baked, the data is stored inside the object data-block and can be moved, animated and linked
|
||||||
|
between blender files.
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
Baking uses the render visibility of the objects in the scene.
|
||||||
|
|
||||||
fclem marked this conversation as resolved
Hans Goudey
commented
`prevent` -> `prevents`
|
|||||||
|
During baking, the scene is converted into a different representation to accelerate light transport.
|
||||||
|
This representation can be very memory intensive and prevents baking if it cannot fit inside the GPU memory.
|
||||||
fclem marked this conversation as resolved
Outdated
Hans Goudey
commented
`Larger scene` -> `Larger scenes`
`or using` -> `or use`
|
|||||||
|
There are a few way to deal with this issue:
|
||||||
|
- Larger scenes should be divided into smaller sections or use different level of details.
|
||||||
|
- Reduce *Surfel Resolution*.
|
||||||
|
- Turn off the light probe volume visibility option on objects that have little to no effect in the bake.
|
||||||
|
|
||||||
|
.. tip::
|
||||||
|
|
||||||
|
The internal scene representation can be inspected using the `Debug Value` 3, 4 and 5.
|
||||||
|
|
||||||
|
Resolution
|
||||||
|
Spatial resolution for volumetric light probes is determined per probe.
|
||||||
fclem marked this conversation as resolved
Hans Goudey
commented
`light sample` -> `light samples`
|
|||||||
|
The local volume is divided into a regular grid of the specified dimensions.
|
||||||
|
The lighting will be captured for each cell in this grid.
|
||||||
|
|
||||||
|
Bake Samples
|
||||||
|
Number of ray directions to evaluate when baking.
|
||||||
|
This increases the baking time proportionally to the size of the scene representation.
|
||||||
|
|
||||||
|
Surfel Resolution
|
||||||
fclem marked this conversation as resolved
Hans Goudey
commented
`quality. Have a huge` -> `quality, but have a huge`
|
|||||||
|
Number of surfels to spawn in one local unit distance.
|
||||||
|
Higher values increase quality, but have a huge impact on memory usage.
|
||||||
|
|
||||||
|
.. tip::
|
||||||
|
A good value is twice the maximum *Resolution*.
|
||||||
|
|
||||||
|
|
||||||
|
Capture
|
||||||
|
=======
|
||||||
|
|
||||||
|
Capture Distance
|
||||||
|
Distance around the light probe volume that will be captured during the bake.
|
||||||
|
A distance of 0 will only considered the inside of the volume.
|
||||||
|
|
||||||
|
World Contribution
|
||||||
|
Bake incoming light from the world instead of just visibility for more accurate lighting,
|
||||||
|
but lose correct blending to surrounding irradiance volumes.
|
||||||
|
|
||||||
|
Indirect Light Contribution
|
||||||
|
Capture light bounces from light source.
|
||||||
|
|
||||||
|
Emission Contribution
|
||||||
|
Capture emissive surfaces when baking.
|
||||||
|
|
||||||
|
|
||||||
|
Clamping
|
||||||
|
========
|
||||||
fclem marked this conversation as resolved
Hans Goudey
commented
`from light object` -> `from the light object`
|
|||||||
|
|
||||||
fclem marked this conversation as resolved
Outdated
Hans Goudey
commented
`or coming` -> or light coming`
|
|||||||
|
Clamp Direct
|
||||||
|
Clamp incoming direct light. 0.0 disables direct light clamping.
|
||||||
|
Here direct light refers to the light that bounces only once (from the light object)
|
||||||
|
or light coming from emissive materials.
|
||||||
|
|
||||||
|
Clamp Indirect
|
||||||
|
Clamp incoming indirect light. 0.0 disables indirect light clamping.
|
||||||
|
Here indirect light refers to the light that bounces off a surface after the first bounce (from the light object)
|
||||||
|
or during the first bounce if the light comes from emissive materials.
|
||||||
|
|
||||||
|
.. tip::
|
||||||
|
|
||||||
|
Setting *Clamp Indirect* to a very non-zero value will effectively only record the first light bounce leading.
|
||||||
|
|
||||||
|
|
||||||
fclem marked this conversation as resolved
Outdated
Hans Goudey
commented
`capture points positioning` -> `capture point positioning`
|
|||||||
|
Offset
|
||||||
fclem marked this conversation as resolved
Hans Goudey
commented
`location. First by` -> `location, first by`
|
|||||||
|
======
|
||||||
fclem marked this conversation as resolved
Hans Goudey
commented
`not so far bellow` -> `not too far below`
|
|||||||
|
|
||||||
|
In order to reduce artifacts caused by bad capture point positioning,
|
||||||
|
the bake process adjusts their location before capturing light.
|
||||||
|
It moves the capture points slightly away from surrounding surfaces and tries to move them out of objects
|
||||||
|
if they are not too far bellow the surface.
|
||||||
|
|
||||||
|
Surface Offset
|
||||||
|
Distance to move the capture points away from surfaces.
|
||||||
|
|
||||||
|
Search Distance
|
||||||
|
Distance to search for valid capture positions if the capture point is near the back-face of a single-sided object.
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
|
||||||
|
Only materials with *Single Sided* turned on for Light Probe Volumes will move capture point position.
|
||||||
|
|
||||||
|
|
||||||
|
Viewport Display
|
||||||
|
================
|
||||||
|
|
||||||
|
Data
|
||||||
|
Show the captured light using small diffuse spheres of the given size.
|
||||||
|
|
||||||
|
Influence
|
||||||
|
Show the influence bounds in the 3D Viewport. The inner sphere is where the falloff starts.
|
||||||
|
|
||||||
|
Clipping
|
||||||
|
Show the clipping distance in the 3D Viewport.
|
144
manual/render/eevee/light_settings.rst
Normal file
@ -0,0 +1,144 @@
|
|||||||
|
|
||||||
|
**************
|
||||||
|
Light Settings
|
||||||
|
**************
|
||||||
|
|
||||||
|
.. reference::
|
||||||
|
|
||||||
|
:Panel: :menuselection:`Properties --> Light`
|
||||||
|
:menuselection:`Shader Editor --> Sidebar --> Options`
|
||||||
|
|
||||||
|
Besides lighting from the background and materials with emission shaders,
|
||||||
fclem marked this conversation as resolved
Outdated
Hans Goudey
commented
`Next to` -> `Besides`
`any object with an emission shader` -> `materials with emission shaders`
|
|||||||
|
lights are another way to add light into the scene.
|
||||||
|
The difference is that they are not directly visible in the rendered image,
|
||||||
|
and can be more easily managed as objects of their own type.
|
||||||
|
|
||||||
|
See :doc:`Light settings </render/lights/light_object>` for settings common to all renderers.
|
||||||
|
|
||||||
|
.. _bpy.types.Light.shadow:
|
||||||
|
|
||||||
|
Shadow
|
||||||
|
======
|
||||||
|
|
||||||
|
EEVEE uses a technique called *Virtual Shadow Mapping* along with *Shadow Map Raytracing*.
|
||||||
|
*Virtual Shadow Mapping* produces more accurate results than traditional shadow mapping by putting resolution
|
||||||
|
only where it is needed. It also includes a very efficient caching mechanism.
|
||||||
|
This technique offers better performance than ray tracing and is compatible
|
||||||
|
with any :ref:`Render Method <bpy.types.Material.render_method>`.
|
||||||
fclem marked this conversation as resolved
Outdated
Hans Goudey
commented
`cannot allocate` -> `cannot allocate enough memory`
|
|||||||
|
|
||||||
|
.. tip::
|
||||||
|
- The error message *Shadow buffer full* means that the system cannot allocate enough shadow memory.
|
||||||
|
Increasing the :ref:`Shadow Pool Size <bpy.types.SceneEEVEE.shadow_pool_size>` or
|
||||||
|
the :ref:`Resolution Limit <bpy.types.Light.shadow_maximum_resolution>` on some lights
|
||||||
|
can fix the issue. Otherwise, the only workaround is to disable shadow casting on some lights.
|
||||||
|
- *Shadow Map Raytracing* can be tweaked in the :ref:`Render Settings <eevee-shadow-raytrace>`.
|
||||||
|
- Turning on :ref:`Jitter <bpy.types.Light.use_shadow_jitter>` can reduce the light leaking artifacts
|
||||||
|
caused by large lights and *Shadow Map Raytracing*.
|
||||||
|
|
||||||
|
.. seealso:: :ref:`Limitations <eevee-limitations-shadows>`.
|
||||||
|
|
||||||
|
.. _bpy.types.Light.use_shadow_jitter:
|
||||||
|
|
||||||
|
Jitter
|
||||||
|
Enable jittered soft shadows to increase shadow precision.
|
||||||
|
Has a high performance impact as the shadow map cannot be cached and needs to be updated for each render sample.
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
The effect isn't visible by default in the viewport. See :ref:`render settings <bpy.types.SceneEEVEE.use_shadow_jitter_viewport>`.
|
||||||
|
|
||||||
fclem marked this conversation as resolved
Outdated
Hans Goudey
commented
Not sure why Not sure why `Percentage Closer Filtering` is capitalized. If it's some concept, maybe it should be a link or reference instead?
|
|||||||
|
.. _bpy.types.Light.shadow_jitter_overblur:
|
||||||
|
|
||||||
|
Overblur
|
||||||
|
Apply shadow tracing to each jittered sample to reduce under-sampling artifacts.
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
Any value higher than zero will result in a blurrier shadow and is not physically correct.
|
||||||
fclem marked this conversation as resolved
Outdated
Hans Goudey
commented
`scene` -> `scenes`
|
|||||||
|
|
||||||
|
.. _bpy.types.Light.shadow_filter_radius:
|
||||||
|
|
||||||
|
Filter
|
||||||
|
Blur shadow aliasing using :abbr:`PCF (Percentage Closer Filtering)` with a circular kernel.
|
||||||
|
The effective world scale of the filter depends on the shadow map resolution at the shadowed pixel position.
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
Any value bigger than 1px will increase the chances of light leaking artifacts.
|
||||||
|
|
||||||
|
.. _bpy.types.Light.shadow_maximum_resolution:
|
||||||
|
|
||||||
|
Resolution Limit
|
||||||
|
Minimum size of a shadow map pixel. Higher values use less memory at the cost of shadow quality.
|
||||||
|
Higher values also speed-up rendering of heavy scenes.
|
||||||
|
Each shadow is scaled depending on the shadowed pixel on screen. This can create very sharp shadows
|
||||||
|
but also requires a lot of memory if the shadowed pixel is close to the camera.
|
||||||
|
This property limits the maximum amount of detail that the shadow map can capture.
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
Reducing the shadow map resolution will increase the chances of light leaking artifacts.
|
||||||
|
|
||||||
|
.. _bpy.types.Light.use_absolute_resolution:
|
||||||
|
|
||||||
|
Absolute Resolution Limit
|
||||||
|
Limit the resolution at 1 unit from the light origin instead of relative to the shadowed pixel.
|
||||||
|
This makes :ref:`Resolution Limit <bpy.types.Light.shadow_maximum_resolution>` act as a regular shadow map pixel size.
|
||||||
|
|
||||||
|
.. hint::
|
||||||
|
|
||||||
|
With this option enabled, the following equation can be used to set the *Resolution Limit* with a desired resolution:
|
||||||
|
|
||||||
|
.. math::
|
||||||
|
resolution\_limit = 2 * \sqrt{2} / resolution
|
||||||
|
|
||||||
|
The :math:`2 * \sqrt{2}` refers to the unit cube diagonal and :math:`resolution` refers to the desired resolution (e.g. 1024px).
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
The setting :ref:`Absolute Resolution Limit <bpy.types.Light.use_absolute_resolution>` does not exist for Sun Light.
|
||||||
|
|
||||||
|
|
||||||
|
Influence
|
||||||
|
=========
|
||||||
|
|
||||||
|
These parameters modulate the intensity of the light depending on the shader type.
|
||||||
|
These are meant for artistic control, and any value other than 1.0 breaks :abbr:`PBR (Physically Based Rendering)` rules.
|
||||||
|
|
||||||
|
.. _bpy.types.Light.diffuse_factor:
|
||||||
|
|
||||||
|
Diffuse
|
||||||
|
Diffuse reflection intensity multiplier.
|
||||||
|
|
||||||
|
.. _bpy.types.Light.specular_factor:
|
||||||
|
|
||||||
|
Glossy
|
||||||
|
Glossy light intensity multiplier.
|
||||||
|
|
||||||
|
.. _bpy.types.Light.transmission_factor:
|
||||||
|
|
||||||
|
Transmission
|
||||||
|
Transmission light intensity multiplier.
|
||||||
|
|
||||||
|
.. _bpy.types.Light.volume_factor:
|
||||||
|
|
||||||
|
Volume Scatter
|
||||||
|
Volume light intensity multiplier.
|
||||||
|
|
||||||
|
|
||||||
|
.. _bpy.types.Light.use_custom_distance:
|
||||||
|
|
||||||
|
Custom Distance
|
||||||
|
===============
|
||||||
|
|
||||||
|
If enabled, uses :ref:`Distance <bpy.types.Light.cutoff_distance>` as the custom attenuation distance
|
||||||
|
instead of global Light Threshold. In order to avoid long setup times, this distance is first computed
|
||||||
|
automatically based on a light threshold.
|
||||||
|
The distance is computed at the light origin and using the inverse square falloff.
|
||||||
|
|
||||||
|
.. _bpy.types.Light.cutoff_distance:
|
||||||
|
|
||||||
|
Distance
|
||||||
|
Specifies where light influence will be set to 0.
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
The setting :ref:`Custom Distance <bpy.types.Light.use_custom_distance>` does not exist for Sun Light.
|
||||||
|
|
||||||
|
.. seealso::
|
||||||
|
|
||||||
|
Global :ref:`Light Threshold <bpy.types.SceneEEVEE.light_threshold>`.
|
@ -1,138 +0,0 @@
|
|||||||
|
|
||||||
**************
|
|
||||||
Light Settings
|
|
||||||
**************
|
|
||||||
|
|
||||||
.. reference::
|
|
||||||
|
|
||||||
:Panel: :menuselection:`Properties --> Light`
|
|
||||||
:menuselection:`Shader Editor --> Sidebar --> Options`
|
|
||||||
|
|
||||||
Next to lighting from the background and any object with an emission shader,
|
|
||||||
lights are another way to add light into the scene.
|
|
||||||
The difference is that they are not directly visible in the rendered image,
|
|
||||||
and can be more easily managed as objects of their own type.
|
|
||||||
|
|
||||||
|
|
||||||
Common
|
|
||||||
======
|
|
||||||
|
|
||||||
:doc:`Light settings </render/lights/light_object>` for all renderers.
|
|
||||||
|
|
||||||
|
|
||||||
.. _bpy.types.Light.use_custom_distance:
|
|
||||||
.. _bpy.types.Light.cutoff_distance:
|
|
||||||
|
|
||||||
EEVEE
|
|
||||||
=====
|
|
||||||
|
|
||||||
Specular
|
|
||||||
Specular Light intensity multiplier. Use it for artistic control. Defines the intensity with which the light object
|
|
||||||
will be visible in reflections on the surface of specular objects, like metals or mirrors.
|
|
||||||
Setting this to 0 will make the light object disappear from specular reflections. Keep it exactly at 1.0 for
|
|
||||||
photo-realistic results.
|
|
||||||
Custom Distance
|
|
||||||
If enabled, uses *Distance* as the custom attenuation distance instead of global Light Threshold.
|
|
||||||
In order to avoid long setup times, this distance is first computed
|
|
||||||
automatically based on a light threshold. The distance is computed
|
|
||||||
at the light origin and using the inverse square falloff.
|
|
||||||
|
|
||||||
Distance
|
|
||||||
Specifies where light influence will be set to 0.
|
|
||||||
|
|
||||||
.. seealso::
|
|
||||||
|
|
||||||
Global :doc:`Light Threshold </render/eevee/render_settings/shadows>`.
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
The light's *Power*/*Strength* affect both specular and diffuse light.
|
|
||||||
|
|
||||||
|
|
||||||
.. _bpy.types.*Light.shadow:
|
|
||||||
|
|
||||||
Shadows
|
|
||||||
=======
|
|
||||||
|
|
||||||
Common Parameters
|
|
||||||
-----------------
|
|
||||||
|
|
||||||
Clip Start
|
|
||||||
Distance from the light object at which the shadow map starts.
|
|
||||||
Any object which is closer to the light than Clip Start will not cast shadows.
|
|
||||||
*Clip Start* is only available for point, spot and area lights.
|
|
||||||
|
|
||||||
Bias
|
|
||||||
Bias applied to the depth test to reduce self-shadowing artifacts.
|
|
||||||
This determines, what size of surface details (for example, bumps) will cast shadows on the object itself.
|
|
||||||
If this value is low, small bumps will cast shadows on the object's surface.
|
|
||||||
This might cause jagged shadow edge between the sunny and shadowy side of the object,
|
|
||||||
but it can be smoothed out by turning on :doc:`Soft Shadows </render/eevee/render_settings/shadows>`
|
|
||||||
|
|
||||||
|
|
||||||
Contact Shadows
|
|
||||||
---------------
|
|
||||||
|
|
||||||
This type of shadow exists to fix light leaking caused by bias or shadow map undersampling.
|
|
||||||
It uses the depth buffer to find occluders (just like Screen Space Reflections).
|
|
||||||
However, just like Screen Space Reflections it has the same limitations,
|
|
||||||
namely, unknown object thickness and effect disappearing at screen edges.
|
|
||||||
|
|
||||||
.. tip::
|
|
||||||
|
|
||||||
The distance of action of Contact Shadows should remain quite small.
|
|
||||||
They are not accurate enough to shadow the entire scene.
|
|
||||||
|
|
||||||
Distance
|
|
||||||
World space distance in which to search for screen space occluder.
|
|
||||||
|
|
||||||
Bias
|
|
||||||
Bias applied to the ray tracing to reduce self-shadowing artifacts.
|
|
||||||
|
|
||||||
Thickness
|
|
||||||
Pixel thickness used to detect occlusion, treating any potential occluder as this thick.
|
|
||||||
|
|
||||||
|
|
||||||
.. _eevee-cascaded-shadow-map:
|
|
||||||
|
|
||||||
Cascaded Shadow Map
|
|
||||||
-------------------
|
|
||||||
|
|
||||||
Sun lights usually illuminate a large scene with many objects, some close, some far away.
|
|
||||||
To optimize shadow calculation in this situation, a technique called Cascaded Shadow Maps is used.
|
|
||||||
The distance between the camera's near clip and far clip point is divided into as many equal intervals
|
|
||||||
(called cascades) as you set the Count parameter below.
|
|
||||||
For each cascade a different resolution shadow will be displayed: higher resolution for closer cascades and lower
|
|
||||||
resolution for distant ones.
|
|
||||||
Do note that cascade shadow maps are always updated because they depend on the camera position or your view origin in
|
|
||||||
the 3D-Viewport. This means they have a high performance impact.
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
In orthographic view the cascades cover the whole depth range of the camera
|
|
||||||
with an evenly distributed shadow precision.
|
|
||||||
|
|
||||||
Count
|
|
||||||
Number of cascades to use. More cascades means better shadow precision but a lower update rate.
|
|
||||||
|
|
||||||
Fade
|
|
||||||
When the Fade is greater than 0, the size of each cascade (distance interval) is increased so that neighboring
|
|
||||||
cascades overlap. Then a fade is applied in the overlapping region to provide a smooth transition between cascades.
|
|
||||||
Higher values mean the cascade's size is increased more, which decreases the available shadow resolution
|
|
||||||
inside the cascade since some of it is used in the overlapping region.
|
|
||||||
|
|
||||||
Max Distance
|
|
||||||
Distance away from the view origin (or camera origin if in camera view) to cover by the cascades.
|
|
||||||
If the view far clip distance is lower than Max Distance, the view far clip distance will be used.
|
|
||||||
Only works in perspective view.
|
|
||||||
|
|
||||||
Distribution
|
|
||||||
Puts more resolution towards the near clip plane. Only works in perspective view.
|
|
||||||
|
|
||||||
.. seealso:: :ref:`Limitations <eevee-limitations-shadows>`.
|
|
||||||
|
|
||||||
|
|
||||||
Limitations
|
|
||||||
===========
|
|
||||||
|
|
||||||
- Unlike in Cycles, the *Size* of spot lights does not change the softness of the cone.
|
|
@ -1,11 +1,10 @@
|
|||||||
|
|
||||||
#############
|
#############
|
||||||
Materials
|
Limitations
|
||||||
#############
|
#############
|
||||||
|
|
||||||
.. toctree::
|
.. toctree::
|
||||||
:maxdepth: 2
|
:maxdepth: 2
|
||||||
|
|
||||||
introduction.rst
|
limitations.rst
|
||||||
nodes_support.rst
|
nodes_support.rst
|
||||||
settings.rst
|
|
@ -25,35 +25,33 @@ Cameras
|
|||||||
Lights
|
Lights
|
||||||
======
|
======
|
||||||
|
|
||||||
- Only 128 active lights can be supported by EEVEE in a scene.
|
- Lights can only have one color and do not support light node trees.
|
||||||
- Only 8 Shadowed sun lights can be supported at the same time.
|
- Unlike in Cycles, the :ref:`Size <bpy.types.SpotLight.shadow_soft_size>` of spot lights does not change the softness of the cone.
|
||||||
- As of now, lights can only have one color and do not support light node trees.
|
- The area light :ref:`Beam spread <bpy.types.SpotLight.spot_size>` option is not supported.
|
||||||
|
|
||||||
|
|
||||||
Light Probes
|
Light Probes
|
||||||
============
|
============
|
||||||
|
|
||||||
- EEVEE only supports up to 128 active Reflection Cubemaps.
|
- EEVEE supports up to 128 active light probe spheres.
|
||||||
- EEVEE only supports up to 64 active Irradiance Volumes.
|
- EEVEE supports up to 16 active light probe planes inside the view frustum.
|
||||||
- EEVEE only supports up to 16 active Reflection Planes inside the view frustum.
|
- Active light probe volumes must fit inside the :ref:`Light Probes Volume Memory Pool <bpy.types.SceneEEVEE.gi_irradiance_pool_size>`.
|
||||||
|
|
||||||
|
|
||||||
Indirect Lighting
|
Indirect Lighting
|
||||||
=================
|
=================
|
||||||
|
|
||||||
- Volumetrics don't receive light from Irradiance Volumes but do receive world's diffuse lighting.
|
- Light probe capture does not support specular reflections. Specular energy is treated as diffuse.
|
||||||
- EEVEE does not support "specular to diffuse" light bounces nor "specular to specular" light bounces.
|
|
||||||
- All specular lighting is turned off during baking.
|
|
||||||
|
|
||||||
|
|
||||||
.. _eevee-limitations-shadows:
|
.. _eevee-limitations-shadows:
|
||||||
|
|
||||||
Shadows
|
Shadows
|
||||||
=======
|
=======
|
||||||
|
|
||||||
- Only 128 active lights can be supported by EEVEE in a scene.
|
- *Shadow Map Raytracing* can produce light leaking because of overlapping shadow casters.
|
||||||
- Only 8 Shadowed sun lights can be supported at the same time.
|
This can be mitigated by using lower :ref:`step count <bpy.types.SceneEEVEE.shadow_step_count>`, enabling
|
||||||
|
:ref:`jitter <bpy.types.Light.use_shadow_jitter>`, or reducing the light shape size.
|
||||||
|
- Thin objects (e.g. walls without thickness) might have light leaking on the shadowed side.
|
||||||
|
This can be mitigated by making the object have some thickness or lowering :ref:`Resolution Limit<bpy.types.Light.shadow_maximum_resolution>`.
|
||||||
|
|
||||||
.. _eevee-limitations-volumetrics:
|
.. _eevee-limitations-volumetrics:
|
||||||
|
|
||||||
@ -62,10 +60,8 @@ Volumetrics
|
|||||||
|
|
||||||
- Only single scattering is supported.
|
- Only single scattering is supported.
|
||||||
- Volumetrics are rendered only for the camera "rays". They don't appear in reflections/refractions and probes.
|
- Volumetrics are rendered only for the camera "rays". They don't appear in reflections/refractions and probes.
|
||||||
- Volumetrics don't receive light from Irradiance Volumes but do receive diffuse lighting from the world.
|
|
||||||
- Volumetric shadowing only work in volumetrics. They won't cast shadows onto solid objects in the scene.
|
- Volumetric shadowing only work in volumetrics. They won't cast shadows onto solid objects in the scene.
|
||||||
- Volumetric shadowing only work for volumes inside the view frustum.
|
- Volumetric shadowing only work for volumes inside the view frustum.
|
||||||
- Volumetric lighting do not respect the lights shapes. They are treated as point lights.
|
|
||||||
|
|
||||||
|
|
||||||
.. _eevee-limitations-dof:
|
.. _eevee-limitations-dof:
|
||||||
@ -73,15 +69,16 @@ Volumetrics
|
|||||||
Depth of Field
|
Depth of Field
|
||||||
==============
|
==============
|
||||||
|
|
||||||
- Alpha blended surfaces cannot be correctly handled by the post-processing blur,
|
- Blended materials cannot be correctly handled by the post-processing blur,
|
||||||
but will be correctly handled by the sample-based method. For this, you need to
|
but will be correctly handled by the sample-based method. For this, you need to
|
||||||
disable the post-process depth of field by setting the *Max Size* to 0.
|
disable the post-process depth of field by setting the *Max Size* to 0.
|
||||||
|
|
||||||
|
.. _eevee-limitations-screenspace:
|
||||||
|
|
||||||
Screen Space Effects
|
Screen Space Effects
|
||||||
====================
|
====================
|
||||||
|
|
||||||
EEVEE is not a ray tracing engine and cannot do ray-triangle intersection.
|
Ray-triangle intersection is not currently supported.
|
||||||
Instead of this, EEVEE uses the depth buffer as an approximated scene representation.
|
Instead of this, EEVEE uses the depth buffer as an approximated scene representation.
|
||||||
This reduces the complexity of scene scale effects and enables a higher performance.
|
This reduces the complexity of scene scale effects and enables a higher performance.
|
||||||
However, only what is in inside the view can be considered when computing these effects.
|
However, only what is in inside the view can be considered when computing these effects.
|
||||||
@ -93,94 +90,41 @@ These limitations creates a few problems:
|
|||||||
This can be partially fixed by using the *overscan* feature.
|
This can be partially fixed by using the *overscan* feature.
|
||||||
- Screen space effects lack deep information (or the thickness of objects).
|
- Screen space effects lack deep information (or the thickness of objects).
|
||||||
This is why most effects have a thickness parameter to control how to consider potential intersected pixels.
|
This is why most effects have a thickness parameter to control how to consider potential intersected pixels.
|
||||||
|
- Objects behind other objects (occluded) are not considered by these effects.
|
||||||
- Blended surfaces are not considered by these effects.
|
- Blended surfaces are not considered by these effects.
|
||||||
They are not part of the depth prepass and do not appear in the depth buffer.
|
They are not part of the depth prepass and do not appear in the depth buffer.
|
||||||
- Objects that a part of :ref:`Holdout Collections <bpy.ops.outliner.collection_holdout_set>`
|
- Objects that a part of :ref:`Holdout Collections <bpy.ops.outliner.collection_holdout_set>`
|
||||||
will not be rendered with screen space effects.
|
will not be rendered with screen space effects.
|
||||||
|
|
||||||
|
|
||||||
.. _eevee-limitations-ao:
|
.. _eevee-limitations-raytracing:
|
||||||
|
|
||||||
Ambient Occlusion
|
Raytracing
|
||||||
-----------------
|
----------
|
||||||
|
|
||||||
- Objects are treated as infinitely thick, producing overshadowing if the *Distance* is really large.
|
|
||||||
|
|
||||||
|
|
||||||
.. _eevee-limitations-reflections:
|
|
||||||
|
|
||||||
Screen Space Reflections
|
|
||||||
------------------------
|
|
||||||
|
|
||||||
- Only one glossy BSDF can emit screen space reflections.
|
|
||||||
- The evaluated BSDF is currently arbitrarily chosen.
|
|
||||||
- Screen Space Reflections will reflect transparent objects and objects using Screen Space Refraction
|
|
||||||
but without accurate positioning due to the one layer depth buffer.
|
|
||||||
|
|
||||||
|
|
||||||
.. _eevee-limitations-refraction:
|
|
||||||
|
|
||||||
Screen Space Refraction
|
|
||||||
-----------------------
|
|
||||||
|
|
||||||
|
- Blended materials and materials using raytrace refractions will not appear in dithered materials reflections.
|
||||||
|
- Blended materials are not compatible with raytracing.
|
||||||
- Only one refraction event is correctly modeled.
|
- Only one refraction event is correctly modeled.
|
||||||
- Only opaque and alpha hashed materials can be refracted.
|
An approximation of the second refraction event can be achieved using the :ref:`Thickness workflow <bpy.types.Material.thickness>`.
|
||||||
|
- Only dithered materials *not* using Raytrace Refractions can be refracted.
|
||||||
|
|
||||||
.. _eevee-limitations-sss:
|
|
||||||
|
|
||||||
Subsurface Scattering
|
|
||||||
---------------------
|
|
||||||
|
|
||||||
- Only one BSSRDF can produce screen space subsurface scattering.
|
|
||||||
- The evaluated BSSRDF is currently arbitrarily chosen.
|
|
||||||
- A maximum of 254 different surfaces can use subsurface scattering.
|
|
||||||
- Only scaling is adjustable per pixel. Individual RGB radii are adjustable in the socket default value.
|
|
||||||
- Input radiance from each surfaces are not isolated during the blurring,
|
|
||||||
leading to light leaking from surface to surface.
|
|
||||||
|
|
||||||
|
|
||||||
Motion Blur
|
|
||||||
===========
|
|
||||||
|
|
||||||
:doc:`Motion Blur </render/eevee/render_settings/motion_blur>`
|
|
||||||
is only available in final renders and is not shown in the 3D Viewport
|
|
||||||
and thus :ref:`Viewport Renders <bpy.ops.render.opengl>`.
|
|
||||||
|
|
||||||
|
|
||||||
.. _eevee-limitations-materials:
|
.. _eevee-limitations-materials:
|
||||||
|
|
||||||
Materials
|
|
||||||
=========
|
|
||||||
|
|
||||||
Refractions
|
|
||||||
Refraction is faked by sampling the same reflection probe used by the Glossy BSDFs,
|
|
||||||
but using the refracted view direction instead of the reflected view direction.
|
|
||||||
Only the first refraction event is modeled correctly.
|
|
||||||
An approximation of the second refraction event can be used for relatively thin objects using Refraction Depth.
|
|
||||||
Using Screen Space refraction will refract what is visible inside the view,
|
|
||||||
and use the nearest probe if there is no hit.
|
|
||||||
|
|
||||||
Screen Space Reflections and Ambient Occlusion are not compatible with Screen Space Refraction;
|
|
||||||
they will be disabled on the surfaces that use it.
|
|
||||||
Surfaces that use Screen Space Refraction will not appear in Screen Space Reflections at the right place.
|
|
||||||
Surfaces that use Screen Space Refraction will not cast Ambient Occlusion onto other surfaces.
|
|
||||||
|
|
||||||
Volume Objects
|
|
||||||
Object volume shaders will affect the whole bounding box of the object.
|
|
||||||
The shape of the volume must be adjusted using procedural texturing inside the shader.
|
|
||||||
|
|
||||||
|
|
||||||
Shader Nodes
|
Shader Nodes
|
||||||
============
|
============
|
||||||
|
|
||||||
- All BSDF's are using approximations to achieve realtime performance
|
- All BSDF's are using approximations to achieve realtime performance
|
||||||
so there will always be small differences between Cycles and EEVEE.
|
so there will always be small differences between Cycles and EEVEE.
|
||||||
- Some utility nodes are not yet compatible with EEVEE.
|
- Some utility nodes are not yet compatible with EEVEE.
|
||||||
|
- Certain combinations of BSDF's will result in more noise than others.
|
||||||
|
This is the case when mixing Diffuse BSDF and Refraction BSDF.
|
||||||
|
- Displacement of flat shaded surfaces will split the mesh into triangles.
|
||||||
|
See :ref:`Displacement <bpy.types.Material.displacement>` for a workaround.
|
||||||
|
|
||||||
.. seealso::
|
.. seealso::
|
||||||
|
|
||||||
For a full list of unsupported nodes see :doc:`Nodes Support </render/eevee/materials/nodes_support>`.
|
For a full list of unsupported nodes see :doc:`Nodes Support </render/eevee/limitations/nodes_support>`.
|
||||||
|
|
||||||
|
|
||||||
Memory Management
|
Memory Management
|
||||||
@ -221,4 +165,4 @@ multiple :abbr:`GPU (Graphic Processing Unit, also known as Graphics Card)` syst
|
|||||||
Headless Rendering
|
Headless Rendering
|
||||||
==================
|
==================
|
||||||
|
|
||||||
There is currently no support for using EEVEE on headless systems (i.e. without a Display Manager).
|
Headless rendering is not supported on headless Windows systems.
|
@ -19,8 +19,10 @@ These nodes are only available if EEVEE is the active render engine. These nodes
|
|||||||
Shader to RGB
|
Shader to RGB
|
||||||
-------------
|
-------------
|
||||||
|
|
||||||
EEVEE supports the conversion of BSDF outputs into color inputs to make any kind of custom shading.
|
EEVEE supports the conversion of BSDF outputs into color inputs to make a wide variety of custom shading.
|
||||||
This is supported using the :doc:`Shader to RGB </render/shader_nodes/converter/shader_to_rgb>` node.
|
This is supported using the :doc:`Shader to RGB </render/shader_nodes/converter/shader_to_rgb>` node.
|
||||||
|
This node evaluates the lighting of the BSDFs connected to it just like a *Blended* material and inherits
|
||||||
|
its limitation.
|
||||||
|
|
||||||
|
|
||||||
Specular BSDF
|
Specular BSDF
|
||||||
@ -51,24 +53,18 @@ Although most BSDFs are supported, many of them are approximations and are not f
|
|||||||
Diffuse BSDF
|
Diffuse BSDF
|
||||||
Roughness is not supported. Only Lambertian diffusion is supported.
|
Roughness is not supported. Only Lambertian diffusion is supported.
|
||||||
|
|
||||||
Emission
|
|
||||||
Treated as indirect lighting and will only show up in :abbr:`SSR (Screen Space Reflection)`\ s and Probes.
|
|
||||||
|
|
||||||
Glass / Refraction BSDF
|
Glass / Refraction BSDF
|
||||||
Does not refract lights. Does not support Beckmann distribution.
|
Only supports GGX and Multiscatter GGX distribution.
|
||||||
See :ref:`Refraction limitations <eevee-limitations-refraction>`.
|
See :ref:`Raytracing limitations <eevee-limitations-raytracing>`.
|
||||||
|
|
||||||
Glossy BSDF
|
Glossy BSDF
|
||||||
Does not support Beckmann and Ashikhmin-Shirley distributions.
|
Only supports GGX and Multiscatter GGX distributions.
|
||||||
|
|
||||||
Subsurface Scattering
|
Subsurface Scattering
|
||||||
Random Walk sampling is not supported. Per color channel Radius is specified by the default socket value.
|
Random Walk sampling, IOR and Anisotropic are not supported.
|
||||||
Any link plugged into this socket gets ignored.
|
|
||||||
Texture Blur is not accurate for any value other than 0.0 and 1.0.
|
|
||||||
|
|
||||||
Transparent BSDF
|
Transparent BSDF
|
||||||
Transparency will only have an effect if the Material blend mode is not Opaque.
|
Colored and additive transparency are only compatible with blended modes.
|
||||||
Colored and additive transparency are only compatible with "Alpha Blend" mode.
|
|
||||||
|
|
||||||
Translucent BSDF
|
Translucent BSDF
|
||||||
Does not diffuse the light inside the object. It only lights the object with reversed normals.
|
Does not diffuse the light inside the object. It only lights the object with reversed normals.
|
||||||
@ -89,8 +85,7 @@ Principled Volume
|
|||||||
Same as Volume Scatter. See :ref:`Volume Limitation <eevee-limitations-volumetrics>`.
|
Same as Volume Scatter. See :ref:`Volume Limitation <eevee-limitations-volumetrics>`.
|
||||||
|
|
||||||
Holdout
|
Holdout
|
||||||
Partially supported, using :ref:`Blend Modes <bpy.types.Material.blend_method>`
|
Partially supported, using dithered mode may give incorrect results.
|
||||||
other than *Alpha* may give incorrect results.
|
|
||||||
|
|
||||||
Anisotropic BSDF
|
Anisotropic BSDF
|
||||||
Not supported.
|
Not supported.
|
||||||
@ -114,9 +109,6 @@ Input Nodes
|
|||||||
Ambient Occlusion
|
Ambient Occlusion
|
||||||
The *Only Local* option is not supported.
|
The *Only Local* option is not supported.
|
||||||
|
|
||||||
Camera Data
|
|
||||||
EveHair Inforything is compatible.
|
|
||||||
|
|
||||||
Geometry
|
Geometry
|
||||||
Pointiness is not supported.
|
Pointiness is not supported.
|
||||||
|
|
||||||
@ -132,37 +124,26 @@ Attribute
|
|||||||
Bevel
|
Bevel
|
||||||
Not supported.
|
Not supported.
|
||||||
|
|
||||||
Fresnel
|
|
||||||
Everything is compatible.
|
|
||||||
|
|
||||||
Curves Info
|
Curves Info
|
||||||
The Random output uses a different :abbr:`RNG (Random Number Generator)` algorithm.
|
The Random output uses a different :abbr:`RNG (Random Number Generator)` algorithm.
|
||||||
Range and statistical distribution of the values should be the same but the values will be different.
|
Range and statistical distribution of the values should be the same but the values will be different.
|
||||||
|
|
||||||
Layer Weight
|
|
||||||
Everything is compatible.
|
|
||||||
|
|
||||||
Light Path
|
Light Path
|
||||||
EEVEE has no real concept of rays. But in order to ease the workflow between Cycles and EEVEE
|
EEVEE has no real concept of rays. But in order to ease the workflow between Cycles and EEVEE
|
||||||
some of the outputs are only supported in particular cases.
|
some of the outputs are only supported in particular cases.
|
||||||
This node makes it possible to tweak indirect lighting in the shader.
|
This node makes it possible to tweak indirect lighting in the shader.
|
||||||
|
|
||||||
Only a subset of the outputs are supported and the ray depth does not exactly have the same meaning.
|
|
||||||
In order for the *Is Camera*, *Is Shadow*, *Is Diffuse*, and *Is Glossy* outputs to work,
|
|
||||||
the object must be inside an :doc:`Irradiance Volume </render/eevee/light_probes/irradiance_volumes>`
|
|
||||||
and :doc:`/render/eevee/render_settings/indirect_lighting` must be baked.
|
|
||||||
|
|
||||||
- *Is Camera*: Supported.
|
- *Is Camera*: Supported.
|
||||||
- *Is Shadow*: Supported.
|
- *Is Shadow*: Supported.
|
||||||
- *Is Diffuse*: Supported.
|
- *Is Diffuse*: Set to 1.0 when baking light probe volume. Otherwise is set to 0.0.
|
||||||
- *Is Glossy*: Supported.
|
- *Is Glossy*: Set to 1.0 when baking light probe sphere or plane. Otherwise is set to 0.0.
|
||||||
- *Is Singular*: Not supported. Same as Is Glossy.
|
- *Is Singular*: Not supported. Same as Is Glossy.
|
||||||
- *Is Reflection*: Not supported. Same as Is Glossy.
|
- *Is Reflection*: Not supported. Same as Is Glossy.
|
||||||
- *Is Transmission*: Not supported. Same as Is Glossy.
|
- *Is Transmission*: Not supported. Same as Is Glossy.
|
||||||
- *Ray Length*: Not supported. Defaults to 1.0.
|
- *Ray Length*: Not supported. Defaults to 1.0.
|
||||||
- *Ray Depth*: Indicates the current bounce when baking the light cache.
|
- *Ray Depth*: Not supported. Defaults to 0.0.
|
||||||
- *Diffuse Depth*: Same as Ray Depth but only when baking diffuse light.
|
- *Diffuse Depth*: Partially supported. Set to 1.0 when baking light probe volume. Otherwise is set to 0.0.
|
||||||
- *Glossy Depth*: Same as Ray Depth but only when baking specular light.
|
- *Glossy Depth*: Partially supported. Set to 1.0 when baking light probe sphere or plane. Otherwise is set to 0.0.
|
||||||
- *Transparent Depth*: Not supported. Defaults to 0.
|
- *Transparent Depth*: Not supported. Defaults to 0.
|
||||||
- *Transmission Depth*: Not supported. Same as Glossy Depth.
|
- *Transmission Depth*: Not supported. Same as Glossy Depth.
|
||||||
|
|
||||||
@ -171,15 +152,9 @@ Light Path
|
|||||||
*Is Glossy* does not work with Screen Space Reflections/Refractions
|
*Is Glossy* does not work with Screen Space Reflections/Refractions
|
||||||
but does work with reflection planes (whether used with SSR or not).
|
but does work with reflection planes (whether used with SSR or not).
|
||||||
|
|
||||||
Object Info
|
|
||||||
Everything is compatible.
|
|
||||||
|
|
||||||
Particle Info
|
Particle Info
|
||||||
Not supported.
|
Not supported.
|
||||||
|
|
||||||
Tangent
|
|
||||||
Everything is compatible.
|
|
||||||
|
|
||||||
Texture Coordinate
|
Texture Coordinate
|
||||||
*From Instancer* is not supported.
|
*From Instancer* is not supported.
|
||||||
|
|
||||||
@ -218,12 +193,3 @@ Other Nodes
|
|||||||
|
|
||||||
Light Falloff
|
Light Falloff
|
||||||
Not supported.
|
Not supported.
|
||||||
|
|
||||||
Bump
|
|
||||||
Imprecision due to less precise derivatives.
|
|
||||||
|
|
||||||
Displacement/Vector Displacement
|
|
||||||
Not supported.
|
|
||||||
|
|
||||||
Material Output
|
|
||||||
Displacement output behavior is broken compared to Cycles.
|
|
198
manual/render/eevee/material_settings.rst
Normal file
@ -0,0 +1,198 @@
|
|||||||
|
*****************
|
||||||
|
Material Settings
|
||||||
|
*****************
|
||||||
|
|
||||||
|
.. reference::
|
||||||
|
|
||||||
|
:Panel: :menuselection:`Properties --> Material --> Settings`
|
||||||
|
|
||||||
|
.. seealso::
|
||||||
|
|
||||||
|
While EEVEE shares the same material node system as Cycles, not all features are supported.
|
||||||
|
See :ref:`Shader nodes limitations <eevee-limitations-materials>`.
|
||||||
|
|
||||||
|
Pass Index
|
||||||
|
==========
|
||||||
|
|
||||||
|
Index number for the *Material Index* :doc:`render pass </render/layers/passes>`.
|
||||||
|
This can be used to give a mask to a material which then can be read with
|
||||||
|
the :doc:`ID Mask Node </compositing/types/mask/id_mask>` in the Compositor.
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
|
||||||
|
:doc:`Volume Objects </modeling/volumes/introduction>` dp not support the pass index.
|
||||||
|
|
||||||
|
|
||||||
|
.. _bpy.types.Material.surface:
|
||||||
|
|
||||||
|
Surface
|
||||||
|
=======
|
||||||
|
|
||||||
|
Backface Culling
|
||||||
|
Backface Culling hides the back side of faces.
|
||||||
|
This option should be turned on whenever it is possible, as it has an impact on performance.
|
||||||
|
|
||||||
|
Camera
|
||||||
|
Use back face culling to hide the back side of the face.
|
||||||
|
|
||||||
|
Shadow
|
||||||
|
Use back face culling when casting shadows.
|
||||||
|
|
||||||
|
Light Probe Volume
|
||||||
|
Use back face culling when baking light probe volumes.
|
||||||
|
Additionally helps rejecting capture point inside the object to avoid light leaking.
|
||||||
|
|
||||||
|
.. seealso::
|
||||||
|
|
||||||
|
:doc:`Light Probe Volume </render/eevee/light_probes/volume>`.
|
||||||
|
|
||||||
|
|
||||||
|
.. _bpy.types.Material.displacement:
|
||||||
|
|
||||||
|
Displacement
|
||||||
|
------------
|
||||||
|
|
||||||
|
Displacement Type
|
||||||
|
Controls how the displacement output from the shader node tree is used.
|
||||||
|
|
||||||
|
:Bump Only:
|
||||||
|
Use Bump Mapping to simulated the appearance of displacement.
|
||||||
|
This only modifies the shading normal of the object. Vertex position is not affected.
|
||||||
fclem marked this conversation as resolved
Hans Goudey
commented
`and fallback to` -> `and falls back to`
|
|||||||
|
|
||||||
|
:Displacement Only:
|
||||||
|
This mode is not supported and falls back to *Displacement and Bump*.
|
||||||
|
|
||||||
|
:Displacement and Bump:
|
||||||
|
Combination of true displacement and bump mapping for finer details.
|
||||||
|
Vertex position is modified.
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
This type of displacement is not precomputed. It has a performance impact multiplied by the
|
||||||
|
render sample count. However, the evaluation is much faster than doing it using geometry
|
||||||
|
nodes or a displacement modifier.
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
Displacing flat shaded geometry will split adjacent faces.
|
||||||
|
This can be worked around by passing the vertex normals as a custom attribute.
|
||||||
|
|
||||||
|
Max Displacement
|
||||||
|
The maximum distance a vertex can be displaced when using true displacement.
|
||||||
|
Displacements over this threshold may cause visibility issues.
|
||||||
|
These visibility issues can be observed when the object is out of view at the edge of screen
|
||||||
|
with parts being displaced inside the view. The object would then disappear because of camera culling.
|
||||||
|
This can also produce missing shadow updates where the displaced geometry is.
|
||||||
|
|
||||||
|
.. _bpy.types.Material.use_transparent_shadow:
|
||||||
|
|
||||||
|
Transparent shadows
|
||||||
|
Use transparent shadows for this material if it contains a Transparent BSDF.
|
||||||
|
Disabling will render faster but not give accurate shadows.
|
||||||
|
|
||||||
|
.. _bpy.types.Material.render_method:
|
||||||
|
|
||||||
|
Render Method
|
||||||
|
Controls the blending and the compatibility with certain features.
|
||||||
|
|
||||||
|
:Dithered:
|
||||||
|
Allows for grayscale hashed transparency, and compatible with render passes and raytracing.
|
||||||
|
Also know as deferred rendering.
|
||||||
|
|
||||||
|
:Blended:
|
||||||
|
Allows the colored transparency, but incompatible with render passes and raytracing.
|
||||||
|
Also known as forward rendering.
|
||||||
|
|
||||||
|
|
||||||
|
Dithered Layers
|
||||||
|
---------------
|
||||||
|
|
||||||
|
When using *Dithered* render method, the materials are rendered in layers.
|
||||||
|
Each layer can only transmit (e.g. refract) light emitted from previous layers.
|
||||||
|
If no intersection with the layers below exists, the transmissive BSDFs will fallback to light probes.
|
||||||
|
|
||||||
|
Raytraced Transmission
|
||||||
|
Use raytracing to determine transmitted color instead of using only light probes.
|
||||||
|
This prevents the surface from contributing to the lighting of surfaces not using this setting.
|
||||||
|
|
||||||
|
|
||||||
|
Sorting Problem
|
||||||
|
---------------
|
||||||
|
|
||||||
|
When using *Blended* render method, the order in which the color blending happens is important as it
|
||||||
fclem marked this conversation as resolved
Hans Goudey
commented
`As of now` can be removed, the documentation should always just refer to the current state/version
|
|||||||
|
can change the final output color. EEVEE does not support per-fragment (pixel) sorting or per-triangle sorting.
|
||||||
|
Only per-object sorting is available and is automatically done on all transparent surfaces based on object origin.
|
||||||
|
Opaque surfaces (i.e. that have no transparency) will still have correct sorting regardless of the render method.
|
||||||
|
|
||||||
|
.. tip::
|
||||||
fclem marked this conversation as resolved
Hans Goudey
commented
How about mentioning the How about mentioning the `Sort Elements` geometry node here too? ;)
|
|||||||
|
Face order can be adjusted in edit mode by using :doc:`sort element </modeling/meshes/editing/mesh/sort_elements>`
|
||||||
|
or using :doc:`geometry node </modeling/geometry_nodes/geometry/operations/sort_elements>`.
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
|
||||||
fclem marked this conversation as resolved
Hans Goudey
commented
`these objects` -> `objects`
|
|||||||
|
Per-object sorting has a performance cost and having thousands of
|
||||||
|
objects in a scene will greatly degrade performance.
|
||||||
|
|
||||||
|
.. _bpy.types.Material.use_transparency_overlap:
|
||||||
|
|
||||||
|
Transparency Overlap
|
||||||
|
If enabled, all transparent fragments will be rendered.
|
||||||
|
If disabled, only the front-most surface fragments will be rendered.
|
||||||
|
This option can be disabled to fix sorting issues caused by blending order.
|
||||||
|
Only available for the *Blended* render method.
|
||||||
|
|
||||||
|
|
||||||
|
.. _bpy.types.Material.thickness:
|
||||||
|
|
||||||
|
Thickness
|
||||||
|
---------
|
||||||
|
|
||||||
fclem marked this conversation as resolved
Outdated
Hans Goudey
commented
`, then a default` -> `, a default`
|
|||||||
|
This feature is used to approximate the inner geometry structure of the object without heavy computation.
|
||||||
|
This is currently used for Subsurface, Translucent BSDF, Refraction BSDF and the nodes containing them.
|
||||||
|
|
||||||
|
If no value is plugged into the output node, a default thickness based on the smallest dimension of the object is computed.
|
||||||
|
If a value is connected it will be used as object space thickness (i.e. scaled by object transform).
|
||||||
|
A value of zero will disable the thickness approximation and treat the object as having only one interface.
|
||||||
fclem marked this conversation as resolved
Hans Goudey
commented
Capitalize list items Capitalize list items
|
|||||||
|
|
||||||
|
.. note::
|
||||||
|
- The thickness is used to skip the inner part of the object.
|
||||||
|
- Refraction will not refract objects inside the thickness distance.
|
||||||
|
- Shadow casting object will not cast shadow within the thickness distance.
|
||||||
|
|
||||||
|
.. tip::
|
||||||
|
- For large or compound meshes (e.g. vegetation), the thickness should be set to the thickness of individual parts (e.g. leaves, grass blades).
|
||||||
|
- Thickness can be baked to textures or custom attributes for more accurate result.
|
||||||
|
|
||||||
|
Thickness Mode
|
||||||
|
Determines what model to use to approximate the object geometry.
|
||||||
|
|
||||||
|
:Sphere:
|
||||||
|
Approximate the object as a sphere whose diameter is equal to the thickness defined by the node tree.
|
||||||
|
This is more suited to objects with rounder edges (e.g. a monkey head), and is perfectly suited to spheres.
|
||||||
|
|
||||||
|
:Slab:
|
||||||
|
Approximate the object as an infinite slab of thickness defined by the node tree.
|
||||||
|
This is more suited to very flat or thin objects (e.g. glass panels, grass blades).
|
||||||
|
|
||||||
|
From Shadow
|
||||||
|
Use the shadow maps from shadow casting lights to refine the thickness defined by the material node tree.
|
||||||
|
This takes the minimum thickness between the shadow map and the material node tree value.
|
||||||
|
This is useful for objects where pre-computation is difficult (e.g. complex meshes), impossible
|
||||||
|
(e.g. procedural geometry with displacement) or just impractical.
|
||||||
|
However, this will have a performance impact that scale with the number of render samples.
|
||||||
|
|
||||||
|
|
||||||
|
.. _bpy.types.Material.volume:
|
||||||
|
|
||||||
|
Volume
|
||||||
|
======
|
||||||
|
|
||||||
|
Intersection
|
||||||
|
Determines which inner part of the mesh will produce volumetric effect.
|
||||||
|
|
||||||
|
:Fast:
|
||||||
|
Each face is considered as a medium interface. Gives correct results for manifold geometry
|
||||||
|
that contains no inner part.
|
||||||
|
|
||||||
|
:Accurate:
|
||||||
|
Faces are considered as medium interface only when they have different consecutive facing.
|
||||||
|
Gives correct results as long as the max ray depth is not exceeded. Has significant memory
|
||||||
|
overhead compared to the fast method.
|
@ -1,25 +0,0 @@
|
|||||||
|
|
||||||
************
|
|
||||||
Introduction
|
|
||||||
************
|
|
||||||
|
|
||||||
EEVEE's materials system uses the same node based approach as :doc:`Cycles </render/materials/index>`.
|
|
||||||
|
|
||||||
|
|
||||||
Nodes Support
|
|
||||||
=============
|
|
||||||
|
|
||||||
Due to realtime constraints, not all Cycles features are available in EEVEE.
|
|
||||||
See :doc:`/render/eevee/materials/nodes_support`.
|
|
||||||
|
|
||||||
|
|
||||||
Performance
|
|
||||||
===========
|
|
||||||
|
|
||||||
Performance is highly dependent on the number of BSDF nodes present in the node tree.
|
|
||||||
|
|
||||||
.. tip::
|
|
||||||
|
|
||||||
Prefer using the Principled BSDF instead of multiple BSDF nodes because EEVEE is optimized for it.
|
|
||||||
|
|
||||||
.. seealso:: :ref:`Limitations <eevee-limitations-materials>`.
|
|
@ -1,170 +0,0 @@
|
|||||||
|
|
||||||
*****************
|
|
||||||
Material Settings
|
|
||||||
*****************
|
|
||||||
|
|
||||||
.. reference::
|
|
||||||
|
|
||||||
:Panel: :menuselection:`Properties --> Material --> Settings`
|
|
||||||
|
|
||||||
|
|
||||||
.. _bpy.types.Material.use_backface_culling:
|
|
||||||
|
|
||||||
Backface Culling
|
|
||||||
================
|
|
||||||
|
|
||||||
Backface Culling hides the back side of faces.
|
|
||||||
|
|
||||||
|
|
||||||
.. _bpy.types.Material.blend_method:
|
|
||||||
|
|
||||||
Blend Mode
|
|
||||||
==========
|
|
||||||
|
|
||||||
After calculating the color of a surface, the blend mode defines how it is added to the color buffer.
|
|
||||||
Depending on this, the final color will be different.
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
Alpha Blending is considered a "Transparent" blend mode
|
|
||||||
and has implications regarding screen space effects.
|
|
||||||
|
|
||||||
Opaque
|
|
||||||
The previous color will be overwritten by the surface color.
|
|
||||||
The alpha component is ignored. This is the fastest option.
|
|
||||||
|
|
||||||
Alpha Clip
|
|
||||||
The previous color will be overwritten by the surface color,
|
|
||||||
but only if the alpha value is above the *Clip Threshold* value.
|
|
||||||
|
|
||||||
Alpha Hashed
|
|
||||||
The previous color will be overwritten by the surface color,
|
|
||||||
but only if the alpha value is above a random clip threshold.
|
|
||||||
This statistical approach is noisy but is able to approximate alpha blending without any sorting problem.
|
|
||||||
Increasing the sample count in the render settings will reduce the resulting noise.
|
|
||||||
|
|
||||||
Alpha Blending
|
|
||||||
Use alpha blending to overlay the surface color on top of the previous color.
|
|
||||||
|
|
||||||
|
|
||||||
Sorting Problem
|
|
||||||
---------------
|
|
||||||
|
|
||||||
When writing to the color buffer using transparent blend modes,
|
|
||||||
the order in which the color blending happens is important as it can change the final output color.
|
|
||||||
As of now EEVEE does not support per-fragment (pixel) sorting or per-triangle sorting.
|
|
||||||
Only per-object sorting is available and is automatically done on all transparent surfaces based on object origin.
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
Per-object sorting has a performance cost and having thousands of
|
|
||||||
these objects in a scene will greatly degrade performance.
|
|
||||||
|
|
||||||
.. _bpy.types.Material.show_transparent_back:
|
|
||||||
|
|
||||||
Show Backface
|
|
||||||
If enabled, all transparent fragments will be rendered.
|
|
||||||
If disabled, only the front-most surface fragments will be rendered.
|
|
||||||
Disable this option to ensure correct appearance of transparency from any point of view.
|
|
||||||
When using *Alpha Blending* this option should be disabled because with *Alpha Blending*,
|
|
||||||
the order in which triangles are sorted is important.
|
|
||||||
|
|
||||||
|
|
||||||
.. _bpy.types.Material.shadow_method:
|
|
||||||
|
|
||||||
Shadow Mode
|
|
||||||
===========
|
|
||||||
|
|
||||||
Type of shadows used for a transparent surface.
|
|
||||||
EEVEE does not support colored shadow maps.
|
|
||||||
|
|
||||||
Half transparent shadows can be produced by using hashed transparent shadows and
|
|
||||||
a larger Soft value on the shadow map.
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
This option does not change the behavior of contact shadows which are traced using the depth buffer.
|
|
||||||
If the material is writing to the depth buffer
|
|
||||||
(in other words, if the blend mode is set to either *Opaque*, *Alpha Clip* or *Alpha Hashed*),
|
|
||||||
contact shadows will be cast by the surface material regardless of the *Transparent Shadow* type.
|
|
||||||
|
|
||||||
None
|
|
||||||
The surface will not cast any shadow.
|
|
||||||
|
|
||||||
Opaque
|
|
||||||
The surface will cast shadows like an opaque surface.
|
|
||||||
|
|
||||||
Alpha Clip
|
|
||||||
The surface will cast shadows like an opaque surface,
|
|
||||||
but only areas where the alpha value is above the *Clip Threshold* value.
|
|
||||||
|
|
||||||
Alpha Hashed
|
|
||||||
The surface will cast shadows like an opaque surface,
|
|
||||||
but only areas where the alpha value is above a random threshold.
|
|
||||||
|
|
||||||
|
|
||||||
.. _bpy.types.Material.alpha_threshold:
|
|
||||||
|
|
||||||
Clip Threshold
|
|
||||||
==============
|
|
||||||
|
|
||||||
Threshold value for Alpha Clip mode in *Blend Mode* and *Shadow Mode*.
|
|
||||||
|
|
||||||
|
|
||||||
Screen Space Refraction
|
|
||||||
=======================
|
|
||||||
|
|
||||||
Enabling Screen Space Refraction on a surface means that refraction BSDFs
|
|
||||||
will do a ray trace against the depth buffer to find the most accurate refracted color.
|
|
||||||
This has a big performance cost if the surface covers a lot of pixels.
|
|
||||||
|
|
||||||
Screen Space Reflections and Ambient Occlusion are not compatible with Screen Space Refraction.
|
|
||||||
They will be disabled on the surfaces that use it.
|
|
||||||
Surfaces that use Screen Space Refraction will not appear in Screen Space Reflections at the right place.
|
|
||||||
Surfaces that use Screen Space Refraction will not cast Ambient Occlusion onto other surfaces.
|
|
||||||
|
|
||||||
If this option is disabled or if the Screen Space Refraction ray tracing fails,
|
|
||||||
the refracted ray will use the color of the nearest probe.
|
|
||||||
|
|
||||||
.. _bpy.types.Material.use_screen_refraction:
|
|
||||||
|
|
||||||
Screen Space Refraction
|
|
||||||
Enables screen space refraction.
|
|
||||||
|
|
||||||
.. _bpy.types.Material.refraction_depth:
|
|
||||||
|
|
||||||
Refraction Depth
|
|
||||||
If Refraction Depth is not 0.0, all refraction BSDFs in the shader will act as if
|
|
||||||
the object is a thin slab of the refraction material having this thickness.
|
|
||||||
This will model a second refraction event that will double the absorption color and
|
|
||||||
start the refraction ray after this second event.
|
|
||||||
|
|
||||||
This option greatly increases the quality of thin glass objects.
|
|
||||||
|
|
||||||
|
|
||||||
.. _bpy.types.Material.use_sss_translucency:
|
|
||||||
|
|
||||||
Subsurface Translucency
|
|
||||||
=======================
|
|
||||||
|
|
||||||
EEVEE's Subsurface Scattering algorithm works by blurring the irradiance in screen space.
|
|
||||||
This means that if no visible part of the surface is lit, the effect disappears.
|
|
||||||
|
|
||||||
However, true Subsurface Scattering goes beneath the surface and can travel a large distance.
|
|
||||||
This is why a human ear lit from behind appears red on the front side.
|
|
||||||
|
|
||||||
That is what this effect mimics. This translucency approximation only works
|
|
||||||
with lights that have shadow maps and only on Subsurface BSDFs (not the Translucency BSDFs).
|
|
||||||
It does not work with indirect lighting. The soft parameter of the shadow maps also affects this effect.
|
|
||||||
|
|
||||||
|
|
||||||
Pass Index
|
|
||||||
==========
|
|
||||||
|
|
||||||
Index number for the *Material Index* :doc:`render pass </render/layers/passes>`.
|
|
||||||
This can be used to give a mask to a material which then can be read with
|
|
||||||
the :doc:`ID Mask Node </compositing/types/mask/id_mask>` in the Compositor.
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
:doc:`Volume Objects </modeling/volumes/introduction>` are not supported.
|
|
11
manual/render/eevee/object_settings/index.rst
Normal file
@ -0,0 +1,11 @@
|
|||||||
|
|
||||||
|
###################
|
||||||
|
Object Settings
|
||||||
|
###################
|
||||||
|
|
||||||
|
Settings for objects and object data.
|
||||||
|
|
||||||
|
.. toctree::
|
||||||
|
:maxdepth: 2
|
||||||
|
|
||||||
|
object_data.rst
|
44
manual/render/eevee/object_settings/object_data.rst
Normal file
@ -0,0 +1,44 @@
|
|||||||
|
|
||||||
|
******
|
||||||
|
Object
|
||||||
|
******
|
||||||
|
|
||||||
|
Ray Visibility
|
||||||
|
--------------
|
||||||
|
|
||||||
|
Objects can be set to be invisible to particular ray types.
|
||||||
|
This can be used, for example, to make an emitting mesh invisible to camera rays.
|
||||||
|
For instanced objects, visibility is inherited; if the parent object is hidden for some ray types,
|
||||||
|
the children will be hidden for these too.
|
||||||
|
|
||||||
|
In terms of performance, using these options is more efficient that using a shader node setup
|
||||||
|
that achieves the same effect.
|
||||||
|
|
||||||
|
.. _bpy.types.Object.visible_shadow:
|
||||||
|
|
||||||
|
Shadow
|
||||||
|
Enables the object to cast shadows. The object will not be capture inside the shadow maps.
|
||||||
|
|
||||||
|
|
||||||
|
Light Probes
|
||||||
|
------------
|
||||||
|
|
||||||
|
Objects can be set to not be captured by certain :doc:`light probe </render/eevee/light_probes/introduction>`.
|
||||||
|
This can be used, for example, to avoid animated object being recorded into static light probes.
|
||||||
|
For instanced objects, visibility is inherited; if the parent object is hidden for some ray types,
|
||||||
|
the children will be hidden for these too.
|
||||||
|
|
||||||
|
.. _bpy.types.Object.hide_probe_volume:
|
||||||
|
|
||||||
|
Volume
|
||||||
|
Makes the object visible during light probe volumes :ref:`baking <eevee-lightprobe-volume-bake>`.
|
||||||
|
|
||||||
|
.. _bpy.types.Object.hide_probe_sphere:
|
||||||
|
|
||||||
|
Sphere
|
||||||
|
Makes the object visible during light probe sphere capture.
|
||||||
|
|
||||||
|
.. _bpy.types.Object.hide_probe_plane:
|
||||||
|
|
||||||
|
Plane
|
||||||
|
Makes the object visible during light probe plane capture.
|
@ -1,40 +0,0 @@
|
|||||||
.. _bpy.types.SceneEEVEE.gtao:
|
|
||||||
|
|
||||||
*****************
|
|
||||||
Ambient Occlusion
|
|
||||||
*****************
|
|
||||||
|
|
||||||
Ambient occlusion is computed using :abbr:`GTAO (Ground Truth Ambient Occlusion)` and applied to indirect lighting.
|
|
||||||
The bent normal option will make the diffuse lighting come from only the least occluded direction.
|
|
||||||
|
|
||||||
Ambient occlusion can be rendered as a separate pass in the Render Layers panel.
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
This effect needs to be enabled for the :doc:`Ambient Occlusion </render/shader_nodes/input/ao>` node to work.
|
|
||||||
|
|
||||||
.. reference::
|
|
||||||
|
|
||||||
:Panel: :menuselection:`Render --> Ambient Occlusion`
|
|
||||||
|
|
||||||
Distance
|
|
||||||
Distance of object that contributes to the ambient occlusion effect.
|
|
||||||
|
|
||||||
Factor
|
|
||||||
Blend factor for the ambient occlusion effect.
|
|
||||||
|
|
||||||
Trace Precision
|
|
||||||
Increases precision of the effect but introduces more noise and lowers the maximum trace distance.
|
|
||||||
Increased precision also increases the performance cost.
|
|
||||||
Lower precision will also miss occluders and lead to undershadowing.
|
|
||||||
|
|
||||||
Bent Normals
|
|
||||||
Compute the least occluded direction.
|
|
||||||
This direction can be used to sample the diffuse irradiance in a more realistic way.
|
|
||||||
|
|
||||||
Bounce Approximation
|
|
||||||
An approximation to simulate light bounces giving less occlusion on brighter objects.
|
|
||||||
It only takes into account the surface color and not its surroundings.
|
|
||||||
This is not applied to the ambient occlusion pass.
|
|
||||||
|
|
||||||
.. seealso:: :ref:`Limitations <eevee-limitations-ao>`.
|
|
@ -1,30 +0,0 @@
|
|||||||
.. _bpy.types.SceneEEVEE.bloom:
|
|
||||||
|
|
||||||
*****
|
|
||||||
Bloom
|
|
||||||
*****
|
|
||||||
|
|
||||||
Bloom is a post-process effect that diffuses very bright pixels. This mimics lens artifacts of real cameras.
|
|
||||||
This allows a better sense of what the actual intensities of the pixels are.
|
|
||||||
|
|
||||||
.. reference::
|
|
||||||
|
|
||||||
:Panel: :menuselection:`Render --> Bloom`
|
|
||||||
|
|
||||||
Threshold
|
|
||||||
Filters out pixels under this level of brightness.
|
|
||||||
|
|
||||||
Knee
|
|
||||||
Makes transition between under/over-threshold gradual.
|
|
||||||
|
|
||||||
Radius
|
|
||||||
Bloom spread distance.
|
|
||||||
|
|
||||||
Color
|
|
||||||
Color applied to the bloom effect.
|
|
||||||
|
|
||||||
Intensity
|
|
||||||
Blend factor.
|
|
||||||
|
|
||||||
Clamp
|
|
||||||
Maximum intensity a bloom pixel can have.
|
|
45
manual/render/eevee/render_settings/clamping.rst
Normal file
@ -0,0 +1,45 @@
|
|||||||
|
|
||||||
|
********
|
||||||
|
Clamping
|
||||||
|
********
|
||||||
|
|
||||||
|
.. reference::
|
||||||
|
|
||||||
|
:Panel: :menuselection:`Render --> Clamping`
|
||||||
|
|
||||||
|
|
||||||
|
.. _bpy.types.SceneEEVEE.clamp_surface_direct:
|
||||||
|
.. _bpy.types.SceneEEVEE.clamp_surface_indirect:
|
||||||
|
|
||||||
|
Surface
|
||||||
|
_______
|
||||||
|
|
||||||
|
Direct Light
|
||||||
|
This option limits the maximum light intensity a surface can reflect.
|
||||||
|
It reduces :term:`Aliasing` noise and :term:`Fireflies` at the cost of accuracy.
|
||||||
|
Setting this option to 0.0 disables clamping altogether.
|
||||||
|
Lower values have a greater effect on the resulting image than higher values.
|
||||||
|
|
||||||
|
|
||||||
|
Indirect Light
|
||||||
|
Similar to **Direct Light** but limits the maximum light intensity reflected using ray-tracing and light-probes.
|
||||||
fclem marked this conversation as resolved
Outdated
Hans Goudey
commented
Mismatched * Mismatched *
|
|||||||
|
|
||||||
|
.. note::
|
||||||
|
|
||||||
|
These options provide a way to limit :term:`Fireflies` and :term:`Aliasing` of highly reflective surfaces and dense volumes.
|
||||||
fclem marked this conversation as resolved
Outdated
Hans Goudey
commented
`These options provides` -> `These options provide`
|
|||||||
|
However, note that as you clamp out such values, other bright lights will be dimmed as well.
|
||||||
|
|
||||||
|
Care must be taken when using this setting to find a balance between mitigating fireflies and
|
||||||
|
losing intentionally bright parts.
|
||||||
|
|
||||||
|
.. _bpy.types.SceneEEVEE.clamp_volume_direct:
|
||||||
|
.. _bpy.types.SceneEEVEE.clamp_volume_indirect:
|
||||||
|
|
||||||
|
Volume
|
||||||
|
______
|
||||||
|
|
||||||
|
Direct Light
|
||||||
|
The same as *Surface Direct Light* but for volume direct lighting.
|
||||||
|
|
||||||
|
Indirect Light
|
||||||
|
The same as *Surface Direct Light* but for volume indirect lighting.
|
@ -48,14 +48,6 @@ Neighbor Rejection
|
|||||||
Lower values will improve the performance but will also reduce the quality of highlights.
|
Lower values will improve the performance but will also reduce the quality of highlights.
|
||||||
Brightness is in the scene's referred color space.
|
Brightness is in the scene's referred color space.
|
||||||
|
|
||||||
Denoise Amount
|
|
||||||
This will reduce the flickering by clamping the color of
|
|
||||||
each pixels to their neighborhood's average instead of their maximum.
|
|
||||||
Higher values gives more stable results but may darken the scene.
|
|
||||||
|
|
||||||
High Quality Slight Defocus
|
|
||||||
Increase the quality of almost in-focus regions.
|
|
||||||
|
|
||||||
Jitter Camera
|
Jitter Camera
|
||||||
Randomize the camera position for every scene render sample to increase precision.
|
Randomize the camera position for every scene render sample to increase precision.
|
||||||
Enabling this option can change the scene's actual sample count.
|
Enabling this option can change the scene's actual sample count.
|
||||||
|
@ -7,7 +7,7 @@ Filter Size
|
|||||||
Due to limited resolution of images and computer screens, pixel filters are needed to avoid :term:`Aliasing`.
|
Due to limited resolution of images and computer screens, pixel filters are needed to avoid :term:`Aliasing`.
|
||||||
This is achieved by slightly blurring the image to soften edges.
|
This is achieved by slightly blurring the image to soften edges.
|
||||||
|
|
||||||
This Setting controls home much the image is softened;
|
This Setting controls how much the image is softened;
|
||||||
lower values give more crisp renders, higher values are softer and reduce aliasing.
|
lower values give more crisp renders, higher values are softer and reduce aliasing.
|
||||||
|
|
||||||
Transparent
|
Transparent
|
||||||
|
@ -8,16 +8,12 @@
|
|||||||
:maxdepth: 2
|
:maxdepth: 2
|
||||||
|
|
||||||
sampling.rst
|
sampling.rst
|
||||||
grease_pencil.rst
|
clamping.rst
|
||||||
ambient_occlusion.rst
|
raytracing.rst
|
||||||
bloom.rst
|
volumes.rst
|
||||||
|
curves.rst
|
||||||
depth_of_field.rst
|
depth_of_field.rst
|
||||||
subsurface_scattering.rst
|
motion_blur.rst
|
||||||
screen_space_reflections.rst
|
|
||||||
motion_blur
|
|
||||||
volumetrics.rst
|
|
||||||
performance.rst
|
|
||||||
hair.rst
|
|
||||||
shadows.rst
|
|
||||||
indirect_lighting.rst
|
|
||||||
film.rst
|
film.rst
|
||||||
|
performance.rst
|
||||||
|
grease_pencil.rst
|
||||||
|
@ -1,73 +0,0 @@
|
|||||||
.. _bpy.ops.scene.light_cache:
|
|
||||||
.. _bpy.types.SceneEEVEE.gi:
|
|
||||||
|
|
||||||
*****************
|
|
||||||
Indirect Lighting
|
|
||||||
*****************
|
|
||||||
|
|
||||||
While not strictly correct, all lighting that is not coming straight out
|
|
||||||
from a light object is considered as indirect lighting in EEVEE.
|
|
||||||
That means distant :term:`HDRI` lighting (or World) is considered as indirect lighting.
|
|
||||||
Mesh objects using an Emission node are also considered as indirect lighting.
|
|
||||||
|
|
||||||
In EEVEE, indirect lighting is separated into two component: Diffuse and Specular.
|
|
||||||
Both have different needs and representation. For efficiency,
|
|
||||||
the indirect lighting data is precomputed on demand into a static lighting cache.
|
|
||||||
|
|
||||||
As of now the light cache is static and needs to be computed before rendering.
|
|
||||||
It cannot be updated per frame (unless via scripting).
|
|
||||||
This limitation is being worked on and will be removed in future versions.
|
|
||||||
|
|
||||||
Only view independent lighting can be baked. This is why Reflection Planes are not stored inside the light cache.
|
|
||||||
|
|
||||||
The visibility and collections used during the baking process are the ones in the current Active View Layer.
|
|
||||||
|
|
||||||
To enable light bounces through large environments, the light baking process can be run multiple times
|
|
||||||
while injecting the previous bake result into the bake.
|
|
||||||
|
|
||||||
Light bounces only concerns diffuse lighting.
|
|
||||||
|
|
||||||
|
|
||||||
.. reference::
|
|
||||||
|
|
||||||
:Panel: :menuselection:`Render --> Indirect Lighting`
|
|
||||||
|
|
||||||
Auto Bake
|
|
||||||
Enabling this option will trigger baking when a probe is changed; useful when positioning probes objects.
|
|
||||||
|
|
||||||
Diffuse Bounces
|
|
||||||
Number of bounces to compute when baking the diffuse irradiance.
|
|
||||||
Total baking time is more or less multiplied by the number of bounce.
|
|
||||||
|
|
||||||
Cubemap Size
|
|
||||||
Size of the reflection cubemaps.
|
|
||||||
|
|
||||||
Diffuse Occlusion
|
|
||||||
Each irradiance sample also stores a shadow map that is used to minimize indirect light leaking.
|
|
||||||
This parameter defines the size of this shadow map.
|
|
||||||
|
|
||||||
Irradiance Smoothing
|
|
||||||
Smooths irradiance interpolation but introduces light bleeding.
|
|
||||||
The irradiance visibility term can make the lighting not interpolate smoothly on some surfaces.
|
|
||||||
This setting relaxes the weight of that interpolation.
|
|
||||||
|
|
||||||
Clamp Glossy
|
|
||||||
Clamp pixel intensity to reduce noise inside glossy reflections from reflection cubemaps (0 is disabled).
|
|
||||||
|
|
||||||
Filter Quality
|
|
||||||
Takes more samples during cubemap filtering to remove artifacts. For now, this only has an effect on cubemaps.
|
|
||||||
|
|
||||||
|
|
||||||
Display
|
|
||||||
=======
|
|
||||||
|
|
||||||
Cubemap Size
|
|
||||||
Display the Reflection Cubemaps present in the cache directly in the 3D Viewport.
|
|
||||||
|
|
||||||
Irradiance Size
|
|
||||||
Display the Irradiance Samples present in the cache in the 3D Viewport.
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
Cache data display only works in the 3D Viewport and
|
|
||||||
only if the viewport uses world lighting in Material Preview or Rendered mode.
|
|
@ -15,8 +15,8 @@ both in a movie frame and in a photograph from a real-world camera.
|
|||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
Motion blur is only available in final renders and is not shown in the 3D Viewport
|
Motion blur is only visible in the viewport during animation playback and uses a simpler
|
||||||
and thus :ref:`Viewport Renders <bpy.ops.render.opengl>`.
|
algorithm than final render. Same thing applies to :ref:`Viewport Renders <bpy.ops.render.opengl>`.
|
||||||
|
|
||||||
Position
|
Position
|
||||||
Controls at what point the shutter opens in relation to the current frame.
|
Controls at what point the shutter opens in relation to the current frame.
|
||||||
@ -35,33 +35,6 @@ Background Separation
|
|||||||
Used by the post-process blur to avoid blurring the background over the foreground.
|
Used by the post-process blur to avoid blurring the background over the foreground.
|
||||||
Lower values will reduce background bleeding onto foreground elements.
|
Lower values will reduce background bleeding onto foreground elements.
|
||||||
|
|
||||||
Max Blur
|
|
||||||
Maximum blur distance a pixel can spread over.
|
|
||||||
A value of 0 will disable the post-process blur and only use the accumulation blur.
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
High maximum blur values may also reduce the quality.
|
|
||||||
|
|
||||||
EEVEE uses a fast post-process vector blur using a vector motion pass.
|
|
||||||
This blurs the image between three time steps using pixel velocity.
|
|
||||||
This technique is fast and produces clean gradients, but issues can occur at object borders
|
|
||||||
or if the motion is locally too complex;
|
|
||||||
for example, if there are many vector variations in a small area.
|
|
||||||
|
|
||||||
This technique uses random sampling and the noise amount is proportional to the sample count found in
|
|
||||||
:menuselection:`Properties --> Render --> Sampling --> Render Samples`.
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
Memory usage (VRAM) will be three times higher for objects using deformation motion blur
|
|
||||||
if using post-process blur.
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
Alpha blended surface or volumetric effects will not have the correct velocity and will not
|
|
||||||
be correctly blurred by this technique. Use the accumulation blur for that.
|
|
||||||
|
|
||||||
Steps
|
Steps
|
||||||
This controls the number of steps used by the accumulation blur and thus its accuracy.
|
This controls the number of steps used by the accumulation blur and thus its accuracy.
|
||||||
More steps means longer render time.
|
More steps means longer render time.
|
||||||
@ -79,6 +52,9 @@ Steps
|
|||||||
By adding more steps you can also reduce the *Max Blur* options because the post-process blur
|
By adding more steps you can also reduce the *Max Blur* options because the post-process blur
|
||||||
has to cover a smaller distance.
|
has to cover a smaller distance.
|
||||||
|
|
||||||
|
Shutter Curve
|
||||||
|
Use a custom shutter curve.
|
||||||
|
|
||||||
|
|
||||||
Example
|
Example
|
||||||
=======
|
=======
|
||||||
|
@ -12,3 +12,31 @@ Performance
|
|||||||
High Quality Normals
|
High Quality Normals
|
||||||
Uses higher precision normals and tangents which can improve
|
Uses higher precision normals and tangents which can improve
|
||||||
visual quality for dense meshes with high frequency textures at the cost of memory.
|
visual quality for dense meshes with high frequency textures at the cost of memory.
|
||||||
|
|
||||||
|
|
||||||
|
Memory
|
||||||
|
======
|
||||||
|
|
||||||
|
.. _bpy.types.SceneEEVEE.shadow_pool_size:
|
||||||
|
|
||||||
|
Shadow Pool Size
|
||||||
|
A bigger pool size allows for more shadows in the scene but might not fit into GPU memory and decreases performance.
|
||||||
|
Increasing it might fix the *Shadow buffer full* error.
|
||||||
|
|
||||||
|
.. seealso::
|
||||||
|
:ref:`Shadow documentation <bpy.types.Light.shadow>`
|
||||||
|
|
||||||
|
.. _bpy.types.SceneEEVEE.gi_irradiance_pool_size:
|
||||||
fclem marked this conversation as resolved
Outdated
Hans Goudey
commented
`more irradiance grid` -> `more irradiance grids`
|
|||||||
|
|
||||||
|
Light Probes Volume Pool Size
|
||||||
|
A bigger pool size allows for more irradiance grids in the scene but might not fit into GPU memory and decreases performance.
|
||||||
|
|
||||||
|
|
||||||
|
Viewport
|
||||||
|
========
|
||||||
|
|
||||||
|
.. _bpy.types.RenderSettings.preview_pixel_size:
|
||||||
|
|
||||||
|
Pixel Size
|
||||||
|
Option to control the resolution for viewport rendering.
|
||||||
|
Allows you to speed up viewport rendering, which is especially useful for displays with high DPI.
|
||||||
|
129
manual/render/eevee/render_settings/raytracing.rst
Normal file
@ -0,0 +1,129 @@
|
|||||||
|
.. _bpy.types.SceneEEVEE.raytracing:
|
||||||
|
|
||||||
|
**********
|
||||||
|
Raytracing
|
||||||
|
**********
|
||||||
|
|
||||||
|
.. reference::
|
||||||
|
|
||||||
|
:Panel: :menuselection:`Render --> Raytracing`
|
||||||
|
|
||||||
|
The ray-tracing pipeline goal is to increase the accuracy of surface indirect lighting.
|
||||||
|
This is done by generating ray from each :abbr:`BSDF (Bidirectional Scattering Distribution Function)`
|
||||||
|
and finding their intersection with the scene individually.
|
||||||
|
|
||||||
|
When disabled, it is replaced by a faster pipeline that uses pre-filtered light-probes.
|
||||||
|
This fallback mode offers a more visually stable and optimized alternative when visual fidelity is not the primary goal.
|
||||||
|
|
||||||
|
.. seealso::
|
||||||
|
|
||||||
|
:ref:`Limitations <eevee-limitations-raytracing>`.
|
||||||
|
|
||||||
|
Method
|
||||||
|
Determine the tracing method used to find scene-ray intersections and indirect lighting.
|
||||||
|
|
||||||
|
:Light Probe:
|
||||||
fclem marked this conversation as resolved
Hans Goudey
commented
`This option is has` -> `This option has`
`but rely` -> `but relies`
|
|||||||
|
Use light-probe spheres and planes to find scene intersection.
|
||||||
|
This option has the lowest tracing cost but relies on manually placed light-probes.
|
||||||
|
|
||||||
|
:Screen-Trace:
|
||||||
|
Trace ray against the screen depth buffer. Fallback to light-probes if ray exits the view.
|
||||||
|
|
||||||
|
|
||||||
|
Resolution
|
||||||
|
Resolution at which the ray-tracing is performed.
|
||||||
|
Lower options will be faster and use less memory but will produce blurrier results.
|
||||||
|
|
||||||
|
Max Roughness
|
||||||
|
Maximum roughness a :abbr:`BSDF (Bidirectional Scattering Distribution Function)` can have to use ray-tracing.
|
||||||
|
BSDFs with higher roughness will progressively use the *Fast GI Approximation*.
|
||||||
|
A value of 1 will raytrace every surfaces and disable the Fast GI.
|
||||||
|
|
||||||
|
|
||||||
|
Screen Tracing
|
||||||
|
______________
|
||||||
|
|
||||||
|
These settings control the behavior of the screen space ray-tracing.
|
||||||
|
They are only visible if *Screen-Trace* is the active tracing *Method*.
|
||||||
fclem marked this conversation as resolved
Outdated
Hans Goudey
commented
`but lowers` -> `but lower`
|
|||||||
|
|
||||||
|
Precision
|
||||||
|
Higher values increase precision of the screen space ray-tracing but lower the maximum trace distance.
|
||||||
|
Increased precision also increases performance cost.
|
||||||
|
|
||||||
|
Thickness
|
||||||
|
How thick to consider the pixels of the depth buffer during the tracing.
|
||||||
|
Higher values will stretch the reflections and add flickering. Lower values may make the ray miss surfaces.
|
||||||
|
|
||||||
|
|
||||||
|
Denoising
|
||||||
fclem marked this conversation as resolved
Outdated
Hans Goudey
commented
`the noise amount` -> `the amount of noise`
`over blur` -> `over-blur`
|
|||||||
|
_________
|
||||||
|
|
||||||
|
Denoising can be enabled to reduce the amount of noise from the raw ray-traced output.
|
||||||
|
This can help image stability but will also over-blur the final ray-traced output.
|
||||||
|
|
||||||
|
Spatial Reuse
|
||||||
|
Reuse the rays from neighbor pixels.
|
||||||
|
Can introduce some light leaks across surfaces.
|
||||||
fclem marked this conversation as resolved
Hans Goudey
commented
`last ray tracing results` -> `the last ray tracing results`
`introduce a lot of color bias` -> `introduces color bias`
`making render converge` -> `making renders converge`
|
|||||||
|
|
||||||
|
Temporal Accumulation
|
||||||
|
Accumulate samples by re-projecting the last ray tracing results.
|
||||||
|
This removes :term:`Fireflies` but also introduces color bias.
|
||||||
|
Useful for viewport temporal stability or making renders converge faster.
|
||||||
|
|
||||||
|
Bilateral Filter
|
||||||
|
Blur the resolved ray-traced output using a bilateral filter.
|
||||||
|
|
||||||
|
|
||||||
|
Fast GI Approximation
|
||||||
fclem marked this conversation as resolved
Hans Goudey
commented
Remove Remove `This`
|
|||||||
|
_____________________
|
||||||
|
|
||||||
fclem marked this conversation as resolved
Outdated
Hans Goudey
commented
`less noisy output` -> `a less noisy output`
`and capture bounce` -> `and captures bounce`
|
|||||||
|
Fast GI Approximation is a fallback to the ray-tracing pipeline for
|
||||||
|
:abbr:`BSDF (Bidirectional Scattering Distribution Function)` with high roughness.
|
||||||
fclem marked this conversation as resolved
Hans Goudey
commented
Will inherit what? Will inherit what?
|
|||||||
|
It produces a less noisy output and captures bounce lighting more efficiently than individually traced rays.
|
||||||
|
|
||||||
|
This is currently implemented as a screen space effect and will inherit all associated :ref:`limitations <eevee-limitations-screenspace>`.
|
||||||
|
|
||||||
|
Method
|
||||||
fclem marked this conversation as resolved
Hans Goudey
commented
`the methods` -> `the method`
|
|||||||
|
Determine the method used to compute the fast GI approximation.
|
||||||
|
|
||||||
|
:Ambient Occlusion:
|
||||||
|
Use scene intersections to shadow the distant lighting from light-probes.
|
||||||
|
This is the fastest option.
|
||||||
|
|
||||||
|
:Global Illumination:
|
||||||
|
Compute global illumination taking into account light bouncing off surrounding objects.
|
||||||
|
|
||||||
|
Resolution
|
||||||
|
Resolution at which the fast GI is computed.
|
||||||
|
Lower options will be faster and use less memory but will produce blurrier results.
|
||||||
|
|
||||||
|
Ray Count
|
||||||
fclem marked this conversation as resolved
Hans Goudey
commented
`Amount of GI ray per pixels` -> `Number of GI rays per pixel`
|
|||||||
|
Number of GI rays per pixel at the specified *Resolution*.
|
||||||
|
Higher values will reduce noise.
|
||||||
|
|
||||||
|
Step Count
|
||||||
fclem marked this conversation as resolved
Hans Goudey
commented
`Amount of screen sample` -> `Number of screen samples`
|
|||||||
|
Number of screen samples per GI ray.
|
||||||
|
Higher values will reduce the noise amount and increase the quality.
|
||||||
|
|
||||||
|
.. tip::
|
||||||
|
|
||||||
fclem marked this conversation as resolved
Hans Goudey
commented
`With higher step count` -> `With a higher step count`
`reflect of block` -> `reflect or block`
`loosing` -> `losing`
|
|||||||
|
With a higher step count, there is less chance to miss other surfaces that could reflect or block the light.
|
||||||
|
This means that the Fast GI *Thickness* parameters can be tweaked to lower values without losing too much light bounce energy.
|
||||||
|
|
||||||
|
Precision
|
||||||
|
Higher values increase the precision of the scene intersections with the GI rays.
|
||||||
|
Increased precision also increases performance cost.
|
||||||
|
|
||||||
|
|
||||||
|
Distance
|
||||||
|
If non-zero, the maximum distance at which other surfaces will contribute to the fast GI approximation.
|
||||||
|
|
||||||
|
Thickness Near
|
||||||
|
Geometric thickness of the surfaces when computing fast GI and ambient occlusion.
|
||||||
|
Reduces light leaking and missing contact occlusion.
|
||||||
|
The effectiveness decreases proportionally to the distance from the shading point, following the inverse square law.
|
||||||
|
|
||||||
|
Thickness Far
|
||||||
|
Angular thickness of the surfaces when computing fast GI and ambient occlusion.
|
||||||
|
Reduces energy loss and missing occlusion of far geometry.
|
||||||
|
Higher values will make the very thin objects block or reflect too much light.
|
@ -13,12 +13,71 @@ TAA is sample based so the more samples the more aliasing is reduced at the cost
|
|||||||
:Panel: :menuselection:`Render --> Sampling`
|
:Panel: :menuselection:`Render --> Sampling`
|
||||||
|
|
||||||
Viewport
|
Viewport
|
||||||
|
========
|
||||||
|
|
||||||
|
Samples
|
||||||
The number of samples to use in the 3D Viewport.
|
The number of samples to use in the 3D Viewport.
|
||||||
When setting this to zero the viewport will be resampled continuously.
|
When setting this to zero the viewport will be resampled continuously.
|
||||||
Render
|
|
||||||
The number of samples to use in the final render.
|
|
||||||
|
|
||||||
.. _bpy.types.SceneEEVEE.use_taa_reprojection:
|
.. _bpy.types.SceneEEVEE.use_taa_reprojection:
|
||||||
|
|
||||||
Viewport Denoising
|
Temporal Reprojection
|
||||||
Reduces noise while moving the viewport or during animation playback.
|
Reduces noise while moving the viewport or during animation playback. Can leave some ghosting.
|
||||||
|
|
||||||
|
.. _bpy.types.SceneEEVEE.use_shadow_jitter_viewport:
|
||||||
|
|
||||||
|
Jittered Shadows
|
||||||
|
Enable jittered shadows on the viewport.
|
||||||
|
Jittered shadows are always enabled for final renders.
|
||||||
|
This also affects shadows casted by transparent shadows.
|
||||||
|
|
||||||
|
|
||||||
|
Render
|
||||||
|
======
|
||||||
|
|
||||||
|
Samples
|
||||||
|
The number of samples to use in the final render.
|
||||||
|
|
||||||
|
|
||||||
|
.. _eevee-shadow-raytrace:
|
||||||
|
|
||||||
|
Shadows
|
||||||
fclem marked this conversation as resolved
Hans Goudey
commented
`Amount of` -> `Number of`
|
|||||||
|
=======
|
||||||
|
|
||||||
|
.. _bpy.types.SceneEEVEE.shadow_ray_count:
|
||||||
|
|
||||||
|
Shadow Rays Count
|
||||||
|
Number of rays to trace for each light.
|
||||||
|
Higher values reduces the noise caused by random shadow sampling.
|
||||||
|
|
||||||
|
.. _bpy.types.SceneEEVEE.shadow_step_count:
|
||||||
|
|
||||||
|
Shadow Steps Count
|
||||||
|
Number of shadow map sample per shadow ray.
|
||||||
|
Higher step count results in softer shadows but have a higher cost.
|
||||||
|
|
||||||
|
.. _bpy.types.SceneEEVEE.volumetric_shadow:
|
||||||
|
|
||||||
|
Volumetric Shadows
|
||||||
|
Approximate light absorption of the surrounding volume objects. This makes the volumes more opaque to light.
|
||||||
|
This is a very computationally expensive option and has limitations.
|
||||||
|
|
||||||
|
.. seealso:: :ref:`Volume Limitations <eevee-limitations-volumetrics>`.
|
||||||
|
|
||||||
|
Volumetric Shadows Steps
|
||||||
|
Number of steps to compute volumetric shadowing.
|
||||||
|
|
||||||
|
|
||||||
|
Advanced
|
||||||
|
========
|
||||||
|
|
||||||
|
.. _bpy.types.SceneEEVEE.light_threshold:
|
||||||
|
|
||||||
|
Light Threshold
|
||||||
|
Minimum light intensity for a light to contribute to the lighting.
|
||||||
|
Used to compute the distance at which to cut-off lights influence.
|
||||||
|
Lower values improve performance.
|
||||||
|
|
||||||
|
.. seealso::
|
||||||
|
|
||||||
|
:ref:`Custom Distance <bpy.types.Light.use_custom_distance>` overrides this setting.
|
||||||
|
@ -1,48 +0,0 @@
|
|||||||
.. _bpy.types.SceneEEVEE.ssr:
|
|
||||||
|
|
||||||
************************
|
|
||||||
Screen Space Reflections
|
|
||||||
************************
|
|
||||||
|
|
||||||
If this effect is enabled, all Materials will use the depth buffer and
|
|
||||||
the previous frame color to create more accurate reflection than reflection probes.
|
|
||||||
|
|
||||||
If a *Reflection Plane* is near a reflective surface,
|
|
||||||
it will be used as the source for tracing rays more efficiently and fix the partial visibility problem.
|
|
||||||
|
|
||||||
.. figure:: /images/render_eevee_render-settings_screen-space-reflections_planar-reflection-combo.jpg
|
|
||||||
|
|
||||||
However, the reflected color will not contain the following effects:
|
|
||||||
Subsurface scattering, volumetrics, screen space reflections, screen space refractions.
|
|
||||||
|
|
||||||
.. reference::
|
|
||||||
|
|
||||||
:Panel: :menuselection:`Render --> Screen Space Reflections`
|
|
||||||
|
|
||||||
Refractions
|
|
||||||
Screen space refractions work the same way as screen space reflections and use the same parameters.
|
|
||||||
But they are not enabled by default on all surfaces.
|
|
||||||
Enabling it will have a small performance cost.
|
|
||||||
You need to enable them in :menuselection:`Material Properties --> Settings`.
|
|
||||||
Materials using screen space refractions will not cast screen space reflections.
|
|
||||||
|
|
||||||
Half Resolution Trace
|
|
||||||
Use half resolution ray tracing. Only cast a ray for every fourth pixel.
|
|
||||||
Enabling this option drastically reduces video memory usage and increases performance at the cost of quality.
|
|
||||||
|
|
||||||
Trace Precision
|
|
||||||
Increases precision of the ray tracing but introduces more noise and lowers the maximum trace distance.
|
|
||||||
Increased precision also increases performance cost.
|
|
||||||
|
|
||||||
Thickness
|
|
||||||
How thick to consider the pixels of the depth buffer during the tracing.
|
|
||||||
Higher values will stretch the reflections and add flickering. Lower values may make the ray miss surfaces.
|
|
||||||
|
|
||||||
Edge Fading
|
|
||||||
Smoothly fade out the reflected and refracted pixels if they are close to a screen edge.
|
|
||||||
The unit is in screen percentage.
|
|
||||||
|
|
||||||
Clamp
|
|
||||||
Clamp the reflected color intensity to remove noise and :term:`Fireflies`.
|
|
||||||
|
|
||||||
.. seealso:: :ref:`Limitations <eevee-limitations-reflections>`.
|
|
@ -1,60 +0,0 @@
|
|||||||
.. _bpy.types.SceneEEVEE.shadow:
|
|
||||||
|
|
||||||
*******
|
|
||||||
Shadows
|
|
||||||
*******
|
|
||||||
|
|
||||||
These settings influence shadows which appear on objects because there is another object (the occluder)
|
|
||||||
between them and a Light. EEVEE uses a technique called Shadow Mapping to calculate these shadows.
|
|
||||||
A shadow map is calculated by looking around from the position of each Light and finding the objects
|
|
||||||
which are closest to the Light. These objects are called the nearest occluders.
|
|
||||||
Everything which is behind (or, you can say, covered by) the nearest occluders will be in shadow.
|
|
||||||
|
|
||||||
The shadow map is a cube (hence the term "cubemap") and the Light is in the middle of this cube.
|
|
||||||
The cube has six sides and each side is divided into a grid.
|
|
||||||
You can set the resolution of the grid (for example, 512 × 512 pixels) with the *Cube Size* setting below.
|
|
||||||
During shadow calculation, the nearest occluders are only searched at grid points but not between grid points.
|
|
||||||
Because of this, the edge of the calculated shadow will appear pixelated at low Cube Size settings.
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
Settings for the shadows and illumination caused by light bouncing between objects (indirect lighting)
|
|
||||||
can be found on the Indirect Lighting tab.
|
|
||||||
|
|
||||||
.. reference::
|
|
||||||
|
|
||||||
:Panel: :menuselection:`Render --> Shadows`
|
|
||||||
|
|
||||||
Cube Size
|
|
||||||
Number of pixels on one side of the shadow cube-map (see above)
|
|
||||||
used to calculate the shadow of Point, Area and Spot lights.
|
|
||||||
If you want to make the edge of shadows less pixelated, then increase this value.
|
|
||||||
But be aware that this increases memory usage and decreases performance since a 512 px cube-map
|
|
||||||
has 6 × 512 × 512 pixels in it.
|
|
||||||
|
|
||||||
Cascade Size
|
|
||||||
Size of one cascade used by *Cascaded Shadow Maps*. This is only for Sun lights.
|
|
||||||
|
|
||||||
High Bitdepth
|
|
||||||
This option can help reduce some artifacts due to float imprecision inside the shadow maps.
|
|
||||||
This option effectively doubles the memory usage of shadow maps and will slow down their update.
|
|
||||||
|
|
||||||
Soft Shadows
|
|
||||||
Randomize the shadow map's origin to create soft shadows. It needs a lot of samples to get rid of the banding.
|
|
||||||
|
|
||||||
Light Threshold
|
|
||||||
The minimum amount of light for a light to contribute for lighting.
|
|
||||||
This light threshold does not take the light shape into account and may not suit every case.
|
|
||||||
That is why Blender provides a :ref:`per-light override <bpy.types.Light.cutoff_distance>`
|
|
||||||
where you can just set the cut off distance.
|
|
||||||
|
|
||||||
The influence distance is also used as shadow far clip distance, which might affect how shadows look.
|
|
||||||
This influence distance does not affect sun lights that still have a far clip distance.
|
|
||||||
|
|
||||||
.. seealso::
|
|
||||||
|
|
||||||
:ref:`Custom Distance <bpy.types.Light.cutoff_distance>`.
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
The Soft Shadows method is not physically based and will not match Cycles for very large lights.
|
|
@ -1,31 +0,0 @@
|
|||||||
.. _bpy.types.SceneEEVEE.sss:
|
|
||||||
|
|
||||||
*********************
|
|
||||||
Subsurface Scattering
|
|
||||||
*********************
|
|
||||||
|
|
||||||
This effect mimics real subsurface scattering by blurring the diffuse lighting in screen space.
|
|
||||||
|
|
||||||
.. reference::
|
|
||||||
|
|
||||||
:Panel: :menuselection:`Render --> Subsurface Scattering`
|
|
||||||
|
|
||||||
Samples
|
|
||||||
Number of samples to compute the scattering effect.
|
|
||||||
|
|
||||||
Jitter Threshold
|
|
||||||
For the effect to be efficient, samples need to be coherent and not random.
|
|
||||||
This can lead to a cross-shaped pattern when the scattering radius is high.
|
|
||||||
Increasing the Jitter Threshold will rotate the samples below this radius percentage
|
|
||||||
in a random pattern in order to hide the visible pattern.
|
|
||||||
This affects the performance if the scattering radius is large.
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
:ref:`Subsurface Translucency <bpy.types.Material.use_sss_translucency>`
|
|
||||||
needs to be enabled in order to make the light go through an object
|
|
||||||
(like simulating a human ear lit from behind).
|
|
||||||
|
|
||||||
This option only works with shadowed lights and does not work with indirect lighting.
|
|
||||||
|
|
||||||
.. seealso:: :ref:`Limitations <eevee-limitations-sss>`.
|
|
46
manual/render/eevee/render_settings/volumes.rst
Normal file
@ -0,0 +1,46 @@
|
|||||||
|
.. _bpy.types.SceneEEVEE.volumetric:
|
||||||
|
|
||||||
|
***********
|
||||||
|
Volumetrics
|
||||||
|
***********
|
||||||
|
|
||||||
|
EEVEE simulates volumetric scattering by evaluating all volume objects inside the view frustum.
|
||||||
|
|
||||||
|
To achieve this, EEVEE uses several 3D textures which have a high video memory usage.
|
||||||
|
The texture dimensions can be tweaked using the *Resolution* and *Steps* parameters.
|
||||||
|
|
||||||
|
.. reference::
|
||||||
|
|
||||||
|
:Panel: :menuselection:`Properties --> Render --> Volumetrics`
|
||||||
|
|
||||||
|
Resolution
|
||||||
|
Controls the quality of the volumetric effects. Lower resolution increases video memory usage and quality.
|
||||||
|
|
||||||
|
Steps
|
||||||
|
Number of steps to compute volumetric effects. Higher count increases video memory usage and quality.
|
||||||
|
These samples are distributed along the view depth (view Z axis).
|
||||||
|
|
||||||
|
Distribution
|
||||||
|
Blend between linear and exponential sample distribution. Higher values put more samples near the camera.
|
||||||
|
|
||||||
|
Max Depth
|
||||||
fclem marked this conversation as resolved
Outdated
Hans Goudey
commented
`Higher values puts` -> `Higher values put`
|
|||||||
|
Maximum surface intersection count used by accurate volume intersection method.
|
||||||
|
Will create artifacts if it is exceeded.
|
||||||
|
|
||||||
|
|
||||||
|
Custom Range
|
||||||
|
============
|
||||||
|
|
||||||
|
When working with volume objects, EEVEE automatically computes the best depth range where to compute
|
||||||
|
the volume sampling and lighting.
|
||||||
|
In certain situations, this isn't enough and produces sub-optimal sampling which increases noise.
|
||||||
fclem marked this conversation as resolved
Outdated
Hans Goudey
commented
`volumes objects` -> `volume objects`
`automatically compute` -> `automatically computes`
|
|||||||
|
This is particularly the case when using a volume shader inside the *World* or when working with large number of volume objects.
|
||||||
|
The custom depth range can be enabled to restrict the computation of volumes to a certain range along the camera depth and thus increase precision.
|
||||||
fclem marked this conversation as resolved
Hans Goudey
commented
`In certain situation` -> `In certain situations`
|
|||||||
|
|
||||||
fclem marked this conversation as resolved
Outdated
Hans Goudey
commented
`large of volume` -> `large number of volume`
|
|||||||
|
Start
|
||||||
|
Start distance of the volumetric effect.
|
||||||
|
|
||||||
|
End
|
||||||
|
End distance of the volumetric effect.
|
||||||
|
|
||||||
|
.. seealso:: :ref:`Limitations <eevee-limitations-volumetrics>`.
|
@ -1,60 +0,0 @@
|
|||||||
.. _bpy.types.SceneEEVEE.volumetric:
|
|
||||||
|
|
||||||
***********
|
|
||||||
Volumetrics
|
|
||||||
***********
|
|
||||||
|
|
||||||
EEVEE simulates volumetric scattering by evaluating all volume objects inside the view frustum.
|
|
||||||
|
|
||||||
To achieve this, EEVEE uses several 3D textures which have a high video memory usage.
|
|
||||||
The texture dimensions can be tweaked using the *Tile Size* and *Samples* parameters.
|
|
||||||
|
|
||||||
Object volumes have some :ref:`limitations <eevee-limitations-volumetrics>`.
|
|
||||||
|
|
||||||
.. reference::
|
|
||||||
|
|
||||||
:Panel: :menuselection:`Properties --> Render --> Volumetrics`
|
|
||||||
|
|
||||||
Start
|
|
||||||
Start distance of the volumetric effect.
|
|
||||||
|
|
||||||
End
|
|
||||||
End distance of the volumetric effect.
|
|
||||||
|
|
||||||
Tile Size
|
|
||||||
Controls the quality of the volumetric effects. Lower size increases video memory usage and quality.
|
|
||||||
This is the size in pixels of a volumetric cell.
|
|
||||||
|
|
||||||
Samples
|
|
||||||
Number of samples to compute volumetric effects. Higher count increases video memory usage and quality.
|
|
||||||
These samples are distributed along the view depth (view Z axis).
|
|
||||||
|
|
||||||
Distribution
|
|
||||||
Blend between linear and exponential sample distribution. Higher values puts more samples near the camera.
|
|
||||||
|
|
||||||
|
|
||||||
.. _bpy.types.SceneEEVEE.volumetric_light:
|
|
||||||
|
|
||||||
Volumetric Lighting
|
|
||||||
===================
|
|
||||||
|
|
||||||
Let the volume scattering scatter light in the scene.
|
|
||||||
Unnecessary if no Volume Scatter is present in the scene.
|
|
||||||
|
|
||||||
Light Clamping
|
|
||||||
Clamp light contribution of the volume scattering effect. Reduces flickering and noise.
|
|
||||||
Set to 0.0 to disable clamping.
|
|
||||||
|
|
||||||
|
|
||||||
.. _bpy.types.SceneEEVEE.volumetric_shadow:
|
|
||||||
|
|
||||||
Volumetric Shadows
|
|
||||||
==================
|
|
||||||
|
|
||||||
Approximate light absorption of the surrounding volume objects. This makes the volumes more opaque to light.
|
|
||||||
This is a very computationally expensive option and has limitations.
|
|
||||||
|
|
||||||
Samples
|
|
||||||
Number of samples to compute volumetric shadowing.
|
|
||||||
|
|
||||||
.. seealso:: :ref:`Limitations <eevee-limitations-volumetrics>`.
|
|
10
manual/render/eevee/scene_settings.rst
Normal file
@ -0,0 +1,10 @@
|
|||||||
|
|
||||||
|
**************
|
||||||
|
Scene Settings
|
||||||
|
**************
|
||||||
|
|
||||||
|
Light Probes
|
||||||
|
============
|
||||||
|
|
||||||
|
Light Probe Spheres Resolution
|
||||||
|
Defines the resolution of every light probe sphere in the scene.
|
@ -1,15 +0,0 @@
|
|||||||
|
|
||||||
*****
|
|
||||||
World
|
|
||||||
*****
|
|
||||||
|
|
||||||
The world environment can emit light, ranging from a single solid color
|
|
||||||
to arbitrary textures.
|
|
||||||
|
|
||||||
In EEVEE, the world lighting contribution is first rendered and
|
|
||||||
stored in smaller resolution textures before being applied to the objects.
|
|
||||||
This makes the lighting less precise than Cycles.
|
|
||||||
|
|
||||||
.. seealso::
|
|
||||||
|
|
||||||
:doc:`Indirect Lighting </render/eevee/render_settings/indirect_lighting>`.
|
|
106
manual/render/eevee/world_settings.rst
Normal file
@ -0,0 +1,106 @@
|
|||||||
|
|
||||||
|
**************
|
||||||
|
World Settings
|
||||||
|
**************
|
||||||
|
|
||||||
|
The world environment can emit light, ranging from a single solid color
|
||||||
|
to arbitrary textures.
|
||||||
|
|
||||||
|
In EEVEE, the world lighting contribution is stored into an internal :doc:`Light Probe </render/eevee/light_probes/index>`.
|
||||||
fclem marked this conversation as resolved
Outdated
Hans Goudey
commented
`stored into internal` -> `stored into an internal`
|
|||||||
|
This makes the lighting less precise than Cycles.
|
||||||
|
|
||||||
|
Mist Pass
|
||||||
|
=========
|
||||||
|
|
||||||
|
.. reference::
|
||||||
|
|
||||||
|
:Panel: :menuselection:`World --> Mist Pass`
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
|
||||||
|
The mist pass must be enabled in the View Layer tab
|
||||||
|
of the :doc:`Properties Editor </editors/properties_editor>`
|
||||||
|
before the settings below are available in the World tab.
|
||||||
|
|
||||||
|
Mist can greatly enhance the illusion of depth in your rendering. To create mist,
|
||||||
|
Blender generates a render layer with a depth map ranging between 0.0 and 1.0
|
||||||
|
that can be used in the Compositor to generate a mist effect.
|
||||||
|
|
||||||
|
.. _bpy.types.WorldMistSettings.start:
|
||||||
|
|
||||||
|
Start
|
||||||
|
The distance from the camera at which the mist starts to fade in.
|
||||||
|
|
||||||
|
.. _bpy.types.WorldMistSettings.depth:
|
||||||
|
|
||||||
|
Depth
|
||||||
|
The distance from *Start* of the mist, that it fades in over.
|
||||||
|
Objects further from the camera than *Start + Depth* are completely hidden by the mist.
|
||||||
|
|
||||||
|
.. _bpy.types.WorldMistSettings.falloff:
|
||||||
|
|
||||||
|
Falloff
|
||||||
|
The curve function that controls the rate of change of the mist's strength further and further into the distance.
|
||||||
|
|
||||||
|
:Quadratic:
|
||||||
|
Uses the same calculation as light falloff (:math:`1\over{x^2}`) and provides the smoothest
|
||||||
|
transition from transparent (0.0) to opaque (1.0).
|
||||||
|
:Linear: Has a steeper start than quadratic (:math:`1\over{x}`).
|
||||||
|
:Inverse Quadratic:
|
||||||
|
Has the steepest start (:math:`1\over{\sqrt{x}}`) and approaches 1.0 faster than the other two functions.
|
||||||
|
|
||||||
|
.. tip::
|
||||||
|
|
||||||
|
A visualization can be activated in the :menuselection:`Camera --> Viewport Display` panel.
|
||||||
|
|
||||||
|
.. figure:: /images/render_cycles_world-settings_mist-example1-BI.jpg
|
||||||
|
|
||||||
|
Mist example
|
||||||
|
(`blend-file <https://archive.blender.org/wiki/2015/index.php/File:25-Manual-World-Mist-Example1.blend>`__).
|
||||||
|
|
||||||
|
|
||||||
|
Settings
|
||||||
|
========
|
||||||
|
|
||||||
|
.. reference::
|
||||||
|
|
||||||
|
:Panel: :menuselection:`World --> Light Probe`
|
||||||
|
|
||||||
|
|
||||||
|
Light Probe
|
||||||
|
-----------
|
||||||
|
|
||||||
|
.. _bpy.types.World.probe_resolution:
|
||||||
|
|
||||||
|
Resolution
|
||||||
|
The resolution used to store the light from the world.
|
||||||
|
This is equivalent to the resolution for light probe spheres.
|
||||||
|
|
||||||
|
.. seealso::
|
||||||
|
|
||||||
|
:doc:`Light Probe Sphere </render/eevee/light_probes/sphere>`.
|
||||||
|
|
||||||
|
Sun
|
||||||
|
---
|
||||||
|
|
||||||
|
EEVEE can separate the light from intense light sources (e.g. a sun from an outdoor :abbr:`HDRI (High Dynamic Range Imaging)`) and
|
||||||
fclem marked this conversation as resolved
Outdated
Hans Goudey
commented
Is there a link/reference to use for "HDRI"? Is there a link/reference to use for "HDRI"?
|
|||||||
|
replace them with a sun light. This increases the quality of the lighting as the internal light probes
|
||||||
fclem marked this conversation as resolved
Outdated
Hans Goudey
commented
`replace them by` -> `replace them with`
|
|||||||
|
alone cannot reproduce this type of lighting with enough precision.
|
||||||
|
|
||||||
|
Threshold
|
||||||
|
If non-zero, the maximum value for world contribution that will be recorded inside the world light probe.
|
||||||
|
The excess contribution is converted to a sun light.
|
||||||
|
This reduces the light bleeding caused by very bright light sources.
|
||||||
|
A value of zero will disable this feature and all lighting will be stored inside the internal light probes.
|
||||||
|
|
||||||
|
Angle
|
||||||
|
Angular diameter of the extracted sun light as seen from the Earth.
|
||||||
|
|
||||||
fclem marked this conversation as resolved
Outdated
Hans Goudey
commented
Missing period/duplicate description Missing period/duplicate description
|
|||||||
|
Use Shadow
|
||||||
|
Enable shadow casting on the extracted sun light.
|
||||||
|
|
||||||
|
.. seealso::
|
||||||
|
|
||||||
|
The shadow properties control the extracted sun shadows.
|
||||||
|
They are exactly the same as for a sun light object.
|
||||||
|
:doc:`Light Properties </render/eevee/light_settings>`.
|
@ -187,7 +187,7 @@ Bloom
|
|||||||
.. _bpy.types.ViewLayerEEVEE.use_pass_transparent:
|
.. _bpy.types.ViewLayerEEVEE.use_pass_transparent:
|
||||||
|
|
||||||
Transparency
|
Transparency
|
||||||
Contain :ref:`Alpha Blended <bpy.types.Material.blend_method>` surfaces,
|
Contain :ref:`Blended <bpy.types.Material.render_method>` surfaces,
|
||||||
so they can be adjusted in the compositor and later mixed with opaque passes.
|
so they can be adjusted in the compositor and later mixed with opaque passes.
|
||||||
|
|
||||||
This pass only supports monochromatic opacity.
|
This pass only supports monochromatic opacity.
|
||||||
@ -329,8 +329,8 @@ The passes can be combined to produce the final image as follows:
|
|||||||
Known Limitations
|
Known Limitations
|
||||||
=================
|
=================
|
||||||
|
|
||||||
- Alpha blended materials are not rendered in render passes except the combined pass.
|
- Blended materials are not rendered in render passes except the combined pass.
|
||||||
Use the *Alpha Clip* or *Alpha Hashed* as :ref:`Blending Mode <bpy.types.Material.blend_method>`
|
Use the *Dithered* as :ref:`Render Method <bpy.types.Material.render_method>`
|
||||||
to render transparent materials in render passes.
|
to render transparent materials in render passes.
|
||||||
- Depth of field is not rendered in render passes except the combined pass.
|
- Depth of field is not rendered in render passes except the combined pass.
|
||||||
It is possible to add the depth of field back in the Compositor using
|
It is possible to add the depth of field back in the Compositor using
|
||||||
|
@ -22,7 +22,7 @@ Color
|
|||||||
Renderer Settings
|
Renderer Settings
|
||||||
=================
|
=================
|
||||||
|
|
||||||
- :doc:`EEVEE specific settings </render/eevee/lighting>`
|
- :doc:`EEVEE specific settings </render/eevee/light_settings>`
|
||||||
- :doc:`Cycles specific settings </render/cycles/light_settings>`
|
- :doc:`Cycles specific settings </render/cycles/light_settings>`
|
||||||
|
|
||||||
|
|
||||||
|
@ -14,7 +14,7 @@ Renderer Settings
|
|||||||
While shading nodes control the appearance, these settings control the quality and algorithms
|
While shading nodes control the appearance, these settings control the quality and algorithms
|
||||||
that each renderer uses to render the material.
|
that each renderer uses to render the material.
|
||||||
|
|
||||||
- :doc:`EEVEE specific settings </render/eevee/materials/settings>`
|
- :doc:`EEVEE specific settings </render/eevee/material_settings>`
|
||||||
- :doc:`Cycles specific settings </render/cycles/material_settings>`
|
- :doc:`Cycles specific settings </render/cycles/material_settings>`
|
||||||
|
|
||||||
|
|
||||||
|
@ -71,9 +71,6 @@ some of the outputs are only supported in particular cases.
|
|||||||
This node makes it possible to tweak indirect lighting in the shader.
|
This node makes it possible to tweak indirect lighting in the shader.
|
||||||
|
|
||||||
Only a subset of the outputs are supported and the ray depth does not exactly have the same meaning.
|
Only a subset of the outputs are supported and the ray depth does not exactly have the same meaning.
|
||||||
In order for the *Is Camera*, *Is Shadow*, *Is Diffuse*, and *Is Glossy* outputs to work,
|
|
||||||
the object must be inside an :doc:`Irradiance Volume </render/eevee/light_probes/irradiance_volumes>`
|
|
||||||
and :doc:`/render/eevee/render_settings/indirect_lighting` must be baked.
|
|
||||||
|
|
||||||
- *Is Camera*: Supported.
|
- *Is Camera*: Supported.
|
||||||
- *Is Shadow*: Supported.
|
- *Is Shadow*: Supported.
|
||||||
|
@ -36,7 +36,7 @@ Poor Performance
|
|||||||
Render Errors
|
Render Errors
|
||||||
-------------
|
-------------
|
||||||
|
|
||||||
See :doc:`EEVEE </render/eevee/limitations>` and
|
See :doc:`EEVEE </render/eevee/limitations/index>` and
|
||||||
:doc:`Cycles </render/cycles/gpu_rendering>` documentation respectively.
|
:doc:`Cycles </render/cycles/gpu_rendering>` documentation respectively.
|
||||||
|
|
||||||
|
|
||||||
|
EEVEE is a based
-> EEVEE is based`