View Issue Details

IDProjectCategoryView StatusLast Update
0004132The Dark ModDesign/Codingpublic22.11.2020 12:50
Reportergrayman Assigned ToSteveL  
Status resolvedResolutionfixed 
Product VersionTDM 2.03 
Target VersionTDM 2.04Fixed in VersionTDM 2.04 
Summary0004132: Weather particle distribution should be more random
DescriptionA snow patch sometimes creates snowflakes that fall in line and descend like little soldiers shoulder-to-shoulder instead of being randomly distributed.

Rain splash patches tend to have more splash particles show up along one edge.

A small rain splash patch and a small rain patch will produce more particles than a large rain splash patch and a large rain patch.

All of which leads me to believe that particles like these are not 1 - positioned randomly or 2 - generated with a constant density across the patch.
Additional InformationI've never been able to change the density or randomness of a patch by changing its x/y scale.


related to 0004165 closedgrayman Make alternative weather materials that have a constant density irrespective of size 
related to 0005138 resolvedstgatilov Refactor particle systems code 




28.04.2015 18:36

reporter   ~0007499

The random number generator used by particles has a very small repeat cycle and is very naive which is enough to explain (1). But it sounds like something else is in play given the inconsistent distribution.


28.04.2015 19:57

viewer   ~0007500

Also, it appears that the same random numbers are applied to each patch in the same frame. If I have a set of steps and give each its own rain splash patch, you can stand at the top of the steps and, looking down, see that each patch paints the same splash in the same relative location, forming a line going down the steps.


28.04.2015 21:04


rain_splash_heavy.jpg (87,750 bytes)   
rain_splash_heavy.jpg (87,750 bytes)   


28.04.2015 21:16

reporter   ~0007502

I just attached a pic showing how easy this is to rep. It's 4 rain_splash_heavy square patches over 4 black_matt patches, seen by noclipping from above (contrast enhanced). All four including the big one have exactly the same pattern stretched across their surface, which confirms the density problem too. Changing the texture scale doesn't help.

Func emitter entities have a random "diversity" parameter which gets used as a random number seed for particle emissions, to stop them all looking like clones. Worldspawn patches are all one combined entity so can't have separate settings but it looks like they need to get an extra random number from somewhere. Maybe use one of their vert coordinates as a seed? I'm getting ahead of myself though, I'll go take a look what's going on in the code.


28.04.2015 21:58

reporter   ~0007503

There's an easy workaround for the density problem. In the material def (, change line

deform particle2 tdm_rain_splash_heavy


deform particle tdm_rain_splash_heavy

There are 2 settings for weather patches in the engine, "deform particle" and "deform particle2". Deform particle2 is a variant of the original that specifically ignores the actual area of the patch when calculating particle densities. For some reason presumably lost in history, TDM weather materials have always used particle2.

It's too late to change the original def files unfortunately... mappers will probably have layered rain to get the right density.


28.04.2015 22:21

reporter   ~0007504

The repetition problem has a workaround too. The weather patches are trying to use the same randomization method as func emitters, i.e. using the diversity shaderparm on the renderEntity as the random number seed. But all worldspawn patches are the same entity, so they all have the same seed. The diversity shaderparm is shaderparm5, so if you change some of your rain patches to be func_statics and set shaderparm5 to something different (range 0.0 -> 1.0), they'l stop being in sync with their neighbours.

Any ideas on how we can make both these things easier for future mappers without breaking old maps? I guess we can auto-randomize safely, but I don't have any ideas for the density problem.


29.04.2015 02:00

viewer   ~0007505

Using shaderparm5 fixed the problem on steps, thanks.

As for density, the best we can do is create new shaders that correct the density problem, and alert mappers of their existence. As you said, existing maps using the current shaders need to be left alone, because the mapper might have compensated for the bug, and now rely on the bug being left in place.


29.04.2015 06:40

reporter   ~0007506

Assigned to myself because I think we should go ahead and randomize the patches automatically. Func emitters and func smokes already force a random shaderparm5 so weather patches can do something similar. Any given emitter needs its seed to stay constant during play, else particles would have no continuity from frame to frame, and worldspawn has nowhere to store a list of seeds, so we can use the patch vert positions in the calculation to get stable variation.

I thought of one more option for density that'd avoid duplicating the materials, but I'm not sure it'll be easier. We could make a new spawnarg for worldspawn, "weather_particle_mode" "0 (default) weather particle patterns are fit 1:1 over your patch, so a bigger patch will have less dense weather. 1 = constant density. The pattern is repeated over larger patches."


14.06.2015 18:52

reporter   ~0007568

I've made an amendment that'll auto-randomize weather particles for worldspawn only, and only if the mapper hasn't set a shaderparm5 on worldspawn, using the centre point of the particle effect's bounding box as a random number seed, so adjacent patches won't look the same.


19.06.2015 18:28

reporter   ~0007583

Last edited: 19.06.2015 18:35

Committed the random weather at rev 6508




19.06.2015 18:35

reporter   ~0007584

I've made a separate tracker for the proposed new material definitions.


22.11.2020 12:50

administrator   ~0013010

I'm doing a major refactoring of all particle systems (0005138).

I think I'll change the way this randomizer works.
Dependence of rand seed on mesh coordinates is rather disturbing, given that I'd like to be able to exactly trace all particles in preprocessing phase for "collisionStatic" with "linear" layout.

Instead, I'll use hash of the following data:
  model name --- this includes area number for worldspawn
  surface index
  particle state index
I already have to determine all these values in order to find cutoffMap generated by offline preprocessing tool (collisionStatic feature).

Issue History

Date Modified Username Field Change
07.04.2015 17:14 grayman New Issue
28.04.2015 18:36 SteveL Note Added: 0007499
28.04.2015 19:57 grayman Note Added: 0007500
28.04.2015 21:04 SteveL File Added: rain_splash_heavy.jpg
28.04.2015 21:16 SteveL Note Added: 0007502
28.04.2015 21:58 SteveL Note Added: 0007503
28.04.2015 22:21 SteveL Note Added: 0007504
28.04.2015 22:25 SteveL Status new => confirmed
29.04.2015 02:00 grayman Note Added: 0007505
29.04.2015 06:30 SteveL Assigned To => SteveL
29.04.2015 06:30 SteveL Status confirmed => assigned
29.04.2015 06:40 SteveL Note Added: 0007506
14.06.2015 18:52 SteveL Note Added: 0007568
19.06.2015 18:28 SteveL Note Added: 0007583
19.06.2015 18:33 SteveL Relationship added related to 0004165
19.06.2015 18:35 SteveL Note Added: 0007584
19.06.2015 18:35 SteveL Status assigned => resolved
19.06.2015 18:35 SteveL Fixed in Version => TDM 2.04
19.06.2015 18:35 SteveL Resolution open => fixed
19.06.2015 18:35 SteveL Note Edited: 0007583
17.03.2016 11:24 SteveL Target Version => TDM 2.04
01.02.2020 05:02 stgatilov Tag Attached: particle
22.11.2020 10:52 stgatilov Relationship added related to 0005138
22.11.2020 12:50 stgatilov Note Added: 0013010