For mesh primitives, the bounds can be calculated trivially in advance
with negligible cost. In case they are needed later on, setting them
eagerly can save the calculation later on. For large meshes, this can
save tens of milliseconds before drawing.
Pull Request: https://projects.blender.org/blender/blender/pulls/105266
Some checks here are really critical and should assert, but that one is
more an indication that something is not going right, though data itself
should still be mostly valid, so better warn the user with a LOG
warning, than be silent in release builds, and crash in debug ones.
Fix seam bleeding of non-manifold sections of the mesh, by copying pixels
that are covered by the brush stroke.
As manifold parts are already handled, the pixel copying solution can be
very straight forward.
* Pixels are copied from the same tile. So we don't need a mechanism that
copies and merges pixels from other tiles.
* Pixels are copied from the closest pixel that is being painted on. We
don't need to consider that that pixel can be in different areas of the
tile.
When we copy a pixel, we find the closest pixel in UV space that is being
directly influenced by a paint brush. We also look for the second closest
pixel, which is still a neighbor from the closest pixel. We can mix both
pixels together and store it in the destination. A mix factor is calculated
using the closest non manifold edge as a guidance.
The result of this step is a list of copy and mix commands that can be
executed to fix the seam bleeding for non-manifold sections of the mesh.
| Destination | Source 1 | Source 2 | Mix factor |
| ----------- | -------- | -------- | ---------- |
| 1780,1811 | 1780,1810| 1779,1810| 0.000000 |
| 1781,1811 | 1781,1810| 1782,1811| 0.168627 |
| 1828,1811 | 1828,1810| 1827,1811| 0.156863 |
| 1829,1811 | 1829,1810| 1828,1810| 0.188235 |
| 1830,1811 | 1830,1810| 1829,1810| 0.188235 |
| 1831,1811 | 1831,1810| 1830,1810| 0.188235 |
| 1832,1811 | 1832,1810| 1831,1810| 0.188235 |
| 1833,1811 | 1832,1810| 1832,1810| 0.000000 |
In the end we go over this list mix the sources and store the result at
the destination.
```
tile_buffer[destination] = mix(tile_buffer[source_1],
tile_buffer[source_2],
mix_factor);
```
**Encoding**
When using a large textures or large seam margins this table can grow
large and reduce performance as data retrieval is slower, than the
operations it has to perform. To improve the performance we encode the
table so less data retrieval needs to be done.
* first `DeltaCopyPixelCommand` is delta encoded from
`CopyPixelGroup#start_destination` and `start_source_1`. The others
are delta encoded from the previous `DeltaCopyPixelCommand`.
* For performance reasons PixelCopyGroup#pixels are ordered from
destination (left to right) for each row a new group would be created
as the delta encoding most likely doesn't fit. When pixels cannot be
delta encoded a new group will also be created.
**Compression rate**
When using Suzanne the compression rate is around 36% when using a seam
margin of 4 pixels. The compression rate may vary depending on seam
margin and model. For Suzanne the compression rate was around 36% for
various resolutions.
| Resolution | Margin | Decoded size | Encoded size | Compression |
| ---------- | ------ | ------------ | ------------ | ----------- |
| 2048x2048 | 4 px | 353.052 | 128.101 | 36% |
| 4096x4096 | 4 px | 700.140 | 255.137 | 36% |
| 8192x8192 | 4 px | 1.419.320 | 513.802 | 36% |
| 2048x2048 | 8 px | 721.084 | 193.629 | 26% |
| 4096x4096 | 8 px | 1.444.968 | 388.110 | 26% |
Pull Request: https://projects.blender.org/blender/blender/pulls/105336
Move two settings that were previously in the "View" menu of the Graph Editor into User Preferences.
It has been mentioned in the meeting by Luciano Muñoz Sessarego that it would be good to move that to the preferences so you can set it once and then forget about it.
The Settings moved are:
Only Selected Curve Keyframes
Use High Quality Display
Pull Request: https://projects.blender.org/blender/blender/pulls/104532
- Both success & ok were used for file reading, use the clearer name.
- Paths were single/double quoted, use double quotes for print/reports.
- Rename `path` to `filepath` / `dirpath`.
Add a filepath argument to load/save pre/post.
Also add save_post_failed and load_post_failed handlers so it's always
possible to for the pre handlers to run a matching post action.
This makes it possible to know the filepath of the blend file mean
loaded/saved as well as supporting running an action when load/save
operations fail.
When loading and saving the startup-file, the path argument is set to
an empty string.
Details:
New RNA types were added to support storing primitive values in
PointerRNA. Primitive{String/Int/Float/Boolean}RNA. These will likely
only be used in some limited cases, in the case of BKE_callback_exec it
allows strings to be included as part of the PointerRNA **pointers
argument.
Ref !104769.
The attribute, like the other attributes that start with `.` is not
supposed to be displayed in the spreadsheet or the attribute list
by default. This was missing from the commit that added the attribute.
Currently the shade smooth status for mesh faces is stored as part of
`MPoly::flag`. As described in #95967, this moves that information
to a separate boolean attribute. It also flips its status, so the
attribute is now called `sharp_face`, which mirrors the existing
`sharp_edge` attribute. The attribute doesn't need to be allocated
when all faces are smooth. Forward compatibility is kept until
4.0 like the other mesh refactors.
This will reduce memory bandwidth requirements for some operations,
since the array of booleans uses 12 times less memory than `MPoly`.
It also allows faces to be stored more efficiently in the future, since
the flag is now unused. It's also possible to use generic functions to
process the values. For example, finding whether there is a sharp face
is just `sharp_faces.contains(true)`.
The `shade_smooth` attribute is no longer accessible with geometry nodes.
Since there were dedicated accessor nodes for that data, that shouldn't
be a problem. That's difficult to version automatically since the named
attribute nodes could be used in arbitrary combinations.
**Implementation notes:**
- The attribute and array variables in the code use the `sharp_faces`
term, to be consistent with the user-facing "sharp faces" wording,
and to avoid requiring many renames when #101689 is implemented.
- Cycles now accesses smooth face status with the generic attribute,
to avoid overhead.
- Changing the zero-value from "smooth" to "flat" takes some care to
make sure defaults are the same.
- Versioning for the edge mode extrude node is particularly complex.
New nodes are added by versioning to propagate the attribute in its
old inverted state.
- A lot of access is still done through the `CustomData` API rather
than the attribute API because of a few functions. That can be
cleaned up easily in the future.
- In the future we would benefit from a way to store attributes as a
single value for when all faces are sharp.
Pull Request: https://projects.blender.org/blender/blender/pulls/104422
Node tree updates can crash if the tree contains a node group that points at an "undefined" tree type.
This can happen if the tree is linked from a library and the path is lost,
or if a custom (python) tree is used and the script is not run.
The fix is to check if the node group type is valid ("registered") and return an empty list otherwise.
Pull Request: https://projects.blender.org/blender/blender/pulls/105564
- "Lines" in the sense of number of lines
- "Number" can mean "amount, count" or "index, offset"
- "Second" can be an ordinal number or a unit
- "Root": add the brush curve to the "square root falloff" sense
- "Strip" can be a sequence or a type of hair rendering
- "Constant" in the sense of a value, for the Geometry Nodes add
submenu (#105447).
Additionally, extract:
- "Press a key" from the Keymap preferences.
- "MaskLayer", upon new mask layer creation
Ref #43295, #105447
When investigating ID user-count issues, it wasn't clear how nodes
were meant to handle user-count for ID's. Specifically that the
initfunc should _not_ increment the ID's user count.
Don't call recursion where it's redundant. The recursive algorithm
can carry dangerous behavior due to stack growth and overflow. The
probability is low for something like the frame nodes. But using a loop
is cheap, providing O(N = const) memory cost. A loop through the links
in a singly linked list is sufficient. The use of 2D vectors for
location mapping and other things can be separate.
Pull Request #105394
This commit introduces a new Main boolean flag that marks is as invalid.
Higher-level file reading code does checks on this flag to abort reading
process if needed.
This is an implementation of the #105083 design task.
Given the extense of the change, I do not think this should be
considered for 3.5 and previous LTS releases.
Drivers: Introduce the Context Properties
The goal: allow accessing context dependent data, such as active scene camera
without linking to a specific scene data-block. This is useful in cases when,
for example, geometry node setup needs to be aware of the camera position.
A possible work-around without changes like this is to have some scene
evaluation hook which will update driver variables for the currently evaluating
scene. But this raises an issue of linking: it is undesirable that the asset
scene is linked to the shot file.
Surely, it is possible to have post-evaluation handler to clear the variables,
but it all starts to be quite messy. Not to mention possible threading
conflicts.
Another possibility of introducing a way to achieve the goal is to make it so
the dependency graph somehow parses the python expression where artists can
(and already are trying to) type something like:
depsgraph.scene.camera.matrix_world.col[3][0]
But this is not only tricky to implement properly and reliably, it hits two
limitations:
- Currently dependency graph can only easily resolve dependencies to a RNA
property.
- Some properties access which are valid in Python are not considered valid
RNA properties by the existing property resolution functions:
`camera.matrix_world[3][0]` is a valid RNA property, but
`camera.matrix_world.col[3][0]` is not.
Using driver variables allows to have visual feedback when the path resolution
fails, and there is no way to visualize errors in the python expression itself.
This change introduces the new variable type: Context Property. Using this
variable type makes allows to choose between Active Scene and Active View
Layer. These scene and view layer are resolved during the driver evaluation
time, based on the current dependency graph.
This allows to create a driver variable in the following configuration:
- Type: Context Property
- Context Property: Active Scene
- Path: camera.matrix_world[3][0]
The naming is a bit confusing. Tried my best to keep it clear keeping two
aspects in mind: using UI naming when possible, and follow the existing
naming.
A lot of the changes are related on making it so the required data is available
from the variable evaluation functions. It wasn't really clear what the data
would be, and the scope of the changes, so it is done together with the
functional changes.
It seems that there is some variable evaluation logic duplicated in the
`bpy_rna_driver.c`. This change does not change it. It is not really clear why
this separate code path with much more limited scope of supported target types
is even needed.
There is also a possible change in the behavior of the dependency graph: it
is now using ID of the resolved path when building driver variables. It used
to use the variable ID. In common cases they match, but when going into nested
data-blocks it is actually correct to use relation to the resolved ID. Not sure
if there was some code to ensure that, which now can be resolved. Also not sure
whether it is still needed to ensure the ID specified in the driver target is
build as well. Intuitively it is not needed.
Pull Request #105132
Currently, curves have a default offset of 1.0, while the initial (and
expected) value is 0.0. When resetting this value to its default, the
curve is now modified unexpectedly. This is most noticeable with text
objects: when resetting the offset of a new text, it will look very
broken.
Internally the value is stored with an offset of 1.0, with custom
setter and getter adding and subtracting 1.0 respectively. To give
this property a default of 0.0, we also need to add 1.0 to the initial
value upon curve creation.
Pull Request #105182
Unify both functions in one, with a more telling name,
to be sure of the order of the arguments. Some functional
cleanup of the using code to make it more explicit.
Pull Request #105413
During the discussion for #101413 there was consensus that we could make
OIIO a mandatory dependency. This patch does just that.
The `idiff` testing tool remains optional.
Pull Request #105111
Similar to the previous commit, this simplifies future refactoring
to change the way edges are stored, and further differentiates
single poly variables from array pointers.
A bulk change, to make things moving as quickly as possible, instead of
doing per-modified-file basis.
This is pretty much direct translation of C code to C++, is not really
"proper" C++ usage. That could happen on a more case-by-cases basis.
Pull Request #105376
Cleanup, try to always use const.
Many function signatures still have incorrect argument order
(constants, mutables). But this is a larger other cleanup.
Pull Request #104937
Increase the buffer sizes used for `BLI_str_format_uint64_grouped` to
prevent overflow on strings representing numbers within the uint64
range. Also creates and uses defines for all the formatted string
buffer sizes.
Pull Request #105263
