Corpse queue-like particle limit option

Remember, just because you request it, that doesn't mean you'll get it.

Moderator: GZDoom Developers

User avatar
Major Cooke
Posts: 8170
Joined: Sun Jan 28, 2007 3:55 pm
Preferred Pronouns: He/Him
Location: QZDoom Maintenance Team

Corpse queue-like particle limit option

Post by Major Cooke »

A nice feature would be an option to toggle particles being treated similarly to the corpse queue system where if there's already a full list of particles up against the limit, the oldest ones are destroyed to make way for the new ones.

Often times at lower particle settings I would find myself unable to spawn new particles because of a low limit that doesn't destroy the older particles, so I have to risk dragging my system down due to raising it.

So if enabled, the oldest particles are destroyed to make room for the new ones if the limit is already reached.
Accensus
Posts: 2383
Joined: Thu Feb 11, 2016 9:59 am

Re: Corpse queue-like particle limit option

Post by Accensus »

Bump for support. This would actually be helpful for maps that utilize particle effects. Hell, it would be helpful for a lot of stuff. If possible, it should be able to be forced via MAPINFO, perhaps.
User avatar
Major Cooke
Posts: 8170
Joined: Sun Jan 28, 2007 3:55 pm
Preferred Pronouns: He/Him
Location: QZDoom Maintenance Team

Re: Corpse queue-like particle limit option

Post by Major Cooke »

Agreed, except for the mapinfo part. That's a questionable one. If anything, I'd see it as something enforcable like jumping and crouching -- being the player's choice ultimately but allowing the map to decide.
User avatar
Major Cooke
Posts: 8170
Joined: Sun Jan 28, 2007 3:55 pm
Preferred Pronouns: He/Him
Location: QZDoom Maintenance Team

Re: Corpse queue-like particle limit option

Post by Major Cooke »

...I'm not even sure how the hell this thing works. I think this is better left to someone else who can handle it better.
User avatar
Matt
Posts: 9696
Joined: Sun Jan 04, 2004 5:37 pm
Preferred Pronouns: They/Them
Operating System Version (Optional): Debian Bullseye
Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia
Contact:

Re: Corpse queue-like particle limit option

Post by Matt »

Seeing as this is a purely aesthetic/interface matter I am in favour of such a thing being determined by the user.

That said, what would the consequences be of having no particle cap at all?
User avatar
Major Cooke
Posts: 8170
Joined: Sun Jan 28, 2007 3:55 pm
Preferred Pronouns: He/Him
Location: QZDoom Maintenance Team

Re: Corpse queue-like particle limit option

Post by Major Cooke »

Ever tried spawning 65535 particles before? I have. Turns FPS to SPF. A fuckin' crawl. And those didn't even move.
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine
Contact:

Re: Corpse queue-like particle limit option

Post by ZZYZX »

Few things that I've already mentioned in private talk with Cooke, but think they should be expressed here as well.
Currently (where "-" are particles that aren't drawn in case of too many, and "=" are particles that get to drawing):

Code: Select all

|===|--------------|
After Cooke's suggestion:

Code: Select all

|--------------|===|
Whereas particles visible to the player might look like this (spread in the list as "#"):

Code: Select all

|#---###---#-###---|
Since there is no relation between where these particles are and how old they are, it will lead to the same issue — if many particles are spawned in a single frame, you end up with them flickering/being deleted/being not visible at all (if many 1 tic particles are spawned for a complex animation like this).
With corpse queue this works only because corpses are created by the player, and normally somewhere near player's current location.

What makes more sense with limits like this one is:
1) don't spawn particles that have <35tic lifetime if they are not visible from the camera (assume 360 fov)
2) if particle overflow happens with visible particles, delete not the oldest, but the farthest or currently invisible particles first, or prefer particles with <0.5 alpha and nonzero fade (that is particles that ARE fading and are close to their death).

The complex part here is visibility check that should account for literally everything:
  • skyboxes
  • portals
  • cameratextures
  • F12
Since particles are always local and clientside, I'd do this in renderer integration (record what cameras were in use on previous frame or at the start of this tick, including textures and portals, and check against these).
Graf, with his "we might eventually move all rendering to GPU including visibility checking and camtex rendering" will probably be against this.
User avatar
Rachael
Posts: 13531
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: Corpse queue-like particle limit option

Post by Rachael »

As long as particles have no effect on the game sim, I doubt that Graf will be against it. You already have particles refusing to spawn based on a client-settable setting, anyhow, and that does not affect game sync. This isn't even hacky. (What's hacky is when the same principle is applied to actors, when actor lists should, in fact, be exactly the same on all systems regardless of how they are rendered)
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine
Contact:

Re: Corpse queue-like particle limit option

Post by ZZYZX »

If the renderer is used, then the visibility checking can be generalized to the list of sectors drawn in the last frame, which is easily done by using an approach similar to validcount (sector_t::drawtime==level.time) to avoid generating an actual list.
Then, either way, a particle that's about to spawn will find the sector that it's going to belong to (even without this system it's already doing it), and if this sector wasn't drawn, just don't spawn it.

The only real issue that I see with this approach is when people spawn particles and expect them to spawn reliably and instantly.
For this, I'd suggest to set the default global cap to 65536 as opposed to 1000 or 4000, but also have two flags:
  • ALWAYSSPAWN: spawn particle even if it should be blocked by this system
  • ALWAYSOPTIMIZE: optimize particle even if it has longer lifetimes (for e.g. particle foutains)
Then by default it'd apply to all particles except ALWAYSSPAWN ones, and to ALWAYSOPTIMIZE it applies even stricter rules.
User avatar
Major Cooke
Posts: 8170
Joined: Sun Jan 28, 2007 3:55 pm
Preferred Pronouns: He/Him
Location: QZDoom Maintenance Team

Re: Corpse queue-like particle limit option

Post by Major Cooke »

Unfortunately that's quite a bit over me at this point. My attempts have flopped terribly due to utter confusion on how to get this working since Randi coded this thing with pointer arithmetic...
User avatar
Rachael
Posts: 13531
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: Corpse queue-like particle limit option

Post by Rachael »

Pointer arithmetic is easy as long as you know how many bytes each structure is and you have the structure definition in-hand.
Post Reply

Return to “Feature Suggestions [GZDoom]”