If the raindrops were 1x1x1 unit cubes, the mdl format gives you a 255x255x255 voxel grid to work with.

Give the mdl a scale factor of (4, 4, 16), then your 1x1x1 raindrops are stretched to that size, and the whole mdl covers 1024x1024 units.

could be viable, and would look good with alpha + fog. The trick would be getting the lerping right to give a convincing animation loop.. 

DP rain/snow can easily become a framerate destroyer. 

I approached the idea of snow with a sprite.
It sounds a bit rare, but what if it was added to the v_weapon so it dazzled on the video screen.

snowsprite 

Could do it as a static entity if the drop falling and splashing is a looping model animation 

All the cheetz ideas.

/Static entity idea is very, very intriguing. Becomes almost free. 

I think Seven made it and while he's awesome, I think he did it in an inefficient manner just because "it worked" (and if optimized would be seriously faster, it's not even CSQC like I was thinking initially). 

That critical point when framerate tanks was always strange to me. I appreciate the feature and it's great in a pinch. A more optimized iteration would of course be nice. I agree with you that engine-side weather is the way to go.

I've poked around at some alternatives using a "forest" of player-facing sprites for rain and a decal on the ground for splashes/ripples, which is the same way I achieved the water caustics effect I posted a while ago. This looks ok and certainly has its limitations, namely, it gets pretty cluttered in the editor. 

I was thinking something like a pooled entity system where only a limited number of raindrop entities are active at any one time, and constantly redistributed to only appear in rain volumes that are in the player's field of view. However, considering the player's view could be constantly whipping around, this starts to look like a rather messy and calculation-intensive way of doing it. 

Use the best tool for the job. If one of the above cheater methods (static entities) doesn't work, the easiest method to grab gl_rain from Qrack. It's already written and has been a feature for a decade. Qrack's rain, 100% engine, comes from sky only. Very fast.

Qrack gl_rain https://youtu.be/50N7QkqbS5Q ^^ 12 seconds into video, you'll see the rain.

Add some sort of worldspawn key or activation command similar to the "fog x y z" and it would be a couple hour job for an experienced engine coder.

Qrack's rain has the same advantages as engine-based fog. Doesn't go in demos, doesn't go in saves, doesn't clog network traffic and can be turned off and is fast as lightning.

/I have to go with what videos I can find --- so ignore the music. 

 

...

but yeah I agree engine-rain is the way to go

(would be nice to have sky-emitted rain/snow in quakespasm with ways of controlling it in-game � la fog) 

The rain looks bad, I'm interested in how mankrip would implement it with his engine though.

as a side note is it pronounced man krip or mank rip? 

 

The rain looks bad

well, everything in that qrack video looks eye-gougingly horrific. If there was demand for it, I'd like to think the developers behind tasteful engines such as QS would implement a weather particle system in such a way that it wouldn't look terrible.

Giving the designer full control over the dynamics and visuals of the particles would obviously be a requirement. 

Instead of using simple, cheap yet fast 2d particles, 3d has much more options, is that the reason why you're discussing about this? I kind of lost me track where this discussion was leading to.

'gl_rain from Qrack' is that the best one out there? 

An entity in Quake is like a monster, a torch on the wall or a box of nails or an actual nail fired from a nail gun.

One method to generate "rain" that mods have used, is to make tons of rain drop entities in QuakeC (think Quake mod: Quoth, Arcane Dimensions, etc). But each rain drop is an entity (think monster).

Having a great many trivial entities each with their own location, frame, model, slot, etc. causes many problems (demo size, save game size, large amount of data sent from client to server, other issues).

A static entity (like a torch or invisible wall like a func_illusionary) cannot move, be created, be destroyed but is almost free. Metlslime brings this up as an option for a rain effect.

The other alternative being discussed is a pure engine effect, like the fog you see in maps. 

Thank you, that made everything much more clear. So could it be animated "thing", which is easy to control through duration/speed keys etc.

I guess that engine effect is still a bit vague to even talk about, yet alone what it is going to be in a practice. 

Yeah, like how torches are animated, even though they are completely inert. 

the problem with using entities is that they may or may not be interpolated.
if they're not interpolated (qs) then they'll be jerky.
if they are interpolated then they'll move upwards for a frame!

/me wonders how easy it would be to port fte's particle system over to quakespasm.

/me wonders how many people would complain about the result... 

Torches in Quakespasm are not lerped ONLY because they are excluded in the r_nolerp_list cvar. (Spike groans).

Do r_lerpmodels 2 in console and they are.

r_lerpmodels 2 lerps everything no matter what. 

you could solve the rain lerping upwards for one frame by having the drop go to zero scale the frame before and after the upwards lerp. 

A heads up for people interested in gamedev. You can get GameMaker: Studio Pro and some add-ons cheap in a Humble bundle for approx eleven days as of today.

https://www.humblebundle.com/gamemaker-bundle

It's not the perfect tool for making games or getting into gamedev by any means, but there are examples of successful indie games made with it. Here are some.

https://www.yoyogames.com/showcase

Some will argue that if you are serious about gamedev, you should learn a real language like C++ and use this or that engine for your serious projects. I don't disagree that these are important considerations for dedicated indie devs, but the thing is you can still learn all these things after playing around with GameMaker to your heart's content. I think of it as an option for someone looking to get started casually in gamedev with a limited budget of time and money.

There is also the free GameMaker: Studio you can get from Steam or Yoyo Games, if you want to take a look before buying anything. It's a good idea to see what it can help you with and what you still got to learn for yourself, because there are no silver bullets or free lunch. 

Although none are actually weather effects, the following models demonstrate the idea of creating particle style effects which disappear and then reappear to allow looping in engines with interpolation:

forcefield and smoke. The forcefield is the closest to the idea as the particles loop - even though there are particles going in both directions, if you track any one you'll notice that it only ever travels in one direction. The smoke is actually performing a similar trick, but because it's a big long thing it's harder to spot.

runic barrier. This is also similar to the smoke, but because it's got a greater number of distinct "particles" it might be more representative.

embers. These aren't intended to loop as such, but they demonstrate the idea of particles disappearing into nothing. They also exhibit a nice "floatiness" which might be good inspiration for snow.