more of a request then a bug but shows up a strange limitation with curve deform modifier,
The mesh bounding box would set the deform axis start/end to map the deformation of the curve to. This means it ignored offset in the object location and object data location (you could use a dummy vertex to trick it).
Old files wont change, added an option (next to stretch), called 'Bounds Clamp', old files have this behavior but newly made curves have it disabled.
Double checked this gives useful results with stretch on/off and negative axis.
A subtle change with the curve deform modifier is when a vgroup is used: the mesh bounds were being calculated based on the verts in the group (ignoring their weight).
Now ignore verts weighted at 0.
Fix#21187: 2.5svn26947 - particles + meta sphere = crash in rendering
Use separated displists for mballs in view3d and render stuff.
Do not recalculate displist for view3d while rendering - mball.c
uses several global variables which shouldn't be accepted from
parallel threads.
* Displacement coordinates are now stored differently, as a grid per
face corner. This means there is duplication of coordinates, especially
at low subdivision levels, but the simpler implementation justifies it
I think.
* ToDo: conversion of existing multires files (2.4x or 2.5x), loading them
may even crash now.
* Editmode preservation/interpolation code also has not been updated yet.
* Multires now works on the CCGDerivedMesh grids instead of CDDerivedMesh,
which should be more memory efficient.
* There are still bad memory peaks (if you're using 32bit) when subdividing
or propagating displacements. Though at least there should be no huge
memory blocks allocated, which windows is now to have trouble with.
* Still found some weird spike artifacts at lower multires levels, some also
happening before this commit. Perhaps computation of tangents needs to be
tweaked more.
* Multires modifier now has viewport, sculpt and render levels. Also the
levels have been made consistent with subsurf, previously the same level
of subdivision was one less for multires.
* Both multires and subsurf modifier now can have their subdivision level
set to 0 for no subdivision.
* Convert all code to use new functions.
* Branch maintainers may want to skip this commit, and run this
conversion script instead, if they use a lot of math functions
in new code:
http://www.pasteall.org/9052/python
Blended shape keys can now be displayed & edited in edit mode. This
is much like showing an armature modifier in edit mode, and shape keys
now are a applied as a virtual modifier (for mesh & lattice only, curve
doesn't fit in the stack well due to tilt).
The main thing missing still is being able to switch between the active
shape key in edit mode, that's more complicated.. but the weights of
other shapes can be edited while in edit mode.
One thing to be careful about is that this does automatic crazyspace
correction, which means that if you edit a shape key with a low value,
the actual vertices will be moved to correct for that and actually move
a (potentially much) longer distance.
Also includes some UI tweaks, mainly placing some buttons horizontally
since the vertical list was getting too long.
Internal change to not apply the shape keys to the Mesh vertex coordinates,
but rather use it as part of the derivedmesh/displist evaluation. This only
has one practical advantage right now, which is that you can now make a
linked duplicate and pin it's shape key to a different shape than the first
object.
Further, this makes shape keys correctly fit into the modifier stack design,
which will help implement some other features later. Also it means the mesh
vertex coordinates are now really the orco's.
So means minimum twist and twist smoothing are now used.
the Z up quaternion from the path is rotated to match the up axis given.
There was no logical rule for the up vector, some cases flipped the normals when used with the CurveDeform modifier.
Use the default X-Up behavior and match other settings with this. (comments explain this in detail).
- Interpolating quaternions didn't work in some cases, disabled for now.
- 'no_rot_axis' is different from in 2.4x since it now removes rotation from the tilt whereas before it edited the axis before calculating the tilt.
- use_radius option, off by default for 2.4x files, on by default on new curves.
- curve deform modifiers (think tentacles)
- follow path (parent mode and constraint)
- curve guides
- added back Alt+S to scale point radius
- Mat3Scale and Mat4Scale arithb.c functions to make a new uniform scale matrix.
- TODO, effectors, looks like they have no way to scale from the radius yet.
* Lattices: properties editable, editmode operators, menus working
again. As a bonus you can now edit u/v/w in editmode.
* Shape Keys: some code cleanup, and added more buttons. The
value/min/max buttons don't work correct yet though.
* Fix issue with uv textures, vertex colors not being visible outside
editmode, and a few other issue. Mesh.edit_mesh is now NULL when
not in editmode.
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
- restored three more C files: editlattice, editkey
and editgroup
- editmode lattice working, (mouse select works)
- accidentally removed yesterday 3d cursor drawing
- removed global editLatt entirely now.
Think global, act local!
The old favorite G.scene gone! Man... that took almost 2 days.
Also removed G.curscreen and G.edbo.
Not everything could get solved; here's some notes.
- modifiers now store current scene in ModifierData. This is not
meant for permanent, but it can probably stick there until we
cleaned the anim system and depsgraph to cope better with
timing issues.
- Game engine G.scene should become an argument for staring it.
Didn't solve this yet.
- Texture nodes should get scene cfra, but the current implementation
is too tightly wrapped to do it easily.
From the anti-globalization department:
G.obedit terminated!
Wherever possible, use CTX_data_edit_object(C) to get this
now. It's stored in scene now, and the screen context has
it defined.
svn merge https://svn.blender.org/svnroot/bf-blender/trunk/blender -r12987:17416
Issues:
* GHOST/X11 had conflicting changes. Some code was added in 2.5, which was
later added in trunk also, but reverted partially, specifically revision
16683. I have left out this reversion in the 2.5 branch since I think it is
needed there.
http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=rev&root=bf-blender&revision=16683
* Scons had various conflicting changes, I decided to go with trunk version
for everything except priorities and some library renaming.
* In creator.c, there were various fixes and fixes for fixes related to the -w
-W and -p options. In 2.5 -w and -W is not coded yet, and -p is done
differently. Since this is changed so much, and I don't think those fixes
would be needed in 2.5, I've left them out.
* Also in creator.c: there was code for a python bugfix where the screen was not
initialized when running with -P. The code that initializes the screen there
I had to disable, that can't work in 2.5 anymore but left it commented as a
reminder.
Further I had to disable some new function calls. using src/ and python/, as
was done already in this branch, disabled function calls:
* bpath.c: error reporting
* BME_conversions.c: editmesh conversion functions.
* SHD_dynamic: disabled almost completely, there is no python/.
* KX_PythonInit.cpp and Ketsji/ build files: Mathutils is not there, disabled.
* text.c: clipboard copy call.
* object.c: OB_SUPPORT_MATERIAL.
* DerivedMesh.c and subsurf_ccg, stipple_quarttone.
Still to be done:
* Go over files and functions that were moved to a different location but could
still use changes that were done in trunk.
Curve modifier on lattice suffered drawing updates, only when the system
was not animated though, missed depsgraph calls then.
Solved it by forcing lattice to always return displist for its vertices,
that's same as for how mesh/curve works now.
This time is was due to different accuracy of floating point computation,
now it uses does a comparison a bit different to avoid this.
Also changed the vectoquat function to be threadsafe.
All data layers, including MVert/MEdge/MFace, are now managed as custom
data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are
still used of course, but allocating, copying or freeing these arrays
should be done through the CustomData API.
Work in progress documentation on this is here:
http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
Replaced TFace by MTFace:
This is the same struct, except that it does not contain color, that now
always stays separated in MCol. This was not a good design decision to
begin with, and it is needed for adding multiple color layers later. Note
that this does mean older Blender versions will not be able to read UV
coordinates from the next release, due to an SDNA limitation.
Removed DispListMesh:
This now fully replaced by DerivedMesh. To provide access to arrays of
vertices, edges and faces, like DispListMesh does. The semantics of the
DerivedMesh.getVertArray() and similar functions were changed to return
a pointer to an array if one exists, or otherwise allocate a temporary
one. On releasing the DerivedMesh, this temporary array will be removed
automatically.
Removed ssDM and meshDM DerivedMesh backends:
The ssDM backend was for DispListMesh, so that became obsolete automatically.
The meshDM backend was replaced by the custom data backend, that now figures
out which layers need to be modified, and only duplicates those.
This changes code in many places, and overall removes 2514 lines of code.
So, there's a good chance this might break some stuff, although I've been
testing it for a few days now. The good news is, adding multiple color and
uv layers should now become easy.
http://download.blender.org/demo/test/2.43/0001_0150_speed.avi
By default the Speed maps in the range 0-100 frames, since there's
not an actual time relationship here.
IMPORTANT: this didn't work before, and default Curve Paths have a
speed Ipo, so past saved scenes will work different now!
- Speed curve points are now drawn on the 3D path as well. With select
info for selected points, if Curve Object is active.
- Duplicating Objects with NLA ActionModifiers now also correctly copies
object pointers, so a duplicate works as expected.
- FORWARD CYCLING & MATCHING
Up to no now, adding multiple actions in NLA with walkcycles required to
animate them standing still, as if walking on a conveyor belt. The stride
option then makes the object itself move forward, trying to keep the foot
stuck on the floor (with poor results!).
This option now allows to make walk cycles moving forward. By
indicating a reference Offset Bone, the NLA system will use that bone to
detect the correct offset for the Armature Pose to make it seamlessly going
forward.
Best of all, this option works as for cyclic Action Strips as well as for
individual Action Strips. Note that for individual strips, you have to set
the strip on "Hold". (Might become automatic detected later).
Here's an example edit image for NLA:
http://www.blender.org/bf/nla_match-cycle.jpg
And the animation for it:
http://download.blender.org/demo/test/2.43/0001_0150_match.avi
Blender file:
http://download.blender.org/demo/test/2.43/mancandy_matching.blend
Using this kind of cycling works pretty straightforward, and is a lot
easier to setup than Stride Bones.
To be further tested:
- Blending cycles
- matching rotation for the bones as well.
- ACTION MODIFIERS (motion deformors)
The above option was actually required for this feature. Typically walk
cycles are constructed with certain Bones to be the handles, controlling
for example the torso or feet.
An Action Modifier allows you to use a Curve Path to deform the motion of
these controlling bones. This uses the existing Curve Deformation option.
Modifiers can be added per Action Strip, each controlling a channel (bone)
by choice, and even allows to layer multiple modifiers on top of each other
(several paths deforming motion). This option is using the dependency graph,
so editing the Curve will give realtime changes in the Armature.
The previous walkcycle, controlled by two curves:
http://download.blender.org/demo/test/2.43/0001_0150_deform.avi
Blender file:
http://download.blender.org/demo/test/2.43/mancandy_actiondeform.blend
Action Modifiers can be added in the NLA Properties Panel. Per Modifier you
have to indicate the channel and a Curve Object. You can copy modifiers from
one strip to another using CTRL+C (only copies to active Object strips).
Setting up a correct Curve Path has to be carefully done:
- Use SHIFT+A "Curve Path" in top view, or ensure the path is not rotated.
- make sure the center point of the Curve Object is at the center of the
Armature (or above)
- move the first point of the curve to the center point as well.
- check if the path starts from this first point, you can change it using
(in Curve EditMode) the option Wkey -> "Switch Direction"
- Make sure alignment uses the correct axis; if the Armature walks into
the negative Y direction, you have to set in Object Buttons, "Anim settings"
Panel, the correct Track option. (Note; option will probably move to the
Modifier later).
This is a good reason to make such paths automatic (on a command). Is on the
todo list.
Also note this:
- the Curve Path extends in beginning and ending, that's (for now) the default,
and allows to use multiple paths. Make sure paths begin and end horizontal.
- Moving the Curve in Object Mode will change the "mapping" (as if the landscape
a character walks over moves). Moving the Curve in Edit Mode will change the
actual position of the deformation.
- Speed (Ipos) on paths is not supported yet, will be done.
- The Curve "Stretch" deform option doesn't work.
- Modifiers are executed *after* all actions in NLA are evaluated, there's no
support yet for blending multiple strips with Modifiers.
- This doesn't work yet for time-mapping...
This commit is mostly for review by character animators... some details or
working methods might change.
This feature can also be used for other modifiers, such as noise (Perlin) or
the mythical "Oomph" (frequency control) and of course Python.
Special thanks to Bassam & Matt for research & design help. Have fun!
settings, rather than using the object's TrackX/Y/Z/etc buttons.
This is good for two reasons: a) having the settings over in the object buttons
before was terribly unintuitive and hidden, now it's more visible how to
control the deformation, and b) now if you have more than one curve modifier,
they can have their own settings, instead of being forced to use the object
level data.
In a quick glance: (temp image)
http://www.blender.org/bf/rt.png
Main reason is that Lattices are useful a lot for Armature deformation.
Lattices just provide much more precise and interesting control. However,
with only bone envelopes it's very hard to use.
Working with Lattice vertex groups is nearly identical to Mesh:
- on CTRL+P 'make parent' you can choose the deform option now
- In editmode, the buttons to control vertex groups are available
- In outliner you can select vertexgroups too
- Deforming Lattices with Armatures has all options as for Mesh now.
Note:
- No WeightPaint has been added yet. To compensate, the editmode
drawing for a Lattice with vertex group shows weight values for the active
vertex group.
- Lattice editmode doesn't undo/redo weight editing yet.
- Softbody for Lattice still uses own vertex weights
Implementation notes:
- derivedmesh weight_to_rgb() is now exported to drawobject.c
- been doing cleanups in code (order of includes, var declarations, etc)
- weightpaint button handling now is generic
I've checked on Brecht's proposal for Custom Element data;
http://mediawiki.blender.org/index.php/BlenderDev/CustomElementData
It could have been used, but that would mean the existing code for
vertexgroup handling and armature deform couldn't be re-used. I guess this
is really a later todo.
to finetune deform further as well.
Note that curve deform requires object buttons 'track' and 'up' axes set
properly. Curve deform can twist/flip a lot, making Vertex Group based
deform hard to set up.
User doc: http://www.blender3d.org/cms/Shape_Keys.678.0.html
- The mixed use of "Vertex Key","Key" or "RVK" in Blender was a bit
confusing. Also a 'vertex key' assumes keys per vertex, which actually is
only a single key for the entire shape. The discussions on blender.org
forums all mentioned "Shape" or "Blend Shapes", which I think is an OK
name for a "Vertex Key" in the UI. :)
- Most work was code spaghetti cleanup. Doing shape-keys now nicely goes
via the depgraph and DerivedMesh. That then allows to have different
shapes per object, with the new "Pin" feature.
Objects now define what Shape is shown (ob->shapenr)
- Added a Shape Panel in the Edit buttons with the various options
- Fixed a lot of issues in the IpoWindow, with drawing the channels.
For example, deleting a key-line there caused the entire Relative option to
go wrong, same for moving the lines up/down.
Changing key-line order now reflects in order of channels. The active
Shape is drawn more clear now too.
- Noticed it doesnt work yet for curves/lattice. Need modifier advise!
- new feature, twiddled with lattice resizing to try to maintain
existing vertex changes... much nicer than just resetting the
lattice if you decide you need more detail in the lattice.
- modifiers work with lattices now. yes, that does mean you
can make a chain of lattices effecting each other 8 miles
long.
- some cleanup of softbody code, was rather splintered and call
path was twisted and confusing. reworked main object step
routine to do things in a more obvious and consistent manner
and without duplicate code
- added ob->softflag OB_SB_RESET instead of sbObjectReset
call
- modifier changes reset softbody now
- moved curve_getVertexCos/curve_applyVertexCos into curve.c
- update curve modifier eval to work with virtual modifiers
- update modifier apply to work with curves/surfs
- update make parent to also recalc object data
NOTE: Although you can turn SB on for curve/font objects at the
moment it doesn't really work because they call deform in
multiple steps and this confuses SB. Not sure how to deal with
atm.
