Object visibility is now handled by the depsgraph iterator, but this API
was incomplete as it made no distinction for visibility of the object itself,
particles and generated instances.
The depsgraph iterator API now includes information about which part of the
object is visible, and this is used by Cycles to replace the old custom logic.
Cycles and EEVEE visibility should now be consistent, which unfortunately does
means some subtle compatibility breakage for both.
Fixes T58956, T58202, T59284.
Differential Revision: https://developer.blender.org/D4109
This commit makes it so curve path parent solving accepts an explicit
arguments for both time and curve speed flag, making it so we don't
have to mock around with scene's frame.
One unfortunate issue still is that if the instancing object is used
for something else, we might be running into a threading conflict.
Possible solution would be to create a temp copy of an object, but
then it will be an issue of preventing drivers from modifying other
datablocks.
At least the original issue is fixed now, and things behave same as
in older Blender version. Additionally, the global variable which
was defining curve speed flag behavior is gone now!
This now only upload data per loops to the GPU, making use of index buffer
to draw polygon. This make use of the vertex cache, speed up renders
and saves a lot of vram.
Update performance is also slightly faster and can even be improved further
by updating only uvs or vcol independently.
This commits breaks texture paint batches. It will be added back in another
commit.
Shaded triangles are not yet implemented (request from gpumaterials).
This also changes the mechanism to draw curve normals to make it not
dependant on normal size display. This way different viewport can
reuse the same batch.
this can be different though (e.g. vertex parenting) and correct location
is already stored in ob->orig
spotted while looking into T59332
Reviewers: fclem, brecht
Differential Revision: https://developer.blender.org/D4076
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.
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 f1975a4639.
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.
This only happens after a certain wireframe threshold.
We sort triangles into 2 bins (start and end of the buffer) based on a
threshold and just draw the first bin if the wireframe slider is low enough.
This optimization is disabled for deformed meshes when playback is active.
This optimization is only implemented for meshes object for now.
This should help resolve (to some extent) T58188.
This only happens after a certain threshold.
We sort triangles into 2 bins (start and end of the buffer) based on a
threshold and just draw the start bin if the wireframe slider is low enough.
This optimization is disabled for deformed meshes.
This should help resolve (to some extent) T58188.
The original offset was wrong because it applied a constant to
homogenous coordinates (the actual depth is z/w), which broke
totally if near clip distance was reduced.
A correct depth offset has to take slope into account like
glPolygonOffset in order to avoid dotted lines caused by
interpolation precision variations. When drawing wire lines
however only the slope of the line itself is accessible, so
also generally increase the offset when the object is close.
