Age | Commit message (Collapse) | Author |
|
There were at least three copies of those:
- OB_RECALC* family of flags, which are rudiment of an old
dependency graph system.
- PSYS_RECALC* which were used by old dependency graph system
as a separate set since the graph itself did not handle
particle systems.
- DEG_TAG_* which was used to tag IDs.
Now there is a single set, which defines what can be tagged
and queried for an update. It also has some aggregate flags
to make queries simpler.
Lets once and for all solve the madness of those flags, stick
to a single set, which will not overlap with anything or require
any extra conversion.
Technically, shouldn't be measurable user difference, but some
of the agregate flags for few dependency graph components did
change.
Fixes T58632: Particle don't update rotation settings
|
|
We had two different ways of doing it, SurfaceDeform and LaplacianDeform
would do it through a special modifier stack evaluation triggered from
binding operator, while MeshDeform would do it through a regular
depsgraph update/eval (also triggered from its binding op).
This enforces the later to search back for orig modifier data inside
modifier code (to apply binding on that one, and not on useless CoW
one).
Besides the question of safety about modifying orig data from threaded
despgraph (that was *probably* OK, but think it's bad idea in general),
it's much better to have a common way of doing that kind of things.
For now it remains rather dodgy, but at least it's reasonably consistent
and safe now.
This commit also fixes a potential memleak from binding process of
MeshDeform, and does some general cleanup a bit.
|
|
thx @sergey for checking
|
|
Split basic object picking logic out into it's own function.
|
|
|
|
When the datablock was empty, the center was not calculated. Now it uses the object location.
|
|
|
|
|
|
|
|
|
|
|
|
See 481cdb08ed6f3
|
|
See previous commit for detail as why.
|
|
The shader is way simpler and run way faster on lower end hardware
(2x faster on intel HD5000) but did not notice any improvement on AMD Vega.
This also adds a few changes to the way the wireframes are drawn:
- the slider is more linearly progressive.
- optimize display shows all wires and progressively decrease "inner" wires
intensity. This is subject to change in the future.
- text/surface/metaballs support is pretty rough. More work needs to be done.
This remove the optimization introduced in f1975a46390a5bf85bb7012375f9bc1e761fc516.
This also removes the GPU side "sharpness" calculation which means that
animated meshes with wireframe display will update slower.
The CPU sharpness calculation has still room for optimization. Also
it is not excluded that GPU calculation can be added back as a
separate preprocessing pass (saving the computation result [compute or
feedback]).
The goal here was to have more speed for static objects and remove
the dependency of having buffer textures with triangle count. This is
preparation work for multithreading the whole DRW manager.
|
|
Some drivers accept shaders with only vertex stage, but some just silently
fails.
|
|
Right now does not add padding at the end of the buffer.
This seems not necessary but may cause problem on some platform. If needed
we will add this padding (only 2 more vertices).
|
|
|
|
|
|
|
|
Show folders and start in the users home.
|
|
Use messages instead of notifiers.
|
|
This reverts commit 892a104d2cc322cb042a687050dcce2403a971f3.
|
|
|
|
|
|
|
|
Using listener here, although I suspect we should be using message
subscriber only. That said, this mimics the behaviour of the buttons
main region.
As for the original bug report what was happening was that when
switching between viewlayers (or when creating one) we may not get the
same active object. So the context breadcrumbs are different.
And the bug itself was that we were missing a redraw on view layer
change.
|
|
Differential Revision: https://developer.blender.org/D4042
|
|
Aka all the thousand of reports duplicated here.
I should have seen this coming, since I had to add a hack in the first
place because things were "not working".
I should have figured out earlier that COW handles base in a really
special way, with its own special object_runtime_backup hack.
|
|
Differential Revision: https://developer.blender.org/D3926
|
|
Other software uses this to define UV islands, so we can't just merge
any UVs with the same coordinate. They have to share a vertex too.
Contributed by Maxime Robinot, with changes by me.
Differential Revision: https://developer.blender.org/D4006
|
|
|
|
Part of T58690
|
|
Without this, it might seem redundant since there is an option
to toggle armature object display.
|
|
Note this is not supported, there exists no geometry at this point, but
it should not crash at least.
|
|
|
|
|
|
Reviewers: brecht
Differential Revision: https://developer.blender.org/D4037
|
|
gpu_framebuffer_update_attachments_and_fill_empty_slots func
|
|
|
|
|
|
|
|
Dozens of renderes are included.
|
|
one case was missing in cleanup commit rB8fc6609cc008
|
|
Differential Revision: https://developer.blender.org/D4039
|
|
|
|
|
|
|
|
The idea is to reflect that the view settings are the best
for cases when one wants to see things as if they are a
render result.
|
|
This fixes our workaround for until proper solution is accepted
in upstream.
Now, when default view behaves same as it was supposed to (and
as it behaves in OCIO-1.0.9) it is obvious that our configuration
violates own design -- default view is used for cases when
images don't want to be displays using "render" settings.
|
|
|