| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
- spelling - turns out we had tessellation spelt wrong all over.
- use \directive for doxy (not @directive)
- remove BLI_sparsemap.h - was from bmesh merge IIRC but entire file commented and not used.
|
|
|
|
|
|
- copy & rename EditMesh stricts for use with scanfill (remove unused members)
|
|
editmesh_loop.c from this range still
|
|
comments is silly, may as well have in declaration)
|
|
|
|
|
|
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
|
|
|
|
didnt initialize delta vectors.
also remove redundant NULL initializers, where the value is initialized immediately after.
|
|
members of the DerivedMesh struct
|
|
|
|
|
|
each quad would result in 2 duplis.
|
|
|
|
* 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.
|
|
|
|
|
|
|
|
http://markmail.org/message/fp7ozcywxum3ar7n
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
https://svn.blender.org/svnroot/bf-blender/trunk/blender, merge pepper, manually merged source/blender/editors/transform/transform_generics.c
|
|
* Subversion bump (also for init_userdef_do_versions).
* Minor fix for compilation without ffmpeg.
|
|
|
|
crashes Blender
|
|
|
|
* 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$
|
|
|
|
manually merged source/blender/editors/uvedit/uvedit_unwrap_ops.c
|
|
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.
|
|
tools
|
|
account.
|
|
|
|
|
|
|
