This was (more or less) OK with hand-drawn strokes, as the number of points made it nearly unoticable, but broke completely with line and poly strokes!
Did this when I implemented linked curve feature because it was easier! Now, convert code always adds a heading and trailing point to the curve,
to get initial/final zero radius. Adds even more complexity to those functions... :/
DAG node tagging was rather an experiment to make derived render working.
However, it ended up in a whole can of worms and need to be re-considered.
It is likely that regular object update tagging and scene update routines
are to be used for this.
Meanwhile no need to keep extra field in dag node. Would save us the whole
byte of the struct which we can use for other purposes meanwhile.
Issue was introduced in a2bf25e and was caused by
do_makeDispListCurveTypes() no longer placing nurbs
to cu->nurb list.
Such an operation isn't thread-safe and proper solution
would require having granular update. For until them
just make object conversion take care of filling cu->nurb
in with splines from font.
When trying to scale bones in EditMode and the bones were drawn using envelope display mode,
this resulted in the joint radii (i.e. the inner part of envelopes) being adjusted instead.
It turns out that this was due to an old hack that was put in place back in 2.4x (see the
tracker logs for full details of the problem here).
This commit introduces the following fixes:
1) Removed the old hack. Scaling (S) works normally now.
2) Ctrl-Alt-S (i.e. "Scale Envelopes/BBones") is as-is.
That is, it is used to adjust the size falloff-region around a bone
(i.e. the "dist" property)
3) Added Alt-S hotkey in EditMode for armatures for adjusting the radii of bones.
This change just means that the "TFM_BONE_ENVELOPE" mode is now able to be
accessed from the UI as a tool on its own right (instead of being accessible
via the old undocumented hack). This tool adjusts the radii of the bone joints,
which define the actual full-influence region of the envelopes.
Issue is causes by vertex parent modifies original BMesh from
a multiple threads. Ideally this is to be done as a separate
update callback for mesh datablock, but it's not so much simple
now (would need to do some re-arranges to DAG which might conflict
with the work from Ali or will double amount of work we did).
So for now use simple solution with mutex lock.
Based on the patch from Campbell Barton with some fixes to make
changes really thread-safe.
Differential Revision: https://developer.blender.org/D168
to previous sculpt fix (OpenGL access from thread with no context
bound). The fact that this has gone unnoticed so far means that people
are dyntopoing like crazy these days.
It doesn't make any sense anymore with the current depsgraph and probably was
not useful for a long time, just a leftover from the pre 2.04 game engine.
Due to float precision issues it was basically random which of the two was used,
now it's slightly biased towards 128, which is the convention for flat colors.
The small difference between 127 and 128 could give problems with sharp glossy
shaders where it would be visible as seams.
When yiz insert a keyframe (on a location keying set f.e.) in the 3D-view and you got an action editor open then the action datablock is not changed (displaying only the button "new") until you hover the action editor with the mouse.
Added a handler in the action_header_area_listener to handle this case
If non-obvious, some technical note about what the cause of the bug was and
how it was solved.
Expose float precision helper in UI_interface.h API, so that numinput can use this helper as numbuttons already do.
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D186
Parameter controls concavity / convexity.
<.25 means: concave inward
.25 means: straight slanted
>.25 means: concave outward
.5 means: circular (the default)
1 means: straight along original sides
For now, there is a hard lower limit of .15
because more work is needed to get decent
results in the range below that.
The profile is actually a superellipse, and the
parameter is 1/4 of the exponent in the implicit equation
for a superellipse, except at the extreme values of 0 and 1.
to exist and accessed without prior NULL checks (with exception of
get_next_frame and get_movie_path). The callbacks are not reliably
initialized however if none of the video formats is enabled (AVI being
the default). Added stub functions now that ensure access to
bMovieHandle callbacks is safe and doesn't crash.
This is done by adding a Volume Scatter node. In many cases you will want to
add together a Volume Absorption and Volume Scatter node with the same color
and density to get the expected results.
This should work with branched path tracing, mixing closures, overlapping
volumes, etc. However there's still various optimizations needed for sampling.
The main missing thing from the volume branch is the equiangular sampling for
homogeneous volumes.
The heterogeneous scattering code was arranged such that we can use a single
stratified random number for distance sampling, which gives less noise than
pseudo random numbers for each step. For volumes where the color is textured
there still seems to be something off, needs to be investigated.
* Now only middle-clip when both left and right parts of remaining strings are at least two times icon-width (thus most short labels will never be middle-clipped).
* Add a trailing ellipsis to right-clipped strings (unless it would take more than 20% of whole available width, in this case just clip chars, to keep as much data visible as possible!).
The sanity check for copying socket default value was using the socket
idname for type compatibility checks, which is too strict. Subtypes
would not be recognized as copyable, but since only the plain data type
is needed below this is all that needs to be checked.
That alone would not cause crash (just missing default value copy),
but the tree view template was messing with the default_value DNA
directly by freeing it in advance, which is not necessary and should
be left to blenkernel when freeing the node. Otherwise this would
leave the node invalid without a default_value if the copy function
bails out.
In separating out the adj mesh change from a profile change,
I'd forgotten that some profiles need to be flat (in particular,
for vertex-only bevels). This fixes that.
This gets rid of a hacky way of setting the mesh
coordinates at corners, which created overlaps
in some cases.
Also, special case a cube-like corner with all
edges beveled, to snap to a sphere, giving more
expected curvature in that case.
