what* resembles doom's sector lighting.. 

Yes, it makes for a very flexible system with loads of different applications. 

ayy lmao kinda explained that poorly.
trigger_fog is NOT the same thing as eg q3's fog volumes.
the client can only use one set of fog at any time, which is applied to the entire map...
the trigger_fog brushes just change that client-wide setting once the player bumps into them, and its is applied smoothly over a short duration.
for practical purposes you're pretty much limited to one sort of fog per room, and transitions from one room to the next have to be handled really carefully to avoid the psychadelic world-changing-colour effect, typically by having small half-way rooms/corridors to keep the player distracted.
the smooth transitions mess up teleporters too.
they can be used for decent enough effects though, just remember that they're global and affect both near and far walls. 

anyway, pick your poison, give it a little momentum and someone will probably implement something eventually

Thanks spike for your reply. I was hoping that some kind of entity filtering happened when client demo's are recorded and another exception could be added to a list somewhere. I use the particle system built into DP/FTE so they produce better demo sizes.

There are so many new features I would love to be added to QuakeSpasm, but I do understand why they are not. Its just frustrating from a QC/MOD point of view as so many modern features (ie. global fog) are just hacks in QC to get them working. 

Would rock 

I will keep that in mind, I need to experiment a bit of it, after all my map will consist a lot of hallways, but I assume even elevator would work as a mood changer. 

I took a very quick shot at generating rain/snow and deconstructing the method used for Qrack's gl_rain.

Qrack gl_rain

Qrack uses for gl_rain video ... look at 13 seconds in to see gl_rain.

1. Take the sky surfaces.
2. In GLQuake, the sky is subdivided. (FitzQuake/Quakespasm it isn't and it would need a fake subdivision added in to have these rain or snow points.)
3. Average out the vertex positions in each sky polygon.
4. Emit rain from around those areas.
5. .. With a bit of randomness in origin
6. .. Some randomness in direction

End result is very easy rain.

But the fine tuning may be important ...
7. Appears to generate particles even out of view, which would be important if entering a new area.
8. But this means a ton of sky in a map is going to use a lot of particles.
9. But the particles at least "as-is" don't check for collision with the map or map entities (retractable bridge) and it would really need to. I can find indoor areas where rain comes through because outside a sky brush is over that structure.
10. Qrack does not appear to have rain in water, but I don't know if this is just because the particles don't last long (possible) or if I didn't find the code that killed off a particle that touches water.

Snow is would be easy to generate but possibly hard to fine tune.

Seven's DarkPlaces rain/snow

Video | Code + info

Another alternative would be the approach Seven used for DarkPlaces .

But Seven's DarkPlaces approach requires snow or rain emitting brushes in a map (func_snow or something?) -- which makes sense because QuakeC very likely has no way to know where sky brushes are.

Qrack's automatically identifying sky points method is vastly superior and easier on someone wanting to use it.

But there'd be a ton of fine tuning required.

I know because I took a quick shot at it screenshot.
1. Edit glpoly_t structure to add a vec3_t midpoint field and offset field.
2. Add a "rain think" in CL_RunParticles
3. Use -particles 8000 in cmdline // Default 2048
4. Pretty much take QMB_LetItRain from Qrack but adapting it to be just normal particles.
5. Some messing with Mod_PolyForUnlitSurface to pick vertex coordinates for snow/rain points. Would need some sort of fake polygon subdivision added back in to get it right.

(*) Seven's actual code appears to not use CSQC (client-side QuakeC), which would be better and required to avoid all of the problems with QuakeC rain (each rain drop particle is an entity, each entity saves in demos and has to go from server to client ... majorly big problems there). 

Note: The above is detailed notes for the benefit of whomever.

I took some time to chart it out, thought it would be good to record the info and make some notes.

But I don't really have time for engine coding--- especially something that would involve a lot of time intensive fine-tuning --- and don't want to create some sort of false expectation here.

On the plus side ... Spike seems intrigued by the idea of adding FTE's particle system to Quakespasm in the General Abuse thread.

If he would actually be willing to do something like that, that would be right avenue ;-) 

I have to say, I'm not sure I agree with this statement:

