Particles system

Discuss programming topics for the various GPL'd game engine sources.
Post Reply
Cobalt
Posts: 445
Joined: Wed Jun 10, 2009 2:58 am
Location: New England, USA
Contact:

Particles system

Post by Cobalt »

I have bought this up to Lord Havoc recently. I find it unusual that the particles system not only in DP but to my knowledge ALL other engines , allows particles to pass through solids. I realize they are most likely non-solid type renders and thats the reason, but I cant think of any effect even as far back as TE_LAVASPLASH that would stand to benefit from it passing through walls / solids. Smoke, blood, sparks, rain and everything else I can think of thats using particles has no use being able to pass through solids.....unless anyone can think of one?
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: Particles system

Post by Spike »

its not an appearance choice, its an efficiency choice.
preventing particles going through walls is seriously expensive when you have 5000 particles on screen at once, each one of them doing collision tests every single frame (although you could optimise it to only one collision test when its first spawned, but then it would still pass through doors and stuff, and that tweak would only apply to particles with no gravity).

there's not really that much you can do when a regular particle hits a wall, other than to remove it so that it doesn't look too goofy when it comes out the other side - bouncing sparks can often be a bit abrupt when it suddenly flips and changes direction of motion, especially if slowly moving along a surface with constant gravity.

and to dispell your myth, FTE supports either bouncing particles, particles that automatically stain surfaces, or particles that spawn new particles on impact. all three need to be enabled via the particle config though, so not all configs will do it (also, be sure to set r_bouncysparks to 1 or it'll be ignored, but configs that depend on that have a nasty habit of forcing it on).
Cobalt
Posts: 445
Joined: Wed Jun 10, 2009 2:58 am
Location: New England, USA
Contact:

Re: Particles system

Post by Cobalt »

Thanks Spike, didnt know that, nor the enhancements for FTE.

Lord Havoc had mentioned checking the ttl as a way of improving this te_rain bug:

Image

(You see the rain particles pass through the solid BSP)

His sugguesiton was:
"Yes it looks like the time to live for the rain particles should be adjusted to compensate for the length of the particles, since right now their origin stops at the impact point but ideally their bottom extent needs to end at the impact point instead..."

To my knowledge I dont believe there has been a build made to test this. Im wondering if this would work for other particle effects if it works for the rain.
leileilol
Posts: 2783
Joined: Fri Oct 15, 2004 3:23 am

Re: Particles system

Post by leileilol »

Collision is expensive. If you've played Engoo with r_particleblood 666 you'll see how brutal particle collision can be as each blood droplet does expensive trace checks to find where and how to move and behave, then again collision is necessary for high pressure blood to not escape the universe


That rain test bsp looks inteesting. Any sharing?
i should not be here
frag.machine
Posts: 2126
Joined: Sat Nov 25, 2006 1:49 pm

Re: Particles system

Post by frag.machine »

I think this is the golden key room in Gloom Keep.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC :) (LordHavoc)
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: Particles system

Post by Spike »

also, when its a big long streak like rain particles, is the 'impact' when the start of the streak hits the ground (in which case it abruptly vanishes) or the end of the streak (in which case it can still poke through)? both bugs can be more distracting than simply passing straight through, at least if the maps were made with the behaviour in mind, anyway.
Cobalt
Posts: 445
Joined: Wed Jun 10, 2009 2:58 am
Location: New England, USA
Contact:

Re: Particles system

Post by Cobalt »

Yes, its E1M5, the golden key room. Creating rain coordinates for the ID maps can be challenging, as you are drawing a box...and some locations like this one, you can draw lots of smaller seperate boxes to fill the general area, or one large one covering the area of the room. That has drawbacks, as shown in the screenshot....instead of making smaller coordinates for locations that dont have the rain hitting a solid, while on its way to the room floor. The same issue happens when it hits a liquid as well...but, that kind of effect does look more or less acceptable if you are in the body of liquid and happen to look up and see this...it gives the impression of it penetrating the liquid ever so slightly.

