Dev:Source/Physics/Sprint

	This page may be outdated
	Last edit on this page was on 2007, it is probably outdated. If you have questions, ask in #blendercoders at IRC

Sprint

Common Solver API

• Simulation rebuild (modified solver setting, re-run the solver with unchanged data)
• Total rebuild (modified geometry, would reallocate, rebuild from scratch)
• One frame step forward will NEVER recalculate the whole simulation.
• Larger or negative frame steps, may require simulation recalculation.

• objects need a new flag for solver for rebuild and recalc.
• flags work in the same way as they do now for object updating. Solvers need a..

flag for total rebuild. flag to rerun simulation (with new settings) and a callbacks for each.

The SolverAPI will manage running these callbacks when needed, the solvers will not need to trigger these events.

Collision System

• Multiple solvers can access.
• objects must have a flag that they are physics type. This will this will flag the objects as needing data from t-1, t+1 (for instance).

when object_update is called the extra physics data is calculated, so all solver's have this data when they start.

• collision system can use groups for defining which objects interact with eachother. (solves collision system overload problem, this may not be a big problem)

Collision Response

• dynamic <> dynamic - need to have a collision response system so different solvers can interact.

Rigid Body (Solver)

Note, Object level dynamics will not interact with vertex level dynamics (cloth, particles, sodtbody) - this is a real limitation but no simple solution.

• Bullet does not support feedback from other systems (its not planned as a part of bullet, and erwin does not want to add this because its not needed for xbox, ps3)
• Could be made a part of the animation system. other solvers would treat rigid body animation like IPO's.
• Rigid body should evaluate animated objects before collision objects so ipo's.

Global Collision Cache

• The modifier stack is used to build this data, each objects stack can have one level set where the data is added to the collision cache.
• API functions to add, remove.
• Blender needs to maintain a physics world.
• It should be able to contain collision (previous and next frame data for interpolation)
• static data is optimized for collision detection (quadtree). (not animated data such as armatures etc, they can use basic speedups like face bounding boxes)

• • add object, remove object.

• • Static objects

• All solvers can use the physics world for collision detection.

• Each collision system needs to use the same method of including/excluding objects from simulation (flag/groups/layers).

Collision

• Separate Static/Dynamic collisions.
• Collision system uses the 'physics world'
• API Call for a list of collisions
  • Point of collision
  • Normal
  • Speed
  • Time of collision
  • Type of collision (vert/edge/face)
  • Particles need to now which face and the faces UV.

• Collision data is collected from a modifier (can be selected similar to render buttons).

Note, Genscher has already implicated many of these features

Solver's

• Each solver has an entry in the modifier stack.

Modifiers

• Simulations are modifiers (layers) - however they will may be calculated in groups. rather then one at a time.
• We need a way NOT to recalculate the entire stack whenever a setting is changed. - This is not a requirement for working, but will speed up operation greatly.
• We need to be able lock modifiers to use cache (disable automatic recalculation), for faster editing.
• Keep in mind modifier nodes may be implemented later. NOT apart of this project.

Cache API

• This is so the system can respond fast on loading - the system has already calculated the data - The cache will rebuild if the cache files are not there.
• Cache is stored on disk (similar to textures) A possibility later on could be to save he bake in the blend. this is managed by blender and the solver will not worry about - but is not a requirement.
• Blender has an API solvers can use for 'display caching'
• This is because the user should be able to load a blend file at frame 500, and go to 499 without regenerating the whole simulation.
• Each solver can write cache to a file, the solver will provide handlers for read and write.
• Cache can be stored compressed - gzip (like fluid)
• Cache memory management can be improved later on (keep the next frame in memory etc)
• File names for temp files - need to be unique - can be a hex of the name, implementation detail.

Rendering Cache

• The rendering engine should be able to generate cache before rendering (on demand). - so the renderfarm can generate all physics.
• Rendering and display cache will need to be separate.

Editable Bake?

We use jahka's the current particle system way of working - by redirecting transform function to the mesh-vertex-keys.

KeyBlocks are stored on the mesh. we need a way to map vertexkeys to modifiers - this could be done by making names unique or by referencing indices and then maintaining them to be correct.

Units

• We could add conversion function per scene. 1BU == 1mm. 1BU == 1km.
• Solvers should give human understandable presets - Silk, Canvas as well as typing in numbers like Fluid/SSS.
• Each solver can have a scaling factor for time, distance and gravity.
• Better units in blender would be an advantage but are not %100 needed.

Cloth

• Cant be merged with SoftBody
• Would be an advantage to use cloth for hair (no stretching)

Particles

Priorities for peach

• Write new caching system
• Implement in particle branch.
• Solve mapping particles.

• Hair does not use cache, data edited directly.
• Cloth and softbody always edited in editmode, particles and hair always edited in particle mode.
• Softbody handles all hair dynamics.
• Hair's softbody will not have an entry in the modifier stack.

OpenMP

• OpenMP is ok to use.
• Get animation system threaded first.
• There are cases where multithreading is a big advantage - 'per animation' or 'per modifier'

Todo

• Physics World
• Collision library
• SolverAPI (blackbox)
• Generic Solver Cache System

2.46 release proposal for pointcache

Since the physics sprint we have implemented some of our goals.

Problems

• Point cache becomes out of date too easily, blender does not invalidate pointcache when it should.
• Point cache does not make a distinction between render and display cache. (which can be different depending on modifier settings)

Solutions

• Have 2 pointcaches, one for display and another for rendering.
  This seams a very inelegant solution, however the render world can contain totally separate geometry from the render world therefor there needs to be 2 separate pointcaches.
• Have a function for baking all pointcache (render level and/or display level)
• Have an option to clear all pointcache in the blend file (This should not be used to workaround existing problems with displaying invalid).