View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004132||The Dark Mod||Design/Coding||public||07.04.2015 17:14||22.11.2020 12:50|
|Product Version||TDM 2.03|
|Target Version||TDM 2.04||Fixed in Version||TDM 2.04|
|Summary||0004132: Weather particle distribution should be more random|
|Description||A 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 Information||I've never been able to change the density or randomness of a patch by changing its x/y scale.|
|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.|
|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.|
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.
There's an easy workaround for the density problem. In the material def (tdm_weather.mtr), 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.
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.
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.
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."
|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.|
Committed the random weather at rev 6508
|I've made a separate tracker for the proposed new material definitions.|
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
particle state index
I already have to determine all these values in order to find cutoffMap generated by offline preprocessing tool (collisionStatic feature).
|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|