Early implementation. Slow and still has quality
3 ways of storing irradiance:
- Spherical Harmonics: Have problem with directionnal lighting.
- HL2 diffuse cube: Very low resolution but smooth transitions.
- Diffuse cube: High storage requirement.
Also include some name change.
Noisy change, but safe, and better do it sooner than later if we are to
rework copying code. Also, previous commit shows this *is* useful to
catch some mistakes.
This is similar to some other datablocks. Mainly applies to collections,
so freeing scene does not involve changing any non-directly owned data.
There are two main usecases foreseen for the future:
- Less CPU ticks on bmain free, where everything is freed anyway and
there is no need to preserve id counters.
- Easier freeing of temporary data, including data which is used by
depsgraph's copy-on-write mechanism.
Neither of those are currently implemented, but will be shortly.
New implementation of hair for Eevee.
Note: A hard coded "transmission" property is being used. This should
eventually be exposed to the UI, possibly in the form of SSS
properties.
This stops the memory breakage caused by the material preview jobs,
to enable the new hair drawing implementation.
(This should be reverted once T51796 is actually fixed!)
Avoids using copy-constructor invoked every time we pass function
to the builder functions.
Should lower number of CPU ticks spent during DEG construction.
Was rather weird and only used for time source. It is simpler to make depsgraph
to keep track of time source directly.
No need to introduce extra entitites without actual need.
There is no reason to be special for workspace and go against other design
decision in Blender. If something like this is going to become a common
practice in Blender it should be well thought and well tested, including
tests of all supported compilers and configurations.
This feature was relying on type re-definition, which is not only confusing
but also available in C11 only.
I considered just copying the evaluated data from the LayerCollection.
However we need to run the evaluation so Depsgraph can handle overrides.
I will double-check with Sergey Sharybin.
We need to traverse the same exact objects for both nodes and relationship
builder. We were using FOREACH_SCENE_OBJECT for relationships, which
would lead to plenty of warnings in multiple situations.
In the future we will need to change this to build the depsgraph
relations and nodes to one single render_layer.
Fix T51780: If an object is in two collections and I do a full copy of
scene things go bad