Take a map like E1M6 where the button is that opens up the door on the floor you drop through , and you have a nightmare trying to make the rain look correct.

If you think about it, you really ought to be able to just draw a thin box way above the map in the skybox, covering the area of the map, and the engine ought to do the rest - drawing particles starting in only CONTENT_EMPTY coordinates from the max_z of the box, allowing them to continue until encountering a solid. However, all the ID maps traditionally use SOLID skies, unless you Re-BSP'd them or ar using all newer maps in your mod. The engine would have to be able to detect the sky textures as well I guess to over come this issue. the other drawback over the way it is now, is that you can use the current syustem to make a trigger field the size of the rainbox as a way to detect a player touching it, and create some lightning effects for example. In my youtube channel, I recently made a demo of some lightning tests using this system, with a new sprite that Madfox made for me, its not too bad for a start.

As for sharing , PM me or post requests whatever you want, and I will see what I can do.
Cobalt
Posts: 445
Joined: Wed Jun 10, 2009 2:58 am
Location: New England, USA
Contact:

Re: Particles system

Post by Cobalt »

Im guessing by what LH wrote in the above quote, the impact is the top half of the particle....there is a "lower half" , which he seems to say can be adjusted via ttl. Upon impact there is a slight "splash like" particle effect resembling a spark which looks ok on the top half...but it could well be that the same effect is being duplicated on the lower half somehow...or that the particles ttl value didnt take the collision into consideration and enforce what happens on the lower half at all. To me, it sounds like you would time it based on the smallest thickness of a BSP bridge that you can find on any given map - and make it so that it starts vanishing as early as possible with that in mind...then any other thickness solid up from that , you would not see the particle passing through as in the screenshot supplied.
Spike wrote:also, when its a big long streak like rain particles, is the 'impact' when the start of the streak hits the ground (in which case it abruptly vanishes) or the end of the streak (in which case it can still poke through)? both bugs can be more distracting than simply passing straight through, at least if the maps were made with the behaviour in mind, anyway.
leileilol
Posts: 2783
Joined: Fri Oct 15, 2004 3:23 am

Re: Particles system

Post by leileilol »

i should not be here
Cobalt
Posts: 445
Joined: Wed Jun 10, 2009 2:58 am
Location: New England, USA
Contact:

Re: Particles system

Post by Cobalt »

Not an engine programmer yet, but I guess what I am hearing is that particles just get "drawn" from start to end, and collision detection never happens because they are not "entities" more or less? What about tracing their projected course / path, and doing a pointcontent type check for a solid along the entire path? Im also guessing the particles are removed only when their ttl expires, so could we not project in a time frame when the particle would be encountering that solid area, and set the ttl to live accordingly?
gnounc
Posts: 428
Joined: Mon Apr 06, 2009 6:26 am

Re: Particles system

Post by gnounc »

Cobalt wrote:What about tracing their projected course / path, and doing a pointcontent type check for a solid along the entire path? [...] could we not project in a time frame when the particle would be encountering that solid area, and set the ttl to live accordingly?
Thats exactly what you said above that LH told you to do.

take the origin, trace down for a long line, find the length until collision, project how long it will take the particle to reach that collision from its origin, and set that as ttl.

Finito.
leileilol
Posts: 2783
Joined: Fri Oct 15, 2004 3:23 am

Re: Particles system

Post by leileilol »

That method could have an issue with brush entities especially those that move. Though another advantage with that is just making rain as a single beam that's already from start to target and controlling its scrolling speed and using a clamped texture. You're trading CPU time for GPU fillrate in that case...
i should not be here
Seven
Posts: 301
Joined: Sat Oct 06, 2007 8:49 pm
Location: Germany

Re: Particles system

Post by Seven »

gnounc wrote:
Cobalt wrote:What about tracing their projected course / path, and doing a pointcontent type check for a solid along the entire path? [...] could we not project in a time frame when the particle would be encountering that solid area, and set the ttl to live accordingly?
Thats exactly what you said above that LH told you to do.

