inconsistent with similar functions & math notation:
mul_m4_m4m4(R, B, A) => mult_m4_m4m4(R, A, B)
mul_m3_m3m4(R, B, A) => mult_m3_m3m4(R, A, B)
For branch maintainers, it should be relatively simple to fix things manually,
it's also possible run this script after merging to do automatic replacement:
http://www.pasteall.org/27459/python
* Made it impossible to try to calculate/create new motion paths lasting 0
frames (i.e. 250 to 250) since we cannot allocate a zero-length array for these.
Start frame can now be at most end-frame - 1, and end frame at least start frame
+ 1
* If an invalid configuration does occur, warnings/reports will now be issued in
response to this instead of silently failing (as per this bugreport).
duplicate of BKE_curframe() which just takes two extra args.
For the few calls in the physics engine where CFRA+1 instead of CFRA
was being used, I've added a new BKE_nextframe() call, which will
calculate for CFRA+1 instead of CFRA in much the same way that
bsystem_time() would end up doing things (which means including
subframe steps).
Due to changes with the way that dupliframes were being evaluated (one
of those being that the animation for the object being animated would
get reevaluated for every frame sample for dupliframes) to get them
working properly again sometime during the 2.5 series, the dupliframe-
sampling loop would be prematurely terminated on the first frame in
this example.
That is because after the first step of the loop, the ob->dupend
property would have changed its value as it was being animated,
leading to the loop terminating, and only the a single dupli getting
added.
There has been quite a bit of fuss about particle dupliobject rotation in 2.59, so here are some changes to make things work a bit more consistently and predictably in 2.60.
Much of the confusion has been about what the "Initial rotation" for particles actually means. Simply put it's just a vector that that the particles (and the dupliobjects) are aligned to and around which they can be rotated with the phase controls. I've now renamed these controls under a label "Rotation axis".
In 2.59 and previous versions the dupliobject's global x-axis was aligned to the particle rotation axis for non-hair particles. This meant that the object's own rotation (in addition to the particle rotation) could effect the dupliobjects' rotations. This old behavior can still be used with the "Rotation" option in the particle render panel when object/group is set as the visualization. This option is also activated automatically for old files to maintain backwards compatibility.
Now the default dupliobject rotations ignore the object's own rotation completely and align the object's tracking axis to the particle rotation axis. The tracking axis can be found under the Object tab -> Animation Hacks panel.
In 2.58 the way of calculating the rotation for hair didn't work as intended and enabled many non-functional combinations of options. For this reason I removed most of the rotation options for hair in 2.59. Now the options have been reimplemented better and the dupliobject's tracking axis is aligned to the hair direction by default (Rotation axis = Velocity / Hair). All the other axis options work too along with the phase controls.
* The emitter object's inverse matrix wasn't in global coordinates during rendering, so the surface normals of the hair emission locations were transformed with the wrong matrix.
Causing a flurry of refresh file prompts post-commit,
Confusing local diffs and causing merge conflicts,
Stating the obvious; redundant and useless...
We shall not miss thou, blasted expand $keywords$
This fixes bug #26764 and several others like it, where modifier
properties (and others, but most visibly modifiers) would not do
anything when animated or driven, as modifier properties require the
RNA update calls to tag the modifiers to get recalculated.
While just adding a call to RNA_property_update() could have gotten
this working (as per the Campbell's patch attached in the report, and
also my own attempt #25881). However, on production rigs, the
performance cost of this is untenatable (on my own tests, without
these updates, I was getting ~5fps on such a rig, but only 0.9fps or
possibly even worse with the updates added).
Hence, this commit adds a property-update caching system to the RNA
level, which aims to reduce to the number of times that the update
functions end up needing to get called.
While this is much faster than without the caching, I also added an
optimisation for pose bones (which are numerous in production rigs) so
that their property updates are skipped, since they are useless to the
animsys (they only tag the depsgraph for updating). This gets things
moving at a more acceptable framerate.
* Grid distribution isn't really suited for hair, so this is now disabled.
* Setting a jittered distribution with particles/face = 1 now creates particles on the center of faces.
* Quite a bit of cleanup of the whole particle distribution code.
problem and crash
- It turns out we still need the "copyob" still, if for nothing other
than making sure that the unkeyed transforms can get restored. This
was removed originally as I thought that just reevaluating the
animation would work.
- Removed a buggy line of logic that was causing crashes when there
was no animation data. It's better to just assume that if animation
data exists, that something exists there.
- Make Duplicates Real was not clearing data such as the new animation
data or constraints.
So, it turns out that dupliframes weren't that bad to restore... the
old version didn't do truly accurate transform freezing as it didn't
update ancestors too. However, as a modelling tool, this will probably
suffice.
- use NULL rather then 0 where possible (makes code & function calls more readable IMHO).
- set static variables and functions (exposed some unused vars/funcs).
- use func(void) rather then func() for definitions.
* Particle duplis are now always created with render percentage if G.rendering is set.
* This is not yet a perfect solution (hair for example won't yet work correctly), but
it's good to have even partial functionality here until a proper way to handle this
is implemented.
* After countless different bugs particles should now render correctly inside dupligroups.
* Only particles with metaball visualization are still problematic, this is mostly due to the ancient metaball code.
* I'll also add a test file for some of the situations, so that hopefully these cases stay fixed :)
Surprising this wasnt noticed in a much more obvious case:
- Key Location, Move, Rotate, Undo-Rotate >> Resets to keyed location as well.
This was happening because DAG_on_load_update() was called on read_undosave(), flagging 'ob->adt->recalc |= ADT_RECALC_ANIM;'
Fix by adding an option to DAG_on_load_update(), not to recalculate time flags.
This would have made bug #25003 very simple to find.
- Objects had their quats normalized when calculating their matrix, this is inconstant with pose bones and isn't useful for animation.
Also it wasn't normalizing the delta rotation so these would give bad rotations.
- Converting between rotation modes BKE_rotMode_change_values() assumed normal length quat. changing quat to euler rotation for eg could change the bone.
- Clear rotation and transform were not normalizing the quat when 4d loc was disabled on quat rotation, corrected and also made it so the quat scale is restored after conversion so animations curves dont jump.
There is 1 case in mat3_to_quat_is_ok() where quat_to_mat3 on an unnormalized quat is needed, for this I had to add an ugly static function quat_to_mat3_no_assert(), but overall its worthwhile IMHO to be able to find incorrect use of rotation conversion.
- removed deprecated bitmap arg from IMB_allocImBuf (plugins will need updating).
- mostly tagged UNUSED() since some of these functions look like they may need to have the arguments used later.
