Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
There was a method explained in the Weighted Blended Order-Independent
Transparency paper to support hardware that does not support per render
target blending function.
So now only 2 geometry passes are required instead of 3 (one being the
outline/depth fill pass).
This also fix how the blending is done. There was some premult confusion
in the implementation.
|
|
This was the last remaining problem with shadow volumes (that I know of).
Only extrude until we hit the far plane.
|
|
This commit restores support for Motion Path drawing in 2.8 (as it wasn't ported over
to the new draw engines earlier, and the existing space_view3d/drawanimviz.c code was
removed during the Blender Internal removal).
Notes:
* Motion Paths are now implemented as an overlay (enabled by default).
Therefore, you can turn all of them on/off from the "Overlays" popover
* By and large, we have kept the same draw style as was used in 2.7
Further changes can happen later following further design work.
* One change from 2.7 is that thicker lines are used by default (2px vs 1px)
Todo's:
* There are some bad-level calls introduced here (i.e. the actgroup_to_keylist() stuff).
These were introduced to optimise drawing performance (by avoiding full keyframes -> keylist
conversion step on each drawcall). Instead, this has been moved to the calculation step
(in blenkernel). Soon, there will be some cleanups/improvements with those functions,
so until then, we'll keep the bad level calls.
Credits:
* Clément Foucault (fclem) - Draw Engine magic + Shader Conversion/Optimisation
* Joshua Leung (Aligorith) - COW fixes, UI integration, etc.
Revision History:
See "tmp-b28-motionpath_drawing" branch (rBa12ab5b2ef49ccacae091ccb54d72de0d63f990d)
|
|
|
|
Also use 'uint'.
|
|
This is motivated by the refactor of DRWInstanceData to be actual non
contiguous mempools.
|
|
|
|
This mimics the behaviour of DRW_shgroup_empty_tri_batch_create and will
replace it eventually.
The advantage is that it's compatible with transform feedback.
|
|
If the object is manifold and the camera is in the shadow side, we can
use the depth fail method to fix the inverted shadow glitch.
Unfortunately this does not really work for non-manifold.
Implementation details:
We try to be as efficient as we can, we precompute camera near plane
projected into 2D shadow space so we can test for intersection with the
shadow boundbox easily.
As the intersection test is done in 2D it's pretty fast.
Unfortunately, this means the shadow bounds are all aligned to the same
space and are not the smallest bound we could extract.
|
|
Since this method have no failure case for manifold objects, use it.
|
|
|
|
|
|
|
|
Also add new debug visualisation.
Depth fail method is not used for the moment but has nice benefits. It will
be used efficiently in the future.
|
|
|
|
This is a usefull feature that can be used to do a lot of precomputation on
the GPU instead of the CPU.
Implementation is simple and only covers the most usefull case.
How to use:
- Create shader with transform feedback.
- Create a pass with DRW_STATE_TRANS_FEEDBACK.
- Create a target Gwn_VertBuf (make sure it's big enough).
- Create a shading group with DRW_shgroup_transform_feedback_create().
- Add your draw calls to the shading group.
- Render your pass normaly.
Current limitation:
- Only one output buffer.
- Cannot pause/resume tfb rendering to interleave with normal drawcalls.
- Cannot get the number of verts drawn.
|
|
And also use a union instead of forcing the cast to void*.
|
|
|
|
|
|
|
|
This is only useful if depth test/wire is disabled.
|
|
Initial review of the shard shadows in the workbench engine.
Speed optimizations like transform feedback are not implemented yet. I first want this part to be reviewed and merged.
@fclem please check the note in drw_stencil_set it was holding back nequal == 0 as by default DST.stencil_mask was set to 0. questioin is should we remove the whole check or not.
Also I am still looking for a better name (or split the enum) for DRW_STATE_STENCIL_DEPTH_FAIL_INCR_DECR_WRAP
Reviewers: fclem
Reviewed By: fclem
Tags: #code_quest
Differential Revision: https://developer.blender.org/D3198
|
|
Usefull to see if the view frustum is totally behind a plane.
|
|
|
|
This add a callback function that runs after frustum culling test.
This callback returns the final visibility for this object.
Be aware that it's called for EVERY drawcalls that use this callback even
if their visibility has been cached.
|
|
|
|
|
|
|
|
This allow to use int uniforms that are not references. Convenient for ids.
|
|
|
|
This uniforms can be used to have a unique id for each drawcall of a shgrp.
This only works for standard shgroups and is an exception for the outline
drawing.
|
|
|
|
Blender allows this.
The Cube in the file in the report would always disappear with the non camera view.
The clip_end was too small.
The correction here is only on the assert.
|
|
And Cleanup.
|
|
Orthographic frustum was incorrect.
There was double transformation.
|
|
Although somewhat less micro efficient, I decided to separate the `viewinv` matrix to calculate the world position separately.
This makes it easier to understand the code.
|
|
|
|
|
|
draw_frustum_boundbox_calc does not work properly it seems in this case.
|
|
usage.
The problem was that textures were assigned to different slots on different draw
calls, which caused shader specialization/patching by the driver. So the shader
would be compiled over and over until all possible assignments were used.
|
|
|
|
frustum boundbox
|
|
This is in order to not mix it with the incomming buffer textures.
|
|
|
|
|
|
Previous approach was not clear enough and caused problems.
UBOs were taking slots and not release them after a shading group even
if this UBO was only for this Shading Group (notably the nodetree ubo,
since we now share the same GPUShader for identical trees).
So I choose to have a better defined approach:
- Standard texture and ubo calls are assured to be valid for the shgrp
they are called from.
- (new) Persistent texture and ubo calls are assured to be valid accross
shgrps unless the shader changes.
The standards calls are still valids for the next shgrp but are not assured
to be so if this new shgrp binds a new texture.
This enables some optimisations by not adding redundant texture and ubo
binds.
|
|
Use the same logic than textures. Also reset bindings only on shader changes.
|