It is better to keep the profile as it is perpedicular
to the edge, and then project it onto a given plane
at the corners. Also fixed the interpolation to a
different number of segments when the profile is not
round.
Issue was in GP draw code: line thickness was not initiated properly (and a null one makes OGL draw a unity-width line).
Also tweaked threshold (when to start a new, width-different OGL linestrip), to make it inversaly proportional to thickness
(so that now, it's 0.2 for a thickness of 1, 0.1 for a thickness of 2, etc.), avoids too big steps when using large thickness.
Gives up to 15% speedup scenes with voronoi-based textures (up to 25% with volumes) on Haswell. The performance change for other CPUs is much smaller: 1-2%.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D203
This simply mimics code used for loopnormals, to enable py scripts to generate and access (temporary)
a tangent 3D vector and bitangent sign for each loop. Together with the split normals, this allow
to recreate a complete tangent space for normal mapping (bitangent = bitangent_sign * cross(normal, tangent)).
Expects all faces to be tri or quads.
Reviewed By: Brecht, campbellbarton
Differential Revision: https://developer.blender.org/D185
group default values.
This can happen when using value sliders for node group input values.
The localized copies were setting the "interface_type" runtime pointer
of the original tree to NULL instead of the new tree (which is created
on-the-fly in general). This type is used in RNA update functions
however, the original tree DNA should not be modified there.
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.
