marker wasn't on the first or last possible position. Caused by clipping.
As bonus; added Cardinal interpolation option too, which is just that
little bit different! (Cardinal goes through the controlpoints, bspline not)
curves. On sharp 'peaking' curves the handle was calculated
using both X and Y distance. This could result in overshooting.
New code only evaluates the X distance, resulting in much more moderate
sized handles.
Thanks Gabio for the demo file!
- bug: posemode, bones were drawing names and axes even when hidden
- bug: using softbody guides actually worked on themselves, causing
an infinite loop
- feature: when a pose/bone is completely locked for transform, a grab
will change into rotate by default.
Well, it already worked a bit, but without weight options or edge
stiffness. You now can set the weights using the "Properties" Panel in
the 3D Window (allows multiple selections too) or with Wkey in Edit Mode.
Bezier curves have this too.
NOTE: Lattice SoftBody Goal created yesterday won't work anymore!
I've had to recode weight support for Nurbs Points, using a new weight
variable... this because the existing W variable was in use for Nurbs
already. Also Lattices have this new Weight variable, so the code is nice
uniform. Sorry for the artists who already created complex Lattices... :)
NOTE2: Surface Objects don't support edge stiffness yet
NOTE3: I've removed ancient screen coordinates from the Bezier struct,
which makes - even with added weight and padding - the struct smaller!
Demo file:
http://download.blender.org/demo/test/2.40/softbody_curve_lattice.blend
Animating detailed clothes with softbody becomes messy, so now we'll
try it this way. :)
It simply uses the W (weight) value, as already available in each Lattice
Point. Only had to make it editable;
- NKey panel
- or press W in editmode
Further there's a minimalistic W button in the softbody Panel!
Vertex-parenting a forcefield to a softbody caused eternal loop :)
It is partially because of the timing system (=weak) but actually also
because derivedmesh calls could also not build meshes all the time!
The locality is restricted to action or user-transform only. Or as it goes
in the code now: by setting a constraint local, it executes the constraint
before it calculates the influence of Action or user transforms.
ALso note that this works in Evil Eulerians. Meaning that when you only
want to copy the X,Y or Z compenent of a euler, it can give unpredictable
results when the other euler values are set, this because euler axis
rotations work on top of each other.
Previously, using the "Stride Bone" tried to get that Bone motionless on
the path by correcting the internal time of the Action. This however caused
too many problems, especially with irregular walks.
The new system also tries to keep the Stride Bone motionless, but this by
moving the entire armature, and not changing the timing of the Action.
Give much nicer results. :)
To make editing Strides easier, I've added a new option in the NLA
panel to disable the path. This way you can quickly switch to editing the
action itself (keying the stride bone) and viewing the result.
- Copy Location Constraint didn't update Object when it was copying from a
Bone
- Deleting bone in editmode, and connecting bones crashed due to evaluation
of deformation code (only allowed for pose).
I've been going over the zbuf.c code, which is indeed very ancient,
with a load of old optimizing and redundant code in use.
Added more 'modern' Span support, which fills per face two arrays
with the scanline information in it. That way you can zbuffer a quad in one
run as well. It was also exactly that code that's copied all over in zbuf.c
For now, to prevent issues for the release, the 'render a quad in 1 run' is
only in use for the strand render. Tests reveil a speedup of about 33%.
Will work on this recode later... which would also result in making zbuf.c
threadsafe.
And: bugfix #3398
When using the new 'render emitter' for particles, the orco array for
particles was accidentally used by mesh too.
doc;
http://www.blender3d.org/cms/Hair_Strand_Rendering.722.0.html
- added width control for strands
- made tangent (anisotropic) render an option
(so you can render strands more solid, like metal/wood)
Also:
- ALT+A anim playback with static particles made cursor flashing
"Additive" Guides. See also:
http://www.blender3d.org/cms/New_Particle_options_a.721.0.html
This Guide type uses the falloff distance to also define how much the
particle (or hair strand) goes over the path, allowing to create local
extremes, or only local particle generating or hairgrowth. Nice for
spiky haircuts!
Note that the current default generates particles based on the original
amount of vertices and faces, this for vertex group support (which is not
subdivided with modifiers). That means that particles generated on
subsurfed faces still have minor approximation errors.
Note for DerivedMesh users; I've added a new API call:
float *mesh_get_mapped_verts_nors(Object *ob);
Which returns an array of 2 * 3 * float size, containing the vertices and
normals, deformed and subsurfered, but only the original me->mvert amount.
Works in all non-editmode cases.
Is in use now for vertex/weight paint and particles.
- "Disp" option allows to go back to zero, effectively disabling the entire
particle generating.
- When parenting guides to an emitter the depgraph sees a cyclic relation,
which caused not updating the particles correct on loading it.
- Moved creating guide Cache completely outside of the particle loop,
should make it faster to use with large amounts of particles and objects.
http://www.blender3d.org/cms/New_Particle_options_a.721.0.html
There's no doubt this patch had a lot of good ideas for features, and I
want to compliment Janne again for getting it all to work even!
A more careful review of the features and code did show however quite some
flaws and bugs... partially because the current particle code was very much
polluted already, but also because of the implementation lacked quality.
However, the patch was too good to reject, so I've fixed and recoded the
parts that needed it most. :)
Here's a list of of most evident changes in the patch;
- Guides support recoded. It was implemented as a true 'force field',
checking all Curve path points for each particle to find the closest. Was
just far too slow, and didn't support looping or bends well.
The new implementation is fast (real time) and treats the paths as actual
trajectory for the particle.
- Guides didn't integrate in the physics/speed system either, was added as
exception. Now it's integrated and can be combined with other velocities
or forces
- Use of Fields was slow code in general, made it use a Cache instead.
- The "even" distribution didn't work for Jittered sample patterns.
- The "even" or "vertexgroup" code in the main loops were badly constructed,
giving too much cpu for a simple task. Instead of going over all faces
many times, it now only does it once.
Same part of the code used a lot of temporal unneeded mallocs.
- Use of DerivedMesh or Mesh was confused, didn't work for Subsurfs in all
cases
- Support for vertex groups was slow, evaluating vertexgroups too often
- When a vertexgroup failed to read, it was wrongly handled (set to zero).
VertexGroup support now is with a name.
- Split up the too huge build_particle() call in some parts (moving new code)
- The "texture re-timing" option failed for moving Objects. The old code used
the convention that particles were added with increasing time steps.
Solved by creating a object Matrix Cache.
Also: the texture coordinates had to be corrected to become "OrCo".
- The "Disp" option only was used to draw less particles. Changed it to
actually calculate fewer particles for 3D viewing, but render all still.
So now it can be used to keep editing realtime.
Removed;
The "speed threshold" and "Tight" features were not copied over. This
resembled too much to feature overkill. Needs re-evaluation.
Also the "Deform" option was not added, I prefer to first check if the
current particle system really works for the Modifier system.
And:
- Added integration for particle force fields in the dependency graph
- Added TAB completion for vertexgroup names!
- Made the 'wait cursor' only appear when particles take more than 0.5 sec
- The particle jitter table order now is randomized too, giving much
nicer emitting of particles in large faces.
- Vortex field didn't correctly use speed/forces, so it didn't work for
collisions.
- Triangle distribution was wrong
- Removed ancient bug that applied in a *very* weird way speed and forces.
(location changes got the half force, speed the full...???)
So much... might have forgotten some notes! :)
DXF: when an error message occurs during read, the main call returned
without clearing the used global vars... causing crash on calling again.
ALso: added warning when trying to assign a taper or bevel using Object
itself. (report from opengl tracker :)
He noted that static particles don't work with force fields yet, and
added a fix for it. This however didn't work for the depgraph yet, and
didn't correct the static particle's local space to world coordinates for
the fields. Nevertheless, while reviewing this small patch I thought it
would be fun to add now.
So: static particles now update realtime on forcefield relations. Warning
for potential slowdowns! Also note that work on the real particle patch
still has to be done... something I really will do, but in time. To get
particles correctly integrated in the animation system, quite some new
development has to be done still.
If a Mesh was "Auto Smooth", it was drawing as smooth in editmode, and
not as smooth in Object mode. Should be consistant.
Better even would be draw autosmooth info, but that's derivedmesh magic now!
1) Stride Bone
For walkcycles, you could already set an NLA strip to cycle over a path
based on a preset distance value. This cycling happens based on a linear
interpolation, with constant speed.
Not all cycles have a constant speed however, like hopping or jumping.
To ensure a perfect slipping-less foot contact, you now can set a Bone
in an Armature to define the stride. This "Stride Bone" then becomes a
sort-of ruler, a conveyor belt, on which the character walks. When using
the NLA "Use Path" option, it then tries to keep the Stride Bone entirely
motionless on the path, by cancelling out its motion (for the entire
Armature). This means that the animation keys for a Stride Bone have to be
exactly negative of the desired path. Only, at choice, the X,Y or Z Ipo
curve is used for this stride.
Examples:
http://www.blender.org/bf/0001_0040.avi
The top armature shows the actual Action, the bottom armature has been
parented to a Path, using the Stride Bone feature.
http://www.blender.org/bf/0001_0080.avi
Here the Stride Bone has a number of children, creating a ruler to be
used as reference while animating.
Test .blend:
http://www.blender.org/bf/motionblender1.blend
Notes:
- Note that action keys for Bones work local, based on the Bone's
orientation as set in EditMode. Therefore, an Y translation always
goes in the Bone's direction.
- To be able to get a "solvable" stride, the animation curve has
to be inverse evaluated, using a Newton Raphson root solver. That
means you can only create stride curves that keep moving forward, and
cannot return halfway.
- Set the Stride Bone in the Editing Buttons, Bone Panel. You can set
change the name or set the axis in the NLA Window, Strip Properties Panel.
- Files in this commit will move to the blender.org release section.
2) Armature Ghosting
In EditButtons, Armature Panel, you can set an armature to draw ghosts.
The number value denotes the amount of frames that have to be drawn extra
(for the active action!) around the current frame.
Ghosts only evaluate its own Pose, executing it's Actions, Constraints and
IK. No external dependencies are re-evaluated for it.
3) NLA/Action time control
If you click in the NLA window on the action (linked to Object), it makes
sure the Timing as drawn in the Action editor is not corrected for NLA.
If you also set the Object to "Action", this timing will be executed on the
Object as well (not NLA time).
(It's a bit confusing... will make a good doc & maybe review UI!)
- Python Drivers
In Ipo Window "transform properties" Panel, added the buttons, and the
initial handling (now only printing text). Willian makes it work!
- Better Matrix to Eul, code submitted by Brecht. No time yet to do it
really nice (like a Mat3ToEulCompat(mat, eul, eulc))
1) Target-less IK
If you add an IK constraint without a target set (no object or bone target),
it now can be grabbed and moved with IK, using its own Bone tip or root as
target itself. This way you can use IK for posing, without having the IK
executed while it animates or while a Pose is being solved for real IK.
After grabbing "Target-less IK", it applies the resulted motion in the
pose-channels, which then can be used to insert keypositions.
The Target-less IK bone can still be rotated without IK, also its chain
can be edited as usual.
UI: The CTRL+I menu gives this as an option too. In the 3D window it is
drawn with orangish color.
Note that IK is not resistant to non-uniform scaling yet.
2) Auto-IK
When the option "Automatic IK" is set, in Edit Buttons Armature Panel,
it creates automatic temporal Target-less IK for the Bone you grab or
translate.
The rules are:
- it only works when a single Bone is selected
- if the Bone is a root bone (no parent), it adds IK to the end of the
chain(s)
- otherwise it adds the IK to the active Bone
- the temporal IK chain only consists of connected Bones.
This method is still a bit experimental. Maybe it should become a special
grabbing option (like SHIFT+G in Pose Mode). It also only works OK for rigs
that fit for it well... when a rig already is fully setup with IK it can't
do much good. :)
- Action Editor: hotkeys V and H for handles were invisible, added menus
- NLA strips: when current frame is exactly on the strip end, it didn't
include that action... needs a rounding correction for it.
- Action/NLA: deleting keys in Action, which results in only 1 key left,
resulted in zero sized strip length. Now the strips are defaulted to be
1 frame in size minimal.
- NLA editor: ALT+C "Convert to strip" didn't increment Action user count
- 3D Window: CTRL+P make parent to Bone still gave the insane menu with all
bone names. With unified PoseMode select it can just parent to the
active Bone. Note; this now requires the Armature to be in PoseMode to
work.
- Rotation Constraint; the new options to only map to X,Y,Z rotation, did
set the not mapped rotation axes to zero. These should remain unchanged.
- AutoKey optionn for Actions; should not insert action keys on ESC
And added a fix myself:
- When SHIFT+selecting a Bone in PoseMode, and the Armature was not selected
or active yet, it doesn't extend-select/deselect the Bone anymore.
This case is only useful when you try to add IK or Constraint, so the
shift+selection should only activate the clicked Bone.
NOTE: I had to fix NMesh.c, Mesh_fromNMesh(), that is a real bad
function... it was returning a Py object as a Mesh (on error).
This is still not really solved (NULL return is not handled).
It works like for moving Object Ipos to the Action, press the Action icon
in the header of the IpoWindow, to the left of the mode selection menu.
It then creates an Action (if not existed) and moves the Shape Ipo to the
Action, using custom channel "Shape".
Main code change was that evaluating Ipo Curves for Relative Shapes had to
be recoded, but that's pretty minor and even much cleaner. (added "curval"
in the KeyBlock struct).
That this feature can work is thanks to the full modifier/derivedmesh
recode Daniel did, can't give him enough credits! :)
Also; small fixes in Outliner, for clicking on the Ipo icon (sets the Ipo
window to show that Ipo).
