| Age | Commit message (Collapse) | Author |
|---|
|
Use a more direct method of checking if a matrix is negative instead of
using cross & dot product.
Also replace some determinant_m3() < 0 checks with is_negative_m3.
|
|
|
|
|
|
|
|
Since {rB2542fda14d85}, `r_node` is an unused parameter.
Changed `load_texture_image` to reflect that.
Differential Revision: https://developer.blender.org/D15759
|
|
|
|
Metaball, curve, text, and surface objects use the geometry component
system to add evaluated mesh object instances to the dependency graph
"for render engine" iterator. Therefore it is unnecessary to process
those object types in these loops-- it would either be redundant work
or a no-op.
|
|
With the ultimate goal of simplifying drawing and evaluation,
this patch makes the following changes and removes code:
- Use `Mesh` instead of `DispList` for evaluated basis metaballs.
- Remove all `DispList` drawing code, which is now unused.
- Simplify code that converts evaluated metaballs to meshes.
- Store the evaluated mesh in the evaluated geometry set.
This has the following indirect benefits:
- Evaluated meshes from metaball objects can be used in geometry nodes.
- Renderers can ignore evaluated metaball objects completely
- Cycles rendering no longer has to convert to mesh from `DispList`.
- We get closer to removing `DispList` completely.
- Optimizations to mesh rendering will also apply to metaball objects.
The vertex normals on the evaluated mesh are technically invalid;
the regular calculation wouldn't reproduce them. Metaball objects
don't support modifiers though, so it shouldn't be a problem.
Eventually we can support per-vertex custom normals (T93551).
Differential Revision: https://developer.blender.org/D14593
|
|
|
|
Also renammed some parameters and sprinkled a dash of documentation.
|
|
|
|
While fixing T100302 (rBd76583cb4a1) I did not realize that the
change in imported vertex order would actually matter. Turns out, it
does for morph targets / mesh shape keys. So redo the fix in a way
that does not change the vertex order. Fixes T100421.
|
|
|
|
This commit moves the hide status of mesh vertices, edges, and faces
from the `ME_FLAG` to optional generic boolean attributes. Storing this
data as generic attributes can significantly simplify and improve code,
as described in T95965.
The attributes are called `.hide_vert`, `.hide_edge`, and `.hide_poly`,
using the attribute name semantics discussed in T97452. The `.` prefix
means they are "UI attributes", so they still contain original data
edited by users, but they aren't meant to be accessed procedurally by
the user in arbitrary situations. They are also be hidden in the
spreadsheet and the attribute list by default,
Until 4.0, the attributes are still written to and read from the mesh
in the old way, so neither forward nor backward compatibility are
affected. This means memory requirements will be increased by one byte
per element when the hide status is used. When the flags are removed
completely, requirements will decrease when hiding is unused.
Further notes:
* Some code can be further simplified to skip some processing when the
hide attributes don't exist.
* The data is still stored in flags for `BMesh`, necessitating some
complexity in the conversion to and from `Mesh`.
* Access to the "hide" property of mesh elements in RNA is slower.
The separate boolean arrays should be used where possible.
Ref T95965
Differential Revision: https://developer.blender.org/D14685
|
|
Implemented the same way as STL or GPencil SVG importers: loop over
the input files, import one by one.
Has been requested by the community for quite a long time
(e.g. https://blender.community/c/rightclickselect/Jhbbbc/), as well
as 3rd party addons to implement just this
(https://github.com/p2or/blender-batch-import-wavefront-obj).
|
|
|
|
textures are present
Report T98781 and part of T97642: the MTLMaterial info only captures
image nodes and the default socket values. When the image information
is present, do not emit the socket defaults - the .MTL spec states
they are multiplied together, but the default value is not used
in blender when the socket is connected.
Also contains svn tests repository update to extend the test coverage,
and update test expectation outputs.
|
|
|
|
While T77801 itself is working as expected in the new C++ obj
importer, the repro file there uses absolute paths to material images,
yet the images themselves are right there in the current folder.
The old python based importer did find them, since it was doing a
really complex image search. My understanding is that while C++
importer was developed, it was decided to not do that -- however
just the "basename file in the mtl directory" sounds simple enough
and gets the repro case file work correctly.
|
|
|
|
span a continuous range
As part of the previous fix (D15410), the importer got code to track
min & max vertex indices used as part of the mesh faces. However, if
faces refer to a "sparse" (i.e. non-contiguous) subset of all vertices,
then the imported mesh would contain all the vertices between min & max
range.
Replace that with proper tracking of actually used vertex indices
for each imported mesh. Fixes T100302.
This does affect import performance a tiny bit, e.g. importing Blender
3.0 splash scene goes 21.7s -> 22.1s, and importing rungholt.obj
goes 2.37s -> 2.48s.
Importer related tests have a bunch of vertex changes in them, since
now vertices are added in the order that the faces are referring
to them. Which incidentally matches the order that the Python based
importer was creating them too.
|
|
|
|
|
|
|
|
Added logic to the USD Preview Surface importer to
convert UDIM textures.
Reviewed by: Sybren and Jesse
Differential Revision: https://developer.blender.org/D15379
|
|
NOTE: This is committed to the 3.3 branch as part of D15606, which we
decided should go to this release still (by Bastien, Dalai and me). That
is because these are important usability fixes/improvements to have for
the LTS release.
Adds `rna_path.cc` and `RNA_path.h`.
`rna_access.c` is a quite big file, which makes it rather hard and
inconvenient to navigate. RNA path functions form a nicely coherent unit
that can stand well on it's own, so it makes sense to split them off to
mitigate the problem. Moreover, I was looking into refactoring the quite
convoluted/overloaded `rna_path_parse()`, and found that some C++
features may help greatly with that. So having that code compile in C++
would be helpful to attempt that.
Differential Revision: https://developer.blender.org/D15540
Reviewed by: Brecht Van Lommel, Campbell Barton, Bastien Montagne
|
|
|
|
|
|
|
|
The Python based exporter was replacing spaces with underscores
in object/group names, mostly to handle cases where names could begin
or end with spaces. The new exporter was not doing that. Note: spaces
in material names were already handled by the new exporter.
Fixes T97769. Updated test coverage expectations; one of the test
files has an object with a space in the name.
|
|
The variable can never be NULL and the comparison was wrong.
|
|
|
|
Since 1a81d268a19f2f140, materials on object data can change during
evaluation. But a different function is necessary to retrieve materials
taking that into account.
Solves part of T96721.
Differential Revision: https://developer.blender.org/D15595
|
|
For SVG is very convenient to be able to import several SVG in one operation. Each SVG is imported as a new Grease Pencil object.
Also, now the SVG file name is used as Object name.
Important: As all SVG imported are converted to Grease Pencil object in the same location of the 3D cursor, the SVG imported are not moved and the result may require a manual fix of location. The same is applied for depth order, the files are imported in alphabetic order according to the File list.
Reviewed By: mendio, pepeland
Differential Revision: https://developer.blender.org/D14865
|
|
|
|
Python based OBJ importer, as well as glTF2 importer, are creating
"placeholder" images for texture images that can't be found. These
are empty textures (displayed as magenta), but with their file paths
set so that File > External Data > Report Missing Files can report
them as missing.
Make the new C++ OBJ importer do the same as well. Fixes T99502.
|
|
This is a partial fix for T90535.
USD allows binding materials generically as well as for a
specific purpose. I.e., purpose may be generic (unspecified)
or one of
- Full: truest representation of the scene
- Preview: lightweight material for preview
Curently, only generically bound materials, with unspecified
purpose (allPurpose), are imported. This issue is preventing
preview materials from being imported in the Alab scene.
This patch adds logic to attempt to fall back on importing
preview or full materials, in that order, if there is no
generic material bound to the mesh.
Reviewed by: Sybren
Differential Revision: https://developer.blender.org/D15352
|
|
|
|
The Python based importer had logic to immediately turn image paths
into relative-to-blender-file paths, if user preference for relative
paths is used (which is on by default). The new importer code did not
have that. Fixes T100076.
|
|
|
|
The new OBJ/MTL importer was creating a new image for any referenced
texture, even if another material (or another property of the same
material) already referenced the same texture. Make it use
BKE_image_load_exists function just like Collada or USD importers do.
Fixes T100075. Extended test coverage to count imported images;
without the fix import_cubes_with_textures_rel would have incorrectly
created 5 images instead of 4.
|
|
|
|
Adds `rna_path.cc` and `RNA_path.h`.
`rna_access.c` is a quite big file, which makes it rather hard and
inconvenient to navigate. RNA path functions form a nicely coherent unit
that can stand well on it's own, so it makes sense to split them off to
mitigate the problem. Moreover, I was looking into refactoring the quite
convoluted/overloaded `rna_path_parse()`, and found that some C++
features may help greatly with that. So having that code compile in C++
would be helpful to attempt that.
Differential Revision: https://developer.blender.org/D15540
Reviewed by: Brecht Van Lommel, Campbell Barton, Bastien Montagne
|
|
any face
The Python based importer had a special case handling of "no faces in
the whole file at all", where it ended up treating the whole file
as essentially a point-cloud-like object (just loose vertices, no
faces or edges). The new importer code was missing this special case.
Fixes T100017. Added gtest coverage that was failing without the fix.
|
|
The Alembic importer uses a linear search over the mesh edges to find
the right edge when setting edge creases. Although the complexity is
`O(m * n)`, with `m` being the number of creased edges, and `n` being
the number of edges, this can lead to a quadratic complexity as `m`
approches `n`.
This patch uses `EdgeHash` to store and retrieve the edges, which
should bring complexity closer to `O(n)`, provided that lookup is
`O(1)`.
See differential for some timings. In most files, this is expected
to give at least a 2-3x speedup for this operation, but can lead
orders of magnitude speed increase for dense meshes with a significant
number of edge creases.
Differential Revision: https://developer.blender.org/D15521
|
|
objects by name
Previously, when creating "very large" (tens-hundreds of thousands)
amounts of objects, the Blender code that was ensuring name
uniqueness was the bottleneck. That got recently addressed (D14162),
however now sorting of IDs by their names is the remaining bottleneck.
Name sorting code in Blender is optimized for the pattern where names
are inserted in already sorted order (i.e. objects expect to get added
near the end of the list). By doing this pre-sorting of objects
intended to get created by an importer (USD and OBJ, in this patch),
this sorting bottleneck can be largely removed, especially with very
high object counts.
Windows, Ryzen 5950X, import times:
- OBJ, splash screen scene (26k objects): 22.0s -> 20.7s
- USD, Disney Moana scene (250k objects): 585s -> 82.2s (10 minutes -> 1.5 minutes)
Reviewed By: Michael Kowalski, Howard Trickey
Differential Revision: https://developer.blender.org/D15506
|
|
Also rearrange some lines to simplify logic.
|
|
Instead of duplicating logic many times.
|
|
Rename and refactor several F-curve key manipulation functions, and move
them from `editors` to `blenkernel`.
The functions formerly known as `delete_fcurve_key`,
`delete_fcurve_keys`, and `clear_fcurve_keys` have been moved from
`ED_keyframes_edit.h` to `BKE_fcurve.h` and have been renamed according
to hierarchical naming rules.
Below is a table of the naming changes.
| From | To |
| -- | -- |
| `delete_fcurve_key(fcu, index, do_recalc)` | `BKE_fcurve_delete_key(fcu, index)` |
| `delete_fcurve_keys(fcu)` | `BKE_fcurve_delete_keys_selected(fcu)` |
| `clear_fcurve_keys(fcu)` | `BKE_fcurve_delete_keys_all(fcu)` |
| `calchandles_fcurve()` | `BKE_fcurve_handles_recalc()` |
| `calchandles_fcurve_ex()`| `BKE_fcurve_handles_recalc_ex()` |
The function formerly known as `delete_fcurve_key` no longer takes a
`do_fast` parameter, which determined whether or not to call
`calchandles_fcurve`. Now, the responsibility is on the caller to run
the new `BKE_fcurve_handles_recalc` function if they have want to
recalculate the handles.
In addition, there is now a new static private function called
`fcurve_bezt_free` which sets the key count to zero and frees the key
array. This function is now used in couple of instances of functionally
equivalent code. Note that `BKE_fcurve_delete_keys_all` is just a
wrapper around `fcurve_bezt_free`.
This change was initially spurred by the fact that `delete_fcurve_keys`
was improperly named; this was a good opportunity to fix the location
and naming of a few of these functions.
Reviewed By: sybren
Differential Revision: https://developer.blender.org/D15282
|
|
|
