| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This caused an additional argument when exiting object modes
and many other low level functions which don't need to access context.
This simplifies fixing T77073.
|
|
|
|
The grab mode was not correctly implemented, so the way it was working
was confusing for users.
- Grab delta was calculated in increments from the last stroke position, so it did not match the behavior of a grab brush. I refactored the grab delta calculation to make this change more explicit.
- Grab displacement was not calculated from the original coordinates
- Grab was using an incorrect strength
Grab is now setting the position of the affected vertices directly and
the constraints solve the rest of the cloth. I also tried to implement
an alternative version based on applying forces to move the vertices to
the grab position, but I think this is more controllable and the grab
falloff can be adjusted by tweaking the simulation falloff.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D7756
|
|
|
|
When using the shift-smooth mode, sculpt_update_cache_invariants is
changing the brush datablock of the paint session if it finds a brush
named "Smooth" (which is a huge hack the brush management project should
try to solve). This is done after the PaintStroke data in the modal
operator is created, which holds a reference to the active brush in the
paint session that was active when the operator started. Because of
this, the StrokeCache was getting the correct smooth brush values but
the paint modal operator was applying the wrong ones from the previous
brush. This was causing the smooth brush behaves unpredictably depending
on the current active brush.
This patch updates the brush in PaintStroke on each modal callback, so
it always gets the values from the current active brush in the Paint
Session.
The way brush switching works and a way to make it more flexible needs
to be discussed in the future as part of the brush management project.
The default smooth brush parameters and curves will probably need to
be updated after this change, as previously they were set using an
incorrect behavior.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D7354
|
|
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.
|
|
Rename:
- WM_modalkeymap_add to WM_modalkeymap_ensure
- WM_modalkeymap_get to WM_modalkeymap_find
|
|
|
|
Both the MS headers and blender headers define the HKEY
which gives all kind of inclusion order issues.
This diff renames all *KEY constants to EVT_*KEY to resolve
this conflict.
Reviewed By: brecht , dfelinto
Differential Revision: http://developer.blender.org/D7164
|
|
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
|
|
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.
|
|
|
|
When processing a timer event WM_event_tablet_data returns 0 instead of
the last valid pressure value from the tablet. This always stores the
last pressure value and uses it in case a timer event is being
processed.
Reviewed By: brecht
Maniphest Tasks: T74074
Differential Revision: https://developer.blender.org/D6950
|
|
This brush has a simple physics solver that helps when sculpting cloth.
- The mass and the damping properties of the simulation are properties of the brush.
- It has two additional radius control to limit the influence and falloff of the simulation.
- Masked vertices are pinned in the simulation, and it applies the sculpt gravity directly in the solver.
- The Cloth Brush has 7 deformation modes with 2 falloff types (radial and plane).
The brush can create the constraints only on the required PBVH nodes, so the simulation is isolated on high poly meshes. As long
as the brush size is not too big it should be possible to keep it real time.
Known issues:
- The way constraints are created is extremely basic and it creates repeated constraints. Maybe there is another way to create fewer constraints while keeping the simulation quality decent. This part can also be multithreaded. (As it is it works ok, but it could be better)
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D6715
|
|
Some other areas in the brush code outside sculpt mode assume that
pressure is multiplied directly on top of the initial size. This patch
calculates the pixel radius correctly using the brush size from sculpt
mode to get the dyntopo detail size.
When the new brush input system is in place, all these values will come
directly from the brush input code with all the custom curves applied
per brush, so all paint modes will have a correct brush behavior and all
this sculpt mode specific code won't be necessary.
Reviewed By: jbakker
Maniphest Tasks: T72092
Differential Revision: https://developer.blender.org/D6339
|
|
The relation between the pressure/size and the pressure/alpha is a
fundamental property that defines the behavior of a brush, so it does
not make sense to have it unified across all brushes. This applies both
for sculpting and painting.
Some of the new 2.82 brushes need pressure/size or pressure/alpha to be
enabled to work propely, while others don't. Users should not be
switching on and off this property manually when changing brushes if they
want to use unified size. This is also causing that some users are using
the brushes with an incorrect configuration.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D6291
|
|
Dash Ratio and Dash Samples are brush properties to modify the strength of the brush during a stroke. This is useful to create dashed lines in texture paint or stitches in sculpt mode.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D5949
|
|
This commit enables antialiasing in 2D painting.
It also includes some fixes related to line drawing in the stroke spacing code.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D5833
|
|
Reviewed By: brecht
Maniphest Tasks: T69227
Differential Revision: https://developer.blender.org/D5977
|
|
Caused by rBc31a849a1474.
Reviewed By: brecht
Maniphest Tasks: T70443
Differential Revision: https://developer.blender.org/D5970
|
|
This mostly happens automatically anyway since there is usually not enough
time left over for it. But when it does it happen it breaks partial redraw,
and may also have a negative impact on responsiveness.
Ref T70295
|
|
Not all the necessary state got restored.
|
|
Reviewed By: jbakker
Maniphest Tasks: T69875
Differential Revision: https://developer.blender.org/D5849
|
|
|
|
Particularly noticeable when vertex painting with a subsurf modifier.
In some cases every sculpt or paint stroke step would evaluate the dependency
graph. This should only happen for redraws. Now more selectively choose if the
dependency graph should be evaluated to initialize the view context. Doing it
in the view context evaluation is somewhat hidden, now it's more explicit.
Differential Revision: https://developer.blender.org/D5844
|
|
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D5816
|
|
|
|
This brush lets the user pose a model simulating an armature-like deformation. The pivot point for rotation is calculated automatically based on the radius of the brush and the topology of the model.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D5647
|
|
This patch implements the paper "Regularized Kelvinlets: Sculpting Brushes based on Fundamental Solutions of Elasticity" https://graphics.pixar.com/library/Kelvinlets/paper.pdf
It includes grab, biscale grab, triscale grab, scale and twist.
All deformation modes are accessible under the same tool. This helps to keep the code organized and it should not make any difference to the user when a better brush management system is implemented.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D5634
|
|
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D5699
|
|
New brush option to calculate the distance to generate a new brush step using the cursor position over the mesh instead of the screen coordinates. This avoids artifacts when sculpting across curved surfaces.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D5432
|
|
Some brush tools were being executed too often when using devices with high polling rates, causing performance issues. This should improve the performance of brushes that don't need those updates.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D5429
|
|
|
|
T68035 by @luzpaz
|
|
The dash_factor wasn't being set in many places, having the graph editor
open for eg, caused box-select in the 3D view not to show dashes.
|
|
|
|
|
|
Apply clang format as proposed in T53211.
For details on usage and instructions for migrating branches
without conflicts, see:
https://wiki.blender.org/wiki/Tools/ClangFormat
|
|
Mostly functions wrapping args, not confirming to our style guide.
|
|
Reviewers: brecht
Maniphest Tasks: T62359
Differential Revision: https://developer.blender.org/D4486
|
|
While \file doesn't need an argument, it can't have another doxy
command after it.
|
|
Move \ingroup onto same line to be more compact and
make it clear the file is in the group.
|
|
BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
|
|
|
|
Prevents clang-format wrapping text before comments.
|
|
|
|
- Rename ePaint* -> PAINT_MODE_*.
- Use PAINT_OVERLAY_ prefix for eOverlayControlFlags.
|
|
This should be purely an implementation change,
for end users there should be no functional difference.
The entire key configuration is in one file with ~5000 lines of code.
Mostly avoiding code duplication and preserve comments and utility
functions from the C code.
It's a bit long but for searching and editing it's also convenient to
have it all in one file.
Notes:
- Actual keymap is shared by blender / blender_legacy
and stored in `keymap_data/blender_default.py`
This only generates JSON-like data to be passed into
`keyconfig_import_from_data`, allowing other presets to load and
manipulate the default keymap.
- Each preset defines 'keyconfig_data'
which can be shared between presets.
- Some of the utility functions for generating keymap items still
need to be ported over to Python.
- Some keymap items can be made into loops (marked as TODO).
See: D3907
|
|
|
