Viewport: Disable Clipping For EEVEE and External Renderers
Currently it is possible that, when using viewport clipping, the display and tools communicate
different information to the user then the renderer does. The reason is
that the renderer does not support viewport clipping. Both EEVEE and
Cycles do not support it.
This patch will disable the clipping in all the tools and drawing code
when the viewport drawing mode is `Material Preview` or `Rendered`.
This patch introduces a `RV3D_CLIPPING_ENABLED` util that checks if
clipping is enabled for the given `rv3d` and `v3d`. Also in places where
it was needed we added the `ViewContext` as a carrier for the `View3D`
and `RegionView3D`.
There are a few areas in the tooling (select, projection painting) that
still needs to be tackled after this patch.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D6047
Adds theme settings to allow change of front and back faces of the Face Orientation overlay
Differential Revision: https://developer.blender.org/D6262
Reviewed by Jeroen Bakker
Multisample buffers were used for smooth line drawing. As we now have
an algorithm that doesn't need the multisample buffers we can remove
them.
The user preference for viewport multi_sampling is replaced by single
toggle overlay `use_overlay_smooth_wire`. By default this setting is
enabled as the new drawing is really quick (<1ms) and uses zero hacks.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D6367
Introduced by 9c337fcfe2 mistaken that `MeshExtract.use_threading` set
to false means that no threading is used at all. This is not the case it
will still perform threading for large objects, it will only run the
different subtasks in serial.
Fixed by scheduling the `lines_loose` in the task_pool after the rest
have been executed. This is cleaner than the previous implementation as
it sticks more to the actual design.
The lines index buffer can contain all edges (edit mode) or only loose
edges (object mode). When switching between these modes the wrong
content of the index buffer can be used.
This patch will clear the lines index buffer when a `loose_edges` is requested. Making sure it is always up to date.
Note that this is supporting an exising hack where the IBO is truncated
during the creation. We should find a different way how to solve these
kind of issues.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D6349
This is the unification of all overlays into one overlay engine as described in T65347.
I went over all the code making it more future proof with less hacks and removing old / not relevent parts.
Goals / Acheivements:
- Remove internal shader usage (only drw shaders)
- Remove viewportSize and viewportSizeInv and put them in gloabl ubo
- Fixed some drawing issues: Missing probe option and Missing Alt+B clipping of some shader
- Remove old (legacy) shaders dependancy (not using view UBO).
- Less shader variation (less compilation time at first load and less patching needed for vulkan)
- removed some geom shaders when I could
- Remove static e_data (except shaders storage where it is OK)
- Clear the way to fix some anoying limitations (dithered transparency, background image compositing etc...)
- Wireframe drawing now uses the same batching capabilities as workbench & eevee (indirect drawing).
- Reduced complexity, removed ~3000 Lines of code in draw (also removed a lot of unused shader in GPU).
- Post AA to avoid complexity and cost of MSAA.
Remaining issues:
- ~~Armature edits, overlay toggles, (... others?) are not refreshing viewport after AA is complete~~
- FXAA is not the best for wires, maybe investigate SMAA
- Maybe do something more temporally stable for AA.
- ~~Paint overlays are not working with AA.~~
- ~~infront objects are difficult to select.~~
- ~~the infront wires sometimes goes through they solid counterpart (missing clear maybe?) (toggle overlays on-off when using infront+wireframe overlay in solid shading)~~
Note: I made some decision to change slightly the appearance of some objects to simplify their drawing. Namely the empty arrows end (which is now hollow/wire) and distance points of the cameras/spots being done by lines.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D6296
Users now can turn on in a viewport collections that are temporarily
hidden (eye) in the view layer.
Design task: T61327
As for the implementation, I had to decouple the visibility in the
depsgraph from the visibility in the view layer.
Also there is a "bug" that in a way was there before which is some
operators (e.g., writing a text inside of a text object, tab into edit
mode) run regardless of the visibility of the active object. The bug was
present already (with object type visibility restriction) in 2.80 so if
we decide to tackle it, can be done separately (I have a patch for it
though P1132).
Reviewed by: brecht (thank you)
Differential Revision: D5992
Camera background images were not shown under transparent objects.
This patch performs an alpha under for background images for cycles.
In order to see the difference the Film transparency needs to be turned on.
Note that workbench and EEVEE still needs to be adapted as they don't
write store alpha value in the viewport.
Side note. This implementation is already an improvement of the current behavior, what users are requesting. (Show background images underneath cycles viewport rendering.) It is clear that this patch still needs to be extended to workbench and eevee. For now that should be marked as a known limitation.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D5437
Adds a check when starting blender if your platform is supported. We use a blacklist
as drivers are updated more regular then blender (stable releases).
The mechanism detects if the support level changed or has been validated by the user previously.
Changes can happen due to users updating their drivers, but also when we change the support
level in our code base.
When the user has seen the limited support level message it is saved in the user config.
It would be better to have a system specific config section, but currently not clear
what could benefit from that.
When the platform is unsupported or has limited support a dialog box will appear including a link
to our user manual describing what to do.
**Windows**
Windows uses the MessageBox that is provided by the windows kernel.
**X11**
We use a very lowlevel messagebox for X11. It is very limited in use and can be fine tuned when needed.
**SDL/APPLE**
There is no implementation for SDL or APPLE at this moment as the platform support feature targets mostly Windows users.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D5955
Also applies to some other sculpt tools like filter and mask expand.
The full update happens after the paint stroke is finished, so it does not
happen on view navigation, which would cause a delay.
Ref T70295
Differential Revision: https://developer.blender.org/D5922
This improves performance of some sculpt tools, particularly those that modify
many vertices like filter and mask tools, or use brushes with large radius.
For mask expand it can make updates up to 2x faster on heavy meshes, but for
most tools it's more on the order of 1-1.1x. There are bigger bottlenecks to
solve, like normal updates.
Ref T70295
Differential Revision: https://developer.blender.org/D5926
Was caused by DRW_mesh_batch_cache_get_edituv_faces_stretch_area called
after DRW_mesh_batch_cache_create_requested. So it was created on the wrong
object/mesh.
Workaround that does not fix the real issue.
The bug is caused by glBufferData inside
DRW_instance_buffer_finish > GPU_vertbuf_use
but only after the selection code which resets the number of items in
idatalist->pool_buffers.
I don't understand why this is happening as the vbo ids are all valid and
no error is reported. What is even more strange, is that it affects another
vbo which has no connection with the ones in DRW_instance_buffer_finish.
Was caused by some drawcall not being done if the volumetric resolve pass
was drawn (using dual source blending seems to be the cause).
Not sure why this is needed since it is still reset before the next
drawcall.
These were only strictly valid for texture space calculation, don't store them
since they should not be used after that. Only store a flag to indicate if the
auto texture space has been evaluated.
In the future it might make sense to store bounding boxes at the mesh level to
speed up bounding box computation for multiple objects using the same mesh, but
then it will need to be implemented differently.
