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-02-11File headers: SPDX License migrationCampbell Barton
Use a shorter/simpler license convention, stops the header taking so much space. Follow the SPDX license specification: https://spdx.org/licenses - C/C++/objc/objc++ - Python - Shell Scripts - CMake, GNUmakefile While most of the source tree has been included - `./extern/` was left out. - `./intern/cycles` & `./intern/atomic` are also excluded because they use different header conventions. doc/license/SPDX-license-identifiers.txt has been added to list SPDX all used identifiers. See P2788 for the script that automated these edits. Reviewed By: brecht, mont29, sergey Ref D14069
2022-01-13Refactor: Move normals out of MVert, lazy calculationHans Goudey
As described in T91186, this commit moves mesh vertex normals into a contiguous array of float vectors in a custom data layer, how face normals are currently stored. The main interface is documented in `BKE_mesh.h`. Vertex and face normals are now calculated on-demand and cached, retrieved with an "ensure" function. Since the logical state of a mesh is now "has normals when necessary", they can be retrieved from a `const` mesh. The goal is to use on-demand calculation for all derived data, but leave room for eager calculation for performance purposes (modifier evaluation is threaded, but viewport data generation is not). **Benefits** This moves us closer to a SoA approach rather than the current AoS paradigm. Accessing a contiguous `float3` is much more efficient than retrieving data from a larger struct. The memory requirements for accessing only normals or vertex locations are smaller, and at the cost of more memory usage for just normals, they now don't have to be converted between float and short, which also simplifies code In the future, the remaining items can be removed from `MVert`, leaving only `float3`, which has similar benefits (see T93602). Removing the combination of derived and original data makes it conceptually simpler to only calculate normals when necessary. This is especially important now that we have more opportunities for temporary meshes in geometry nodes. **Performance** In addition to the theoretical future performance improvements by making `MVert == float3`, I've done some basic performance testing on this patch directly. The data is fairly rough, but it gives an idea about where things stand generally. - Mesh line primitive 4m Verts: 1.16x faster (36 -> 31 ms), showing that accessing just `MVert` is now more efficient. - Spring Splash Screen: 1.03-1.06 -> 1.06-1.11 FPS, a very slight change that at least shows there is no regression. - Sprite Fright Snail Smoosh: 3.30-3.40 -> 3.42-3.50 FPS, a small but observable speedup. - Set Position Node with Scaled Normal: 1.36x faster (53 -> 39 ms), shows that using normals in geometry nodes is faster. - Normal Calculation 1.6m Vert Cube: 1.19x faster (25 -> 21 ms), shows that calculating normals is slightly faster now. - File Size of 1.6m Vert Cube: 1.03x smaller (214.7 -> 208.4 MB), Normals are not saved in files, which can help with large meshes. As for memory usage, it may be slightly more in some cases, but I didn't observe any difference in the production files I tested. **Tests** Some modifiers and cycles test results need to be updated with this commit, for two reasons: - The subdivision surface modifier is not responsible for calculating normals anymore. In master, the modifier creates different normals than the result of the `Mesh` normal calculation, so this is a bug fix. - There are small differences in the results of some modifiers that use normals because they are not converted to and from `short` anymore. **Future improvements** - Remove `ModifierTypeInfo::dependsOnNormals`. Code in each modifier already retrieves normals if they are needed anyway. - Copy normals as part of a better CoW system for attributes. - Make more areas use lazy instead of eager normal calculation. - Remove `BKE_mesh_normals_tag_dirty` in more places since that is now the default state of a new mesh. - Possibly apply a similar change to derived face corner normals. Differential Revision: https://developer.blender.org/D12770
2021-12-25Cleanup: use new c++ guarded allocator APIAaron Carlisle
API added in rBa3ad5abf2fe85d623f9e78fefc34e27bdc14632e
2021-12-15Fix meta-ball bound-box calculation reading past buffer boundsCampbell Barton
This broke "test_undo.view3d_multi_mode_select" test in "lib/tests/ui_simulate" and is likely exposed by recent changes to bounding box calculation. The missing check for DL_INDEX4 dates back to code from 2002 which intended to check this but was checking for DL_INDEX3 twice which got removed as part of a cleaned up. This could be hidden from memory checking tools as meta-balls over-allocate vertex arrays.
2021-12-07Cleanup: move public doc-strings into headers for 'blenkernel'Campbell Barton
- Added space below non doc-string comments to make it clear these aren't comments for the symbols directly below them. - Use doxy sections for some headers. - Minor improvements to doc-strings. Ref T92709
2021-12-02Cleanup: Rename curve struct fieldsHans Goudey
These existing names were unhelpful at best, actively confusing at worst. This patch renames them to be consistent with the terms used to refer to the values in the UI. - `width` -> `offset` - `ext1` -> `extrude` - `ext2` -> `bevel_radius` Differential Revision: https://developer.blender.org/D9627
2021-11-29Fix T93384: Objects with Constraints to curves have wrong locations on file loadSergey Sharybin
Regression since 3.93 caused by 752c6d668bcb. Follow the code from 2.93 which was always leaving curve modifiers evaluation with a valid and clean state of the bounding box. This is also what was proposed and agreed on in the following design task: T92206: Bounding Box: compute during depsgraph evaluation Tested with files from T90808 and T93384. For the 3.0 going with the safest and minimal change. The rest of the bounding box un-entanglement is to happen outside of the stable branch. Thanks The patch is based on the code from Philipp Oeser and investigation by Germano Cavalcante and Dr. Sybren A. Stüvel, thanks! Differential Revision: https://developer.blender.org/D13409
2021-11-24Fix T90808: wrong BoundBox after undo curve selectionGermano Cavalcante
There are two functions that recalculate the boundbox of an object: - One that considers the evaluated geometry - Another that only considers the object's `data`. Most of the time, the bound box is calculated on the final object (with modifiers), so it doesn't seem right to just rely on `ob->data` to recalculate the `ob->runtime.bb`. Be sure to calculate the BoundBox based on the final geometry and only use `ob->data` as a fallback Differential Revision: https://developer.blender.org/D12282
2021-11-05Fix T92815: Incorrect handling of evaluated meshes from curvesHans Goudey
Evaluated meshes from curves are presented to render engines as separate instance objects now, just like evaluated meshes from other object types like point clouds and volumes. For that reason, cycles should not consider curve objects as geometry (previously it did, meaning it retrieved a second mesh from the curve object as well as the temporary evaluated mesh geometry). Further, avoid adding a curve object's evaluated mesh as data_eval, since that is special behavior for meshes that is arbitrary. Adding an evaluated mesh there but not an evalauted pointcloud is arbitrary, for example. Retrieve the evaluated mesh in from the geometry set in BKE_object_get_evaluated_mesh now, to support that change. This gets us closer to a place where all of an object's evaluated data is stored in geometry_set_eval, and we just have helper functions to access specific geometry components. Differential Revision: https://developer.blender.org/D13118
2021-10-06Cleanup: rename BKE_font.h -> BKE_vfont.hCampbell Barton
Match API naming prefix (BKE_vfont_*) and DNA_vfont_types.h.
2021-09-24Cleanup: spelling in commentsCampbell Barton
2021-09-23Fix D12533: Simplify curve object to mesh conversionHans Goudey
This patch simplifies the curve object to mesh conversion used by the object convert operator and exporters. The existing code had a convoluted model of ownership, and did quite a bit of unnecessary work. It also assumed that curve objects always evaluated to a mesh, which is not the case anymore. Now the code checks if the object it receives is evaluated. If so, it can simply return a copy of the evaluated mesh (or convert the evaluated curve wire edges to a mesh if there was no evaluated mesh). If the object isn't evaluated, it uses a temporary copy of the object with modifiers removed to create the mesh in the same way. This follows up on the recent changes to curve evaluation, namely that the result is always either a mesh or a wire curve. Differential Revision: https://developer.blender.org/D12533
2021-09-17Cleanup: Pass const mesh argumentHans Goudey
Also remove unnecessary parantheses.
2021-09-11Cleanup: Remove no-op/unused codeHans Goudey
2021-09-11Geometry Nodes: Support modifier on curve objectsHans Goudey
With this commit, curve objects support the geometry nodes modifier. Curves objects now evaluate to `CurveEval` unless there was a previous implicit conversion (tessellating modifiers, mesh modifiers, or the settings in the curve "Geometry" panel). In the new code, curves are only considered to be the wire edges-- any generated surface is a mesh instead, stored in the evaluated geometry set. The consolidation of concepts mentioned above allows remove a lot of code that had to do with maintaining the `DispList` type temporarily for modifiers and rendering. Instead, render engines see a separate object for the mesh from the mesh geometry component, and when the curve object evaluates to a curve, the `CurveEval` is always used for drawing wire edges. However, currently the `DispList` type is still maintained and used as an intermediate step in implicit mesh conversion. In the future, more uses of it could be changed to use `CurveEval` and `Mesh` instead. This is mostly not changed behavior, it is just a formalization of existing logic after recent fixes for 2.8 versions last year and two years ago. Also, in the future more functionality can be converted to nodes, removing cases of implicit conversions. For more discussion on that topic, see T89676. The `use_fill_deform` option is removed. It has not worked properly since 2.62, and the choice for filling a curve before or after deformation will work much better and be clearer with a node system. Applying the geometry nodes modifier to generate a curve is not implemented with this commit, so applying the modifier won't work at all. This is a separate technical challenge, and should be solved in a separate step. Differential Revision: https://developer.blender.org/D11597
2021-08-26Cleanup: use C style comments for descriptive textCampbell Barton
2021-08-13Cleanup: remove use of BKE_mesh_calc_normals_mapping_simpleCampbell Barton
Use BKE_mesh_calc_normals instead of BKE_mesh_calc_normals_mapping_simple for curve modifier calculation. This only made sense for derived-mesh which is no longer used.
2021-07-28Fix T90154, T90213: curve issues since recent cleanup commitPhilipp Oeser
Caused by {rB8cbff7093d65}. Since above commit only one modifier would get calculated and the displaylist boundingbox was calculated wrong. Maniphest Tasks: T90154 Differential Revision: https://developer.blender.org/D12037
2021-07-02Cleanup: Use const variables for object's evaluated meshHans Goudey
Generally the evaluated mesh should not be changed, since that is the job of the modifier stack. Current code is far from const correct in that regard. This commit uses a const variable for the reult of `BKE_object_get_evaluated_mesh` in some cases. The most common remaining case is retrieving a BVH tree from the mesh.
2021-06-29Cleanup: Use function name for allocation stringsHans Goudey
This is simpler, more consistent, and takes up less space.
2021-06-29Curves: Avoid duplication of control points during evaluationHans Goudey
This commit avoids duplicating the deformed control point list twice by modifying the list in the object curve cache directly. For curves, the original control point data was duplicated into a local listbase, deformed, used to create the "bevel list" data, and then duplicated again for the object-level storage of deformed control points. Text objects and surface objects had a similar unnecessary duplication.
2021-06-29Cleanup: Avoid freeing curve evaluation data twiceHans Goudey
The curve bevel list was freed, and then freed again in a call to the function that recalulates it. The curve "anim path" data was freed only to be freed again in its calculation function as well. Also move the anim_path calculation directly after the bevel list creation to make its requirements more explicit.
2021-06-29Cleanup: Split curve and surface data evaluation functions, renameHans Goudey
Surface objects were already handled by an early return in the main "curve types" function. This commit splits them, renames the funtions to match (and be more consistent with other names), and sanitizes the checking of object types.
2021-06-29Cleanup: Order return arguments last, use r_ prefixHans Goudey
2021-06-28Cleanup: Replace paranoid check with assertHans Goudey
Every call to `BKE_displist_make_curveTypes` already checks the object type beforehand, there is no need to check it again. Also removed an outdated comment.
2021-06-28Cleanup: Remove unused "for_orco" argument to curve evaluationHans Goudey
`BKE_displist_make_curveTypes` had a `for_orco` argument that was always false in calls to the function. Removing it allows the curve displist and modifier evaluation code to become simpler. There are some related cleanups in rBdf4299465279 and rB93aecd2b8107.
2021-06-24Cleanup: comment blocks, trailing space in commentsCampbell Barton
2021-06-14Cleanup: Reduce indentation from redundant checkHans Goudey
2021-06-14Cleanup: Order return argument lastHans Goudey
2021-06-08Fix test failure caused by earlier cleanup commitHans Goudey
rB8cbff7093d65 neglected to move the "pre-tesselation" modifier to the next before calculating the second part of the curve modifier stack.
2021-06-08Cleanup: Order return argument lastHans Goudey
2021-06-07Cleanup: Use const arguments, return by valueHans Goudey
Also use Curve as an argument instead of Object, since the object was only used to retrieve the curve, and the calling code is already working with curve data.
2021-06-07Cleanup: Make function staticHans Goudey
This was not used in any other file, and it's not likely to be used elsewhere in the future anyway.
2021-06-07Cleanup: Remove outdated/useless commentsHans Goudey
Some of the comments referenced code that was no longer there, or even defines that were removed. Other comments were more confusing and vague than helpful. Also adjust formatting in a few cases.
2021-06-07Cleanup: Remove unused function, make function privateHans Goudey
2021-06-07Cleanup: Decrease variable scopeHans Goudey
Also use const and bool in a few places.
2021-04-26Cleanup: Move displist.cc to C++Hans Goudey
This is a change split from the geometry nodes curves branch. Since curve object modifier evaluation happens in this file, moving it to C++ will be quite helpful to support the `GeometrySet` type. Other than that, the code in the branch intends to replace a fair amount of this file anyway, so I don't plan to do any further cleanup here. Differential Revision: https://developer.blender.org/D11078