Age | Commit message (Collapse) | Author |
|
Before this change, you could have the new sculpt symmetry code and the
older weight paint symmetry code active at the same time. This would
lead to users easily trashing their weigh paint data if they were not
careful when switching between modes.
Now the specific weight paint symmetry code is an exclusive toggle so
the user can't accidentally mirror strokes and vertex groups at the same
time. This also paves the way of supporting Y and Z symmetry in the
future for weight groups mirroring if we decide to add it in the future.
Reviewed By: Sybren
Differential Revision: http://developer.blender.org/D10426
|
|
Now `ED_view3d_backbuf_depth_validate`, `ED_view3d_draw_depth` and
`ED_view3d_draw_depth_gpencil` are unified in `ED_view3d_depth_override`.
This new function replaces `ED_view3d_autodist_init`.
Also, since `ED_view3d_depth_update` depends on the render context, and
changing the context is a slow operation, that function also was removed,
and the depth buffer cached is now updated inside the new unified drawing
function when the "bool update_cache" parameter is true.
Finally `V3D_INVALID_BACKBUF` flag has been renamed and moved to
`runtime.flag`.
Differential revision: https://developer.blender.org/D10678
|
|
Display the bone axes at the head (root) of the bone by default, instead
of the tail (tip), and add a slider so that it's possible to adjust this
position.
Versioning code is in place to ensure existing files behave the same
(axes shown at tail), whereas new Armatures will be using the new
default (axes shown at head).
Reviewed By: #animation_rigging, #user_interface, Severin, Sybren
Differential Revision: https://developer.blender.org/D7685
|
|
Minor manual tweak to prevent wrapping an array into columns.
|
|
|
|
Define visibility error to be 1 by default to avoid undefined behaviour.
|
|
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.
|
|
Previously area lights were just considered as point lights.
We now use a "most representative point" technique that make the
light shape appearant and gives more homogenous result.
This technique is quite cheap but it is not physically correct.
So I came up with a power function to have almost the same intensity
output as cycles in the general case.
|
|
This makes volume lights more efficient if they have lower power.
|
|
Sun lights are treated as distant light source and need to gather
shadowing from the full frustum.
This might have performance impact on certain scenes.
|
|
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.
|
|
Caused by recent change for contact shadow raytracing. rB4e236326c137
|
|
Transforms in certain cases
This was caused by wrong flag checking in {rB278011e44d43}, which just
seems to be a copy-paste error.
For example, enabeling 'Auto-Offset' in the View menu would lead to CM
being ignored.
Maniphest Tasks: T86219
Differential Revision: https://developer.blender.org/D10751
|
|
|
|
This is because the refractive materials were using the deferred AO
computation instead of tracing their own.
|
|
This was cause by the change of some epsilon values for reflections.
This commit changes the planar reflection tracing to have correct
handling of parallel rays and discard any self intersection with normal
screen raytrace.
|
|
|
|
is hidden from the viewport
Check visibilty (as done in workbench_cache_populate) in
overlay_edit_uv_cache_populate as well.
Maniphest Tasks: T86542
Differential Revision: https://developer.blender.org/D10724
|
|
The shader was filtering everything but the selected color.
The fix inverts the check to make sure that color is selected.
Reviewed By: fclem
Maniphest Tasks: T86370
Differential Revision: https://developer.blender.org/D10670
|
|
Accumulate error caused by the low amount of integration slices and
correct it for the low roughness surfaces.
This increases light leak but it is less distracting than dark fringe
everywhere.
|
|
It is more straightforward to understand and is define in common file.
|
|
|
|
|
|
The shader was not using the horizon texture and was trying to
trace the AO again.
Also the depth reconstruction was off because now using the maxzBuffer.
|
|
This shader is of no use now that we the fullres hizbuffer.
|
|
Use the maxzbuffer to get the correct depth information.
|
|
This happens when the normal is too much deformed to give valid
reflection even after ensure_valid_reflection.
Cycles seems to not handle this case either so we just discard the
rays.
|
|
Simple divide by 0 error. The input radius was assumed to be safe
but is not when the user can scale it arbitrarly.
This also move the division out of the loop.
|
|
This fixes NaNs / blown up values when using alpha-hashed transparency
or alpha clip with SSS.
|
|
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.
|
|
This avoids going through geometry when ray have certain angle.
|
|
This make sure the rays are generated randomly from a fullres
texel center.
This creates more noise but increase the convergence when doing
half res tracing.
|
|
|
|
|
|
This split is to make code easier to manage and rename the files to
`effect_reflection_*` to avoid confusion.
Also this cleans up a bit of the branching mess in the trace shader.
|
|
|
|
|
|
|
|
This makes the hit delta threshold dependant on the ray angle.
If the ray is more aligned with the view, its intersection
threshold gets bigger to avoid going through geometry.
This improves reflections and fix T86448 refraction issue.
|
|
|
|
This was cause by a division by 0 if the ray direction had no
depth difference. Adding a small epsilon fix the issue.
|
|
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 sampling routine to use the method described in
"A Simpler and Exact Sampling Routine for the GGXDistribution of Visible Normals"
by Eric Heitz.
http://jcgt.org/published/0007/04/01/slides.pdf
This avoids generating bad rays and thus improve noise level in screen-
space reflections / refraction.
|
|
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.
|
|
|
|
No functional changes.
This function replaces some of the logic in
`DRW_select_buffer_find_nearest_to_point` that traverses a buffer in a
spiral way to search for a closer pixel (not the closest).
Differential Revision: https://developer.blender.org/D10548
|
|
with many objects
When you have many distinct objects, in an Eevee render then the shadow caster gets exponentially slower as the number of (distinct) objects increase.
This is because of the way that frontbuffer->bbox (EEVEE_BoundBox array) and the associated frontbuffer->update bitmap are resized.
Currently the resizing is done by reserving space for SH_CASTER_ALLOC_CHUNK (32) objects at a time.
When the number of objects is large, then the MEM_reallocN() gets progressively slower because it must memcpy the entire bbox/bitmap data to the new memory chunk.
And there will be a lot of *memcpy* operations for a large scene.
(Obviously there are a significant number of memory allocations/deallocations too - though this would be linear performance.)
I've switched to doubling the frontbuffer->alloc_count (buffer capacity) instead of adding SH_CASTER_ALLOC_CHUNK (32). As I understand this is the only way to eliminate exponential slowdown. Just increasing the size of SH_CASTER_ALLOC_CHUNK would still result in exponential slowdown eventually.
In other changes, the "+ 1" in this expression is not necessary.
if (id + 1 >= frontbuffer->alloc_count)
The buffer is 0-based. So when the buffer is initially allocated then id values from bbox[0] to bbox[31] are valid. Hence when frontbuffer->count == frontbuffer->alloc_count, is when the resizing should be triggered.
As it stands the "+ 1" results in resizing the buffer, when there is still capacity for one more object in the buffer.
I've changed the initial buffer allocation to use MEM_mallocN() instead of MEM_callocN(). The difference is that malloc() doesn't memset buffer (with zeros) when allocated. I've checked the code where new bbox records are created, and it does not rely on the buffer being initialised with zeros.
Anyway, isn't calloc() safer than using malloc()? Well no, it's actually the opposite in this case. Every time the buffer size is increased, it is done using realloc(), and this does not zero-out the uniniitialised portion of the buffer. So the code would break if it was modified to assume that the buffer contains zeros. Hence I believe initialising the buffer using calloc() could be misleading to a new developer.
Won't this result in increased memory usage? Yes, if you have millions of objects in your scene, then you are potentially using up-to twice the memory for the shadow caster. (However if you have millions of objects in your scene you're probably finding the Eevee render times a slow.)
Note that once the render gets going the frontbuffer bbox/bitmap will be shrunk to a multiple of SH_CASTER_ALLOC_CHUNK (32), therefore releasing the overallocation of memory.
As observed in Visual Studio - this appears to be prior to peak memory usage anyway.
Note this shrinking is executed in EEVEE_shadows_update() - during the first render sample pass. If necessary you could consider shrinking the buffer immediately after the EEVEE_shadows_caster_register() has done it's work. (Note however it appears you would need to add that function call is multiple places.)
Anyway as per the bug report I raised, I observed a 5% increase in peak-memory. And I'm unclear whether this difference in memory is due to me running the debug build. (It could be that there is no difference because of the shrinking.)
I couldn't figure out how the shadow caster backbuffer works. I see that EEVEE_shadows_init() has an explicit command to swap the front/back buffers. However this is done only when the buffers are first initialised and there is nothing in there yet. In my testing, the backbuffer->count was always zero, EEVEE_shadows_update() never did anything with the backbuffer.
Finally this problem is most evident when using Geometry Nodes or a Particle System to instantiate many objects. Objects created through say the array modifier do not cause any issues because it is considered one object by the shadow caster.
Reviewed By: #eevee_viewport, fclem
Differential Revision: https://developer.blender.org/D10631
|
|
This was due to the AO random sampling using the same "seed" as
the AA jitter. Decorelating the noise fixes the issue.
|