Note: Metaballs only support the first material slot. Splicing it per
material would create empty Batches. In order to overcome this we set
the batch for other materials to NULL. We added extra checks in EEVEE
and Workbench to not draw when the geom is NULL.
This make the limited wireframe not a performance problem anymore.
However, this does change the number of edges displayed as the threshold
is now computed per vertex instead of per edges.
For this reason we extended (internaly) the range of the slider so that the
users can hide more edge.
Only OB_MESH is supported for now.
Creates a simple index buffer with negative indices if the edges is not a
real edge.
Also create the buffer texture representation of this buffer along with the
pos_in_order buffer texture.
The implementation is pretty straightforward.
In Cycles, sampling the shapes is currently done w.r.t. area instead of solid angle.
There is a paper on solid angle sampling for disks [1], but the described algorithm is based on
simply sampling the enclosing square and rejecting samples outside of the disk, which is not exactly
great for Cycles' RNG (we'd need to setup a LCG for the repeated sampling) and for GPU divergence.
Even worse, the algorithm is only defined for disks. For ellipses, the basic idea still works, but a
way to analytically calculate the solid angle is required. This is technically possible [2], but the
calculation is extremely complex and still requires a lookup table for the Heuman Lambda function.
Therefore, I've decided to not implement that for now, we could still look into it later on.
In Eevee, the code uses the existing ltc_evaluate_disk to implement the lighting calculations.
[1]: "Solid Angle Sampling of Disk and Cylinder Lights"
[2]: "Analytical solution for the solid angle subtended at any point by an ellipse via a point source radiation vector potential"
Reviewers: sergey, brecht, fclem
Differential Revision: https://developer.blender.org/D3171
This makes the shadows ~10 times faster in the general case.
This only create extrusion geometry on the outline edges. Also we increment
or decrement the stencil buffer by 2 for each manifold edge and only by 1
for non manifold. This make the algorithm robust yet less heavy than creating
one prism for each triangles.
We can not rely on edit->psys, it is not set for particle edit,
and there is some logic deeper inside which does different things
dependent on that.
We need to replace those checks with some some HAIR vs. PARTICLES
flag and always set psys pointer.
The idea is that edit mode structure is owned by original object,
and used for drawing. This is a bit confusing, especially since
path cache is also in that structure and needs evaluated object
to calculate cache.
In the future we should split edit data from visualization data,
but that's bigger refactor.
The actual code is a bit convoluted but allows good and "pseudo efficient"
drawing. (pseudo efficient because rendering instances with that amount of
vertices is really inneficient. We should go full procedural but need to
have bufferTexture implemented first) But drawing speed is not a bottleneck
here and it's already a million time less crappy than the old (2.79) immediate
mode method.
Instead of drawing actual wires with different width we render a triangle
fan batch (containing 3 fans: bone, head, tail) which is then oriented in
screen space to the bone direction. We then interpolate a float value
accross vertices giving us a nice blend factor to blend the colors and
gives us really smooth interpolation inside the bone.
The outside edge still being geometry will be antialiased by MSAA if enabled.
Now the axes are displayed correctly at the tip of the bone and with the
axes names.
I've made some modifications though:
- Axes are colored. (should not be in object mode but that's TODO)
- Axes ends are not flat arrows anymore. Replaced with a small diamond.
- Axes names are now scale by their respective axes instead of being
affected by other axes.
- Changed axes names "font" to be a bit more sexy.
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.
