 |
This is partly done in: r9020. Implemented "mapLayout linear" for particle collisions. r9019. Added "diversityPeriod" property to particle stage declarations. However, right now it only works for "particle deform" systems. For more popular "particle models" it is not implemented yet. In order to use it, several properties must be defined in particle stage: collisionStatic 1 Needed to trigger any collisions --- obviously =) mapLayour linear Specifies that collisions are precomputed for every possible particle trajectory. diversityPeriod K Says that every K-th cycle of the system looks exactly the same. This limits number of possible particle trajectories, making it possible to inspect them all beforehand. collisionStaticTimeSteps T In order to find first collision, the particle trajectory is approximated with a polyline having N segments in it. This is not needed/ignored if particle stage is such that every particle travels along straight line (without any randomness or curving). Suppose that particle system has N particles in total (recall that "count" is multiplied by surface area or number of triangles for particle deform systems). Then the cost of static collisions is: N * K texels in precomputed map O(N * K * T) rays to trace against world for runParticle So numbers K and T should be kept reasonably low since performance strongly depends on it. |
|
|
Added support for particle models in svn rev 9032, along with preparational commits 9030 and 9031. Now particle models can also benefit from collisionStatic, although there are many limitations for this. 1) I did not support the attachment system. So if mapper creates an entity which has "def_attach" spawnarg, inside which there is a particle model, collisions won't work for it. I have outlined conventions for this, but did not implement it due to bad architecture (right now I have to search for entity for every particle system every frame). The idea is to have filename like: [atdm_moveable_candle1_4][_candle][_flame][_lit], where two middle parts define "name_attach" paths (first is entity, last is model suffix). 2) Does not support entities with several "model_*" spawnargs using the same particle declaration. That's once again only because of bad architecture: I have no way of distinguishing the models from each other right now. 3) Any thing which has "diversity" randomized by game code or scripts won't work properly. This includes func_emitters (randomized in C++ code) and various "light" entities (randomized in script). "mapLayout linear" relies on having the same randseed in runParticle tool and during gameplay. So in order to fix these cases, it is necessary to remove all these randomizations in future. In order to make systems look different, randomizer can be deduced from "signature" using idParticle_ComputeRandomizer. Anyway, all those limitations are caused by lack of global manager of all particle system instances. There should be "particleManager" singleton, and every particle system should be registered in it, getting back a handle. Then all the information for identifying particle system (basically, the full "signature") can be stored near particle system instance (instead of having to recompute it on every update). The same manager would make it possible to implement GPU particles. |
|
|
Also updated "rain collisions" sample FM in svn rev 16030. |
|
|
Updated wiki article: https://wiki.thedarkmod.com/index.php?title=Particle_collisions_and_cutoff |
- Anonymous
