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`.
|
|
|
|
The abbreviation 'init' is brief, unambiguous and already used
in thousands of places, also initialize is often accidentally
written with British spelling.
|
|
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
|
|
|
|
|
|
|
|
- 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.
|
|
|
|
There was a mix of old and new constants. Now have one list of WM_CURSOR_*
cursor types, using GHOST standard cursors when available and otherwise falling
back to our custom cursors.
Ref D5197
|
|
|
|
|
|
Part of T66420
Option for snapping to the nearest point of a reference coordinate.
The patch also adds Edge Center and Perpendicular snaps to the ruler.
{F7675906}
Reviewers: campbellbarton, brecht
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D5543
|
|
|
|
This change ensures that operators which needs access to evaluated data
first makes sure there is a dependency graph.
Other accesses to the dependency graph made it more explicit about
whether they just need a valid dependency graph pointer or whether they
expect the graph to be already evaluated.
This replaces OPTYPE_USE_EVAL_DATA which is now removed.
Some general rules about usage of accessors:
- Drawing is expected to happen from a fully evaluated dependency graph.
There is now a function to access it, which will in the future control
that dependency graph is actually evaluated.
This check is not yet done because there are some things to be taken
care about first: for example, post-update hooks might leave scene in
a state where something is still tagged for update.
- All operators which needs to access evaluated state must use
CTX_data_ensure_evaluated_depsgraph().
This function replaces OPTYPE_USE_EVAL_DATA.
The call is generally to be done in the very beginning of the
operator, prior other logic (unless this is some comprehensive
operator which might or might not need access to an evaluated state).
This call is never to be used from a loop.
If some utility function requires evaluated state of dependency graph
the graph is to be passed as an explicit argument. This way it is
clear that no evaluation happens in a loop or something like this.
- All cases which needs to know dependency graph pointer, but which
doesn't want to actually evaluate it can use old-style function
CTX_data_depsgraph_pointer(), assuming that underlying code will
ensure dependency graph is evaluated prior to accessing it.
- The new functions are replacing OPTYPE_USE_EVAL_DATA, so now it is
explicit and local about where dependency graph is being ensured.
This commit also contains some fixes of wrong usage of evaluation
functions on original objects. Ideally should be split out, but in
reality with all the APIs being renamed is quite tricky.
Fixes T67454: Blender crash on rapid undo and select
Speculation here is that sometimes undo and selection operators are
sometimes handled in the same event loop iteration, which leaves
non-evaluated dependency graph.
Fixes T67973: Crash on Fix Deforms operator
Fixes T67902: Crash when undo a loop cut
Reviewers: brecht
Reviewed By: brecht
Subscribers: lichtwerk
Maniphest Tasks: T67454
Differential Revision: https://developer.blender.org/D5343
|
|
|
|
Needed for changes to the scale gizmo.
|