View Issue Details

IDProjectCategoryView StatusLast Update
0005437The Dark ModGraphicspublic09.12.2020 17:17
Reporterstgatilov Assigned Tostgatilov  
Status resolvedResolutionfixed 
Product VersionTDM 2.08 
Target VersionTDM 2.09Fixed in VersionTDM 2.09 
Summary0005437: Particles: static collision with "linear" mapLayout
DescriptionRight 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 InformationOriginal proposal:
TagsNo tags attached.


related to 0004957 resolvedstgatilov Snow and rain particles stopping on brushes 
related to 0005138 resolvedstgatilov Refactor particle systems code 




02.12.2020 05:50

administrator   ~0013067

Last edited: 02.12.2020 05:51

View 2 revisions

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.


05.12.2020 12:07

administrator   ~0013099

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.


05.12.2020 12:12

administrator   ~0013100

Also updated "rain collisions" sample FM in svn rev 16030.


09.12.2020 17:17

administrator   ~0013115

Updated wiki article:

Issue History

Date Modified Username Field Change
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