Main problem was in poly_rotate_plane() (which rotates a ngon to make its normal aligned with Z axis), it did not handled the case where the normal was aligned but opposite to the Z axis (which had the consequence that, as with the T mesh of the given blend, all tested new edges inside face were detected as outside, and vice-versa...).
Additionnaly, I made a mistake in previous Triangulate commit (r48243) in bm_face_goodline, which could allow a few invalid triangles in some specific cases, fixed!
And done a bit of cleanup, as I was at it.
The glViewport used for 2D Filters wasn't quite matching the 3d view. It seems the height and width were both off by one. There may be a deeper bug with the canvas rectangle having slightly wrong dimensions, but this at least fixes the 2D Filters.
1. first pass only fast nodes are calculated and only to the active
viewer node
2. second pass all nodes to all outputs
Temp disabled highlights because of random crashes.
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.
(From personal stash of bugs - since early 2.5 versions)
F-Curve colors get applied only on Graph Editor "refresh()". In some cases, undo
was reverting back to a state where the colors had not yet been set. In these
cases, there would be no refresh() after that undo (until expanding a channel or
some other similar action), resulting in "black F-Curves" appearing. So, now we
force such an update after undo to ensure that the curves never display black.
(Noticed while investigating another bug for Mango related to
CLIP_OT_constraint_to_fcurve not sending notifiers required when new F-Curves
are added)
* Elbeem exporter code now overrides user settings to No Slip in case the object is animated;
* UI of fluid obstacles now disables slip settings when export animated is enabled;
* Added in this later option's tooltip a mention that it enforces No Slip!
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!!!
