Simple solution is to get rid of this stupid `rna_TextureSlot_brush_update` func, and do what it was doing directly
in BR case of `rna_TextureSlot_update`. That way, all updates to brush texture will invalidate correctly the overlay.
Note that this double definition of texture pointer for brushes looks rather fishy, am really not convinced this helps
keeping things simple and clear at all (what happened here is that texture selector in image paint editor was using
'texture' member of brush itself, which was performing correct RNA update, while context-based brush texture selector
from buttons space was using 'texture' member of the TextureSlot struct, which had default texture update callback
which was not invalidating overlay).
- Access with Shift-LMB or from the 'Create' toolbar tab.
- Uses curve fitting for bezier curves, with error and corner angle options.
- Optional tablet pressure to curve radius mapping.
- Depth can use the cursor or optionally draw onto the surface,
for the entire stroke or using the stroke start.
- Stroke plane can optionally be perpendicular to, or aligned to the surface normal.
- Optional radius tapering and for start/end points.
- Supports operator redo and calling from Python.
Similar to velocity, it was kind of supported by the mesh manager but
was missing a code in BlenderSession to get actual values.
In Cycles Heat is an attribute which goes from -1 to 1, where -1 is
the coldest ever temperature, 1 is the hottest ever one.
This was a feature request from a few years back (IIRC from ZanQdo?) to make it
easier to reuse one set of driver variables across several different drivers.
Dev Notes:
* Finally it's done! All that trouble for two little buttons.
* Grr... cmake... grrr!
* Use an RNA enum callback for NLA FModifier types too
* Cleaned up tooltips for these operators in Graph and NLA editors
* Fix update notifiers after adding FModifiers in the Graph Editor
This brings the UI here more in line with the Constraints and Modifiers UI's.
TODO:
* The tooltips/descriptions on the operators now need fixing, as we can no longer
use custom tooltips when defining these buttons.
* The operators need to be fixed to only operate on the active data
This change means that when going from having no FCurves active to having
an active FCurve, the properties panels will not get stuck with only showing
the "View" tab, which is not that useful a lot of the time.
This is a regression since 4310128 which is cased by really bad logic:
there might be dependencies between dupli-objects, which means _if_ we
really want to ensure derived mesh on dupli creation we have to do it
before any matrix is overwritten.
I'm not sure if such derived mesh trick is really the only way to go
without major refactor, but seems simple fix for now will do it.
This prevents twisted quads from self-intersecting.
This change makes the duplicate surface match the first vertex in the face,
so the diagonal indices match in the face copy.
Previous fix made another issue even more visible, leading to +1 particle on first vert
and none on last one. This commit should fix both original and new issues.
The patch contains an implementation of the wide lines and the line stipple that is necessary for OpenGL upgrade.
For the implementation I have chosen the geometry shader because it required minimum changes for the wrapper calls and such implementation is the best for the "basic shader" architecture.
There are few shortcomings that can be corrected in future. They all are related to the fact that the lines in one strip are not connected with each other. So the stipple pattern is not continuous on the common vertex of two lines. There is also no continuity of form (each line is an independent rectangular).
But the advantage is that even outdated glBegin, glVertex work! Though with the above restrictions.
Continuity of form and stipple can be implemented with additional attributes, and it will require more changes in calls.
At the moment, the patch replaces calls for some "gestures". It works satisfactorily for "cross" or "rectangular" and not so good for "lasso" and "circle" due to the above-mentioned shortcomings.
Don't forget to set USE_GLSL to true for testing.
Alexander Romanov (Blend4Web Team)
Reviewers: merwin, brecht
Reviewed By: merwin, brecht
Subscribers: aligorith, Evgeny_Rodygin, AlexKowel, yurikovelenov
Differential Revision: https://developer.blender.org/D1880
This patch depends on D1747, which upgrades the Recast version. It exposes the new Recast partitioning methods in the navmesh generation.
Reviewers: campbellbarton, moguri
Reviewed By: moguri
Projects: #bf_blender
Differential Revision: https://developer.blender.org/D1748
The version of Recast that Blender ships with is from 2009. This patch updates the Recast version to the latest version, 1.5.0. The Detour version remains untouched.
Reviewers: campbellbarton, moguri
Reviewed By: moguri
Projects: #bf_blender
Differential Revision: https://developer.blender.org/D1747
The addressed issue is a regression from Blender 2.75, after the internal
switch from double to single precision floating-point numbers in the
Freestyle code base. Face normal calculations require the higher
precision during the computations, even though the results can be stored
as single precision numbers.
Support for driver variables that don't resolve to numbers, eg:
objects, bones, curves... etc.
Without this, Python expressions to access this data needed to use an absolute path from `bpy.data`,
however this is inconvenient, breaks easily (based on naming) and wouldn't set the dependencies correctly.
This fixes reported issue, but there could be more of those hidden in Freestyle code,
it did not handle user refcount at all (and the fact it by-passes BKE in some places
for efficiency does not help here).
Note that this should be relatively harmless, since freestyle uses own Main during
render, so everything is cleaned up in the end in any case... But better try to
handle IDs correctly here too. :)
Note that we may want to review that some day, we have quite a bit of ID types here that are
'blend file' view only, might be worth splitting the check based on this.
That might consider a bit more objects to be considered deform modified,
but it covers common case of using taper object without require of doing
recursive checks.
In worst case it'll be just some extra synchronization time, no render
time difference will happen for false-positive because of extra checks
happening in Cycles.
