Dev:Source/Physics/Guidelines

提供: wiki
移動先: 案内検索

--- this doc is a work in progress ---

Physics system requirements

General remarks

  • Reliability is paramount. Users should never be in a situation where they're not sure if what they are seeing on screen is what they get. If simulations are being approximated for realtime tweaks/scrubs, this should be communicated very clearly that it's not a final result.
  • Apart from if a simulation is baked/locked, simulations should never require manual 'updating' especially in the case of doing unrelated actions (such as tab-tab for edit mode), in order to show correct results.
  • Updates/redraws should not be ignored arbitrarily in the code for performance reasons - it leads to far too many hidden 'rules' for users to remember and keep track of the system's state ("oh, i must remember that the system doesn't get updated after I move a force field"). Options should be available (with good feedback) for users to disable/approximate physics calculations if it's too slow - users can make these decisions for themselves based on the performance experienced.
  • API for accessing not only properties but as much information from the system should be present. ie: collision locations and forces involved

Guidelines

  • Playing back animation should reset physics back to initial starting point upon reaching end frame and looping to start. (no leftover physics results)
  • Once a simulation has been baked (either to disk or memory), using the bake button, it is locked and will not be modified in any circumstance other than by the user explicitly clearing the bake.
  • Physics systems must use the provided scene-level measurements/units by default (distance units and scale, start/end frame timing, gravity). Additional consistent options can be provided to override these, such as editable/animatable time scales, but by default physics must be consistent with the blender scene.
  • Physics results must be able to be retrieved on fractional sub-frames, from the solver and any caching mechanism. This is necessary for motion blur.


--Matt Ebb 09:32, 22 June 2010 (UTC)


See also old physics sprint doc http://wiki.blender.org/index.php/Dev:Source/Physics/Sprint