| Age | Commit message (Collapse) | Author |
|---|
|
|
|
We now use GPU_blend for enabling / disabling blending and explicitly
set the blend equation.
|
|
This is a first step into removing uniforms from GPU_batch and Imm.
|
|
And a minor fix when there is no `USE_SNAP_DETECT_FROM_KEYMAP_HACK`.
|
|
|
|
|
|
This replaces header include guards with `#pragma once`.
A couple of include guards are not removed yet (e.g. `__RNA_TYPES_H__`),
because they are used in other places.
This patch has been generated by P1561 followed by `make format`.
Differential Revision: https://developer.blender.org/D8466
|
|
The abbreviation 'init' is brief, unambiguous and already used
in thousands of places, also initialize is often accidentally
written with British spelling.
|
|
Remove use of GL* constants and types inside the codebase. There is still
a few occurence to get rid of.
|
|
|
|
We use the polyline shader for drawing the rotation gizmo now.
This shader supports clipping without hardware clip planes.
|
|
|
|
|
|
Issue is reported on Linux ith Intel HD6xx iGPU. Inside
`gpu_select_sample_query.c` the call to `glGetQueryObjectuiv` froze. After
bisecting this lead to the polyline shader. When using a 3d color shader
in stead of the polyline shader during selection seems to fix the issue.
Other parts of blender might also be effective, but I wasn't able to
freeze blender in these areas. When it does, we might want to add
a similar work-around to button2d, cage2d, cage3d & move3d, navigate.
Backport this patch to 2.83.
Reviewed By: Clément Foucault
Differential Revision: https://developer.blender.org/D8217
|
|
This addresses warnings from Clang-Tidy's `readability-else-after-return`
rule in the `source/blender/editors` module.
No functional changes.
|
|
|
|
|
|
|
|
- Interactively adding primitives with two clicks.
- Scene orientation used for new objects.
- Depth [view-plane, axis-plane, surface]
- Origin [base, center]
- Primitive types [cube, cylinder, cone, uv-sphere, ico-sphere ]
- Settings for object types in the top-bar.
Shortcuts:
- Snapping (Ctrl).
- Constrain 1:1 aspect (Shift).
- Toggle center (Alt).
Part of T57210 design task.
|
|
|
|
|
|
ED_gizmotypes_snap_3d_context_get could have returned NULL,
rename _get(..) to _ensure(..) and initialize the snap context
in this function.
|
|
Generic snap gizmo to be used for different tools.
The Gizmo can be configured initially by the following properties:
- `"snap_elements_force"`, `"prev_point"`
The following properties can be read as return:
- `"location"`, `"normal"`, `"snap_elem_index"`
This property can be linked to another (tool_setting.snap_elements):
- `"snap_elements"`
And this 3 extra utilities have been added:
- `ED_gizmotypes_snap_3d_draw_util`,
- `ED_gizmotypes_snap_3d_context_get`,
- `ED_gizmotypes_snap_3d_update`.
Differential Revision: https://developer.blender.org/D7071
|
|
This was caused by the sRGB viewport changes. The fix is to modify the
alpha values manually.
|
|
|
|
This also fix line width support for button2D shape batch
|
|
This new shader is able to emulate smooth wide lines drawing using a
geometry shader.
This shader needs viewportSize and lineWidth uniforms to be set.
There is multiple variants to replace the usage of wide lines for most
shaders.
This patch only fix the gizmo_types files and the navigation gizmo.
Other areas could be fixed afterward, I just limited the patch size.
Fix T57570.
Reviewed By: billreynish
Differential Revision: https://developer.blender.org/D7487
|
|
Follow up of b2ee1770d4c3 and 10c2254d412d, part of T74432.
Now the area and region naming conventions should be less confusing.
Mostly a careful batch rename but had to do few smaller fixes.
Also ran clang-format on affected files.
|
|
|
|
|
|
This fixes node corner-pin and sun-beam gizmo's cursor offsets.
|
|
While it might be handy to have type-less functionality which is
similar to how C++ math is implemented it can not be easily achieved
with just preprocessor in a way which does not have side-effects on
wrong usage.
There macros where often used on a non-trivial expression, and there
was at least one usage where it was causing an actual side effect/bug
on Windows (see change around square_f(sh[index++]) in studiolight.c).
For such cases it is handy to have a function which is guaranteed to
have zero side-effects. The motivation behind actually removing the
macros is that there is already a way to do similar calculation. Also,
not having such macros is a way to guarantee that its usage is not
changed in a way which have side-effects and that it's not used as an
inspiration for cases where it should not be used.
Differential Revision: https://developer.blender.org/D7051
|
|
Currently, this change does not bring functional changes.
But it is necessary to extend the use of the snap system for gizmos,
since, after a Undo, the `depsgraph` pointed by the `snap_context`
has its memory invalidated.
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D7013
|
|
The old convention was easy to confuse with ScrArea.
Part of https://developer.blender.org/T74432.
This is mostly a batch rename with some manual fixing. Only single word
variable names are changed, no prefixed/suffixed names.
Brecht van Lommel and Campbell Barton both gave me a green light for
this convention change.
Also ran clan clang format on affected files.
|
|
Part of https://developer.blender.org/T74429.
There's a chance that this causes some issues becaue in some cases we
change from getting the window from context to getting it from somewhere
else.
|
|
gizmos are too big
Caused by rB9cac5fa681c5 which fixed the handles for the camera border
gizmo (being much too small)-- which in turn was broken by
rB98e4fbc7cc9e.
Camera border gizmo sets up its matrix_space a bit differently [this is
why we are getting very small values in gizmo_calc_rect_view_scale --
needs more investigation], but instead of breaking it for Light, Image
and Compositor Backdrop, lets just compensate by scaling the Camera
Border Gizmo for now.
Maniphest Tasks: T74278
Differential Revision: https://developer.blender.org/D6991
|
|
|
|
|
|
NOTE: This change shouldn't have any visible effect. It's just the
first (easiest) step towards decoupling gizmo redraws from viewport
redraws.
We currently redraw the entire region whenever a gizmo needs redrawing,
which would be nice to avoid in the future, see T73198. The first step
towards this would be having a separate tag for them, which is what
this patch implements.
The term "editor-overlays" was chosen because for the forseeable future,
we'll also have to redraw non-gizmo overlays in-between drawing 3D and
2D gizmos. Namely annotations.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D6838
|
|
There were some visual artifacts when the spin gizmo had a rotation
greater than 360 degrees.
Avoids this by drawing the arc over the span of one rotation only
and adjusting the background color based on the rotation count.
|
|
|
|
Fixes issue where UV transform circle was being masked by the arrows.
|
|
It's simpler to support a single gizmo type for 2D/3D.
|
|
Allows 2D arrows to be removed, since they work slightly differently
and don't support offset matrices.
Use these in the UV editor.
|
|
Make the UV editor gizmos the same size as the 3D view.
|
|
|
|
Happened when used in 2D view.
|
|
This allows using the gizmo for a screen circle with a hollow
area in the center, useful for general dragging gizmos.
|
|
Previously the only way to draw polygon shapes from buttons
was to use a polygon that included the circular outline
with negative space for the un-filled areas.
This didn't always have visibility, especially when the gizmo was
overlaying colors that didn't contrast much.
Support drawing a generic backdrop with a polygon shape over it.
|
|
|
