| Age | Commit message (Collapse) | Author |
|---|
|
This only make the edge fully selected. There is still no gradient like in
2.79 when only one vertex is selected.
|
|
This also do some renaming/cleanups.
|
|
|
|
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()).
|
|
|
|
|
|
|
|
The issue was caused mpoly array urequired by the cache filling,
but the pointer was never set when preparing render data.
Seems this change is safe enough, in terms it shouldn't be
causing slowdown, since the assignment of mpoly is cheap, but
hard to tell if there is anything else affected by thing underneath.
|
|
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
|
|
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.
|
|
|
|
Part of T58690
|
|
|
|
|
|
|
|
|
|
This is a very small improvement and only concerns wireframe update.
My tests.
old 6fps > new 7fps > baseline (wireframe disabled) 10fps
|
|
|
|
|
|
|
|
|
|
selected
|
|
|
|
|
|
Also optimize deferred engine by only outputing material data if needed.
This make the bare flat shading mode (no effects) only a depth prepass.
|
|
This seems to be a driver bug. Only windows + Radeon HD 7500M seems
to be affected. Fix can be extended to more config if necessary.
|
|
|
|
|
|
Since it seems that CD_ORIGINDEX is not available for loops,
the only choice is to simply use the loop normals already
computed by depsgraph after evaluating modifiers.
This revealed a bug where the Auto Smooth settings would be lost
from the mesh after complex modifiers, or after edit mesh to mesh
conversion, so restoring them is needed to get correct results.
|
|
I tried to make it progressive using the wireframe slide but it did not
work well.
So taking the most straight forward way.
|
|
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.
|
|
|
|
Use --debug-gpu for debugging non found uniforms
|
|
This reduces the bandwidth + vram usage of workbench even further.
|
|
We separate the background and foreground shading passes to be able to make
the object id pass optionnal if we don't need it.
This saves a bit more memory. Also not clearing all rendertargets saves
some GPU time too.
|
|
This is to be able to only draw the background pixels by using a depth
test EQUAL.
|
|
It is not used anymore
|
|
This was a bug that was making the grid drawing even more slower than it
is.
|
|
We exploit the fact that we are using the metallic workflow for material
and pass the metallic parameter instead of the specular color.
Pack the front facing bit in the color buffer only for matcap display.
Change buffer formats to use less bytes as possible.
Also don't request buffers that we won't use.
Saved 40MB on 2K screen on StudioLight + Shadows + Specular Lighting.
Includes several cleanups.
|
|
The particles was not ready when the drawing cache try to use it.
|
|
|
|
|
|
It happens on multiple configuration so we cannot isolate the fix to only
some config.
Thanks Hugo Lamarche for helping finding the fix.
|
|
|
|
|
|
Lower Vram usage a bit
|
|
The cause is that FOREACH_OBJECT_IN_MODE_BEGIN assumed that the active
object is in the correct mode, which is wrong in this case. It also
only considered objects of the same type as active, which had to be
replaced with an explicit type parameter.
|
