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
|
||||
: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 ---
|
||||
|
@ -10,8 +10,10 @@
|
||||
|
||||
introduction.rst
|
||||
render_settings/index.rst
|
||||
materials/index.rst
|
||||
world.rst
|
||||
lighting.rst
|
||||
scene_settings.rst
|
||||
world_settings.rst
|
||||
object_settings/index.rst
|
||||
material_settings.rst
|
||||
light_settings.rst
|
||||
light_probes/index.rst
|
||||
limitations.rst
|
||||
limitations/index.rst
|
||||
|
@ -3,23 +3,23 @@
|
||||
Introduction
|
||||
************
|
||||
|
||||
EEVEE is Blender's realtime render engine built using :term:`OpenGL` focused on
|
||||
speed and interactivity while achieving the goal of rendering :abbr:`PBR (Physically Based Rendering)` materials.
|
||||
EEVEE is Blender's realtime render engine focused on speed and interactivity while achieving the
|
||||
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.
|
||||
|
||||
.. figure:: /images/render_eevee_introduction_viewport.png
|
||||
|
||||
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.
|
||||
For Cycles users, this makes EEVEE work great for previewing materials in realtime.
|
||||
EEVEE materials are created using the same shader nodes as Cycles, making it easy to render existing
|
||||
scenes. For Cycles users, this makes EEVEE work great for previewing materials in realtime.
|
||||
|
||||
Unlike Cycles, EEVEE is not a raytrace render engine.
|
||||
Instead of computing each ray of light, EEVEE uses a process called rasterization.
|
||||
Rasterization estimates the way light interacts with objects and materials using numerous algorithms.
|
||||
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, 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.
|
||||
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,
|
||||
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
|
||||
|
||||
|
@ -9,6 +9,6 @@
|
||||
:maxdepth: 2
|
||||
|
||||
introduction.rst
|
||||
irradiance_volumes.rst
|
||||
reflection_cubemaps.rst
|
||||
reflection_planes.rst
|
||||
volume.rst
|
||||
sphere.rst
|
||||
plane.rst
|
||||
|
@ -3,10 +3,10 @@
|
||||
Introduction
|
||||
************
|
||||
|
||||
Probe objects are used by EEVEE as support objects.
|
||||
They record lighting information locally in order to light the scene using indirect lighting.
|
||||
Light probe objects are used by EEVEE as support objects.
|
||||
|
||||
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).
|
||||
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::
|
||||
:maxdepth: 2
|
||||
|
||||
introduction.rst
|
||||
limitations.rst
|
||||
nodes_support.rst
|
||||
settings.rst
|
@ -25,35 +25,33 @@ Cameras
|
||||
Lights
|
||||
======
|
||||
|
||||
- Only 128 active lights can be supported by EEVEE in a scene.
|
||||
- Only 8 Shadowed sun lights can be supported at the same time.
|
||||
- As of now, lights can only have one color and do not support light node trees.
|
||||
- Lights can only have one color and do not support light node trees.
|
||||
- Unlike in Cycles, the :ref:`Size <bpy.types.SpotLight.shadow_soft_size>` of spot lights does not change the softness of the cone.
|
||||
- The area light :ref:`Beam spread <bpy.types.SpotLight.spot_size>` option is not supported.
|
||||
|
||||
|
||||
Light Probes
|
||||
============
|
||||
|
||||
- EEVEE only supports up to 128 active Reflection Cubemaps.
|
||||
- EEVEE only supports up to 64 active Irradiance Volumes.
|
||||
- EEVEE only supports up to 16 active Reflection Planes inside the view frustum.
|
||||
|
||||
- EEVEE supports up to 128 active light probe spheres.
|
||||
- EEVEE supports up to 16 active light probe 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
|
||||
=================
|
||||
|
||||
- Volumetrics don't receive light from Irradiance Volumes but do receive world's diffuse lighting.
|
||||
- EEVEE does not support "specular to diffuse" light bounces nor "specular to specular" light bounces.
|
||||
- All specular lighting is turned off during baking.
|
||||
|
||||
- Light probe capture does not support specular reflections. Specular energy is treated as diffuse.
|
||||
|
||||
.. _eevee-limitations-shadows:
|
||||
|
||||
Shadows
|
||||
=======
|
||||
|
||||
- Only 128 active lights can be supported by EEVEE in a scene.
|
||||
- Only 8 Shadowed sun lights can be supported at the same time.
|
||||
|
||||
- *Shadow Map Raytracing* can produce light leaking because of overlapping shadow casters.
|
||||
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:
|
||||
|
||||
@ -62,10 +60,8 @@ Volumetrics
|
||||
|
||||
- Only single scattering is supported.
|
||||
- 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 for volumes inside the view frustum.
|
||||
- Volumetric lighting do not respect the lights shapes. They are treated as point lights.
|
||||
|
||||
|
||||
.. _eevee-limitations-dof:
|
||||
@ -73,15 +69,16 @@ Volumetrics
|
||||
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
|
||||
disable the post-process depth of field by setting the *Max Size* to 0.
|
||||
|
||||
.. _eevee-limitations-screenspace:
|
||||
|
||||
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.
|
||||
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.
|
||||
@ -93,94 +90,41 @@ These limitations creates a few problems:
|
||||
This can be partially fixed by using the *overscan* feature.
|
||||
- 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.
|
||||
- Objects behind other objects (occluded) 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.
|
||||
- Objects that a part of :ref:`Holdout Collections <bpy.ops.outliner.collection_holdout_set>`
|
||||
will not be rendered with screen space effects.
|
||||
|
||||
|
||||
.. _eevee-limitations-ao:
|
||||
.. _eevee-limitations-raytracing:
|
||||
|
||||
Ambient Occlusion
|
||||
-----------------
|
||||
|
||||
- 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
|
||||
-----------------------
|
||||
Raytracing
|
||||
----------
|
||||
|
||||
- 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 opaque and alpha hashed materials 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>`.
|
||||
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-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
|
||||
============
|
||||
|
||||
- All BSDF's are using approximations to achieve realtime performance
|
||||
so there will always be small differences between Cycles and 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::
|
||||
|
||||
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
|
||||
@ -221,4 +165,4 @@ multiple :abbr:`GPU (Graphic Processing Unit, also known as Graphics Card)` syst
|
||||
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
|
||||
-------------
|
||||
|
||||
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 node evaluates the lighting of the BSDFs connected to it just like a *Blended* material and inherits
|
||||
its limitation.
|
||||
|
||||
|
||||
Specular BSDF
|
||||
@ -51,24 +53,18 @@ Although most BSDFs are supported, many of them are approximations and are not f
|
||||
Diffuse BSDF
|
||||
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
|
||||
Does not refract lights. Does not support Beckmann distribution.
|
||||
See :ref:`Refraction limitations <eevee-limitations-refraction>`.
|
||||
Only supports GGX and Multiscatter GGX distribution.
|
||||
See :ref:`Raytracing limitations <eevee-limitations-raytracing>`.
|
||||
|
||||
Glossy BSDF
|
||||
Does not support Beckmann and Ashikhmin-Shirley distributions.
|
||||
Only supports GGX and Multiscatter GGX distributions.
|
||||
|
||||
Subsurface Scattering
|
||||
Random Walk sampling is not supported. Per color channel Radius is specified by the default socket value.
|
||||
Any link plugged into this socket gets ignored.
|
||||
Texture Blur is not accurate for any value other than 0.0 and 1.0.
|
||||
Random Walk sampling, IOR and Anisotropic are not supported.
|
||||
|
||||
Transparent BSDF
|
||||
Transparency will only have an effect if the Material blend mode is not Opaque.
|
||||
Colored and additive transparency are only compatible with "Alpha Blend" mode.
|
||||
Colored and additive transparency are only compatible with blended modes.
|
||||
|
||||
Translucent BSDF
|
||||
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>`.
|
||||
|
||||
Holdout
|
||||
Partially supported, using :ref:`Blend Modes <bpy.types.Material.blend_method>`
|
||||
other than *Alpha* may give incorrect results.
|
||||
Partially supported, using dithered mode may give incorrect results.
|
||||
|
||||
Anisotropic BSDF
|
||||
Not supported.
|
||||
@ -114,9 +109,6 @@ Input Nodes
|
||||
Ambient Occlusion
|
||||
The *Only Local* option is not supported.
|
||||
|
||||
Camera Data
|
||||
EveHair Inforything is compatible.
|
||||
|
||||
Geometry
|
||||
Pointiness is not supported.
|
||||
|
||||
@ -132,37 +124,26 @@ Attribute
|
||||
Bevel
|
||||
Not supported.
|
||||
|
||||
Fresnel
|
||||
Everything is compatible.
|
||||
|
||||
Curves Info
|
||||
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.
|
||||
|
||||
Layer Weight
|
||||
Everything is compatible.
|
||||
|
||||
Light Path
|
||||
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.
|
||||
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 Shadow*: Supported.
|
||||
- *Is Diffuse*: Supported.
|
||||
- *Is Glossy*: Supported.
|
||||
- *Is Diffuse*: Set to 1.0 when baking light probe volume. Otherwise is set to 0.0.
|
||||
- *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 Reflection*: Not supported. Same as Is Glossy.
|
||||
- *Is Transmission*: Not supported. Same as Is Glossy.
|
||||
- *Ray Length*: Not supported. Defaults to 1.0.
|
||||
- *Ray Depth*: Indicates the current bounce when baking the light cache.
|
||||
- *Diffuse Depth*: Same as Ray Depth but only when baking diffuse light.
|
||||
- *Glossy Depth*: Same as Ray Depth but only when baking specular light.
|
||||
- *Ray Depth*: Not supported. Defaults to 0.0.
|
||||
- *Diffuse Depth*: Partially supported. Set to 1.0 when baking light probe volume. Otherwise is set to 0.0.
|
||||
- *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.
|
||||
- *Transmission Depth*: Not supported. Same as Glossy Depth.
|
||||
|
||||
@ -171,15 +152,9 @@ Light Path
|
||||
*Is Glossy* does not work with Screen Space Reflections/Refractions
|
||||
but does work with reflection planes (whether used with SSR or not).
|
||||
|
||||
Object Info
|
||||
Everything is compatible.
|
||||
|
||||
Particle Info
|
||||
Not supported.
|
||||
|
||||
Tangent
|
||||
Everything is compatible.
|
||||
|
||||
Texture Coordinate
|
||||
*From Instancer* is not supported.
|
||||
|
||||
@ -218,12 +193,3 @@ Other Nodes
|
||||
|
||||
Light Falloff
|
||||
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.
|
||||
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
|
||||
Randomize the camera position for every scene render sample to increase precision.
|
||||
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`.
|
||||
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.
|
||||
|
||||
Transparent
|
||||
|
@ -8,16 +8,12 @@
|
||||
:maxdepth: 2
|
||||
|
||||
sampling.rst
|
||||
grease_pencil.rst
|
||||
ambient_occlusion.rst
|
||||
bloom.rst
|
||||
clamping.rst
|
||||
raytracing.rst
|
||||
volumes.rst
|
||||
curves.rst
|
||||
depth_of_field.rst
|
||||
subsurface_scattering.rst
|
||||
screen_space_reflections.rst
|
||||
motion_blur
|
||||
volumetrics.rst
|
||||
performance.rst
|
||||
hair.rst
|
||||
shadows.rst
|
||||
indirect_lighting.rst
|
||||
motion_blur.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::
|
||||
|
||||
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>`.
|
||||
Motion blur is only visible in the viewport during animation playback and uses a simpler
|
||||
algorithm than final render. Same thing applies to :ref:`Viewport Renders <bpy.ops.render.opengl>`.
|
||||
|
||||
Position
|
||||
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.
|
||||
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
|
||||
This controls the number of steps used by the accumulation blur and thus its accuracy.
|
||||
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
|
||||
has to cover a smaller distance.
|
||||
|
||||
Shutter Curve
|
||||
Use a custom shutter curve.
|
||||
|
||||
|
||||
Example
|
||||
=======
|
||||
|
@ -12,3 +12,31 @@ Performance
|
||||
High Quality Normals
|
||||
Uses higher precision normals and tangents which can improve
|
||||
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`
|
||||
|
||||
Viewport
|
||||
========
|
||||
|
||||
Samples
|
||||
The number of samples to use in the 3D Viewport.
|
||||
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:
|
||||
|
||||
Viewport Denoising
|
||||
Reduces noise while moving the viewport or during animation playback.
|
||||
Temporal Reprojection
|
||||
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:
|
||||
|
||||
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.
|
||||
|
||||
This pass only supports monochromatic opacity.
|
||||
@ -329,8 +329,8 @@ The passes can be combined to produce the final image as follows:
|
||||
Known Limitations
|
||||
=================
|
||||
|
||||
- Alpha 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>`
|
||||
- Blended materials are not rendered in render passes except the combined pass.
|
||||
Use the *Dithered* as :ref:`Render Method <bpy.types.Material.render_method>`
|
||||
to render transparent materials in render passes.
|
||||
- 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
|
||||
|
@ -22,7 +22,7 @@ Color
|
||||
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>`
|
||||
|
||||
|
||||
|
@ -14,7 +14,7 @@ Renderer Settings
|
||||
While shading nodes control the appearance, these settings control the quality and algorithms
|
||||
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>`
|
||||
|
||||
|
||||
|
@ -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.
|
||||
|
||||
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 Shadow*: Supported.
|
||||
|
@ -36,7 +36,7 @@ Poor Performance
|
||||
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.
|
||||
|
||||
|
||||
|
EEVEE is a based
-> EEVEE is based`