Current startup .blend has old (percent?) values for particle brush strength.
Since rBe4e21480d6331903c90ab073746484498441e1ac, UI controls do not clamp automatically values anymore,
which means when you first enable comb (or any other brush) you get a 50 strength, waaaayyyy to powerful.
This commit fixes this in `BLO_update_defaults_startup_blend`, note that it does not fix custom users'
startup files, nothing to do here...
Handling `me` data here is not good idea anyway, we override it completly with data
from `tmp` (crash came from freeing already existing bb from me, while pointer still existed in tmp).
(rediscovered it while working on T47676...).
To be backported to 2.77.
Image filter was not set, but only if invoked from toolbar (image strip needs to be selected to see the button).
Caused by rB7fa72b8970, Wasn't aware there's another button for this for image strips.
Quite trivial idea -- just pass tread ID to the texture sampling function.
Implemented as a TLS to avoid passing huge amount of extra contexts around.
Should be working on all platforms, but compilation test is required.
Reviewers: juicyfruit, campbellbarton
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D1831
It'll be nice to eventually go C11/C++11 by default, but for until
then it's kinda handy to be able to build locally with C11 support,
Reviewers: mont29, campbellbarton
Reviewed By: mont29, campbellbarton
Differential Revision: https://developer.blender.org/D1752
Note that we could increase to 524286 without loosing subframe precision,
however this is a round number allowing for longer video export / animations.
See T46859 for details.
`m` unit when used after `cm`/`mm`/etc. ones would get ignored, and the alt version of miles
would be used instead.
The root of the issue is that, in `unit_find_str`, once we get a 'hit' for a unit, we check
it's actual unit (since 'm' would also hit on 'cm', 'mm', etc.). In case that hit is not a
valid unit one, we would just return NULL, breaking the cycle of checks over that unit, and
hence missing all later usages of it.
So now, in case we have an 'invalid unit hit', we immediately retry to find it within remaining string.
This was we don't have re-compo or viewport re-rendering happening when changing
nodes which are not connected to the output at all (for example when adding new
nodes or changing settings for unconnected nodes).
Only basic operations are covered for now. checks could be added to more tools
when needed.
Currently it's not fully optimal implementation, but seems to work fast enough.
Don't see reliable alternative to that -- keeping tag in the node wouldn't work
because of the node groups (which are probably already broken, but should be
easy to solve with current approach). So guess it's more matter of optimizing
path search from a node to output.
Before processing forward let's check whether it's indeed something we want
and whether the approach is indeed not fully bad.
Reviewers: campbellbarton, mont29
Subscribers: sebastian_k
Differential Revision: https://developer.blender.org/D1765
Pointers of faces were passed as face keys during parametrizer's face creation. Since those
addresses were different for every run, the layout of the faces ended up being different
in the internal hash, leading to inconsistent order of their evaluation during LSCM solving,
and slightly different UV maps.
Solved by simply using faces' indices as key instead, which ensures we always get same results
with exact same input data now.
Many thanks to Roman Nagornov (RomanN) for raising the issue, investigating it and finding
the solution! And thanks to Brecht for quick review too.
The issue was caused by some code accessing R from a functions which
are marked as safe for use from outside of render pipeline.
Now those functions are safe(er) for use.
This is an alternative to passing a copy callback which is some times inconvenient.
Instead the caller can write to the key - needed when the key is duplicated memory.
Allows for minor optimization in ghash/gset use.
Also add BLI_gset_ensure_p_ex
Code was using degrees as radians.
Still unclear why default cube will have 180 degrees angle, but new meshes 30,
but that's kinda separate topic which is to be addressed separately.
This is a subject for final 2.77 release.
See rB935e241fa6ea095493 for details of the issue, but first fix caused regression T47632.
So for now handling the issue in a localized way, this is not a real solution (since this could happen
in other cases), but will do for 2.77.
This commit is to be backported to 2.77.
