-softbody BodyPoint indexes were created with a lag of one leading to use of wrong softbody points for particles when creating path cache
-interpolation points for softbody hair weren't chosen optimally when not yet at the end of a hair
a glance to view is the "STU PID semi implicit euler"
most of the work to implement a semi implicit euler was done ..
now i am dealing with the tradeoffs between 'calculation time' which is quite expensive .. inverting a 0(n*n) sparse matrix /* once agian thanks to brecht for his work on making sparse matrices LU decomposition and evaluating inverses that easy*/ putting it into and cropping works pretty nice .. argh off topic again
...
while i spent a little time on reading recent papers i found :
1. control on springs needs to be split in pushing and pulling /* fabric pushes easy but pulls hard */
2. diagonals on 4-gons (in the current SB model) can be seen as shear .. thus need a contol to modify .. this commit wil add it
3. 2 nd order springs /*aka rigidity */ can focus on bending .. thus renaming 'em
i have no idea how i would provide backward compatiblity, but the spots i marked in code :)
=========
Merge of the famous particle patch by Janne Karhu, a full rewrite
of the Blender particle system. This includes:
- Emitter, Hair and Reactor particle types.
- Newtonian, Keyed and Boids physics.
- Various particle visualisation and rendering types.
- Vertex group and texture control for various properties.
- Interpolated child particles from parents.
- Hair editing with combing, growing, cutting, .. .
- Explode modifier.
- Harmonic, Magnetic fields, and multiple falloff types.
.. and lots of other things, some more info is here:
http://wiki.blender.org/index.php/BlenderDev/Particles_Rewritehttp://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite_Doc
The new particle system cannot be backwards compatible. Old particle
systems are being converted to the new system, but will require
tweaking to get them looking the same as before.
Point Cache
===========
The new system to replace manual baking, based on automatic caching
on disk. This is currently used by softbodies and the particle system.
See the Cache API section on:
http://wiki.blender.org/index.php/BlenderDev/PhysicsSprint
Documentation
=============
These new features still need good docs for the release logs, help
for this is appreciated.
/* special hidden feature! shrink to fit */
if (G.rt > 500){
scale = (G.rt - 500) / 100.0f;
}
-- shrink a T shirt to fit .. evil grin
-- by the way i did set up the rule 'if any *outer object* hits no *inner* will be regarded' ... pretty poor IMHO .. well but it works
bsystem_time was being called with an extra variable, which was useless. Most of the places that called it, were passing NULL for that variable anyway.
I've also cleaned up that function a bit, but the underlying problems with that part of the code still exist (EVIL GLOBALS that are exported for frame_to_float), for mblur and fields rendering features. That remains for another time.
This commit upgrades the modifier stack to only calculate the data which is
needed, either by modifiers further down the stack or by other functions at
the end of the stack (e.g. drawing functions).
This speeds up modifier stack recalculation, especially where vertex
groups and UV coordinates are concerned. For example, a mesh with an Armature
modifier followed by a Subsurf modifier would previously have required the
Subsurf modifier to interpolate all the vertex groups in the mesh, slowing
down modifier calculations considerably. With this update, vertex group data
is not propagated beyond the Armature modifier, so calculations are faster.
Note that this depends on the order of modifiers in the stack. If the Armature
and Subsurf modifiers were swapped in the above example, the Subsurf modifier
would have to interpolate vertex groups, as they are needed by the Armature
modifier.
Doing NULL pointer paranoia check in time.
It's completely pointless calling the function with null pointer,
but who knows.
At least it does not crash then.
nice little 'debug' feature
SHIFT_ESC breaks baking without throwing away the baked keys
so you can check the solution calculated so far
baked sb replay checks for NULL pointers in keys -> motion will stop there
even saving and loading to file works here,
but i would not expect it to do so
humm .. may be i'll add a dirty flag for that
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.
Added a less 'strict' solver step size control.
Cuts down needed loops to a 1/5 in 'regular' collision situations.
So why be a maths smartass when we want to do a skirt in a breeze :)
Is on by default, old mode can be turned on with the 'O' button beside the RK-limit.
Some minor fixes to the UI
1. UI review -> disabeling options when not available .. giving hints why ( even tried to give usefull tooltips )
1.1 give some more user control to the solving process (mins,maxs).. optional feedback on the console
2. replacing ugly object level 'sumohandle' with SB (private runtime) level/pointer 'scratch'
which holds runtime data like cached collider data and more .. and it's thread save this way :)
3.related no 2. write a 'private' history of collision objects to ease the 'fast' collider tunneling syndrome'
4. some <clean> optimizations, 3-BSP for self collision, general AABB checking before ever going to collision details
5. some <dirty> ( in the sense of do some inacurate physics noone ever will see ) little tricks to make things faster .. ..fuzzy collision situation bypass .. forward collision resolution
SB collision targets may be picked up from modifier stack
works fine with static targets having subsurf and/or array mofifiers
see-->
http://www.wund.homepage.t-online.de/hidden/Mstack.blendhttp://www.wund.homepage.t-online.de/hidden/Mstack_II.blend
however when calulating the SB object dynamics the vertices of the
'deform only' m-stack result are used
so SB <-> SB may look strange
subsuf modifier is applied to SB object after doing SB dynamics
(that is: colliding mesh is subsurfed, SB is not )
subsurfed SB cubes colliding
link --> http://www.wund.homepage.t-online.de/hidden/ColSelfMod.blend
or may give unwanted results
subsuf and array modifier is applied to SB object after doing SB dynamics
link --> http://www.wund.homepage.t-online.de/hidden/ColSelfMod_nobug.blend
last, modifiers that change vertex locations in time (like waves)
suffer from not beeing seen at needed time resolution
(SBs see colliders static in a frame)
well but that's beyond the limits of the current dep-graph use
and needs to be resolved on design level
anyhoo have fun
BM
nicer kinematics in self collision -> blending to complete inelastic impact
now does something close to real physics
first steps towards aerodynamics
anisotropic friction
springs 'see' their movement in media
--> see surrrounding media does not move and/or reacts on wind
(*for now needs to have a pseudo collider araound -> that is: add a cube in the same layer
and make it a deflector *)
just did a few tests, with the 'surprising' result that balls are not curves ..
and i don't want to be swamped by bug reports tellling me
'it does not collide as i whised it would'
only alow self collision for suited objects
feature request from hairdressers
self collision for curves
works amazingly well if you keep in mind there balls around vertices colliding
ironing out a few glitches related to goal pinning
volatile test blend ->
http://www.wund.homepage.t-online.de/hidden/sb_col_must.blend
+ adding a few alternative collision ball calculation algos
since i did not want to blow up (waste) DNA space without need,
coded as -1.0 -0.1 -1.1 values in 'ball size' (look at tooltip popup)
simple (naive) self collision
estimates a collision ball
using the spring lenght to attached neighbours
(idea stolen from old cloth modifier files, but i'm sure ZAZ and genscher won't mind)
-- usefull for untangeling static cloth like objects
-- may be used for cloth simulation with known limitations
like 'tunnel effect' if objects are moving too fast ...
demo -- volatile files
http://www.wund.homepage.t-online.de/hidden/sb_without_selfcol.avihttp://www.wund.homepage.t-online.de/hidden/sb_with_selfcoll.avi
have fun
BM
Gives local structure stability for though fabrics, thin steelplates ..
even suzanne gets pretty crash resistant that way.
If non zero it not only adds diagonals but all other "2edge-wide" springs
so it somehow replaces stiff quads for meshes too.
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.
Sofbody simulation happens in global coordinate space, and this was also
used for baking softbodies. Too bad you cannot re-use or further animate
the baked softbody then... :)
If you now use the new "Local" button in the Bake menu, it will allow to
animate or move the baked object.
