Dev:Source/Physics/Sprint

提供: wiki
移動先: 案内検索
Blender3D FreeTip.png
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).