| Age | Commit message (Collapse) | Author |
|---|
|
World space and view space normals were mixed up, we should only convert from
world to view space if a custom normal is connected, otherwise it is already in
view space.
|
|
Changing the filepath wouldn't reload the font even after calling scene.update().
|
|
|
|
Also use SWAP macro
|
|
|
|
On changing, clear drawable window to force update.
|
|
is open"
This reverts commit fe7bab13439fe6f0181f6661fbf7bb7ae18f5310.
Setting correct context is important,
but this is setting DPI and widget unit on *every* mouse move.
|
|
Changing virtual pixelsize only had an affect when a second window was open. (Was also possible to trigger update by opening another window.)
Steps to reproduce:
* Change any editor into user preferences *in main window*
* Change virtual pixel size -> nothing happens
|
|
Basque one, grr).
|
|
Only applied in a really few cases actually.
To reproduce:
* Open User Preferences *in own window*
* Search for node wrangler add-on (it's one of the few cases where this happens)
* Enable and open details
* Click on one of the menues in the add-on preferences
Actually this was reproducable in any window, user preference area just had to take up most/all of the width.
Note: I'm not totally sure if just disabling these lines is correct, but I didn't find any issues or any information why this was needed. So it seems to be redundant.
|
|
Once a dupli had a valid bbox, that bbox would be used for all following objects
without bbox, instead of skipping clipping check.
Issue unveiled by rB3fa0a1a5bc0ff2, but not related at all (in fact, bug was present before that commit).
|
|
Many other places weren't clearing boundbox dirty flag after calculation.
|
|
|
|
Partially revert e29a5ba6
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
handle users own default startup files, among others...).
|
|
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
|
|
|
|
Useful for writing asset-libraries to a file, eg.
`bpy.data.libraries.write(filepath, datablocks, relative_remap=False, fake_user=False)`
|
|
Move to re-usable BKE_blendfile_write_partial API
|
|
|
|
|
|
find_package(Git) will already print this.
|
|
|
|
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
|
|
|
|
On first assignment the value was clamped, but successive assignments weren't.
|
|
|
|
|
|
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.
|
|
Never used keys and better reload in same order loaded.
|
|
'1mm+1m' would fail with original fix, now consuming all alpha chars before checking unit again...
|
|
Seriously...
|
|
`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.
|
|
Was caused by d49985c.
|
|
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.
|
