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.
Now they are properly converted to Linear space before interpolation.
Since the only way to get vertex color in eevee and cycles is via the
attribute node with the CD_AUTO_FROM_NAME flag, we have to know at binding
time which type of buffer will be connected to this auto input.
We store this information inside the batch cache (together with the according
uniform name) and pass it as uniform to the shader which does conversion if
needed. The same shader can then be reused to draw another mesh with
different auto layers configuration.
The way how particle state is to be accessed or used did not change
in Blender 2.8, so the drawing code should follow old design.
This code is somewhat duplicated from drawobject.c, but old draw
code is on the way to be removed anyway.
This fixes issue with disappearing particles when tweaking number
of particles.
This separate context allows two things:
- It allows viewports in multi-windows configuration.
- F12 render can use this context in a separate thread and do a non-blocking render.
The downside is that the context cannot be used while rendering so a request to refresh a viewport will lock the UI. This is something that will be adressed in the future.
Under the hood what does that mean:
- Not adding more mess with VAOs management in gawain.
- Doing depth only draw for operators / selection needs to be done in an offscreen buffer.
- The 3D cursor "autodis" operator is still reading the backbuffer so we need to copy the result to it.
- All FBOs needed by the drawmanager must to be created/destroyed with its context active.
- We cannot use batches created for UI in the DRW context and vice-versa. There is a clear separation of resources that enables the use of safe multi-threading.
Read from the GPUMaterial to find custom-data layers used for drawing.
This resolves problem where having UV's would always calculate tangents
causing noticeable slow down compared to 2.7x.
This still has a couple of issues:
* Instancing is not working when multiple particle systems use the same
primitive. Only the last particle system to be drawn with a particular
primitive shows up.
* Because of colors being passed as uniforms with static variables, the
color of the collection of the last object to be evauluated is used for
all particles being displayed.
Also, note that while this is being drawn in the clay engine, this might
be moved to the object mode later intead.
Part of T51378
Mainly adding 'wire' suffix to wire/distance drawing func and shader.
Also, match wire vertex shader behavior with solid one regarding
head/tail only drawing (i.e. alwas expect head bone mat, never tail one,
and assume that if a radius is negative, then we only draw on the other
end of the bone).
Envelope bones are now pretty much identical to old drawing code.
Note that currently new DwM drawing code does not seem to care about
wire/solid drawing modes at all, guess this is still TODO... For now we
hence just get both wire and solid for envelope bones, this can be
refined later.
This is not complete, it does not implement 3D solid drawing of
envelope bones. 2D wire is hence always drawn for now.
Some notes:
I did not try to implement the 'capsule' approach suggested by @fclem, because:
1. I spent enough time on this already, and finally got something working.
2. I managed to get rid of geometry shader completely.
3. Current approach allows us to use same shader for
distance outline and envelope wire.
It's working fine, except for one glitch - superpositions of envelope
outlines do not work as expected, not sure what's wrong here, tried to
disable zbuff, enable GL_BLEND, no luck so far...
I think we need our own 'background' drawpass to get them working (also
to avoid them drawing over the wire lines).
This implements weight rendering with the draw manager, with all drawing
options (Shading, wire, face masking, vertex masking).
This is part of T51208
Reviewers: campbellbarton
Subscribers: dfelinto
Differential Revision: https://developer.blender.org/D2654
