To get the versioning code properly work, the condition should have been:
DNA_struct_elem_find(fd->filesdna, "FreestyleLineStyle", "MTex", "*mtex[18]")
The present commit uses another new structure member instead, to avoid referring
to the magic number 18 in the last string literal.
This was because to the filtering code, those FCurves still weren't in any
groups, and so couldn't be visible (since a temporary group is created to
house them). As a result, the visible-channels list would be empty, causing
all hidden FCurves to be treated as hidden.
These were broken by 1f3655d224, since
an argument of the wrong type was getting passed to ANIM_animdata_filter(),
resulting in no channels ever being picked up for the "visible channels" list.
Turned out there was still quite a few cases were indices were set dirty,
but elem_index_dirty was not tagged accordingly (mostly for BM_LOOP,
but a few others as well). So probably this crash was not the only one
hidden here.
Hopefully all possible cases were catched this time!
This fixes most of the cases, the only situation not addressed is when
the highpoly object(s) has non-uniform scale.
mul_transposed_mat3_m4_v3() should take care of non-uniform scales so
I'm a bit confused on why it doesn't work. The lowpoly object can have
any transformation, the only issue is if the highpoly object has
non-uniform scale.
Test file of the remaining issue:
https://developer.blender.org/file/info/PHID-FILE-tpw2xgddyzxtpg3e7xzs/
Reference reading:
http://www.unknownroad.com/rtfm/graphics/rt_normals.html
bleeding at the symmetry edges.
We need an extra way to detect if faces overlap here. An easy way is to
detect the winding of the faces in UV space. If the winding differs, the
faces will naturally overlap. I have tried a few approaches here such as
choosing an offset point from the middle of the edge for intersection in
both faces of the edge in uv space, but winding is the safest way and
should work with very small faces/dense meshes too.
Check that up_axis is not aligned with bone was wrong in at least two aspects
(not working against negative alignement case, and since ages it seems,
using Z axis when bones are along Y axis...).
Also optimized a bit here, better to have a normalized version of vec_roll_to_mat3(),
since it needs normalized vector anyway, and we have to normalize it for the tests
before calling it anyway (so now, we only do that twice in Transform code, instead
of three times).
And we can perform aling test *before* calling vec_roll_to_mat3!
This information only really seems to be for helping developers track
down bugs, and isn't really something the user needs. So, lets not spam
their console.
The bug was caused by using negative numbers as the end for playing forever (or until the end of the sound is reached) in the library. This was used with speaker objects which have an end of FLT_MAX now instead and the negative number interpretation was removed. I hope this doesn't break anything else.
Revert small part of own rB8714ae09f894, which changed scale setting from absolute to relative
(was good in absolute, but bad because it breaks existing rigs).
It can't be undoe with Ctrl-Z, but Alt-H works just fine.
So instead of breaking someone's workflow let's just add
an info about how to bring bones back.
So! First, frame for absolute shape keys: never allow a new key to have the same pos as an
existing one (this does not make sense). This way, the two workflows are possible (create
all keys and then animate ctime, or animate ctime and then create keys where you need them).
Also, fixed UIList for shapekeys, the "absolute" test was wrong, and better to show frame
value, even though not editable, than nothing in case of absolute keys.
And finally, add getter to RNA 'frame' readonly value, so that we output real frame values,
and not dummy internal ones (which are /100) in our API.
On windows "." was replaced with the root directory.
On other systems any path starting with a '.' would be replaced with "/"
This was added for the file selector only,
so better handle this in the file selector (though it looks not to be needed).
