| Age | Commit message (Collapse) | Author |
|---|
|
this patch resolves the following warnings;
```
Warning C4028 formal parameter 1 different from declaration blenkernel\intern\ocean.c 764
Warning C4098 'attach_stabilization_baseline_data': 'void' function returning a value blenkernel\intern\tracking_stabilize.c 139
Warning C4028 formal parameter 3 different from declaration blenkernel\intern\cachefile.c 148
Warning C4028 formal parameter 3 different from declaration blenkernel\intern\paint.c 413
Warning C4028 formal parameter 1 different from declaration blenkernel\intern\editderivedmesh.c 591
Warning C4028 formal parameter 3 different from declaration blenkernel\intern\library_remap.c 709
Warning C4028 formal parameter 1 different from declaration blenkernel\intern\ocean.c 754
Warning C4028 formal parameter 1 different from declaration blenkernel\intern\ocean.c 758
Warning C4028 formal parameter 1 different from declaration blenkernel\intern\ocean.c 759
Warning C4028 formal parameter 1 different from declaration blenkernel\intern\ocean.c 763
Warning C4028 formal parameter 1 different from declaration blenkernel\intern\ocean.c 764
Warning C4028 formal parameter 1 different from declaration blenkernel\intern\ocean.c 765
Warning C4028 formal parameter 1 different from declaration blenkernel\intern\ocean.c 769
Warning C4028 formal parameter 1 different from declaration blenkernel\intern\ocean.c 770
Warning C4028 formal parameter 1 different from declaration blenkernel\intern\DerivedMesh.c 3458
```
It's mostly things where the signature in the .h and the actual implementation in the .c do not match. And a bunch functions who do not match the TaskRunFunction declaration cause they leave out the __restrict keyword.
Reviewers: brecht, juicyfruit, sergey
Reviewed By: sergey
Subscribers: Blendify
Differential Revision: https://developer.blender.org/D2268
|
|
those flags were set!
Dummy mistake, to be backported to 2.78a.
|
|
Blender doesn't necessarily crash when Python doesn't keep references to
the returned strings. As a result, someone that implements this incorrectly
could be lulled into a false sense of correctness by Blender not crashing.
|
|
|
|
One day we'll have to reconsider why some many 'real' ID usages are not
refcounting... :(
To be backported to 2.78a.
|
|
Objects is enabled
Previously the editor will always try to only show UV faces with the same exact active
image or image texture, which is quite difficult to control on a production shaders, where
each material can have multiple objects assigned.
The idea of this commit is to bring option which allows to easily control what to display
when "Draw Other Objects" is enabled, so currently we can have old behavior ("Same Image")
or tell editor to show everything ("All"). In the future we can extend it with such filters
as "Same Material" and things like that.
Hopefully this will help @eyecandy's workflow of texturing.
|
|
the issue was caused by wrong default value for brush particle count
which was clamped on display from 0 to 1. This is technically a regression
but how to port this to 2.78a?
|
|
|
|
Couple of issues here:
* Missing initialization for 3D view keyframe options for "Reset to Default Theme"
* Alpha values not reset correctly on "Reset to Default Theme"
* Alpha values of timeline keyframe options not reset correctly for old files
Also corrected old version patches even though they're overridden later, to avoid more issues in case people copy this code.
Corrections to d7af7a1e04c243 and 8d573aa0ecb61
|
|
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D2304
|
|
These were only passed to own recursion calls.
|
|
Needed for outliner "Sequence" display mode.
|
|
|
|
|
|
|
|
Regression from rB69b66d549bcc8, was supposed to be non-functionnal
change, so not sure why search menu was reduced here? For now, restore
to 2.77 width.
|
|
zoom distance.
Allow for zooming in at max zoom distance.
Reviewed By: Severin
Differential Revision: https://developer.blender.org/D2291
|
|
Seems to be a bug in original implementation of a830280: code was always
using tangent space instead of UV map because it had the same name. Now
prefer UVMap over tangent because this is how Cycles works. At least it's
closer to.
Not sure it the save+reload issue is still relevant after this fix, that
needs to be double-checked.
Thanks @dfelinto for looking into the report and simplifying the case.
Should be included into 2.78a.
|
|
Such a "referenced proxy" could be a proxy that is used in a constraint on
another object. Brings back part of 1cdc54dc7db85766 but without the
memory leak.
|
|
|
|
|
|
This allows appending of an entire scene from another blend file into this one,
even when that blend file contains proxified armatures.
This replaces the approach from commit 1cdc54dc7db85766.
Thanks @sergey for the help.
|
|
Column flow layout was abuse ui_item_fit in a weird way, which was
broken for last column items.
Now rather use own code, which basically spread available width as
equally as possible between all columns.
|
|
Things are complicated enough like that, no need to add useless noise on
top of it!
|
|
|
|
|
|
input node.
|
|
Seems to be rounding error. Hopefully new code handles the error fixed back in
SVN revision 28901 and still have proper frame number for Hjalti.
What could possibly go wrong here..
|
|
|
|
|
|
constant key value
Technically it is a regression in behavior and should be 2.78a.
|
|
from scene
|
|
|
|
Original fix in this area was not really complete (but was the safest at
the release time). Now all the crazy configurations of slots going out
of sync should be handled here.
|
|
Flagging of pool to cancel was done in the wrong place, making last
frames missing in the final video.
|
|
It was possible to have two viewports opened and start using Ctrl-0
to make different objects an active camera for the viewport. This
worked fine for viewports which had decoupled camera from the scene,
but if viewport was locked to scene camera it was possible to run into
situation when two different viewports are locked to scene camera but
had different v3d->camera pointers.
|
|
Apparently, the whole G.is_break is not used by OpenGL render, meaning
this flag will not be clear before running the operator. This was
causing missing file output after pressing Esc once for the rest of
Blender session.
|
|
|
|
Reworked logic in the one place that still called this. Deleted the "GLSL not supported" fallback.
(equivalent to rB78abbdf26451 on blender2.8 branch)
|
|
Reworked logic in the few places that still called this. Deleted the "GLSL not supported" fallbacks.
Also removed some nearby checks for ARB_multitexture and OpenGL 1.1. Blender 2.77 removed checks like this, but game engine still has some.
|
|
in BI
Nice to have in 2.78a, though not a regression.
|
|
This code is confusing, such dirty details should not sneak out of
particles' own private code. :(
|
|
dangling to invalid value in read code...
|
|
|
|
We were checking for number of tasks from given pool already active, and
then atomically increasing it if allowed - this is not correct, number
could be increased by another thread between check and atomic op!
Atomic primitives are nice, but you must be very careful with *how* you
use them... Now we atomically increase counter, check result, and if we
end up over max value, abort and decrease counter again.
Spotted by Sergey, thanks!
|
|
Since the collision modifier cannot be disabled, it causes a constant
hit on the viewport animation playback FPS. Most of this overhead can
be automatically removed in the case when the collider is static.
The updates are only skipped when the collider was stationary during
the preceding update as well, so the state is stored in a field.
Knowing that the collider is static can also be used to disable similar
BVH updates for substeps in the actual cloth simulation code.
Differential Revision: https://developer.blender.org/D2277
|
|
Previously if the rendering is much faster than saving (for example,
when transcoding stuff via VSE) it was possible to have 100s of frames
in memory.
This isn't ideal because of limited amount of RAM, so need to have
some sort of limit. This is exactly what is implemented in this commit.
|
|
By the design of task scheduler it was possible that tasks from somewhere
in the middle of scheduled list will be handled first.
For example, one thread might be iterating over the scheduled list and
ignore tasks because there is other thread is working on task from the
same pool. However, if that other thread finishes task before iteration
is over current thread will pick up task from somewhere in in the middle
of the list.
This isn't a problem in general case, but for movie rendering we do need
to have strict order of frames.
|
|
|
|
|
