Age | Commit message (Collapse) | Author |
|
|
|
Probe counting now needs to have proper gl capabilities initialised to run
correctly.
|
|
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.
|
|
|
|
Changed the blending mode to full blending. I found the issue when
during development of a material pass containing alpha values.
|
|
Missing code-path in recent refactoring.
|
|
|
|
This reverts commit 403bb357ae2b1d2561a0d77c96035ba54c197cbd.
The old implementation matches cycles closer. See T74378
|
|
|
|
Differential Revision: https://developer.blender.org/D6959
|
|
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.
|
|
|
|
Revert the change that renders the background black.
|
|
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
|
|
For when we support sources of hair other than particle systems.
|
|
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.
|
|
|
|
|
|
The render passes checked all bits of an integer, that can lead to
runtime errors. Added the max bit in the DNA and used this.
|
|
SSS buffers are lazy initialized when needed. When shaders recompile the
SSS buffers could be incorrectly drawn. During the render passes project
we tried to fix this, but that resulted in incorrect result of the first
sample after a shader was compiled.
We revert this change knowing that we know the issue, but haven't found
a proper solution for it.
|
|
|
|
|
|
This is using the GGX probe as background. This has the drawback of
having the resolution choosed in the indirect lighting setting.
The blurring is not really high-quality.
The pros is that it has a simple implementation and is fast to evaluate.
This patch also fades the background alpha to make overlay engine draw the
default background color in the correct color space. Removing one colorspace
hack.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D6895
|
|
|
|
This was caused by the texture size not being power of 2. Thus the
padding applied to the base LOD did not match the highest mipmaps.
|
|
|
|
|
|
This patch adds new render passes to EEVEE. These passes include:
* Emission
* Diffuse Light
* Diffuse Color
* Glossy Light
* Glossy Color
* Environment
* Volume Scattering
* Volume Transmission
* Bloom
* Shadow
With these passes it will be possible to use EEVEE effectively for
compositing. During development we kept a close eye on how to get similar
results compared to cycles render passes there are some differences that
are related to how EEVEE works. For EEVEE we combined the passes to
`Diffuse` and `Specular`. There are no transmittance or sss passes anymore.
Cycles will be changed accordingly.
Cycles volume transmittance is added to multiple surface col passes. For
EEVEE we left the volume transmittance as a separate pass.
Known Limitations
* All materials that use alpha blending will not be rendered in the render
passes. Other transparency modes are supported.
* More GPU memory is required to store the render passes. When rendering
a HD image with all render passes enabled at max extra 570MB GPU memory is
required.
Implementation Details
An overview of render passes have been described in
https://wiki.blender.org/wiki/Source/Render/EEVEE/RenderPasses
Future Developments
* In this implementation the materials are re-rendered for Diffuse/Glossy
and Emission passes. We could use multi target rendering to improve the
render speed.
* Other passes can be added later
* Don't render material based passes when only requesting AO or Shadow.
* Add more passes to the system. These could include Cryptomatte, AOV's, Vector,
ObjectID, MaterialID, UV.
Reviewed By: Clément Foucault
Differential Revision: https://developer.blender.org/D6331
|
|
|
|
|
|
The render passes didn't follow the DrawManager way of doing things. It added new geometry and shading groups during drawing. This would make it harder to migrate to Vulkan later on.
This change will re-implement this part by using uniform references.
Reviewed By: Clément Foucault
Differential Revision: https://developer.blender.org/D6875
|
|
|
|
This fixes the issue where sun shadowmaps needs a very big bias value to
make any difference.
The bias is now in world space and not dependant on shadow bounds.
Unfortunatelly this breaks compatibility with previous version and old
scene are likely to need user intervention to fix.
Also fixes the property range.
Fix T71661 EEVEE shadow from sun on incorrect face
|
|
Reviewed By: brecht sergey jbakker
Differential Revision: http://developer.blender.org/D6729
|
|
|
|
|
|
|
|
Old Name New Name
========= =========
init_def_material BKE_materials_init
BKE_material_gpencil_default_free BKE_materials_exit
test_object_materials BKE_object_materials_test
test_all_objects_materials BKE_objects_materials_test_all
give_matarar BKE_object_material_array
give_totcolp BKE_object_material_num
give_current_material_p BKE_object_material_get_p
give_current_material BKE_object_material_get
assign_material BKE_object_material_assign
assign_matarar BKE_object_material_array_assign
give_matarar_id BKE_id_material_array
give_totcolp_id BKE_id_material_num
assign_material_id BKE_id_material_assign
clear_matcopybuf BKE_material_copybuf_clear
free_matcopybuf BKE_material_copybuf_free
copy_matcopybuf BKE_material_copybuf_copy
paste_matcopybuf BKE_material_copybuf_paste
BKE_material_init_gpencil_settings BKE_gpencil_material_attr_init
BKE_material_add_gpencil BKE_gpencil_material_add
BKE_material_gpencil_get BKE_gpencil_material
BKE_material_gpencil_default_get BKE_gpencil_material_default
BKE_material_gpencil_settings_get BKE_gpencil_material_settings
|
|
|
|
This will catch any non renderable size.
|
|
|
|
Try to never do operation twice and try to use MADD operations. Even if this
is very unlikely to make any difference, it can help compilers do some
optimization. I did not measure any difference as probes have much higher
impact on render time because of texture lookups.
Note that disk light is currently the most expensive light type so it
does not hurt to micro optimize.
|
|
This is an issue on some drivers that might output NaN out of sqrt if the
number is infinity.
|
|
|