This is an important change. Starting from now, all lights have a finite
influence radius (similar to the old sphere option for BI).
In order to avoid costly setup time, this distance is first computed
automatically based on a light threshold. The distance is computed
at the light origin and using the inverse square falloff. The setting
can be found inside the render settings panel > shadow tab.
This light threshold does not take the light shape into account an may not
suit every case. That's why we provide a per lamp override where you can
just set the cutt off distance (Light Properties Panel > Light >
Custom Distance).
The influence distance is also used as shadow far clip distance.
This influence distance does not concerns sun lights that still have a
far clip distance.
---
This change is important because it makes it possible to cull lights
an improve performance drastically in the future.
I made an empirical test with a 100% diffuse sphere and manually tweak the
lighting power of a sun lamp trying to fit cycles and eevee the best I can.
Then I plotted the result and found a rough fit to the equation and that
seems to work pretty well.
The python getters for the array already allowed that, but not the
actual C RNA access functions. This is inconsistent, so implement
the fallback in all cases. Now if by default the property should
contain the same value in all positions, it is not necessary to
actually use an array.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D3940
We need to make sure that all the nested node trees are localized.
Because of this reason, we need to roll back to a bit older way
of dealing with materials.
Should be all safe now with the fixes from few moments ago.
Note: I didn't change the shortcuts, I think this is a separate decision
to be made. I just want at the moment to have the H operator to mimic
the upcoming popover.
Personally if we are to keep the 1-10 shortcuts (and they do work) I
think we should skip the excluded collections altogether.
In fact we could have an option to hide them from the outliner too.
I only specified the identifiers for the units that are actually accessible for now.
This way we can postpone some decisions for now. E.g. if it should be `METER_SQUARE`, `SQUARE_METER`, `METER_SQ`, ...
Reviewers: brecht
Differential Revision: https://developer.blender.org/D3945
Tssst… that piece of code should have been removed when we got rid of
bases here, kind of obvious it would break if object pointer itself is
NULL! And since deleting an object clears its ID pointers in outliner
tree, this fixes for free the issue of deleting several time the same
object (being selected in several collections at once).
Do early output when trying to add target relation with wrong rna_path.
We can't do anything reliably in that case anyway, so hopefully it is
a no-functional-change for artists, just avoids noisy error prints in
the terminal.
The constraint is supposed to automatically initialize the rest
length when it is first evaluated, so now that evaluation is done
on a separate copy it also has to copy the value to the master
instance - or newly created constraints will be broken.
Since this is supposed to happen once at constraint creation,
implementing as a search for now instead of adding new fields.
This finished old standing TODO which was attempting to
ignore objects of all invisible collections.
The difference here is that we remove invisible bases from
view layers. This guarantees that the evaluated state is
consistent and does not reference original objects.
Rig generators (e.g. rigify) use dummy drivers to attach extra
ID references to rigs for Append/Link. These references use
Single Property variables with empty path, which is intentionally
invalid and shouldn't produce low-level error logs from depsgraph.
The removed code would always print an error because RNAPathKey
requires a valid path to produce a non-NULL reference.
It appears that Python gets next item before using current one, which
would break our Depsgraph instance iterator (since only current item is
valid there, we use the same memory at each iteration).
Working around that with an ugly ping-pong game between two sets of
iterator data, so that previous one (C RNA-iterator-wise) remains valid
memory for Python to access to.
Logical flaw in `BKE_scene_objects_iterator_begin()` code (two errors
actually, wrong handling of first object of Master collection, and
missing call to `object_base_unique()` to 'register' that first object
and avoid getting it returned a second time).
Simply fixed by always calling `BKE_scene_objects_iterator_next()`
after minimal proper init, that one knows how to do the things. ;)
With the current implementation it only confuses logic around
checks like vewport/render subdivision levels.
If this mode is really needed for any decision making, implement
this properly.
Among all the lines moved around, the general idea is quite simple.
Actually, there are two ideas implemented there.
First one, is when object itself is tagged for update, we tag its
point cache component for evaluation, which makes it so point cache
is properly reset. We do it implicitly because otherwise we'll need
to go everywhere and add explicit tag in almost all the properties.
Second thing is, we link all collider and force fields to a point
cache component using special type of link. This type of link only
allows flush if change is caused by a user update. This way reset
does not happen when change is caused due to animation, but will
properly happen when user causes indirect change to the objects
which are part of physics simulation.
