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).