Since UVs are now stored as 2D vectors in meshes, they can be copied
directly to the vertex buffers. Somewhat surprisingly, multithreading
the copying into the vertex buffer provides a good speedup-- on a CPU
with many cores at least.
Here is a test uploading two UV maps created in geometry
nodes with a 1 million quad mesh, with a Ryzen 7950x:
| | Before | After | Speedup |
| ------- | ------- | ------ | ------- |
| Average | 24.3 ms | 7.5 ms | 3.2x |
| Min | 17.6 ms | 7.0 ms | 2.5x |
I added the copying utilities to the array utils header, since the
need for them has come up in a few different places already, and the
existing function with a selection argument didn't make sense here.
Pull Request: https://projects.blender.org/blender/blender/pulls/105793
When deleting UV UI attributes it isn't necessary to use the higher
level C attribute API, since we already know we aren't working with
the edit mesh here.
There were logic errors and use-after-free errors with the attribute
removal function. Because the custom data layers are reallocated,
we can't reuse the name pointer after removing an attribute. And
we can't return early on the first domain to fail for the edit mode
implementation, because another domain might have the attribute.
Also reorganize some of the code to make the logic clearer: only remove
sub-attribuutes and change attribute names after actually removing the
attribute,and assert if the attribute isn't removed after it is found.
Geometry Nodes: SDF Volume nodes milestone 1
Adds initial support for SDF volume creation and manipulation.
`SDF volume` is Blender's name of an OpenVDB grid of type Level Set.
See the discussion about naming in #91668.
The new nodes are:
- Mesh to SDF Volume: Converts a mesh to an SDF Volume
- Points to SDF Volume: Converts points to an SDF Volume
- Mean Filter SDF Volume: Applies a Mean Filter to an SDF
- Offset SDF Volume: Applies an offset to an SDF
- SDF Volume Sphere: Creates an SDF Volume in the shape of a sphere
For now an experimental option `New Volume Nodes` needs to be
enabled in Blender preferences for the nodes to be visible.
See the current work plan for Volume Nodes in #103248.
Pull Request: https://projects.blender.org/blender/blender/pulls/105090
The crash is fixed by reverting 87fd798ae3 and
some follow up commits. While it would generally be nice to move to a more
SoA format for these things, we are not there yet and this is causing more
trouble than it's worth currently. The main difficulty is that the socket
indices are changed by many different operations which invalidates the array
too often and led to many follow up bugs.
Pull Request: https://projects.blender.org/blender/blender/pulls/105877
Change code fragments where `BKE_mesh_vert_coords_alloc` had been used
to temporarily copy vertex coordinates of a mesh (see #103789) and
providd pointers to the mesh's stored vertex positions instead.
This reduces memory usage and improves performance.
Pull Request: https://projects.blender.org/blender/blender/pulls/105756
Implement GBuffer prepass and deferred lighting (lights only).
This decouple lighting from the material shaders making them lighter,
less expensive and faster to compile.
Trying to keep a nice data flow so we could potentially use the
subpass programable blending feature on tiled GPU arch.
Not everything is covered yet and #105880 is making the GBuffer layout
a bit awkward and not easily extendable.
Pull Request: https://projects.blender.org/blender/blender/pulls/105868
Changed `edge->v2` to `endVert` to make it consistent with surrounding code.
Removed the unused `totedges` variable.
Currently `totpoly` is also unused, but is fixed in a separate PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/105870
Follow connections when reading the varname attribute of a primvar
reader, and support both string and TfToken types for the varname.
A unit test is also provided.
Authored by Apple: Matt McLin
Pull Request: https://projects.blender.org/blender/blender/pulls/105508
This was lost in the refactor to store material indices in a generic attribute.
The attribute API still allows this, but that will be handled separately
since it's a more complex task. The existing API that already clamped
input values should still do that.
Other areas like blenkernel and Cycles clamp the material indices to be
positive so this should be consistent with them. There is still discussion
if material indices should be made impossible, but this at least avoids
crashing for the 3.5 release.
There was also an inconsistency in how sculpt mode handles material index
higher than the number of slots.
Ref #105577
This flag is moved to a different variable but the default value is still placed on the wrong variable.
This fixes the default value assignment but due to the old flag bits are in conflict with used bits in the new flag variables, versioning changes are not included.
Pull Request: https://projects.blender.org/blender/blender/pulls/105852
1) There was a logic error in FileBuffer where when it was trying to
add a new 64kb chunk to hold output, it was adding an empty chunk,
but making sure we have space capacity to hold 64 thousand chunks.
So that was a bit of pointless juggling to get nothing good.
2) In UV_vertex_key, instead of trying to combine three members into
a hash value, badly, by doing some ad-hoc shifts and xors, use
get_default_hash_3 instead, which combines them way more properly.
Also avoid copying the whole hash map object.
On my windows box (Ryzen 5950X, VS2022), exporting Stanford Lucy 3D
scan:
- Binary: 13.4 -> 5.4 sec
- ASCII: 29.3 -> 14.6 sec
So basically 2x faster for two tiny changes.
When multiple nodes (Frame nodes included in the selection) are scaled/
rotated, the TransData location and center can get "wrong" due to the
fact that Frame nodes dont only use `locx`/`locy` for their
representation while drawing, but also `offsetx`/`offsety`.
So in order to use the "real" top-left corner in the transform system,
we have to respect `offsetx`/`offsety` when creating/flushing transform
data.
In addition to the file in the report, this patch was also tested to work
well with nested Frame nodes.
Pull Request: https://projects.blender.org/blender/blender/pulls/105400
Fixes:
* General:
- Was assuming that positions/normals/UVs are always `float`, and colors
are always `uchar`. But e.g. positions are sometimes doubles, or colors
are floats etc.
- Was assuming that `face` element is always just a single vertex indices
property. But some files have more arbitrary properties per-face.
* ASCII importer:
- Was assuming that file elements are always in this order: `vertex`,
`face`, `edge`. That is not necessarily the case.
- Was only handling space character as separator, but not other
whitespace e.g. tab.
- Was not checking for partially present properties (e.g. if just `nx` is
present but not `ny` and `nz`, it was still assuming whole normal is there).
* Binary importer:
- Was assuming that faces are always 1-byte list size and 4-byte indices.
- Was assuming that edge vertex indices are always 4-byte.
For the assumptions above, it often lead to either crashes, garbage data
or not detecting presence of a vertex component. E.g. binary importer was
just always reading 4 bytes for vertex indices, but if a file has 2 byte
indices then that would read too much, and then later on would start reading
garbage. ASCII importer was doing out-of-bounds reads into properties array
if some assumptions were not correct, etc.
Improvements:
- Some ply files use different property type names, e.g. `float32`,
`uint16` or `int8` instead of `float`, `ushort`, `char`; now that is
supported too.
- Handles `tristrips` element. Some files out there do not have `face` but
rather has a triangle strip, internally using -1 indices for strip restarts.
Performance:
While doing the above fixes/improvements, in order to fix some things it was
more convenient to also make them more performant :) Now it avoids splitting
each ASCII line into a vector of `std::string` objects, for example, or
reading a binary file in tiny chunks.
Generally this is now 2x-4x faster than the previous state of C++ importer.
The code has changed quite a bit to achieve both the fixes and performance:
- Instead of separate files for ASCII and Binary reading, they are now both
in `ply_import_data.cc/hh`. Reason is that all of the "find correct property
indices" logic is the same between both (and that bit was mostly missing
previously).
- Instead of using raw C++ `fstream` object and reading line by line (which
in turn reads one byte at a time) or reading field by field, now there's a
`ply_import_buffer.cc/hh` that reads in 64KB chunks and does any needed
logic for the ASCII/header part to properly split into lines. This avoids
all the mutex locking, locale lookups, C++ abstraction layers overhead
that C++ iostreams have when doing a ton of tiny reads.
Tests:
Extended test coverage with new files (comitted in svn revision 63274).
11 new "situations", in both ascii and binary forms. Additionally, now also
has a Big Endian binary file to test; BE codepath was completely untested
before.
Overall reworked the tests so that they don't do the whole "load dummy
blend file, import ply file on top, go over meshes, check them", but rather
do a simpler "run ply importer logic that fills in PlyData structure, check
that". The followup conversion to blender meshes is fairly trivial and the
tests were not really covering that in a useful way.
Pull Request: https://projects.blender.org/blender/blender/pulls/105842
Viewer node paths usually start with the modifier, but in pinned
node editors the tree may not be used by the object in context.
In that case the modifier part of the path should be ignored.
The viewer node is always disabled in that case.
Pull Request: https://projects.blender.org/blender/blender/pulls/105826