"Qrack's automatically identifying sky points method is vastly superior and easier on someone wanting to use it."


Unless there was some other way to limit which sky sections snow/rain could fall from, it would be a rather unfriendly situation to work with. Obviously the majority of cases it would be perfectly fine to have the particles fall from any sky surface, and it would certainly save on a few brushes, I can't think of a situation where it was better not to have as much fine-grained control as possible in content creation.

Just my 2 cents, of course. 

We'd still want the option of just spawning from all sky though - to suit the 90% of users who'd want to do it like that.

We'd certainly also want the ability to trigger sky rain on/off and change the density of it etc. midgame (like we do with fog triggers in AD and whatnot). 

That is some awesome info collation / analysis.

Best option (IMO) would be to use a particle based system from a func_weather/rain/snow brush. This way it could be triggered on or off, disabled in multiplayer, chosen where to implement and could allow flexibility in properties.

Style: snow, rain, acid-rain, etc
Density: distance apart.
Speed: speed.
Angle: straight down or xy

Am I going to implement this myself? Fuck no, I have enough shit on my plate already =P 

It could be blocked with skip brushes or skip the engine supported it which it should since particles should be blocked by geometry. 

 

baker, if you're using points rather than triangles/polys, you're doing it the lame way.
you can find the correct(afaict) maths for an even distribution in eg fte's R_Clutter_Insert function. no need to subdivide that way, and you don't get particles spawning within walls either (excluding fpu precision, anyway).

the idea of quakespasm with effects like https://www.youtube.com/watch?v=q-rO8haGoh4 (please excuse the bugged gloss, that's an ooold video) and yet no texture replacements kinda makes me laugh.
at the same time, the idea of a load of cubes or quads or circles or whatever doesn't fill me with confidence either.

regarding csqc, the idea of that without any other qc extensions nor replacement textures is also a bit of a joke, at least for everyone but the guy trying to use it, who would get too frustrated to produce anything worthwhile.

really though, if you want an engine with a decent particle system and decent csqc etc, then just use an engine that already has that stuff.
in all seriousness, a low-res weather system is imho just going to look as goofy as eg the gloss in that youtube clip. sure, its interesting to do for the sake of doing, but I'm skeptical about the results and repercussions. 

in all seriousness, a low-res weather system is imho just going to look as goofy as eg the gloss in that youtube clip

What I had in mind visually, was something that follows the same kind of aesthetic as sock's particle stuff. It's totes quakey. Just simple pixelley spritey things. 

@Spike -- interesting points ... of course my attempt to was to chart out existing bodies of work --- I was curious as to R00k's method of picking rain origin points.

Snow? I was thinking a bit subtle along the lines of Nehahra snow.

https://www.youtube.com/watch?v=6141F64dB0k

... but adapted to look a little more like Seven's DarkPlaces snow.

I'm in the school of thought that map effects in this game should add very gently to the content they appear in. Versus the idea of the effects being the center of the attention.

/Which may be largely academic, lack of time and all that ... 

Baker, that video almost perfectly describes what I was thinking in terms of weather effect quality. 

"I'm in the school of thought that map effects in this game should add very gently to the content they appear in. Versus the idea of the effects being the center of the attention. "

Wins the thread.

Also that video is nice and subtle, yeah. Works well. 

Nice and inoffensively quakesque. 

is perfectly fine for those engines aiming for a "classic" feel. Anything else would be jarring. 

Looking at the neh snow video, it's striking how something so simple adds so much life to an otherwise static scene. A Good Addition To Quake. 

The same way as Sock and other top modern mappers use fog and coloured lighting. 

So, is it possible to use a custom screen resolution in full screen mode? Setting vid_height, vid_width in the config appears to do nothing unless it fits one of the standard resolutions available in the in-game menu. 

The menu should list all the video modes that your driver says it can support, so probably not, unless the list is incomplete. 

Well, I'm trying to set it to 960x540 on my 1920x1080 laptop lcd (so, exactly half-resolution).

960x540 doesn't appear in the menu :{

Reason I'm trying this is because I think quake looks best at around 480 vertical resolution. I figured if I could set it to exactly half-resolution of my LCD it might minimise the shitty blurring that happens when LCDs try to display lower than native res.