From BlenderWiki
Subpages
Idea is to make a number of largely independent steps keep it manageable and modular.
- A more flexible particle buffer. This would be a multi-layer buffer, similar to custom data in meshes, but with better support for adding/removing arbitrary elements. The buffer itself is totally passive, no physics sim or other behavior is directly and necessarily attached to it.
- It gets a proper API so it can be scripted (unlike current particles which just break all the time). Even without fully fledged simulation nodes, many of the commonly needed features ("make a forest with particle instances") can be implemented with a bit of a python scripting then.
- Dupli objects feature for particles: This is one of the most useful and common applications of particles. For a start, a number of standard particle attributes can be used to define basic dupli objects: position, orientation, scale (transform in general). A list of object references can be used to map a simple int index layer to duplicate different objects. In the long run i'd like to improve the dupli API to allow passing data to shaders and animation system more flexibly, this can be implemented at a later stage.
- Scene-level physics solvers. Like the Bullet "Dynamics World", the solvers for physical simulations have to work on a scene-wide level, to ensure a consistent state of object data (see e.g. T36362). The problem with Blender's physics systems is that they perform this process per object instead of on the whole scene. This means that the state of collision objects etc. is inconsistent - some objects use the correct state if they are by chance calculated first, but others then use the already modified state after their predecessors have already finished the step and updated to the next (sub)frame.
- Better point cache implementation. This is not limited to the particle buffer, but could be used for meshes (at least deformation, maybe topology too), cloth/softbody, hair, etc. Our current pointcache system is too fractured and has several severe limitations (no custom data layers, fixed number of elements). Backend could probably be done with Alembic, or perhaps PartIO. Will not be immediately useful to particles without further steps below, so could be postponed.
- Programmable particle simulation. Like programmable shaders, this would be done with a custom tailored scripting language (syntactically similar to OSL). Artists would not be required to learn this language (see next step), but using a domain-specific formal language (DSL) is a good way of creating clear specifications. A specialized data type with list-like properties describes particle data a set of built-in functions can be used to construct any operator needed.
- This language can be executed in a variety of ways, from python, python+numpy, llvm to OpenCL. Another advantage of using a DSL over precompiled blackbox functions (like in cycles SVM and the compositor) is that once the language is correctly implemented in either of these backends they will rarely need to be upgraded, since it's basic building blocks are a fixed set of opcodes. New functions (nodes) will work automatically in each implementation.
- Node system! Using the new pynodes, this would be a fairly simple step, once the DSL is in place. Each node is associated to a function of the DSL. Evaluating a node tree then simply means concatenating all these functions.
- Most nodes can be generated automatically from the DSL code, some may require a small amount of extra python scripting for specialized UI functionality.
- Bullet-Particles feature: Bullet is great for implementing complex collision dynamics with lots of rigid bodies. To make use of it we need to extend the existing "Rigid Body World" to support particle data (create/sync RBs from particles, do simulation step, update affected particle data from RBs).
- This would work great in combination with a new "shards" system currently in development by scorpion86 to create dynamic fracture simulation. The shards are stored in their own buffer as dynamic mesh data and are used as bullet collision shapes, while the particles provide transformations and constitute the RBs.
- If feasible and in high demand a limited Bullet hook could be implemented at an earlier stage before the simulation DSL as a sort of standalone tool. But then it should be ensured that the work is not wasted by incompatible implementation and limitations need to be communicated clearly.
