If the RNA path of a Single Property variable goes through a pointer
to a different ID, the property should be attached to that ID using
the owner reference in the RNA pointer. This already happened when
building some, but not all of the relations and nodes.
This patch fixes the remaining cases.
Differential Revision: https://developer.blender.org/D15323
The viewport compositor crashes when it is disabled then enabled after
the compositor node tree is edited.
This happens because the compositor engine uses the view_update callback
of the draw engine type to detect changes in the node tree and reset its
state for future evaluation. However, the draw manager only calls the
view_update callback for enabled engines, so the compositor never
receives the needed updates to properly reset its state and then crashes
at draw time.
This patch call the view_update callback for all registered engines
regardless if they are enabled or not, that way, they always receive
the potentially important updated needed to maintain a correct state.
Aside from the compositor engine, this change affects the EEVEE and
Workbench engines because they are the only engines that utilizes this
callback. However, both of them only reset a flag that is checked at
draw time. So the change should have no side effects. For the EEVEE
engine, we just add a null check in case it was not instanced, while
Workbench already have the appropriate null check.
Differential Revision: https://developer.blender.org/D15821
Reviewed By: Clement Foucault
This patch moves material indices from the mesh `MPoly` struct to a
generic integer attribute. The builtin material index was already
exposed in geometry nodes, but this makes it a "proper" attribute
accessible with Python and visible in the "Attributes" panel.
The goals of the refactor are code simplification and memory and
performance improvements, mainly because the attribute doesn't have
to be stored and processed if there are no materials. However, until
4.0, material indices will still be read and written in the old
format, meaning there may be a temporary increase in memory usage.
Further notes:
* Completely removing the `MPoly.mat_nr` after 4.0 may require
changes to DNA or introducing a new `MPoly` type.
* Geometry nodes regression tests didn't look at material indices,
so the change reveals a bug in the realize instances node that I fixed.
* Access to material indices from the RNA `MeshPolygon` type is slower
with this patch. The `material_index` attribute can be used instead.
* Cycles is changed to read from the attribute instead.
* BMesh isn't changed in this patch. Theoretically it could be though,
to save 2 bytes per face when less than two materials are used.
* Eventually we could use a 16 bit integer attribute type instead.
Ref T95967
Differential Revision: https://developer.blender.org/D15675
This change makes it so that objects which are temporary hidden from
the viewport (the icon toggle in outliner) do not affect on the
performance of the viewport.
The attached file demonstrates the issue. Before this change hiding
the object does not change FPS, after this change FPS goes high when
the object is hidden.
F13435936
Changing the object temporary visibility is already expected to tag
scene for bases updates, which flushes down the stream to the object
visibility update. So the only remaining topic was to ensure the
graph does a special round of visibility update on such changes.
Differential Revision: https://developer.blender.org/D15813
While it is hard to measure the performance impact accurately, there
is no need to perform per-modifier string lookup on every frame update.
Implemented as an exceptional case in the code which flushes updates to
the entire component. Sounds a bit suboptimal, but there are already
other exception cases handled in the function.
Differential Revision: https://developer.blender.org/D15812
From the 3DView code has basically no knowledge of collection hierarchy,
so we can either not remap any local usage of linked objects that are
being overridden, or remap them in all their local collections.
The second behavior makes most sense in the vast majority of cases.
Note that this was only an issue when directly linking and overriding
objects, not when doing so through collections.
The purpose of `NodeTreeRef` was to speed up various queries on a read-only
`bNodeTree`. Not that we have runtime data in nodes and sockets, we can also
store the result of some queries there. This has some benefits:
* No need for a read-only separate node tree data structure which increased
complexity.
* Makes it easier to reuse cached queries in more parts of Blender that can
benefit from it.
A downside is that we loose some type safety that we got by having different
types for input and output sockets, as well as internal and non-internal links.
This patch also refactors `DerivedNodeTree` so that it does not use
`NodeTreeRef` anymore, but uses `bNodeTree` directly instead.
To provide a convenient API (that is also close to what `NodeTreeRef` has), a
new approach is implemented: `bNodeTree`, `bNode`, `bNodeSocket` and `bNodeLink`
now have C++ methods declared in `DNA_node_types.h` which are implemented in
`BKE_node_runtime.hh`. To make this work, `makesdna` now skips c++ sections when
parsing dna header files.
No user visible changes are expected.
Differential Revision: https://developer.blender.org/D15491
This checks for the availability of `gl_BaseInstanceARB` or equivalent.
Disabling for any workaround that disables shader_image_load_store_support
as a preventive measure.
The case when the query uv is almost on an edge but outside of any
triangle was handled before. Now the case where the query uv is
almost on an edge but inside more than one triangle is handled as well.
I want to add support for PBR materials extension to OBJ, but the way
current I/O code syntax handling was done made it quite cumbersome
to extend the number of MTL textures/parameters.
Simplify all that by removing FormatHandler template on "syntax"
that gets routed through keyword enums, and instead just have
simple `write_obj_*` and `write_mtl_*` functions.
Simplify MTLMaterial to not contain a map of textures (that is always
fully filled with all possible textures), instead now there's
a simple array. Rename `tex_map_XX` to `MTLTexMap`.
All this does not affect behavior or performance, but it does result
in 170 fewer lines of code, and saves a couple kilobytes of executable
size.
While missing the break before a default that only breaks isn't
an error, it means adding new cases needs to remember to add the
break for an existing case, changing the default case will also
result in an unintended fall-through.
Also avoid `default:;` and add an explicit break.
This patch is a response to T92588 and is implemented
as a Function/Shader node.
This node has support for Float, Vector and Color data types.
For Vector it supports uniform and non-uniform mixing.
For Color it now has the option to remove factor clamping.
It replaces the Mix RGB for Shader and Geometry node trees.
As discussed in T96219, this patch converts existing nodes
in .blend files. The old node is still available in the
Python API but hidden from the menus.
Reviewed By: HooglyBoogly, JacquesLucke, simonthommes, brecht
Maniphest Tasks: T92588
Differential Revision: https://developer.blender.org/D13749
When creating a curves data-block, one is expected to set the new
position values. We can slightly improve performance by avoiding
doing that redundantly.
Similar to cccc6d6905.
The "write_only" (i.e. no reading) API function expects the caller to
set values for all new attribute elements, so using calloc or setting
the default value first is redundant. In theory this can improve
performance by avoiding an extra pass over the array. I observed a
6% improvement in a basic test with the mesh to points node:
from 47.9ms to 45ms on average.
See 25237d2625 for more info.
Similar to cccc6d6905.
In all these cases, it was clear that the layer values were set right
after the layer was created anyway. So there's no point in using
calloc or setting the values to zero first.
See 25237d2625 for more info.
If a "rest_position" attribute already existed, potentiall with another
type, the next name "rest_position.001" would be used, which might
even conflict with a name on another domain. Use the C++ attribute
API instead, which has more standard/predictable behavior.
