Yamyam: 1版をインポートしました

2018-06-28T17:52:20Z

1版をインポートしました

2014年8月19日 (火) 00:42にwiki>Britaによる

2014-08-19T00:42:32Z

新規ページ

{{NiceTip
|This page may be outdated
|Last edit on this page was on 2007, it is probably outdated.<br/>
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.<br>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).

← 古い版	2018年6月28日 (木) 17:52時点における版
(相違点なし)

Dev:Source/Physics/Sprint - 版の履歴

Yamyam: 1版 をインポートしました

2014年8月19日 (火) 00:42にwiki>Britaによる

Yamyam: 1版をインポートしました