Will document the new options in release notes, then in manual.
Still a bit of work to do on the bulging shape that appears
on cube corners if using arc inner miters, but will do that later.
Also need to do something smarter in clamp overlap.
Reported by @pepeland.
Adding missing events on the first point was breaking the guide behaviour.
Also, updated Ckey so it always defaults to Circular mode when guides are off.
Instead of doing manual ray-plane intersection we use normalized positions
of the grid mesh and apply scaling after interpolation so that we keep
good precision even at really far distances.
Precision is now two order of magnitude better and does not produce the
same kind of artifact at lower clip start values.
This commit also cleanup the implementation.
Fixes T58918 Grid not appearing correctly at low clip start in 2.8
Memfile undo isn't compatible with sculpt or edit-mode.
This didn't work in 2.7x, so best disable memfile undo for now in
situations where it's going to loose data or crash.
Before that only normal component was averaged, which is not
really correct.
Unfortunately, the new code is somewhat slower due to more
involved math to deal properly with non-quad faces, but the
plan is to move averaging from runtime to edit time, This
means, that mdisps will always be continuous around the edges
and no averaging on every frame change of animated character
will be needed.
Avoids nasty code all over where such math is required, and
compilers can easily deal with such situation.
Don't prefer questionable micro-optimization which comes with
a cost of nasty actual logic code.
The idea is to run reshaping for every boundary vertex
of a grid rather than trying to copy boundary grid
elements.
While this is somewhat slower, this avoids all this
tangent flipping magic, which tempts to be rather tricky
and fragile.
The boundary copy code was not dealing correct with flipping
tangent vectors, hence causing discontinuity in the final
positions.
Now we only copy boundaries for quads, where we know how to
deal with tangent vectors and where we know that this is
needed.
More clear solution could be to change the code in a way that
handles handles displacement grids of quads in the same way
as it's done for non-quad faces.
Use normal_quad_v3 instead of normal_tri_v3 and compute the mean of all
corner distance during frustum plane extraction.
Fix T58243 Flickering of viewport when rotating and zooming
Having clipping limit selection and tools is confusing when not visible.
Disable on load until it's supported
(doing this via ifdef's isn't practical).
Fixes T59580
While changing RGBA or color wheel didn't add undo steps,
HSV and Hex values did.
Disable undo for these button types since an undo push happens when
exiting the picker.
The problem here was that when a render result is allocated, the standard render passes are added according to the
pass bitfield. Then, when the render engine sets the result, it adds the additional passes which are then merged
into the main render result.
However, when using Save Buffers, the EXR is created before the actual render starts, so it's missing all those
additional passes.
To fix that, we need to query the render engine for a list of additional passes so they can be added before the EXR
is created. Luckily, there already is a function to do that for the node editor.
The same needs to be done when the EXR is loaded back.
Due to how that is implemented though (Render API calls into engine, engine calls back for each pass), if we have
multiple places that call this function there needs to be a way to tell which one the call came from in the pass
registration callback. Therefore, the original caller now provides a callback that is called for each pass.
Some of Eevee's Bloom defaults are not very good for physically based rendering. This patches addresses this issue.
This picture shows one of the problems with current default. Bloom looks very foggy:
{F6280495}
Even worse, light emitters much dimmer than the Sun can make everything equally hazy if Clamp is set to 1.0 and intensity to 0.8 (current default). Artists often forget to adjust Clamp value and do not know what value to use for realistic intensity. Also, currently both Clamp and Intensity do not have good UI ranges. This is why often Eevee renders end up very hazy and bloom often does not look right.
Bloom effect plays important role to help to distinguish between bright and relatively dim light sources. With current defaults this is broken because Clamp set to 1.0. Also, it cannot be disabled if set to 0 like expected. This patch fixes this and sets it to 0 by default. If users need to clamp, they can do so easily with UI range up to 1000. This range is good enough for most cases and provides enough precision to control lower values, and the highest value helps to limit bloom from the Sun if necessary and will leave untouched most other light emitters. If needed, much higher values for Clamp can be entered manually up to 100000. 10000 is still affects the Sun, but up to 100000 highest limit allows to clamp anything that is much brighter than the Sun if user needs to limit bloom in such cases (for example, bright explosion in the sky or anything else very bright).
I propose new default for bloom Intensity - 0.05 and UI range to suggests realistic values. Bloom Intensity > 0.1 is not realistic for clean lens but the user can enter manually much larger values if needed.
For comparison, here is a my own photo with and without bloom caused by the Sun (on second photo the Sun was occluded with an object).
{F6280500}
{F6280492}
In real life bloom is much more subtle and does not look hazy. If Clamp is disabled, then out of 0.1, 0.05 and 0.025 values I have tried, 0.05 looks most similar to the photo. Here is test render with and without bloom with the Sun in similar position like on the photo:
{F6280496}
{F6280494}
Using color probe 27x27 I compared lightness below the horizon under the Sun. In rendered by Eevee images lightness difference was 17. In case of the photos lightness difference in similar place was 11. I then compared leftmost spot (also below the horizon) and lightness difference was approximately 2 between two photos and 1 between rendered images. In other words, with these settings bloom effect is not too strong and is not too weak. Visually it may seem like decreasing bloom intensity may increase photorealism, but then bloom effect would be too localized even for the Sun.
Besides this single test, I tested in many other scenes as well, with and without the Sun, with different HDRIs, and as far as I can tell 0.05 intensity turned out to be good default - it produces bloom strong enough to be noticeable and not too hazy.
In Cycles shutter default value is 0.50, so for consistency set to 0.5 by default in Eevee too. Besides, 0.5 is typical standard for real cameras, and values higher than 0.5 usually are needed only if very strong motion blur is desired.
Here is summary of all changes:
Bloom Intensity: 0.8 > 0.05
Bloom Intensity UI range: 0-10 > 0-0.1
Bloom Clamp: 1.0 > 0.0 (disabled by default)
Bloom Clamp manual range: 0-1000 > 0-100000
Bloom Clamp UI range: 0-10 > 0-1000
Shutter: 1.0 > 0.5
This patch is related to the discussion in this thread, there are more examples of what bloom will look like with 0.05 intensity by me and others:
https://devtalk.blender.org/t/eevee-needs-to-have-physically-based-defaults/4700
Reviewers: fclem
Reviewed By: fclem
Subscribers: pablovazquez, billreynish, rboxman
Tags: #eevee
Differential Revision: https://developer.blender.org/D4212
This is in order to make the API more multithread friendly inside the
draw manager.
GPU_shader_get_uniform will only serve to query the shader interface and
not do any GL call, making it threadsafe.
For now it only print a warning if the uniform was not queried before.
While form a strict consistency point of view it could make sense to
return identity matrix for non-instance items, it can be very handy to
get that info (common to both instances and regular objects) directly in
all cases.
