Note: This still needs some copy-on-write magic to get the bone pointers
to get remapped properly (e.g. evaluated pose still refers to original
arm->bones, and arm->act_bone isn't getting remapped).
After copying animation data we need to re-map action, otherwise
our original DNA values will go out of symc, causing flickering
when tweaking values on animated node tree.
The idea is to re-use evaluated datablock from within current context.
This relies on the following factors:
- It expects scene to be fully evaluated before preview jobs starts.
- It expects datablocks to be localized.
The workaround removal was wrong, the whole id->adt of a local
copy is to be NULL.
But now instead of modifying original datablock, we tell library
manager to not copy animation data.
This was due to the background being drawn by a batch that had its VAO
generated in the windows "UI" context.
Since we use the DRW ogl context to draw the entire area, we have to
regenerate the VAO for thoses UI batches to be drawn correctly.
The actual weighting calculation is not smooth as the bone display.
The bone itself can be smooth for esthetic purpose but the distance display
should match the underlying weighting formula.
Past shader was too slow and had bad artifacts. This method is much simpler
and eficient and only exhibit some popping when the raidus of the head/tail
is changed.
We now use a more pleasant and efficient way to display enveloppe bones
and their radius.
For this we use a capsule geometry that is displaced (in the vertex shader)
to a signed distance field that represents the bone shape.
The bone distance radius are now drawn in 3D using a "pseudo-fresnel" effect.
This gives a better understanding of what is inside the radius of influence.
When capsules are not needed, we switch to default raytraced points.
The capsules are not distorded by the bone's matrix (same as their actual
influence radius) and are correctly displayed even with complex scaled
parents hierarchy.
Here is how it works:
We render a high poly disc that we orient & scale towards the camera so that
it covers the same pixel of the sphere it's supposed to represent.
Then the pixel shader raytrace the sphere (effectively starting from
the poly disc depth) and outputs the depth to gl_FragDepth.
This approach has many benefit:
- high quality obviously: per pixel accurate depth!
- compatible with MSAA: since the sphere horizon is delimited by polygons,
we get the coverage computed by the rasterizer. However we still gets
aliasing if the sphere intersect directly other meshes.
- virtually no overdraw: there is no backface to shade but we still get
overdraw because by little triangle [gpus rasterize pixel by groups of 4].
- allows early depth test: since the poly disc is set at the nearest depth
we can output, we can use GL_ARB_conservative_depth to enable early depth
test and discard pixels that are already behind geometry.
- can draw outline pretty easily without geometry shader.
This manually resolve the content of a multisample FB to a single sample FB.
It resolves color (combine the 2 framebuffers in a logical maner keeping
depth buffer occlusion etc..) instead of a plain glBlitFramebuffer copy.
Group all fetches together without interleived alu to let compiler optimize.
Also do the color samples only if needed.
Went from 3.86ms to [1.11-2.22]ms [min-max] for the 16samples resolve pass
on my nvidia card.
This shader is used instead of blitting back and forth to a single sample
buffer.
This means it resolves the color and depth samples and outputs a fragment
which can be depth tested and blended on top of an existing framebuffer.
We do static shader variation with manual loop unrolling for performance
reason. In my test I get 25% more perf with intel integrated gpu and 75%
performance gain with dedicated nvidia card compared to a single shader
with a uniform for sample count.
This fix the issue with the zfighting we were getting at bones edges.
Moreover, this enables us to render arbitrarly large outline with
varying thickness.
It's usefull in some scenario to tweak the specular intensity of a light
without modifying the diffuse contribution.
Cycles allows it via lamps material which we currently not support in Eevee.
This is a good workaround for now.
