| Age | Commit message (Collapse) | Author |
|---|
|
This patch adds color attributes to TexPaintSlot. This allows an easier selection
when painting color attributes.
Previously when selecting a paint tool the user had to start a stroke, before the
UI reflected the correct TexPaintSlot. Now when switching the slot the active
tool is checked and immediate the UI is drawn correctly.
In the future the canvas selector will also be used to select an image or image texture node
to paint on. Basic implementation has already been done inside this patch.
A limitation of this patch is that is isn't possible anymore to rename images directly from
the selection panel. This is currently allowed in master. But as CustomDataLayers
aren't ID fields and not owned by the material supporting this wouldn't be easy.
{F12953989}
In the future we should update the create slot operator to also include color attributes.
Sources could also be extended to use other areas of the object that use image textures
(particles, geom nodes, etc... ).
Reviewed By: brecht
Maniphest Tasks: T96709
Differential Revision: https://developer.blender.org/D14455
|
|
Add new `BKE_id_is_editable` helper in `BKE_lib_id.h`, that supercedes
previous check (simple `ID_IS_LINKED()` macro) for many editing cases.
This allows to also take into account 'system override' (aka
non-editable override) case.
Ref: {T95707}.
|
|
|
|
This does not happen with **any** image, but with images that have ID
properties.
ID properties are used to store view projection matrices (e.g. for
reprojection with `Image from View` or `Quick Edit` -- these are the
ones we are interested in), but of course they can be used for anything
else, too. The images in the file from the report have ID properties from
an Addon for example.
So the crash can reliably be reproduced with **any** image doing the
following:
```
bpy.data.images['myImage']['myIDprop'] = "foo"
```
This would lead code in `texture_paint_camera_project_exec` to think the
needed `view_data` is on the image (but in reality it was just some
other IDprop).
Solution is simple: just check `view_data` is really valid after getting
it from the IDprops.
Maniphest Tasks: T95787
Differential Revision: https://developer.blender.org/D14116
|
|
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
|
|
Also other minor corrections & reformat particle system copyright.
|
|
23775f3914d6474fd73eff7 removed this comment, but it's
preferred to keep it instead.
|
|
Remove functions and function pointers that were never set or never
used at all. The "tessface" original index handling in `subsurf_ccg.c`
can be removed because the data was never used.
|
|
As described in T91186, this commit moves mesh vertex normals into a
contiguous array of float vectors in a custom data layer, how face
normals are currently stored.
The main interface is documented in `BKE_mesh.h`. Vertex and face
normals are now calculated on-demand and cached, retrieved with an
"ensure" function. Since the logical state of a mesh is now "has
normals when necessary", they can be retrieved from a `const` mesh.
The goal is to use on-demand calculation for all derived data, but
leave room for eager calculation for performance purposes (modifier
evaluation is threaded, but viewport data generation is not).
**Benefits**
This moves us closer to a SoA approach rather than the current AoS
paradigm. Accessing a contiguous `float3` is much more efficient than
retrieving data from a larger struct. The memory requirements for
accessing only normals or vertex locations are smaller, and at the
cost of more memory usage for just normals, they now don't have to
be converted between float and short, which also simplifies code
In the future, the remaining items can be removed from `MVert`,
leaving only `float3`, which has similar benefits (see T93602).
Removing the combination of derived and original data makes it
conceptually simpler to only calculate normals when necessary.
This is especially important now that we have more opportunities
for temporary meshes in geometry nodes.
**Performance**
In addition to the theoretical future performance improvements by
making `MVert == float3`, I've done some basic performance testing
on this patch directly. The data is fairly rough, but it gives an idea
about where things stand generally.
- Mesh line primitive 4m Verts: 1.16x faster (36 -> 31 ms),
showing that accessing just `MVert` is now more efficient.
- Spring Splash Screen: 1.03-1.06 -> 1.06-1.11 FPS, a very slight
change that at least shows there is no regression.
- Sprite Fright Snail Smoosh: 3.30-3.40 -> 3.42-3.50 FPS, a small
but observable speedup.
- Set Position Node with Scaled Normal: 1.36x faster (53 -> 39 ms),
shows that using normals in geometry nodes is faster.
- Normal Calculation 1.6m Vert Cube: 1.19x faster (25 -> 21 ms),
shows that calculating normals is slightly faster now.
- File Size of 1.6m Vert Cube: 1.03x smaller (214.7 -> 208.4 MB),
Normals are not saved in files, which can help with large meshes.
As for memory usage, it may be slightly more in some cases, but
I didn't observe any difference in the production files I tested.
**Tests**
Some modifiers and cycles test results need to be updated with this
commit, for two reasons:
- The subdivision surface modifier is not responsible for calculating
normals anymore. In master, the modifier creates different normals
than the result of the `Mesh` normal calculation, so this is a bug
fix.
- There are small differences in the results of some modifiers that
use normals because they are not converted to and from `short`
anymore.
**Future improvements**
- Remove `ModifierTypeInfo::dependsOnNormals`. Code in each modifier
already retrieves normals if they are needed anyway.
- Copy normals as part of a better CoW system for attributes.
- Make more areas use lazy instead of eager normal calculation.
- Remove `BKE_mesh_normals_tag_dirty` in more places since that is
now the default state of a new mesh.
- Possibly apply a similar change to derived face corner normals.
Differential Revision: https://developer.blender.org/D12770
|
|
|
|
Goals of this refactor:
* More unified approach to updating everything that needs to be updated
after a change in a node tree.
* The updates should happen in the correct order and quadratic or worse
algorithms should be avoided.
* Improve detection of changes to the output to avoid tagging the depsgraph
when it's not necessary.
* Move towards a more declarative style of defining nodes by having a
more centralized update procedure.
The refactor consists of two main parts:
* Node tree tagging and update refactor.
* Generally, when changes are done to a node tree, it is tagged dirty
until a global update function is called that updates everything in
the correct order.
* The tagging is more fine-grained compared to before, to allow for more
precise depsgraph update tagging.
* Depsgraph changes.
* The shading specific depsgraph node for node trees as been removed.
* Instead, there is a new `NTREE_OUTPUT` depsgrap node, which is only
tagged when the output of the node tree changed (e.g. the Group Output
or Material Output node).
* The copy-on-write relation from node trees to the data block they are
embedded in is now non-flushing. This avoids e.g. triggering a material
update after the shader node tree changed in unrelated ways. Instead
the material has a flushing relation to the new `NTREE_OUTPUT` node now.
* The depsgraph no longer reports data block changes through to cycles
through `Depsgraph.updates` when only the node tree changed in ways
that do not affect the output.
Avoiding unnecessary updates seems to work well for geometry nodes and cycles.
The situation is a bit worse when there are drivers on the node tree, but that
could potentially be improved separately in the future.
Avoiding updates in eevee and the compositor is more tricky, but also less urgent.
* Eevee updates are triggered by calling `DRW_notify_view_update` in
`ED_render_view3d_update` indirectly from `DEG_editors_update`.
* Compositor updates are triggered by `ED_node_composite_job` in `node_area_refresh`.
This is triggered by calling `ED_area_tag_refresh` in `node_area_listener`.
Removing updates always has the risk of breaking some dependency that no
one was aware of. It's not unlikely that this will happen here as well. Adding
back missing updates should be quite a bit easier than getting rid of
unnecessary updates though.
Differential Revision: https://developer.blender.org/D13246
|
|
Ref T92709
|
|
Dirty regions when painting are not using rcti. Meaning less
understandable code. Found issue when refactoring the image_gpu partial
update. In a future change gpu partial update API will be using rcti
also what makes the code even cleaner.
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D13260
|
|
Caused by {rBaf162658e127}, so long standing bug.
When changing clone slots (report involved a quite complicated sequence
of selecting textures and undo -- but I think this could happen in more
situations) code checks for UV of new clone slot.
However, since above commit the slot and the clone slot were mixed up,
so in this case the responsible NULL check (for when no UV is assigned)
wasnt working.
Now correct this (NULL check the clone slot uv -- instead of the paint
slot UV).
note: not sure why low level CustomData functions actually dont do the
name NULL checks themselves (seems like callers are always responsible).
Maniphest Tasks: T93117
Differential Revision: https://developer.blender.org/D13378
|
|
|
|
|
|
Choosing a UV layer would actually affect the overlay in the viewport
and also painting with the mask brush was in that UV space, but the
resulting stencil mask was always applied with the active UV (not the
explicitly selected stencil UV -- the one one is looking at in the
viewport!) to painting.
This has been like that as far as I have checked back (at least 2.79b),
I am surprised this has not come up before, but it does not seem to make
sense at all...
Now use the UV specified for the stencil layer when applying the mask for
painting, so it corresponds to the stencil mask one is looking at in the
viewport.
Maniphest Tasks: T91557
Differential Revision: https://developer.blender.org/D12583
|
|
|
|
|
|
While doxygen supports both, conform to our style guide.
Note that single back-tick's are already used in a majority of comments.
|
|
|
|
|
|
Also use doxy style function reference `#` prefix chars when
referencing identifiers.
|
|
|
|
|
|
|
|
|
|
This patch fixes many minor spelling mistakes, all in comments or
console output. Mostly contractions like can't, won't, don't, its/it's,
etc.
Differential Revision: https://developer.blender.org/D11663
Reviewed by Harley Acheson
|
|
After looking into task isolation issues with Sergey, we couldn't find the
reason behind the deadlocks that we are getting in T87938 and a Sprite Fright
file involving motion blur renders.
There is no apparent place where we adding or waiting on tasks in a task group
from different isolation regions, which is what is known to cause problems. Yet
it still hangs. Either we do not understand some limitation of TBB isolation,
or there is a bug in TBB, but we could not figure it out.
Instead the idea is to use isolation only where we know we need it: when
holding a mutex lock and then doing some multithreaded operation within that
locked region. Three places where we do this now:
* Generated images
* Cached BVH tree building
* OpenVDB lazy grid loading
Compared to the more automatic approach previously used, there is the downside
that it is easy to miss places where we need isolation. Yet doing it more
automatically is also causing unexpected issue and bugs that we found no
solution for, so this seems better.
Patch implemented by Sergey and me.
Differential Revision: https://developer.blender.org/D11603
|
|
|
|
Under some circumstances using task isolation can cause deadlocks.
Previously, our task pool implementation would run all tasks in an
isolated region. Now using task isolation is optional and can be
turned on/off for individual task pools.
Task pools that spawn new tasks recursively should never enable
task isolation. There is a new check that finds these cases at runtime.
Right now this check is disabled, so that this commit is a pure refactor.
It will be enabled in an upcoming commit.
This fixes T88598.
Differential Revision: https://developer.blender.org/D11415
|
|
|
|
|
|
Caused by rB5b34d11b55e0.
Above commit restored the view matrices in ED_view3d_draw_offscreen
_before_ they can be stored in the ImBuff (see ED_view3d_draw_offscreen
/ texture_paint_image_from_view_exec).
Now make restoring the view matrices optional and dont do this in case
of reprojection, so the used matrices can still be saved in the ImBuff
later.
Reviewed By: campbellbarton
Maniphest Tasks: T85395
Differential Revision: https://developer.blender.org/D10331
|
|
|
|
|
|
Comment blocks not conforming to convention.
|
|
|
|
Approximately 138 changes in the spelling of compound words
and proper names like "Light Probe", "Shrink/Fatten", "Face Map".
In many cases, hyphens were used where they aren't correct, like
"re-fit". Other common changes include:
- "Datablock" -> "data-block"
- "Floating point" -> "floating-point"
- "Ngons" -> "n-gons"
These changes help give the language used in the interface
a consistent, more professional feel.
Differential Revision: https://developer.blender.org/D9923
|
|
Approximately 33 changes of capitalization to conform to MLA title style.
Differential Revision: https://developer.blender.org/D9796
Reviewed by Julian Eisel
|
|
Correct usage of compound modifiers like '32-bit'.
Differential Revision: https://developer.blender.org/D9769
Reviewed by Julian Eisel
|
|
|
|
Corrects incorrect usages of the words 'then' and 'than'.
Differential Revision: https://developer.blender.org/D9246
Reviewed by Campbell Barton
|
|
Follow our code style guide by using C-comments for text descriptions.
|
|
Cleanup old tracker task format to the new. e.g: [#34039] to T34039
Ref D8718
|
|
Forgot that arc land also did the pus ot originh.
|
|
I created a bugreport T80859 earlier.
The problem is in the file source/blender/editors/sculpt_paint/paint_image_proj.c (line numbers against commit d376aea61)
at the lines 5309 and 5320 the functions `IMB_rect_from_float(...)` and `IMB_float_from_rect(...)` are called from threaded code on a shared ibuf.
However, ps->reproject_ibuf is shared between threads, so this is not thread-safe.
This is a race condition and leads to wrong output when projecting float data onto a uchar texture or vice versa on a multithreaded system.
The checks on line 5308 and 5319 are already a race condition.
I created this patch which fixes the problem , but I'm not sure if I'm overlooking something.
This makes sure reproject_ibuf contains the correct formats *before* the threadpool is started.
I replaced the original location of the conversions with BLI_asserts(). That may be overkill?
Reviewed By: #sculpt_paint_texture, mont29
Maniphest Tasks: T80859
Differential Revision: https://developer.blender.org/D8936
|
|
Those two functions had `BKE_` prefix, were defined in BKE headers, but
implemented in ED code, yuck.
Moved everything to ED area for now, since those do not look fondamental
enough to belong to BKE, and none of their usages requires it currently.
|
|
As noted by @lichtwerk (thanks), one can have a local object and/or
material using a linked image data-block, this case needs some different
handling to prevent painting on such linked image.
For now, tweak `BKE_paint_proj_mesh_data_check` (eeeek, that name
prefix!) to consider paintslots with linked image as 'non-existing'.
|
|
Mainly use false/true for bool, but also a few others.
No change in behavior expected.
|
