View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005437||The Dark Mod||Graphics||public||30.11.2020 10:07||09.12.2020 17:17|
|Product Version||TDM 2.08|
|Target Version||TDM 2.09||Fixed in Version||TDM 2.09|
|Summary||0005437: Particles: static collision with "linear" mapLayout|
|Description||Right now only "texture" mapLayout is supported for collisionStatic feature.|
It is severely limited: it can only process particles which have non-random path, i.e. their movement is fully defined by their emit location.
The "linear" mapLayout should model all particles across several consecutive cycles, and precompute their collisions.
It exploits determinism of PRNG and is suitable for all particles, including randomly moving ones (snow, flame, etc).
It can also be used for particle models ("texture" layout is only usable with particle deform).
|Additional Information||Original proposal:|
|Tags||No tags attached.|
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:
Needed to trigger any collisions --- obviously =)
Specifies that collisions are precomputed for every possible particle trajectory.
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.
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:
|30.11.2020 10:07||stgatilov||New Issue|
|30.11.2020 10:07||stgatilov||Status||new => assigned|
|30.11.2020 10:07||stgatilov||Assigned To||=> stgatilov|
|30.11.2020 10:07||stgatilov||Relationship added||related to 0004957|
|30.11.2020 10:07||stgatilov||Relationship added||related to 0005138|
|02.12.2020 05:50||stgatilov||Note Added: 0013067|
|02.12.2020 05:51||stgatilov||Note Edited: 0013067||View Revisions|
|05.12.2020 12:07||stgatilov||Note Added: 0013099|
|05.12.2020 12:12||stgatilov||Note Added: 0013100|
|05.12.2020 12:12||stgatilov||Status||assigned => resolved|
|05.12.2020 12:12||stgatilov||Resolution||open => fixed|
|05.12.2020 12:12||stgatilov||Fixed in Version||=> TDM 2.09|
|09.12.2020 17:17||stgatilov||Note Added: 0013115|