Also this display is optimized. It does not use blending and pixel discard.
Working with scanned data should be more pleasant with this.
A better option would be to use gl_FragDepth to have a better sense of
volume but this discards early depth test.
This makes it possible for engines to ask for batches and only fill their
data after all engine populate functions have run.
This means that, when creating the batches data we already know all the
batches that are needed for this redraw and the needed data.
This allows for less redundant data preparation and better attrib masking.
Ideally, we should run all viewports populate function before executing
the batch construction but this is not the scope of this patch.
Conversion from the old request method will be progressive and both can
coexist (see uses of mesh_create_pos_and_nor()).
This is a small change. We delay all gl calls at the first use of the
GPUIndexBuf / GPUVertBuf in order to be able to create multiple buffers
from different threads without having many gl contexts.
Basically, armature update is not supposed to be run in edit mode.
This worked in master and new dependency graph because nobody was
tagging armature for an update.
But with all those copy-on-write and other things we can't ensure
tag doesn't happen (and we shouldn't). So now we ensure unwanted
code is not run from the code itself.
P.S. Deeper reason of this goes to the optimization of not updating
pose channels when in edit mode. Since pose doesn't define anything
there we don't want to be bothered with a pose update after every
operation which changes it.
Textures are now hooked up to the RESET operation of particle
settings, which ensures particles being re-distributed when
texture is changed.
This is limited to a direct user modifications, which matches
old behavior in 2.79.
Seriously... There is no point in having those subversions if one does
not take advantage of them to reduce doversion work on file load! Now we
have to raise subversion again just for that. :(
We cannot let those data be generated on-the-fly in RBW evaluation
anymore, since those would be added to CoW eval object and never ported
back to orig objects.
We *could* get orig objects in eval code, of course, but as in
constratints, this is not really threadsafe and future proof, depsgraph
evaluation should really write back to orig data as little as possible.
So instead, add code to ensure required data is generated to objects
when their collection is added to rigidbody world.
Note that we *may* want to clean that up once collection is no more used
by RB? On the other hand, people might want to keep those data around to
be able to switch between different setups easily... So think it's OK to
keep them at least for now.
There is no guarantee that object in rigidbody collection already have a
valid rgigidbody data when rebuilding deg relations, that is often
generated on-the-fly by actual rigid body simulation.
Note that this can be an issue when generating deg relations I guess...
But at least it won't crash anymore.
The issue here is that in the new dependency graph drivers are
individual nodes which depends on what they are driving. This
means that changes to RNA path or property index should ensure
those nodes are updated. Easiest way to do so is to tag relations
for update.
One issue that especially newer users often run into is that they accidentally reset changes to the scene by switching frame without creating a keyframe first.
Therefore, this commit adds a new color that is used to draw properties if their current value differs from the one that would be set when switching to this frame.
This works both for existing keyframes as well as for currently interpolated frames.
Unfortunately the flags in but->flag are full, so I had to move the new flag to but->drawflag and pass that to all relevant functions.
I went with orange for the color since afaics it fits with the green and yellow that are currently used for keyframe states and since it's somewhat reddish to signify that there might be something to look out for here.
Reviewers: campbellbarton, #user_interface, brecht
Reviewed By: campbellbarton
Subscribers: brecht, predoe
Differential Revision: https://developer.blender.org/D3949
This is for 2.80 (though bug I mistakenly merged into was for 2.78.
Duplicate bugs T58127, T58411, T58440, and T58789 all fixed.
Bevel weights and crease are not real Mesh layers so get lost
on coversion of mesh to bmesh unelss the mesh's cd_flag member
tells the converter to create layers for them.
Most code the copies or partially copies meshes uses
mesh_new_nomain_from_template_ex, so copied the flag there.