From description, Use Coordinates evaluates the texture using
target coordinates in the local space of the force field object.
2D is supposed to ignore the Z coordinate. Thus one would assume
that if both are enabled, the force field effect would move with
the force field object, and Z would be 0.
However, instead first the 2D option projects points onto a plane
passing through the global zero and orthogonal to the local Z,
and only then the resulting point is transformed into local space.
Z is not locked at 0, so procedural textures like Spherical Blend
don't work as expected.
To fix this, apply local transform first, and then just clear Z if 2D.
Separate the creation of trees from EditMesh from the creation of trees from DerivedMesh.
This was meant to simplify the API, but didn't work out so well.
`bvhtree_from_mesh_*` actually is working as `bvhtree_from_derivedmesh_*`.
This is inconsistent with the trees created from EditMesh. Since for create them does not use the DerivedMesh.
In such cases the dm is being used only to cache the tree in the struct DerivedMesh. What is immediately released once
bvhtree is being used in functions that change(tag) the DM cleaning the cache.
- Use a filter function so users of SnapObjectContext can define how edit-mesh elements are handled.
- Remove em_evil.
- bvhtree of EditMesh is now really cached in the snap functions.
- Code becomes organized and easier to maintain.
This is an important patch for future improvements in snapping functions.
Own regression from rB019ce363b01bba0af, not totally sure why removing the heading
zero value in element_sum broke binary search distribution in random branch, but...
New code makes thing sooo much simpler, by simply getting rid of all zero-weight
items in element_sum (at the cost of adding a temporary extra index mapping array),
that way neither random nor 'even ordered' distribution code has to wory anymore
about skipping zero-weighted items!
Now CD_SHAPEKEY_INDEX customdata is stored in edit-mode when hooks and vertex parents are used.
This also fixes a bug where undo would loose key-index data.
Move to structs for BM_mesh_bm_to/from_me to avoid passing many argument, which mostly aren't used.
The issue was caused by missing indirect dependencies from other scenes in the
current scene depsgraph, which was causing some threading conflicts.
Not sure what would be ideal solution here, for now use stupid but rather robust
approach to solve that. Maybe there's something better to do here tho.
Annoying bug caused by temp nature of looptri layer for CCGDM.
Fixed in a similar to CCG loops by using lock when allocating and
filling looptri arrays.
Real fix would be to make sure this array is allocated on object
evaluation using DAG's eval_flag, but that's more involved change
which we'll work on later.
This is a follow-up fix for rBa10b2fe. The Action constraint uses a hackish
stub object and pose, which doesn't have a hash table for fast lookups.
This doesn't seem to be a big issue with the old depsgraph, but in the new
depsgraph it creates a large number of cache misses and significant slowdown,
possibly because of additional threading and less simple bone loops.
Normal Map node support for GLSL mode and the internal render (multiple tangents support).
The Normal Map node is a useful node which is present in the Cycles render.
It makes it possible to use normal mapping without additional material node in a node tree.
This patch implements Normal Map node for GLSL mode and the internal render.
Previously only the active UV layer was used to calculate tangents.
- 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.
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!
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.
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.
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.
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.
When non-random, particle distribution used a small start offset (to avoid
zero-weight faces), which is fine with "continuous" entities like faces, but not
for discrete ones like vertices - in that case it was generating some undesired
"jump" over a few verts in case step was small enough
(i.e. total number of verts/particles was big enough).
Point-cached particles (those using simulations) would not update at all outside of
first frame, due to PSYS_RECALC_RESET flag being ingnored in `system_step()`...
For some mysterious reasons, udate is still non-fully functional outside of startframe
(e.g. changing face distribution between random and jittered), but at least when choosing
'Vertices' you get particles from verts and not faces!
