Until now, there was never any code for making drivers on materials get
recalculated when their dependencies were changed. However, since changing
material colors with drivers is something that is quite common, a workaround was
introduced to ensure that materials could still be driven (albeit with the
relevant drivers rooted at object level). This worked well enough so far with
traditional materials - though it was sometimes clunky and confusing for some
users - and would have been ok to tide us over until the depsgraph refactor.
The introduction of Cycles changed this, as it has in many other ways. Now that
people use Cycles to render, they'll need to drive the material colors through
the nested nodetree (and other things nested deeply within that). However, this
is much more difficult to generate hacks to create the relevant paths needed to
work around the problem.
== This Commit... ==
* Adds a recursive driver calculation step to the BKE_object_handle_update()
(which gets called whenever the depsgraph has finished tagging object datablocks
for updates), which goes through calculating the drivers attached to the object
(and the materials/nodetrees attached to that). This case gets handled everytime
the object is tagged as needing updates to its "data" (OB_RECALC_DATA)
* When building the depsgraph, every dependency that the drivers there have are
treated as if they were attached to object.data instead. This should trick the
depsgraph into tagging OB_RECALC_DATA to force recalculation of drivers, at the
expense perhaps of modifiers getting recalculated again.
== Todo ==
* The old workarounds noted are still in place (will be commented out in the
next commit). This fix renders at least the material case redundant, although
the textures case still needs a bit more work.
* Check on whether similar hacks can be done for other datablock combinations
* So far, only simple test cases have been tested. There is probably some
performance penalty for heavy setups still (due to need to traverse down all
parts of material/node hierarchy to find things that need updates). If there
really is a problem here, we could try introducing some tags to limit this
traversal (which get added at depsgraph build time). <--- USER TESTING
NEEDED!!!
In the file included with the bugreport, framerates were dropping from 60fps to
11fps for an armature with several lattices parented, and a 5fps drop everytime
an object was parented to the armature.
Upon (re-)inspection of the code, it became apparent that this was being caused
by a block of code that would recalculate the parent (perhaps recursively) as it
thought the parent state was for the wrong timestamp. However, the timestamps
this was using was never really updated (except for a single place, which set it
to a single fixed value to force recalculations to take place), which meant that
this branch was run all the time. AFACT, this is a remnant from some of the old
timeoffset stuff + pre-Depsgraph timestamping hacks that are no longer used/set.
===============================================
This patch adds a new "Character" BGE physics type which uses Bullet's btKinematicCharacter for simulation instead of full-blown dynamics. It is appropiate for (player-controlled) characters, for which the other physics types often result unexpected results (bouncing off walls, sliding etc.) and for which simple kinematics offers much more precision.
"Character" can be chosen like any other physics type in the "Physics" section of the properties window. Current settings for tweaking are "Step Height" (to make the object automatically climb small steps if it collides with them), "Fall Speed" (the maximum speed that the object can have when falling) and "Jump Speed", which is currently not used.
See http://projects.blender.org/tracker/?func=detail&atid=127&aid=28476&group_id=9
for sample blends and a discussion on the patch: how to use it and what influences the behavior of the character object.
Known problem: there is a crash if the "compound" option is set in the physics panel of the Character object.
* The operator creates bones for each input edge (does not subdivide
them like the skin operator does), adds a fake root bone for skin
roots with multiple children.
* The operator adds vertex weight groups to the original mesh.
* Make copy_object_transform() public, used to match the armature
object to the mesh object.
Skin modifier documentation:
http://wiki.blender.org/index.php/User:Nicholasbishop/SkinModifier
Most of the changes are related to adding support for motion data throughout
the code. There's some code for actual camera/object motion blur raytracing
but it's unfinished (it badly slows down the raytracing kernel even when the
option is turned off), so that code it disabled still.
Motion vector export from Blender tries to avoid computing derived meshes
when the mesh does not have a deforming modifier, and it also won't store
motion vectors for every vertex if only the object or camera is moving.
- Make sure functions are named in way BKE_<object>_<action> (same way as RNA callbacks)
- Make functions which are used by mball.c only static and remove their prototypes
from public header file.
Further cleanup is coming.
--debug
--debug-ffmpeg
--debug-python
--debug-events
--debug-wm
This makes debug output easier to read - event debug prints would flood output too much before.
For convenience:
--debug-all turns all debug flags on (works as --debug did before).
also removed some redundant whitespace in debug prints and prefix some prints with __func__ to give some context.
Was missed check for if modifier is available for particular object type
which ended up with unpredictable results when modifier which isn't supported
yet for some object type as linked to that object type.
