EEVEE-Next: Update Documentation #104816
@ -14,10 +14,9 @@ EEVEE can be used interactively in the 3D Viewport but also produce high quality
|
||||
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 is a based on rasterization and is not a path tracer.
|
||||
Instead of computing each ray of light, EEVEE uses a process called rasterization to determine what
|
||||
surface is visible from the camera. It then estimates the way light interacts with these surfaces
|
||||
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.
|
||||
For these reasons, EEVEE has a set of :doc:`limitations </render/eevee/limitations/index>`.
|
||||
|
@ -6,7 +6,7 @@ Introduction
|
||||
Light probe objects are used by EEVEE as support objects.
|
||||
|
||||
There are three different types of light probes.
|
||||
Each type of light probe record the lighting at different resolution and frequency.
|
||||
They are used together to recover incoming light information when using ray tracing is not possible (either for performance or for technical limitations).
|
||||
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).
|
||||
|
@ -8,15 +8,15 @@ 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 probes increases the render time as the scene needs to be rendered for
|
||||
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 ray tracing method is set to `Screen-Trace`. When enabled, they
|
||||
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.
|
||||
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
|
||||
@ -34,9 +34,9 @@ Alternatively you can disable the light probe visibility in the object visibilit
|
||||
|
||||
Distance
|
||||
A probe object only influences the lighting of surfaces inside its influence zone.
|
||||
This influence zone is defined by the Distance parameter and object scaling.
|
||||
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.
|
||||
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.
|
||||
|
||||
|
||||
@ -44,7 +44,7 @@ Capture
|
||||
=======
|
||||
|
||||
Clipping Offset
|
||||
Define how much below the plane the near clip is when capturing the scene.
|
||||
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.
|
||||
|
||||
|
||||
|
@ -6,37 +6,34 @@ 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.
|
||||
They then smoothly blend to light probe volume lighting for completely diffuse 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 usage, the light probe spheres are shadowed by light probe volume.
|
||||
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 have an internal light probe sphere which resolution can be adjusted in the *World* data panel.
|
||||
|
||||
.. seealso::
|
||||
|
||||
:doc:`World Settings </render/eevee/world_settings>`.
|
||||
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
|
||||
Select the shape of the influence volume. Can be set to Sphere or Box.
|
||||
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 during which the influence of a probe fades linearly.
|
||||
Percentage of the influence distance in which the influence of a probe fades linearly.
|
||||
|
||||
|
||||
Capture
|
||||
@ -62,7 +59,7 @@ 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, just enable the *Custom Parallax* and
|
||||
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)
|
||||
|
@ -3,7 +3,7 @@
|
||||
Light Probe Volume
|
||||
******************
|
||||
|
||||
A volume probe records the light incomming from all directions at a many locations inside a 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.
|
||||
@ -41,8 +41,8 @@ View Bias
|
||||
Can lead to view dependant result if set too high. Prefer this if camera is static.
|
||||
|
||||
Facing Bias
|
||||
When set to zero, avoids capture points behind the shaded surface to bleed light onto
|
||||
the shaded surface, but this produces non-smooth interpolation when the capture resolution is high.
|
||||
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.
|
||||
|
||||
|
||||
@ -50,7 +50,7 @@ Validity & Dilation
|
||||
===================
|
||||
|
||||
During the baking process, a validity score is assigned to each capture point.
|
||||
This score is based on the number of back-face was hit when capturing the incoming lighting.
|
||||
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
|
||||
@ -77,9 +77,9 @@ between blender files.
|
||||
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 prevent baking if it cannot fit inside the GPU memory.
|
||||
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 scene should be divided into smaller sections or using different level of details.
|
||||
- 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.
|
||||
|
||||
@ -90,7 +90,7 @@ There are a few way to deal with this issue:
|
||||
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.
|
||||
Irradiance light sample will be computed for each cell in this grid.
|
||||
The lighting will be captured for each cell in this grid.
|
||||
|
||||
Bake Samples
|
||||
Number of ray directions to evaluate when baking.
|
||||
@ -98,7 +98,7 @@ Bake Samples
|
||||
|
||||
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. Have a huge impact on memory usage.
|
||||
Higher values increase quality, but have a huge impact on memory usage.
|
||||
|
||||
.. tip::
|
||||
A good value is twice the maximum *Resolution*.
|
||||
@ -127,12 +127,12 @@ Clamping
|
||||
|
||||
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 light object)
|
||||
or coming from emissive materials.
|
||||
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 light object)
|
||||
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::
|
||||
@ -143,9 +143,10 @@ Clamp Indirect
|
||||
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 points positioning, the bake process will adjust their location.
|
||||
First by moving them slightly away from surrounding surfaces, avoiding banding artifacts.
|
||||
It also tries to move them out of objects if they are not so far bellow the surface.
|
||||
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.
|
||||
|
@ -8,7 +8,7 @@ Light Settings
|
||||
:Panel: :menuselection:`Properties --> Light`
|
||||
:menuselection:`Shader Editor --> Sidebar --> Options`
|
||||
|
||||
Next to lighting from the background and any object with an emission shader,
|
||||
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.
|
||||
@ -27,7 +27,7 @@ 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 more shadow memory.
|
||||
- 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.
|
||||
@ -57,7 +57,7 @@ Overblur
|
||||
.. _bpy.types.Light.shadow_filter_radius:
|
||||
|
||||
Filter
|
||||
Blur shadow aliasing using Percentage Closer Filtering with a circular kernel.
|
||||
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::
|
||||
@ -67,7 +67,7 @@ Filter
|
||||
|
||||
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 scene.
|
||||
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.
|
||||
|
@ -25,7 +25,7 @@ Cameras
|
||||
Lights
|
||||
======
|
||||
|
||||
- For 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.
|
||||
|
||||
|
@ -60,7 +60,7 @@ Displacement Type
|
||||
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 fallback to *Displacement and Bump*.
|
||||
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.
|
||||
@ -118,17 +118,18 @@ 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. As of now EEVEE does not support per-fragment (pixel) sorting or per-triangle sorting.
|
||||
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>`.
|
||||
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
|
||||
these objects in a scene will greatly degrade performance.
|
||||
objects in a scene will greatly degrade performance.
|
||||
|
||||
.. _bpy.types.Material.use_transparency_overlap:
|
||||
|
||||
@ -147,7 +148,7 @@ Thickness
|
||||
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, then a default thickness based on the smallest dimension of the object is computed.
|
||||
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
|
||||
|
||||
|
@ -26,7 +26,7 @@ Indirect Light
|
||||
|
||||
.. note::
|
||||
|
||||
These options provides a way to limit :term:`Fireflies` and :term:`Aliasing` of highly reflective surfaces and dense volumes.
|
||||
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
|
||||
|
@ -29,7 +29,7 @@ Shadow Pool Size
|
||||
.. _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 grid in the scene but might not fit into GPU memory and decreases performance.
|
||||
A bigger pool size allows for more irradiance grids in the scene but might not fit into GPU memory and decreases performance.
|
||||
|
||||
|
||||
Viewport
|
||||
|
@ -24,7 +24,7 @@ Method
|
||||
|
||||
: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 is has the lowest tracing cost but rely on manually placed light-probes.
|
||||
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.
|
||||
@ -47,7 +47,7 @@ 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 lowers the maximum trace distance.
|
||||
Higher values increase precision of the screen space ray-tracing but lower the maximum trace distance.
|
||||
Increased precision also increases performance cost.
|
||||
|
||||
Thickness
|
||||
@ -58,17 +58,17 @@ Thickness
|
||||
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 noise amount from the raw ray-traced output.
|
||||
This can help image stability but will also over blur the final ray-traced output.
|
||||
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 last ray tracing results.
|
||||
This removes :term:`Fireflies` but also introduce a lot of color bias.
|
||||
Useful for viewport temporal stability or making render converge faster.
|
||||
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.
|
||||
@ -77,16 +77,14 @@ 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`
|
||||
This Fast GI Approximation is a fallback to the ray-tracing pipeline for
|
||||
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 less noisy output and capture bounce lighting more efficiently than individually traced rays.
|
||||
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.
|
||||
|
||||
.. seealso:: :ref:`Limitations <eevee-limitations-screenspace>`.
|
||||
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 methods used to compute the fast GI approximation.
|
||||
Determine the method used to compute the fast GI approximation.
|
||||
|
||||
:Ambient Occlusion:
|
||||
Use scene intersections to shadow the distant lighting from light-probes.
|
||||
@ -100,17 +98,17 @@ Resolution
|
||||
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`
|
||||
Amount of GI ray per pixels at the specified *Resolution*.
|
||||
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`
|
||||
Amount of screen sample per GI ray.
|
||||
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 higher step count, there is less chance to miss other surfaces that could reflect of block the light.
|
||||
This means that the Fast GI *Thickness* parameters can be tweaked to lower values without loosing too much light bounce energy.
|
||||
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.
|
||||
|
@ -47,13 +47,13 @@ Shadows
|
||||
.. _bpy.types.SceneEEVEE.shadow_ray_count:
|
||||
|
||||
Shadow Rays Count
|
||||
Amount of shadow rays to trace for each light.
|
||||
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
|
||||
Amount of shadow map sample per shadow ray.
|
||||
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:
|
||||
|
@ -21,7 +21,7 @@ Steps
|
||||
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.
|
||||
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.
|
||||
@ -31,10 +31,10 @@ Max Depth
|
||||
Custom Range
|
||||
============
|
||||
|
||||
When working with volumes objects, EEVEE automatically compute the best depth range where to compute
|
||||
When working with volume objects, EEVEE automatically computes the best depth range where to compute
|
||||
the volume sampling and lighting.
|
||||
In certain situation, this isn't enough and produces sub-optimal sampling which increases noise.
|
||||
This is particularly the case when using a volume shader inside the *World* or when working with large of volume objects.
|
||||
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
|
||||
|
@ -6,7 +6,7 @@ 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 internal :ref:`Light Probe`.
|
||||
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
|
||||
@ -83,8 +83,8 @@ Resolution
|
||||
Sun
|
||||
---
|
||||
|
||||
EEVEE can separate the light from intense light sources (e.g. a sun from an outdoor HDRI) and
|
||||
replace them by a sun light. This increases the quality of the lighting as the internal light probes
|
||||
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
|
||||
@ -94,8 +94,7 @@ Threshold
|
||||
A value of zero will disable this feature and all lighting will be stored inside the internal light probes.
|
||||
|
||||
Angle
|
||||
Angle of the extracted sun light.
|
||||
Angular diameter of the Sun as seen from the Earth
|
||||
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.
|
||||
|
EEVEE is a based
-> EEVEE is based`