The instance modifier needs to access the derived mesh data of the particle parent object to create stuff on the hairs, however the dm does not exist when the particle modifier is hidden. This is a general design problem: Objects accessing another object's derived mesh data is unsafe. For now it just checks valid dm pointer and uses identity transform if NULL.
Replace pseudo-LRU approach of determining which buffer
to remove when running out of space allowed for cache
with approach which would remove the frame which is most
far away from newly added frame.
This is still a bit tricky because it's impossible to
distinguish which frame to delete in situation of:
CCCC...CC
^
it's either user wants to extend left segment of cached
frames and buffers from right segment should be removed
or he wants to join this two segments and in that case
buffers from right segment should be removed.
Would need a bit more investigation which situation
is more common in general usecase.
Additional changes:
- Cleanup some memutil files (which are familiar to cache limiter)
- Add option to make moviecache verbose. If DEBUG_MESSAGES is
defined in moviecache.c detailed logs would be printed to the
console.
- Movie caches are now named which helps reading debug messages.
when specific circumstances are met.
Mainly issue was caused by checking ImBuf pointers, which used to fail
when some post-processing flags are changed. This was caused by the
fact that freeing old ImBuf and allocating new one could lead to new
ImBuf have the same pointer as previous one, which confuses cache.
There was some bad recursion introduced recently that caused crashes
when a Material node is the same material as the material itself (e.g.,
if Material.001 has a node with Material.001).
This commit attempt to correct this by keeping track of the material
at the root of the node tree, and doesn't recurse further if it
encounters it again within the nodetree.
Joshua, please review!
Forgot DNA needed stable names... :/ Correct spelling would involve keeping the old one for load code anyway, so better live with incorrect spelling here.
This creates a list of splines to be rasterized in nitExecution which
is being called from main thread. This should resolve possible threading
issues discovered in tomato branch.
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!!!
Added back face validation to BKE_mesh_validate_arrays.
This is needed because some addons (like OBJ importer) are reading
tessfaces and then converting them to ngons and validation of tessfaces
is needed before such a conversion.
Validation of faces would happen only if there's no polys in mesh.
When removing a skin or multires modifier, it skips deletion of the
associated CustomData layer if the object has any other modifiers of
that type. This check has been extended to all objects that use the
object's data.
Similarly, deleting higher multires levels and multires subdivision
will not update the maximum level of any other multires modifiers on
objects that link to the same mesh.
Note that modifier_apply_obdata() doesn't need any changes as it
does not allow applying to multi-user data.
Object joining has also been modified to synchronize multires levels
objects that share a mesh. This is needed because joining can
subdivide or delete levels in order to match the maximum level of the
join-from object to the join-to object.
Fixes bug [#31880] instance multiresolution modifier error.
http://projects.blender.org/tracker/index.php?func=detail&aid=31880&group_id=9&atid=498
Reviewed by Sergey:
http://codereview.appspot.com/6332047/
