| Age | Commit message (Collapse) | Author |
|---|
|
This code was duplicated in multiple engines. Now it is the draw manager
responsability to manage the throwaway fluid textures.
|
|
This is supported throught the visibility toggle. The light cache will
then only be used for world lighting. This is the behavior as light
objects.
|
|
This commit removes all EEVEE specific code from the `gpu_shader_material*.glsl`
files. It defines a clear interface to evaluate the closure nodes leaving
more flexibility to the render engine.
Some of the long standing workaround are fixed:
- bump mapping support is no longer duplicating a lot of node and is instead
compiled into a function call.
- bump rewiring to Normal socket is no longer needed as we now use a global
`g_data.N` for that.
Closure sampling with upstread weight eval is now supported if the engine needs
it.
This also makes all the material GLSL sources use `GPUSource` for better
debugging experience. The `GPUFunction` parsing now happens in `GPUSource`
creation.
The whole `GPUCodegen` now uses the `ShaderCreateInfo` and is object type
agnostic. Is has also been rewritten in C++.
This patch changes a view behavior for EEVEE:
- Mix shader node factor imput is now clamped.
- Tangent Vector displacement behavior is now matching cycles.
- The chosen BSDF used for SSR might change.
- Hair shading may have very small changes on very large hairs when using hair
polygon stripes.
- ShaderToRGB node will remove any SSR and SSS form a shader.
- SSS radius input now is no longer a scaling factor but defines an average
radius. The SSS kernel "shape" (radii) are still defined by the socket default
values.
Appart from the listed changes no other regressions are expected.
|
|
|
|
These were missed in previous passes. Also remove some logic
in `draw_hair.c` that was redundant after f31c3f8114616bb8964c8e7.
|
|
The GPU evaluation for curves will have to change significantly from the
current particle hair drawing code, due to its more general use cases
and support for more curve types. To simplify that process and avoid
introducing regressions for the rendering of hair particle systems,
this commit splits drawing functions for the curves object and
particle hair.
The changes are just inlining of functions and copying code
where necessary.
Differential Revision: https://developer.blender.org/D14576
|
|
Add blank lines after file references to avoid them being interpreted as
doc-strings the following declarations.
|
|
|
|
Previously, objects and geometries were mapped between frames
using different hash tables in a way that is incompatible with
geometry instances. That is because the geometry mapping happened
without looking at the `persistent_id` of instances, which is not possible
anymore. Now, there is just one mapping that identifies the same
object at multiple points in time.
There are also two new caches for duplicated vbos and textures used for
motion blur. This data has to be duplicated, otherwise it would be freed
when another time step is evaluated. This caching existed before, but is
now a bit more explicit and works for geometry instances as well.
Differential Revision: https://developer.blender.org/D13497
|
|
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
|
|
Based on discussions from T95355 and T94193, the plan is to use
the name "Curves" to describe the data-block container for multiple
curves. Eventually this will replace the existing "Curve" data-block.
However, it will be a while before the curve data-block can be replaced
so in order to distinguish the two curve types in the UI, "Hair Curves"
will be used, but eventually changed back to "Curves".
This patch renames "hair-related" files, functions, types, and variable
names to this convention. A deep rename is preferred to keep code
consistent and to avoid any "hair" terminology from leaking, since the
new data-block is meant for all curve types, not just hair use cases.
The downside of this naming is that the difference between "Curve"
and "Curves" has become important. That was considered during
design discussons and deemed acceptable, especially given the
non-permanent nature of the somewhat common conflict.
Some points of interest:
- All DNA compatibility is lost, just like rBf59767ff9729.
- I renamed `ID_HA` to `ID_CV` so there is no complete mismatch.
- `hair_curves` is used where necessary to distinguish from the
existing "curves" plural.
- I didn't rename any of the cycles/rendering code function names,
since that is also used by the old hair particle system.
Differential Revision: https://developer.blender.org/D14007
|
|
With (center) position, radius and random value outputs.
Eevee does not yet support rendering point clouds, but an untested
implementation of this node was added for when it does.
Ref T92573
|
|
MSVC used to warn about const mismatch for arguments passed by value.
Remove these as newer versions of MSVC no longer show this warning.
|
|
|
|
Ref T92709
|
|
Issue is that external engine uses the gpu info. but overwrote the
instance data. The draw manager would then detect instance data and
required the engine type to have a instance free callback.
The solution is to save some space in the engine data to hold an empty
and unused instance_data attribute to comply with `ViewportEngineData`
struct.
|
|
The Cycles accurate mode was removed, but the Eevee option for this has
a different meaning and should not have been removed. The Eevee accurate
makes cryptomatte accumulate for every sample, which Cycles has always
done regardless of any option.
|
|
This includes much improved GPU rendering performance, viewport interactivity,
new shadow catcher, revamped sampling settings, subsurface scattering anisotropy,
new GPU volume sampling, improved PMJ sampling pattern, and more.
Some features have also been removed or changed, breaking backwards compatibility.
Including the removal of the OpenCL backend, for which alternatives are under
development.
Release notes and code docs:
https://wiki.blender.org/wiki/Reference/Release_Notes/3.0/Cycles
https://wiki.blender.org/wiki/Source/Render/Cycles
Credits:
* Sergey Sharybin
* Brecht Van Lommel
* Patrick Mours (OptiX backend)
* Christophe Hery (subsurface scattering anisotropy)
* William Leeson (PMJ sampling pattern)
* Alaska (various fixes and tweaks)
* Thomas Dinges (various fixes)
For the full commit history, see the cycles-x branch. This squashes together
all the changes since intermediate changes would often fail building or tests.
Ref T87839, T87837, T87836
Fixes T90734, T89353, T80267, T80267, T77185, T69800
|
|
|
|
Also use doxy style function reference `#` prefix chars when
referencing identifiers.
|
|
|
|
The new clamping works by modifying the lamp internal radius which
then soften the light contribution.
However this does remove more light compare to the old solution.
This is because the clamp now affects the light over a much larger
distance since it is smoother. Old scene needs manual tweaking.
|
|
Soft surface shadows were already supported but now we support
soft shadows of the volume themselves.
This is only enabled if the light casts shadow and the scene soft
shadows toggle is enabled.
|
|
This adds 2 new sliders for light objects that modulates the diffuse
light and the volume light intensities.
This also changes the way volume light is computed using point lamp
representation. We use "Point Light Attenuation Without Singularity"
from Cem Yuksel instead of the usual inverse square law.
|
|
This shader is of no use now that we the fullres hizbuffer.
|
|
We now reuse 9 hitpoints from the neighboorhood using a blue noise
sample distribution as mentionned in the reference presentation.
Reusing more rays does however make some area a bit more blury.
The resulting noise is quite lower compared to previous implementation
which was only reusing 4 hits.
|
|
|
|
|
|
We now have a new buffer to output reflection depth. This buffer is
only usefull for non planar SSR but we use it to tag the planar rays.
This also touch the raytrace algo for planars to avoid degenerate
lines on vert sharp reflections.
|
|
This changes the hitBuffer to store `ReflectionDir * HitTime, invPdf`
just as the reference presentation.
This avoids issues when the hit refinement produce a coordinate that
does not land on the correct surface.
We now store the pdf in the same texture and store it inversed so we can
remove some ALU from the resolve shader.
This also rewrite the resolve shader to not be vectorized to improve
readability and scalability.
|
|
This removes the need for per mipmap scalling factor and trilinear interpolation
issues. We pad the texture so that all mipmaps have pixels in the next mip.
This simplifies the downsampling shader too.
This also change the SSR radiance buffer as well in the same fashion.
|
|
Current implementation was to restricting for future enhancements where
the CryptomatterLayer could be read from existing metadata.
|
|
AO is always on in this case.
|
|
This modifies the principled BSDF and the Glass BSDF which now
have better fit to multiscatter GGX.
Code to generate the LUT have been updated and can run at runtime.
The refraction LUT has been changed to have the critical angle always
centered around one pixel so that interpolation can be mitigated.
Offline LUT data will be updated in another commit
This simplify the BTDF retreival removing the manual clean cut at
low roughness. This maximize the precision of the LUT by scalling
the sides by the critical angle.
I also touched the ior > 1.0 approximation to be smoother.
Also incluse some cleanup of bsdf_sampling.glsl
|
|
This is a complete refactor over the old system. The goal was to increase quality
first and then have something more flexible and optimised.
|{F9603145} | {F9603142}|{F9603147}|
This fixes issues we had with the old system which were:
- Too much overdraw (low performance).
- Not enough precision in render targets (hugly color banding/drifting).
- Poor resolution near in-focus regions.
- Wrong support of orthographic views.
- Missing alpha support in viewport.
- Missing bokeh shape inversion on foreground field.
- Issues on some GPUs. (see T72489) (But I'm sure this one will have other issues as well heh...)
- Fix T81092
I chose Unreal's Diaphragm DOF as a reference / goal implementation.
It is well described in the presentation "A Life of a Bokeh" by Guillaume Abadie.
You can check about it here https://epicgames.ent.box.com/s/s86j70iamxvsuu6j35pilypficznec04
Along side the main implementation we provide a way to increase the quality by jittering the
camera position for each sample (the ones specified under the Sampling tab).
The jittering is dividing the actual post processing dof radius so that it fills the undersampling.
The user can still add more overblur to have a noiseless image, but reducing bokeh shape sharpness.
Effect of overblur (left without, right with):
| {F9603122} | {F9603123}|
The actual implementation differs a bit:
- Foreground gather implementation uses the same "ring binning" accumulator as background
but uses a custom occlusion method. This gives the problem of inflating the foreground elements
when they are over background or in-focus regions.
This is was a hard decision but this was preferable to the other method that was giving poor
opacity masks for foreground and had other more noticeable issues. Do note it is possible
to improve this part in the future if a better alternative is found.
- Use occlusion texture for foreground. Presentation says it wasn't really needed for them.
- The TAA stabilisation pass is replace by a simple neighborhood clamping at the reduce copy
stage for simplicity.
- We don't do a brute-force in-focus separate gather pass. Instead we just do the brute force
pass during resolve. Using the separate pass could be a future optimization if needed but
might give less precise results.
- We don't use compute shaders at all so shader branching might not be optimal. But performance
is still way better than our previous implementation.
- We mainly rely on density change to fix all undersampling issues even for foreground (which
is something the reference implementation is not doing strangely).
Remaining issues (not considered blocking for me):
- Slight defocus stability: Due to slight defocus bruteforce gather using the bare scene color,
highlights are dilated and make convergence quite slow or imposible when using jittered DOF
(or gives )
- ~~Slight defocus inflating: There seems to be a 1px inflation discontinuity of the slight focus
convolution compared to the half resolution. This is not really noticeable if using jittered
camera.~~ Fixed
- Foreground occlusion approximation is a bit glitchy and gives incorrect result if the
a defocus foreground element overlaps a farther foreground element. Note that this is easily
mitigated using the jittered camera position.
|{F9603114}|{F9603115}|{F9603116}|
- Foreground is inflating, not revealing background. However this avoids some other bugs too
as discussed previously. Also mitigated with jittered camera position.
|{F9603130}|{F9603129}|
- Sensor vertical fit is still broken (does not match cycles).
- Scattred bokeh shapes can be a bit strange at polygon vertices. This is due to the distance field
stored in the Bokeh LUT which is not rounded at the edges. This is barely noticeable if the
shape does not rotate.
- ~~Sampling pattern of the jittered camera position is suboptimal. Could try something like hammersley
or poisson disc distribution.~~Used hexaweb sampling pattern which is not random but has better
stability and overall coverage.
- Very large bokeh (> 300 px) can exhibit undersampling artifact in gather pass and quite a bit of
bleeding. But at this size it is preferable to use jittered camera position.
Codewise the changes are pretty much self contained and each pass are well documented.
However the whole pipeline is quite complex to understand from bird's-eye view.
Notes:
- There is the possibility of using arbitrary bokeh texture with this implementation.
However implementation is a bit involved.
- Gathering max sample count is hardcoded to avoid to deal with shader variations. The actual
max sample count is already quite high but samples are not evenly distributed due to the
ring binning method.
- While this implementation does not need 32bit/channel textures to render correctly it does use
many other textures so actual VRAM usage is higher than previous method for viewport but less
for render. Textures are reused to avoid many allocations.
- Bokeh LUT computation is fast and done for each redraw because it can be animated. Also the
texture can be shared with other viewport with different camera settings.
|
|
Approximately 91 spelling corrections, almost all in comments.
Differential Revision: https://developer.blender.org/D10288
Reviewed by Harley Acheson
|
|
|
|
Stores cryptomatte hashes as meta data to the render result. Compositors could
use this for lookup on names in stead of hashes.
Differential Revision: https://developer.blender.org/D9553
|
|
In Cycles the volume transmittance is already composited into the color
passes. In Eevee the volume transmittance pass was separate and needed
to be composited in the compositor. This patch adds the volume
transmittance pass direct in the next render passes:
* Diffuse Color
* Specular Color
* Emission
* Environment
This patch includes the removal of the volume transmittance render pass.
It also renames the volume render passes to match Cycles. The setting
themselves aren't unified.
Maniphest Tasks: T81134
|
|
Cryptomatte is a standard to efficiently create mattes for compositing. The
renderer outputs the required render passes, which can then be used in the
compositor to create masks for specified objects. Unlike the Material and Object
Index passes, the objects to isolate are selected in compositing, and mattes
will be anti-aliased.
Cryptomatte was already available in Cycles this patch adds it to the EEVEE
render engine. Original specification can be found at
https://raw.githubusercontent.com/Psyop/Cryptomatte/master/specification/IDmattes_poster.pdf
**Accurate mode**
Following Cycles, there are two accuracy modes. The difference between the two
modes is the number of render samples they take into account to create the
render passes. When accurate mode is off the number of levels is used. When
accuracy mode is active, the number of render samples is used.
**Deviation from standard**
Cryptomatte specification is based on a path trace approach where samples and
coverage are calculated at the same time. In EEVEE a sample is an exact match on
top of a prepared depth buffer. Coverage is at that moment always 1. By sampling
multiple times the number of surface hits decides the actual surface coverage
for a matte per pixel.
**Implementation Overview**
When drawing to the cryptomatte GPU buffer the depth of the fragment is matched
to the active depth buffer. The hashes of each cryptomatte layer is written in
the GPU buffer. The exact layout depends on the active cryptomatte layers. The
GPU buffer is downloaded and integrated into an accumulation buffer (stored in
CPU RAM).
The accumulation buffer stores the hashes + weights for a number of levels,
layers per pixel. When a hash already exists the weight will be increased. When
the hash doesn't exists it will be added to the buffer.
After all the samples have been calculated the accumulation buffer is processed.
During this phase the total pixel weights of each layer is mapped to be in a
range between 0 and 1. The hashes are also sorted (highest weight first).
Blender Kernel now has a `BKE_cryptomatte` header that access to common
functions for cryptomatte. This will in the future be used by the API.
* Alpha blended materials aren't supported. Alpha blended materials support in
render passes needs research how to implement it in a maintainable way for any
render pass.
This is a list of tasks that needs to be done for the same release that this
patch lands on (Blender 2.92)
* T82571 Add render tests.
* T82572 Documentation.
* T82573 Store hashes + Object names in the render result header.
* T82574 Use threading to increase performance in accumulation and post
processing.
* T82575 Merge the cycles and EEVEE settings as they are identical.
* T82576 Add RNA to extract the cryptomatte hashes to use in python scripts.
Reviewed By: Clément Foucault
Maniphest Tasks: T81058
Differential Revision: https://developer.blender.org/D9165
|
|
This patch adds support for AOVs in EEVEE. AOV Outputs can be defined in the
render pass tab and used in shader materials. Both Object and World based
shaders are supported. The AOV can be previewed in the viewport using the
renderpass selector in the shading popover.
AOV names that conflict with other AOVs are automatically corrected. AOV
conflicts with render passes get a warning icon. The reason behind this is that
changing render engines/passes can change the conflict, but you might not notice
it. Changing this automatically would also make the materials incorrect, so best
to leave this to the user.
**Implementation**
The patch adds a copies the AOV structures of Cycles into Blender. The goal is
that the Cycles will use Blenders AOV defintions. In the Blender kernel
(`layer.c`) the logic of these structures are implemented.
The GLSL shader of any GPUMaterial can hold multiple outputs (the main output
and the AOV outputs) based on the renderPassUBO the right output is selected.
This selection uses an hash that encodes the AOV structure. The full AOV needed
to be encoded when actually drawing the material pass as the AOV type changes
the behavior of the AOV. This isn't known yet when the GLSL is compiled.
**Future Developments**
* The AOV definitions in the render layer panel isn't shared with Cycles.
Cycles should be migrated to use the same viewlayer aovs. During a previous
attempt this failed as the AOV validation in cycles and in Blender have
implementation differences what made it crash when an aov name was invalid.
This could be fixed by extending the external render engine API.
* Add support to Cycles to render AOVs in the 3d viewport.
* Use a drop down list for selecting AOVs in the AOV Output node.
* Give user feedback when multiple AOV output nodes with the same AOV name
exists in the same shader.
* Fix viewing single channel images in the image editor [T83314]
* Reduce viewport render time by only render needed draw passes. [T83316]
Reviewed By: Brecht van Lommel, Clément Foucault
Differential Revision: https://developer.blender.org/D7010
|
|
HDRI preview should have resolution dependent on dpi, viewport scale and HDRI gizmo size.
This patch uses a LOD to render a more round sphere.
Reviewed By: Jeroen Bakker
Differential Revision: https://developer.blender.org/D9382
|
|
This is caused by the TAA being reset after the init phase, leading to
1 sample being kept as valid when it is clearly not.
To fix this, we run the lookdev validation before TAA init.
Reviewed By: Jeroen Bakker
Differential Revision: https://developer.blender.org/D9452
|
|
Regular rendering uses a custom blend mode, but render passes renders to
2 separate textures. This wasn't configured correctly inside the
fragment shaders. This patch adds a switch to configure the fragment
shader with the correct attachments.
Backport to Blender 2.83.
Reviewed By: Clément Foucault
Differential Revision: https://developer.blender.org/D9038
|
|
Following the most widely used convention for including todo's in
the code, that is: `TODO(name):`, `FIXME(name)` ... etc.
|
|
This wraps the functionality used to speedup EEVEE volumetrics.
This touches the rendering code of EEVEE as it should fix a mis-usage of
the GL barrier. The barrier changed type and location, removing an
unused barrier.
|
|
This will add the remaining static shaders to the eevee shader test suite.
- Downsampling
- GGX LUT generation
- Mist
- Motion Blur
- Ambient Occlusion
- Render Passes
- Screen Raytracing
- Shadows
- Subsurface
- Volumes
Reviewed By: Clément Foucault
Differential Revision: https://developer.blender.org/D8779
|
|
No functional changes
|
|
This patch moves the EEVEE depth of field shaders to eevee_shaders.c and
adds them to the eevee shaders test suite.
Reviewed By: Clément Foucault
Differential Revision: https://developer.blender.org/D8771
|
|
- moved to eevee_shaders
- added to test suite
Reviewed By: Clément Foucault
Differential Revision: https://developer.blender.org/D8763
|
