A mistake in the mesh normal refactor caused the wrong mesh to
be used when calculating normals with a shape key's deformation.
This commit fixes the normal calculation by using the correct mesh,
with just adjusted vertex positions, and calculating the results
directly into the result arrays when possible. This completely avoids
the need to make a local copy of the mesh, which makes sense,
since the only thing that changes is the vertex positions.
Differential Revision: https://developer.blender.org/D14317
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
- 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
Those were only shallow wrappers around `BKE_id_copy`, barely used (even
fully unused in some cases), and we want to get rid of those ID-specific
helpers for the common ID management tasks. Also prevents weird custom
behaviors (like `BKE_object_copy`, who was the only basic ID copy
function to reset user count of the new copy to zero).
Part of 71219.
This replaces header include guards with `#pragma once`.
A couple of include guards are not removed yet (e.g. `__RNA_TYPES_H__`),
because they are used in other places.
This patch has been generated by P1561 followed by `make format`.
Differential Revision: https://developer.blender.org/D8466
BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
Since shape keys are stored as raw floating point data, this
unfortunately requires changes to all code that works with it.
An additional complication is that bezier and nurbs control
points have different entry size, and can be mixed in the same
object (and hence shape key buffer).
Shape key entries are changed from:
bezier: float v1[3], v2[3], v3[3], tilt, pad, pad;
nurbs: float vec[3], tilt;
To:
bezier: float v1[3], v2[3], v3[3], tilt, radius, pad;
nurbs: float vec[3], tilt, radius, pad;
The official shape key element size is changed to 3 floats,
with 4 elements for bezier nodes, and 2 for nurbs. This also
means that the element count is not equal to the vertex count
anymore.
While searching for all curve Shape Key code, I also found that
BKE_curve_transform_ex and BKE_curve_translate were broken. This
can be seen by trying to change the Origin of a Curve with keys.
Reviewers: campbellbarton, sergey
Differential Revision: https://developer.blender.org/D3676
This will allow much finer controll over how we copy data-blocks, from
full copy in Main database, to "lighter" ones (out of Main, inside an
already allocated datablock, etc.).
This commit also transfers a llot of what was previously handled by
per-ID-type custom code to generic ID handling code in BKE_library.
Hopefully will avoid in future inconsistencies and missing bits we had
all over the codebase in the past.
It also adds missing copying handling for a few types, most notably
Scene (which where using a fully customized handling previously).
Note that the type of allocation used during copying (regular in Main,
allocated but outside of Main, or not allocated by ID handling code at
all) is stored in ID's, which allows to handle them correctly when
freeing. This needs to be taken care of with caution when doing 'weird'
unusual things with ID copying and/or allocation!
As a final note, while rather noisy, this commit will hopefully not
break too much existing branches, old 'API' has been kept for the main
part, as a wrapper around new code. Cleaning it up will happen later.
Design task : T51804
Phab Diff: D2714
Noisy change, but safe, and better do it sooner than later if we are to
rework copying code. Also, previous commit shows this *is* useful to
catch some mistakes.
This function was only a wrapper around id_clear_lib_data(), and shapekeys
are not linkable nor shareable anyway, no point keeping this currently,
was only adding confusion about shapekey 'status' as a datatblock.
Mostly pass bmain and do not check for NULL key, keys' make_local is
suspiciously simple in fact, but think until those behave like real
full-featured IDs, it's doing enough!
Title says pretty much everything, we now have BKE and RNA funcs to get vertex, poly and
loop normals of a given shapekey.
This will be used e.g. in FBX exporter (shapekeys need normal data too).
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D1510
Thing is, those functions always reallocate the whole keyblock's data mem,
while in some cases we already have right amount of elements, so we can just
copy over. Further more, `BKE_key_convert_from_offset`, despite its name,
was not making any check nor allocation on keyblock's data elements!
So split 'copy' operation itself in `BKE_key_update_from_...`,
where no mem checks/operations are performed (only an assert).
Only useful in sculpt mode currently, but will be used by fix for T35170 too.
Main moving logic is moved to new `BKE_keyblock_move()`, which makes it available from anywhere.
In addition, move code was reworked so that it only loops once on whole keyblocks list,
and it accepts arbitrary org and dest indices, not only neighbor ones.
Partly based on work by revzin (Grigory Revzin) in his soc-2014-shapekey GSoC branch, thanks!
This commit fixes two different issues, which were caused by
how weights are being calculated for relative shapekeys.
Weights for key block used to saved in KeyBlock DNA structure,
which lead to situations when different objects could start
writing to the same weights array if they're sharing the same
key datablock.
Solved this in a way so weights are never stored in KeyBlock
and being passed to shapekeys routines as an array of pointers.
This way weights are still computed run-time (meaning they're
calculated before shapekey evaluation and freed afterwards).
This required some changes to GameEngine as well, to make it
never cache weights in the key blocks.
Another aspect of this commit makes it so weight for a given
vertex group is only computed once. So if multiple key blocks
are using the same influence vertex group, they'll share the
same exact weights array. This gave around 1.7x speedup in
test chinchilla file which is close enough to if we've been
caching weights permanently in DNA (test machine is dual-code
4 threads laptop, speedup measured in depsgraph_mt branch,
trunk might be not so much high speedup).
Some further speed is optimization possible, but it could be
done later as well.
Thanks Brecht for idea of how the things might be solved in
really clear way.
--
svn merge -r58786:58787 ^/branches/soc-2013-depsgraph_mt
Hans Goudey
Campbell Barton
Campbell Barton
Bastien Montagne
Sebastian Parborg
Jacques Lucke
Bastien Montagne
Dalai Felinto
Bastien Montagne
Alexander Gavrilov
Sergey Sharybin