Welcome to mirror list, hosted at ThFree Co, Russian Federation.

git.blender.org/blender.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2022-08-17Cleanup: Remove redundant use of evaluated non-mesh objectsHans Goudey
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.
2022-08-17Metaball: Evaluate metaball objects as mesh componentsHans Goudey
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
2022-08-17Cleanup: strip blank lines around comment blocksCampbell Barton
2022-08-16Cleanup: use a structure for Alembic import parametersKévin Dietrich
Also renammed some parameters and sprinkled a dash of documentation.
2022-08-16Merge branch 'blender-v3.3-release'Aras Pranckevicius
2022-08-16Fix T100421: OBJ importer in 3.3 does not keep the vertex orderAras Pranckevicius
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.
2022-08-12Cleanup: repeated words in commentsCampbell Barton
2022-08-11Mesh: Move hide flags to generic attributesHans Goudey
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
2022-08-11obj: support importing multiple files at onceAras Pranckevicius
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).
2022-08-11Merge branch 'blender-v3.3-release'Aras Pranckevicius
2022-08-11Fix T98781: OBJ exporter wrongly writing default material socket values when ↵Aras Pranckevicius
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.
2022-08-10Merge branch 'blender-v3.3-release'Aras Pranckevicius
2022-08-10obj: Also find .mtl images by their basename, if all else fails (T77801)Aras Pranckevicius
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.
2022-08-10Merge branch 'blender-v3.3-release'Aras Pranckevicius
2022-08-10Fix T100302: New OBJ importer produces too many vertices when faces don't ↵Aras Pranckevicius
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.
2022-08-09Merge branch 'blender-v3.3-release'Campbell Barton
2022-08-09Fix memory leak exporting to colladaCampbell Barton
2022-08-09Cleanup: sort cmake file-listsCampbell Barton
2022-08-04T90535: import UDIM textures from USDMichael Kowalski
Added logic to the USD Preview Surface importer to convert UDIM textures. Reviewed by: Sybren and Jesse Differential Revision: https://developer.blender.org/D15379
2022-08-04Cleanup: Move RNA path functions into own C++ fileJulian Eisel
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
2022-08-04Merge branch 'blender-v3.3-release'Hans Goudey
2022-08-04Fix: Avoid OBJ importer assert seting normals on mesh with no facesHans Goudey
2022-08-03Merge branch 'blender-v3.3-release'Aras Pranckevicius
2022-08-03Fix T97769: new OBJ exporter does not replace spaces in object namesAras Pranckevicius
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.
2022-08-02GPencil: Fix compiler warningAntonio Vazquez
The variable can never be NULL and the comparison was wrong.
2022-08-02Merge branch 'blender-v3.3-release'Hans Goudey
2022-08-02Fix: Use evaluated materials in OBJ exporterHans Goudey
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
2022-08-02GPencil: Allow import several SVG at timeAntonio Vazquez
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
2022-08-01Merge branch 'blender-v3.3-release'Aras Pranckevicius
2022-08-01Fix T99502: OBJ/MTL import: behavior changed for missing texture filesAras Pranckevicius
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.
2022-08-01USD import: Handle material purposeMichael Kowalski
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
2022-08-01Merge branch 'blender-v3.3-release'Aras Pranckevicius
2022-08-01Fix T100076: OBJ import: new importer doesn't use //relative/image/pathsAras Pranckevicius
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.
2022-07-31Merge branch 'blender-v3.3-release'Aras Pranckevicius
2022-07-31Fix T100075: OBJ import: images loaded multiple times instead of being reusedAras Pranckevicius
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.
2022-07-30Cleanup: braces around statements in OBJ parserAras Pranckevicius
2022-07-29Cleanup: Move RNA path functions into own C++ fileJulian Eisel
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
2022-07-28Fix T100017: OBJ: new importer does not import vertices that aren't part of ↵Aras Pranckevicius
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.
2022-07-24Alembic: speed up edge crease importKévin Dietrich
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
2022-07-23IO: speed up import of large amounts of objects in USD/OBJ by pre-sorting ↵Aras Pranckevicius
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
2022-07-22Cleanup: Use r_ prefix for boolean return parametersHans Goudey
Also rearrange some lines to simplify logic.
2022-07-15Cleanup: add utlity function to compute render resolutionBrecht Van Lommel
Instead of duplicating logic many times.
2022-07-14Cleanup: Rename & refactor several F-curve functionsColin Basnett
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
2022-07-11Cleanup: spelling in commentsCampbell Barton
2022-07-10Fix T99532: New OBJ importer in some cases fails to import facesAras Pranckevicius
The importer code was written under incorrect assumption that vertex data (v, vn, vt commands etc.) are grouped by object, i.e. follow the o command, and that each object has its own vertex data commands. This is not the case -- all the vertex data in the whole OBJ file is "global", with no relation to any objects/groups; it's just that the faces belong to the object, and then they pull in any vertices they like. This patch fixes this incorrect assumption in the importer: - Vertex data is now properly global; no need to track some sort of "offsets" per object like it was doing before. - For each object, face definitions track the minimum & maximum vertex indices referenced by the object, and then all that vertex range is created in the final Blender object. Note: it might be (unusual, but possible) that an object does not reference a sequential range of vertices, e.g. just a single face with vertex indices 1, 10, 100 -- the resulting Blender mesh will have all the 100 vertices (some "loose" without belonging to a face). It should be possible to track the used vertices exactly (e.g. with a vector set), but I haven't done that for performance reasons. Reviewed By: Howard Trickey Differential Revision: https://developer.blender.org/D15410
2022-07-10Fix T99536: new 3.2 OBJ importer fails with trailing space after wrapped linesAras Pranckevicius
Address the issue by re-working line continuation handling: stop trying to parse sequences like "backslash, newline" (which is the bug: it should also handle "backslash, possible whitespace, newline") during parsing. Instead, fixup line continuations after reading chunks of input file data - turn backslash and the following newline into spaces. The rest of parsing code does not have to be aware of them at all then. Makes the file attached to T99536 load correctly now. Also will extend one of the test files in subversion tests repo to contain backslashes followed by newlines.
2022-07-08Geometry Nodes: new geometry attribute APIJacques Lucke
Currently, there are two attribute API. The first, defined in `BKE_attribute.h` is accessible from RNA and C code. The second is implemented with `GeometryComponent` and is only accessible in C++ code. The second is widely used, but only being accessible through the `GeometrySet` API makes it awkward to use, and even impossible for types that don't correspond directly to a geometry component like `CurvesGeometry`. This patch adds a new attribute API, designed to replace the `GeometryComponent` attribute API now, and to eventually replace or be the basis of the other one. The basic idea is that there is an `AttributeAccessor` class that allows code to interact with a set of attributes owned by some geometry. The accessor itself has no ownership. `AttributeAccessor` is a simple type that can be passed around by value. That makes it easy to return it from functions and to store it in containers. For const-correctness, there is also a `MutableAttributeAccessor` that allows changing individual and can add or remove attributes. Currently, `AttributeAccessor` is composed of two pointers. The first is a pointer to the owner of the attribute data. The second is a pointer to a struct with function pointers, that is similar to a virtual function table. The functions know how to access attributes on the owner. The actual attribute access for geometries is still implemented with the `AttributeProvider` pattern, which makes it easy to support different sources of attributes on a geometry and simplifies dealing with built-in attributes. There are different ways to get an attribute accessor for a geometry: * `GeometryComponent.attributes()` * `CurvesGeometry.attributes()` * `bke::mesh_attributes(const Mesh &)` * `bke::pointcloud_attributes(const PointCloud &)` All of these also have a `_for_write` variant that returns a `MutabelAttributeAccessor`. Differential Revision: https://developer.blender.org/D15280
2022-07-08Cleanup: Move mesh legacy conversion to a separate fileHans Goudey
It's helpful to make the separation of legacy data formats explicit, because it declutters actively changed code and makes it clear which areas do not follow Blender's current design. In this case I separated the `MFace`/"tessface" conversion code into a separate blenkernel .cc file and header. This also makes refactoring to remove these functions simpler because they're easier to find. In the future, conversions to the `MLoopUV` type and `MVert` can be implemented here for the same reasons (see T95965). Differential Revision: https://developer.blender.org/D15396
2022-07-07OBJ: more robust .mtl texture offset/scale parsing (T89421)Aras Pranckevicius
As pointed out in a comment on T89421, if a MTL file contained something like: `map_Ka -o 1 2.png` then it was parsed as having offset `1 2` and the texture filename just a `.png`. Make it so that mtl option numbers are parsed in a way where the number is only accepted only if it's followed by whitespace. Differential Revision: https://developer.blender.org/D15385
2022-07-07OBJ: always set eevee blend mode when material "d" is below 1.0Aras Pranckevicius
Fixes T97743: the import code was setting EEVEE blending mode whenever a transparency texture was present (map_d), or when the materials illum was saying "yo, transparency!". But if only the material's d was below 1.0, it was not setting the blend mode, which is different to user expectations. Differential Revision: https://developer.blender.org/D15383