take the origin, trace down for a long line, find the length until collision, project how long it will take the particle to reach that collision from its origin, and set that as ttl.

Finito.
Hello gnounc,
unfortunately it is not that easy.
I made rain .ent files for the id1 maps and could gather experience with this topic.
Picking an example map: E1M4
Directly at the end of this map there is a great outside area with a big bridge and several castle-like brushes.
So, height difference in this area from sky to solid ground is always different.
And this is the case for almost all outside areas, as you always have obstacles, or walls or other things.
The beautiful thing about DP´s rain is, that it spawns small splashes when it hits solids or switches from air to water.
I love this effect. And it works absolutely robust.
The only issue is, as Cobalt mentioned, the splash effect is passing through the solids.
BUT, it is directly depending on the *thickness* of the solid (or better said ist layers).
The bridge in the example E1M4 again:
Below the bridge you can almost not see splash particles bleeding through, as the bridge has 2 surfaces:
on top and below.
Other situations, like the screen shown by Cobalt has almost no stopping-effect on the splashing particels.
They bleed through it, almost as if there were no solid.

And my experience also shows, that it is depending on DP builds.
The behaviour was a lot worse in early releases before 2011.
While many "bleeding through" areas with builds before 2011, these areas were completely issue free with later builds in some maps.
Unfortunately it did not get better with newer builds.
Most probably due to the focus of LH and friends. If he would focus more on this topic, it would probably be possible to improve it more.

I used a trick to compensate this issue several times:
Cut the outside areas into pieces/cubes and leave out some areas which would lead to bleeding, when the area is not directly accessable by the player.
In most cases the difference is not noticable from the ground when looking upwards. Example: E1M5.

The situation is totally different with the snow effect of DP:
I also made snow version for many maps and the fact that snow particles do not spawn "splashes", makes it never bleed through solids.
Just like the rain particle never bleed through.
It is only the rain-splashes that bleed through.

Solution would be easy:
Limit the lifetime of the rain-splashes and the issue is 100% solved.
If I would know how the effectnum is, even i could fix it via external effectinfo.txt, but unfortunately I do not know the effect name for the splashes.
It is hardcoded in .c (which I cannot read).
Maybe Cobalt can ask LH in one of his next conversations with him, as he seems to stay in close contact with LH.

Best regards.
Cobalt
Posts: 445
Joined: Wed Jun 10, 2009 2:58 am
Location: New England, USA
Contact:

Re: Particles system

Post by Cobalt »

I can see if there is a door that the rain hits and its now an open door - the particle would vanish , but I dont think thats too much an issue as long as the door isnt directly on the floor.

One of my points I made to LH was that we could make rain very simple if we placed one thin rainbox matching the maps max_x and max_y dimensions at a point in the skybox slightly higher than the highest BSP or max BSP height before the sky texture hits it. Then, we can code the particle to detect contact with the skybox, and treat it as if its open content - which would allow the particle to continue in the skybox. Perhaps some kind of depthtest to allow it to still be drawn would need t be applied, and perhaps a pvs check as well to cut back on fps. This would allow us to see rain in the skybox possibly, improving the effect. That way you draw one large box on a map, and you are done. the disadvantage over the current system is you could not have "partial" rain on maps, where its raining say on 75% of the map, and some areas the storm has already passed over, and no rain is there.
leileilol wrote:That method could have an issue with brush entities especially those that move. Though another advantage with that is just making rain as a single beam that's already from start to target and controlling its scrolling speed and using a clamped texture. You're trading CPU time for GPU fillrate in that case...
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: Particles system

Post by revelator »

Could use sprite32 for rain (should use the alias model collision and culling code not sure how big the impact would be though).
I used it for underwater bubbles and explosions and it seems to Work quite ok there collision wise.
Productivity is a state of mind.
Post Reply