### Description of the problem
Until now, it is only possible to correctly add a lightprobe in python via an operator:
`bpy.ops.object.lightprobe_add()`
### Description of the proposed solution
The idea of this patch is to fix the lack of consistency lightprobe creation without operator.
It allow creation of different lightprobe type directly via `bpy.data.lightprobes.new(name, type)` (such as for curves).
In order to make it possible I had to:
1. Add a function `BKE_lightprobe_configure` in charge of lightprobe settings configuration (avoid code redundancy)
2. Allow an object to take lightprobe datablock as data during is initialization.
### A short example of this patch usage
```
lp = bpy.data.lightprobes.new('some_name','PLANAR')
bpy.data.objects.new('toto', lp)
```
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D6396
There were some visual artifacts when the spin gizmo had a rotation
greater than 360 degrees.
Avoids this by drawing the arc over the span of one rotation only
and adjusting the background color based on the rotation count.
This way we remove the need for the srgb boolean uniform and a lot of code complexity. However, mesh update is going to be a bit slower.
I did not benchmark the performance impact.
This also fix a typo in draw_cache_impl_particles.c and fix hair not using vertex color in workbench.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D6610
This will make this consistent with the behaviour of other start/end
ranges in blender. So start/end will instead be adjusted to always
satisfy the "start >= end" requirement instead of clamping the values.
EEVEE Soft shadows were not rendered correctly during viewport
rendering. The reason for this is that during viewport rendering the
shadow buffers were only update once and not per sample. This resulted
that all the samples calculated the same shadow.
This fix moves the call to `EEVEE_shadows_update` from cache finished to
draw scene. This needs to happen before `EEVEE_lightprobes_refresh`.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D6538
There is a cornercase when the user edits an uvmap, that is not part of
the material (yet). When this is the case the uvmap was not added to the
uv buffer and the 'pos' alias was not created.
This change will always request the active uv map when uv editing.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D6534
Even though we build USD as static, it still feels the need to mark its
symbols with declspec(dllexport) which means the blender binary now exports
these symbols.
this patch fixes that unwanted behaviour, however USD libs still need to
rebuild before this becomes visible in the blender binary
Differential Revision: https://developer.blender.org/D6563
Reviewed By: sybren
Embree's local intersection routine was not prepared
for local intersections without per-object BVH.
Now it should be able to handle any kind of local
intersection, such as AO, bevel and SSS.
Differential Revision: https://developer.blender.org/D6602
UI
Seems like we need to set the error with the evaluated ModifierData.
Pass this to 'surfacedeformBind' and report with that.
Differential Revision: https://developer.blender.org/D6601
This integrates hair collisions with the new cloth collision system,
greatly improving reliability, and reducing the amount of hair-specific
code paths in the cloth code.
The removes all the point constraint based collision stuff, instead
implementing segment impulse based collisions, using the same collision
response code as the normal cloth solver.
The hair system can now also collide with the emitter if it is a
collision object.
Reviewed By: mano-wii, Sebastian Parborg
Differential Revision: https://developer.blender.org/D6545
This avoids the problem where Blender doesn't start because
the PYTHONPATH points to an incompatible Python version,
see T72807.
Previously we chose to assume people who set the PYTHONPATH know what
they're doing, however users may have set this for non Blender projects.
So it's not obvious that this is the cause of Blender not to launch
on their system.
To use Python's environment vars, pass the argument:
--python-use-system-env
Note that this only impacts Python run-time environment variables
documented in `python --help`, Access from `os.environ` remains.
Old pre 2.5 files may have had non active spaces stored that doen't have
a header. The 2.5 versioning only added headers for active spaces, not
inactive (so invisible) ones.
Newer versioning code assumed there to always be a header though.
Inserted a version patch to make sure there's always a header now.
Fixes error reported to Debian,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949035.
The last handle wasn't corrected, also, there is no reason
to flip the handles while sorting (checking the same handles many times)
move this into it's own loop.
It's not certain this fixes the issue since I can't reproduce the crash, but
the code was wrong in any case.
Thanks to Ray Molenkamp and Anonymous for finding this.
`ARegion.alignment` unfortunately is a mixture of value and bitflag
enumerations. When checking for left/right/top/bottom region alignment,
the flags have to be masked out usually.
Most of the fixed cases here probably didn't cause issues in practice,
but could in fact break at any point when surrounding logic changes.
In fact the assert in #region_visible_rect_calc() failed in an older
file from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949035. This
fixes it.
Outliner tree building code was not handling properly empty libraries
(i.e. Lib datablocks in our bmain which have no used actual data
anymore).
Main issue here is unclean states of indirect hierarchies of linking
involving several libraries after undo operation.
This is not a critical issue though, just annoying and untidy.
Just some rewording of the documentation of `Particle.uv_on_emitter()`,
so that it no longer refers to 'derived mesh' but 'evaluated mesh', and
document that it expects a modifier from an evaluated object.
No functional changes.
