When sculpting the GPU batches are constructed with only the required data
for a single viewport. When that viewport changes shading or coloring mode (object
to vertex) batches might not hold all the needed information.
There is also a case when you have two 3d viewport one in object color
mode and the other in vertex color mode that the GPU batches were
updated without any vertex colors.
In order to fix these category of issues this patch would always
construct the full GPU batches for sculpting.
Reviewed By: Clément Foucault, Pablo Dobarro
Maniphest Tasks: T75908
Differential Revision: https://developer.blender.org/D7701
This fix the issue by introducing a default material only for collection
holdouts. This avoids hash colision when the same material is used in
collections without holdout enabled.
The material indices in a mesh can exceed the number of available materials
slots in the object or mesh, sculpt drawing was not taking that into account.
Note this only changes cases where the variable was declared inside
the for loop. To handle it outside as well is a different challenge.
Differential Revision: https://developer.blender.org/D7320
EEVEE and Workbench both had the same issue that they continue with the
last sample when leaving navigating. This is ok for regular meshes as
they are all the same. For multiresolution it ain't as a low res version
of the mesh is used during navigation.
This patch also resets the AA samples when the user leaves navigation.
Problem is that the RenderEngines will change the RenderData cfra when
rendering (when time remapping is used -- at least workbench/eevee/
gpencil do a combination of BKE_scene_frame_get() plus
RE_GetCameraWindow() which alters the RenderData cfra).
Later on in the pipeline, the Compositor will use this RenderData cfra
to determine the output file name for the FileOutput node. (In contrast
to this, the 'regular' Output will use the Scene's RenderData -- not the
Render's -- cfra [which hasnt been altered])
It is not entirely clear why RE_GetCameraWindow was setting the cfra on
the Render, but it appears to be legacy OGL rendering related and is not
needed anymore.
Removing this will keep the cfra as needed for the Compositor FileOutput
node.
This patch adds support for alpha hash for hair rendering in EEvee. Here's a comparison of with alpha hashing:
{F7588610}
And no alpha hashing:
{F7588615}
Note that this needs "soft shadows" enabled, otherwise shadows will be noisy; here's a render with soft shadows disabled:
{F7588621}
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D5221
* Space: volume density and step size in object or world space
* Step Size: override automatic step size
* Clipping: values below this are ignored for tighter volume bounds
The last two are Cycles only currently.
Ref T73201
Only the volume drawing part is really finished and exposed to the user. Hair
plugs into the existing hair rendering code and is fairly straightforward. The
pointcloud drawing is a hack using overlays rather than Eevee and workbench.
The most tricky part for volume rendering is the case where each volume grid
has a different transform, which requires an additional matrix in the shader
and non-trivial logic in Eevee volume drawing. In the common case were all the
transforms match we don't use the additional per-grid matrix in the shader.
Ref T73201, T68981
Differential Revision: https://developer.blender.org/D6955
Fixed memory leak that showed up after the original issue (crash) had been fixed in 93ac4709eb. The fix ensures that light cache bakes free up GPU smoke textures and the smoke domain list correctly.
This commit also removes the workaround (f3a33a9298) that disabled light cache bakes for fluid objects.
We implement cubemap array support for EEVEE's lightcache reflection probes.
This removes stretched texels and bottom hemisphere seams artifacts caused
by the octahedral projection previously used.
This introduce versioning code for the lightcache which will discard any
lightcache version that is not compatible.
Differential Revision: https://developer.blender.org/D7066
This has no user visible impact yet since smoke volumes only support a fixed
set of attributes, but will become important with the new volume object.
For GPU shader compilation, volume grids are now handled separately from
image textures. They are somewhere between a vertex attribute and an image
texture, basically an attribute that is stored as a texture.
Differential Revision: https://developer.blender.org/D6952
This is more in line with standard grids and means we don't have to make
many special exceptions in the upcoming change for arbitrary number of volume
grids support in Eevee.
The workbench shader was also changed to fix bugs where squared density was
used, and the smoke color would affect the density so that black smoke would
be invisible. This can change the look of smoke in workbench significantly.
When using the color grid when smoke has a constant color, the color grid
will no longer be premultiplied by the density. If the color is constant
we want to be able not to store a grid at all. This breaks one test for
Cycles and Eevee, but the setup in that test using a color without density
does not make sense. It suffers from artifacts since the unpremultiplied
color grid by itself will not have smooth boundaries.
Differential Revision: https://developer.blender.org/D6951
While it might be handy to have type-less functionality which is
similar to how C++ math is implemented it can not be easily achieved
with just preprocessor in a way which does not have side-effects on
wrong usage.
There macros where often used on a non-trivial expression, and there
was at least one usage where it was causing an actual side effect/bug
on Windows (see change around square_f(sh[index++]) in studiolight.c).
For such cases it is handy to have a function which is guaranteed to
have zero side-effects. The motivation behind actually removing the
macros is that there is already a way to do similar calculation. Also,
not having such macros is a way to guarantee that its usage is not
changed in a way which have side-effects and that it's not used as an
inspiration for cases where it should not be used.
Differential Revision: https://developer.blender.org/D7051
The old convention was easy to confuse with ScrArea.
Part of https://developer.blender.org/T74432.
This is mostly a batch rename with some manual fixing. Only single word
variable names are changed, no prefixed/suffixed names.
Brecht van Lommel and Campbell Barton both gave me a green light for
this convention change.
Also ran clan clang format on affected files.
When using Material Previews not all uniform blocks were filled. This
patch will add the renderpass_block when drawing the background.
Note that I wasn't able to reproduce the issue on my system, but
according the the backtrace it most likely solves the issue. I let the
reporter test.
Cycles recently fixed this issue, EEVEE needed to be adapted to output
similar results in the light passes.
This patch implements cycles `safe_divide_even_color` function to a GLSL
function that will be used when extracting the light passes.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D6948
Shadow could penetrate occluded geometry. This patch adds a check to see
if the light is in the right location to light the pixel.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D6918
Bug was introduced by the render passes. We had to tweak the bloom
shader a bit so we could reuse it. After that tweaking the original
alpha was ignored.
This patch will read and store the correct alpha channel.
When disabling AO or BLOOM in the render tab, when the pass is shown in
a 3d viewport the pass wasn't reset. This resulted in showing a black
texture and a not filled UI render pass in the shading popover.
This patch will by default reset to the combined pass. It is intended
that the render_pass in the 3d shading struct isn't set to combined as
people could have disabled AO/bloom by mistake and it could reset
viewports that aren't visible.
