The idea is to give a control over direction of twist, and maybe amount of
twist as well. More concrete example: make braids on left and right side of
character head to be twisting opposite directions.
Now, tricky part: we need some negative values to flip direction, but weights
can not be negative. So we use same trick as displacement map and tangent normal
maps, where 0.5 is neutral, values below 0.5 are considered negative and values
above 0.5 are considered positive.
It allows to have children hair to be twisted around parent curve, which is
quite an essential feature when creating hair braids.
There are currently two controls:
- Number of turns around parent children.
- Influence curve, which allows to modify "twistness" along the strand.
This isn't supported since there are subsequent reads to all point coordinates
after modification started.
Probably we need to create a temp copy of point, but that's like extra CPU
ticks.
It seems to be useful still in cases where the particle are distributed in
a particular order or pattern, to colorize them along with that. This isn't
really well defined, but might as well avoid breaking backwards compatibility
for now.
This is like the only way to add variety to hair which is created
using simple children. Used here for the hair.
Maybe not ideal, but the time will show.
Burley SSS uses a bit of strange thing where the albedo and closure weight are
different, which makes the subsurface color act a bit like a subsurface radius
indirectly by the way the Burley SSS profile works.
This can't work for random walk SSS though, and it's not clear to me that this
is actually a good idea since it's really the subsurface radius that is supposed
to control this. For now I'll leave Burley SSS working the same to not break
backwards compatibility.
This can be very slow if it contains a big texture, and it's not
necessarily setup in a useful way anyway, and materials can be used
in multiple scenes.
It is basically brute force volume scattering within the mesh, but part
of the SSS code for faster performance. The main difference with actual
volume scattering is that we assume the boundaries are diffuse and that
all lighting is coming through this boundary from outside the volume.
This gives much more accurate results for thin features and low density.
Some challenges remain however:
* Significantly more noisy than BSSRDF. Adding Dwivedi sampling may help
here, but it's unclear still how much it helps in real world cases.
* Due to this being a volumetric method, geometry like eyes or mouth can
darken the skin on the outside. We may be able to reduce this effect,
or users can compensate for it by reducing the scattering radius in
such areas.
* Sharp corners are quite bright. This matches actual volume rendering
and results in some other renderers, but maybe not so much real world
objects.
Differential Revision: https://developer.blender.org/D3054
Looks like there was no way to avoid that so far, since
WM_event_add_timer_notifier can set mere int-in-pointer there, this can
cause issues. So added mere flags system to wmTimer to allow
controlling this.
Instead of calling an operator I just call `collection.new()`. Moving the
code into a separate function also simplifies it. In its new form there is
also no undefined behaviour when me.vertex_colors is non-empty but without
active layer.
- normalize → average the vector: the vector isn't normalized here, because
it doesn't necessarily becomes unit length. Instead, the sum is converted
to an average vector.
- angle is the acos()…: the dot product between the vertex normal and the
average direction of the connected vertices is computed, and not the
opposite.
- The initial `con` list was discarded immediately and replaced by a new
list.
- File didn't end with a newline.
We've got quite comprehensive BMesh based implementation, which is way easier
for maintenance than abandoned Carve library.
After all the time BMesh implementation was working on the same level of
limitations about manifold meshes and touching edges than Carve. Is better
to focus on maintaining one boolean implementation now.
Reviewers: campbellbarton
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D3050
Previously quads always split along first-third vertices.
This is still the default, to avoid flickering with animated deformation
however concave quads that would create two opposing triangles now use
second-fourth split.
Reported as T53999 although this issue has been known limitation
for a long time.
