This function is more expansive than the simpler `rna_ensure_property()`
one, and should only be used when IDProperty data is actually needed.
If one only needs to ensure it has a valid PropertyRNA pointer,
`rna_ensure_property()` is much more efficient.
Also add compiler warnings when results of those functions are unused,
this should never be the case.
When using the sun, we need to sun sampling logic to avoid excessive
sampling map resolution, but that logic assumes that the Vector input
comes from the view direction.
That is the case in the vast majority of cases anyways, so the easiest
solution is to just remove the input for that case.
Differential Revision: https://developer.blender.org/D8091
For animation/driver purposes, being able to go outside of the 0-360
range makes things easier.
Differential Revision: https://developer.blender.org/D8091
The force node can now be used to control the behavior of particles.
Forces can access particles attributes. Currently, there are three attributes:
`Position` (vector), `Velocity` (vector) and `ID` (integer).
Supported nodes are: Math, Vector Math, Separate Vector, Combine Vector and Value.
Next, I'll have to split `simulation.cc` into multiple files and move
some stuff out of blenkernel into another folder.
Instead of using the mouse cursor position,
this selects between existing selected elements.
Access this since picking a selection path doesn't
work from the menu.
This is no longer used by default, when '--python-use-system-env' is set
there are many Python environment variables, don't list them in
Blender's help message.
- Remove the "mapping" subpanel and moves the source axis
selection ot the destination subpanel.
- Rename "Source" and "Destination" to "Map From" and "Map To" to
make the action more clear
- Gray out source axes when their data isn't selected.
These changes were discussed in D8041.
Performance is not great currently due to the API not seeming to support
efficient denoising of multiple tiles at the same time. So in many cases
only one or a few threads will actually be denoising at the same time.
In renders with many samples this is not a big problem, but for faster
renders it's a signficant overhead.
We should try to optimize this still, possibly by batching denoising of
a bigger neighborhood of multiple tiles at once.
