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
The Camera Background Images uses a alpha under blending. For alpha
under blending to work correctly the framebuffer containing the result
of the render engine needs to be active
(`DefaultFramebufferList.default_fb`) and the source blend color needs
to be premultiplied with alpha.
Due to recent refactoring this wasn't the case and it seemed that the
background image was drawn in front of the scene. This patch sets the
correct state so it seems to be drawn behind the scene.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D6365
This use the overlay AA pass to antialias the selection outlines.
This also do all search and expand in one pass and reduce the computation
time and memory used (2 x 32bit/pixel buffer less).
Note that the aliasing is a bit worse than the old FXAA that we used to have.
Bone relationship lines needs to be hidden in:
* object mode
* or when relationship lines are turned off
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D6356
Now when change the setting the strokes are recalculated.
To do this, it was necessary to move the UV recalc to BKE module in order to share with Draw Engine. If the recalc it was done in draw engine, the factor was only calculated for evaluated version and there was a problem when draw a new sytroke.
Now, the RNA parameter recalc the original datablock instead of tag for be calculated in Draw Engine.
Fix for T72136: Bounding boxes were still drawn even with disabled
overlays. Also the outline displayed the original mesh
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D6350
To do this we do a half pixel offset in the normal direction.
However, we use the shading vertex normal instead of the geometric normal
(for speed) and this leads to imprecisions.
So we try to mitigate the common case and leave the corner cases as is.
Instead of relying on undefined behavior to discard the line, we put the
vertex at the camera origin so that interpolation does not produce any
fragment. We don't use FLT_MAX as it also gives unpredicatble results on
NVidia.
This Simplify and should also speedup the drawing a tiny bit.
We now discard the edges in the vertex shader by setting one of the verts
at vec4(0,0,0,0) to not produce any fragment
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
This patch will allow the user to select the EEVEE renderpass to be
shown in the viewport by default the combined pass will be shown.
Limitations:
* Viewport rendering stores the result in a `RenderResult`. RenderResult
is not aware of the type of data it holds. In many places where RenderResult
is used it is assumed that it stores a combined pass and the display+view
transform are applied.
I will propose to fix this in a future patch. But that is still being
designed and discussed.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D6319
BIF_gl.h included hacks like redefining glew functions and a constant.
The named constant `GLA_PIXEL_OFS` has been moved to `GPU_viewport.h`
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D5860
Small performance improvements by caching the world_ubo in the World.
It was detected that NVIDIA driver created threads to update the
world_ubo (304 bytes). This patch will reuse the previous created
ubo when not changed.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D6087
Most of the renderpasses in EEVEE used post-processing on the CPU. For
final image rendering this is sufficient, but when we want to display
the data to the user we don't want to transfer to the CPU to do post
processing to then upload it back to the GPU to display the result.
This patch moves the renderpass postprocessing to a GLSL shader.
This is the first step to do, before we will enable the renderpasses in the viewport.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D6206
When rendering the Subsurface scattering lighting render layer with high
sample count render artifacts can appear. This patch will remove these
render artifacts by using a more precise texture format when samples
will be larger than 128. As with the new eevee-shadows it is more common
to use higher number of samples.
The reason why it was visible in the subsurface scattering is that every
sample could change the color. Adding different values will reduce
precision over the number of samples.
The subsurface color render layer also has this issue, but it is not noticeable as
the colors tend to be close to each other so the colors would
most of the time just shift the precision and hold up better.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D6245
By error, the original datablock was used while rendering. Actually, only while the user is drawing the original data must be used because when we tested, the time the system uses to copy the datablock created a very bad "lag" feeling while drawing. Maybe the lag was half second only, but it ruined the pencil feeling.
I talked some time ago with Sergey about that and we decided use this approach.
Now, only the original datablock is used while the user is "moving" the pen, but not in any other situation.
Thanks @sergey for help me with this bug and sorry for thinking it was a depsgraph issue.
When the stroke has less than 3 points, but only the fill material is enabled, the stroke is invisible and makes the shaders to remove any fill because the shader start and end pointers are not correct.
Now, if the stroke has only fill, but it is not fillable, it is drawn with the stroke color to avoid the errors and these ghost strokes.
