Droplets on screen

[aVoX]

Hello!
I want to do the following: When the player enters a func_precipitation, the screen should be covered with slowly trickly drops.
The problem is not checking whether the player is inside or outside a func_precipitation (that's done in the code already), my problem is: how to create such a "rainy screen" (like in GTA IV when driving a boat or NFSU2 - click for example)? Does anybody have an animated texture in stock or an idea how to create something like this?

Thanks in advance.

[episoder]

those are lil screenspace billboards with a refract shader. the texture could be a simple sphere normal map or you do some different shape to make it look better. if you want to you could rotate the billboards based on the center then check how fast you're moving forward and scale them to the outside based on that speed. should look awesome. maybe you even want to add a lowres noise texture over it animating and blending based on that speed. lots of possibilities.

[aVoX]

Thanks for your input, but I have no idea where tostart and what to do :\

[episoder]

so "that's done in the code already" means you using the regular client? or you coding yourself?

if you coding yourself. create a entity for that effect, find the meshbuilder and how to use it to generate geometry on the fly and attach materials to it, setup parameters to control it and render that as viewmodel.

if you not coding you have to model the billboards and create an animation that does that effect. then attach it to the player so it gets rendered infront of the "player camera" (his eyes). also have to setup some logic to switch it off and on and basicly to control it.

not much more i could say here.

[Biohazard_90]

Originally Posted by episoder

so "that's done in the code already" means you using the regular client? or you coding yourself?

if you coding yourself. create a entity for that effect, find the meshbuilder and how to use it to generate geometry on the fly and attach materials to it, setup parameters to control it and render that as viewmodel.

Better draw it via vgui.

Originally Posted by episoder

if you not coding you have to model the billboards and create an animation that does that effect. then attach it to the player so it gets rendered infront of the "player camera" (his eyes). also have to setup some logic to switch it off and on and basicly to control it.

not much more i could say here.

In that case a particle effect would be preferable.

[episoder]

Originally Posted by Biohazard_90

Better draw it via vgui.

that's just 1 big screen quad. how'd he get more of that droplets on screen? don't tell me you'd really recommend using an animated texture for that? this overkill on texture memory load. you can do that on a vertex level with simple textures. that's why meshbuilder and do the effect dynamicly.

Originally Posted by Biohazard_90

In that case a particle effect would be preferable.

eats a lil performance for a not so "need to be simulated" effect. but sure it's probably best for gettting some random sprites in front of the player. i just wonder how to attach that to the player's eyes. i didn't do much screenspace stuff yet. :/

[Biohazard_90]

Originally Posted by episoder

that's just 1 big screen quad. how'd he get more of that droplets on screen? don't tell me you'd really recommend using an animated texture for that? this overkill on texture memory load. you can do that on a vertex level with simple textures. that's why meshbuilder and do the effect dynamicly.

I didn't say anything like that. You can actually draw stuff on a vgui panel that doesn't cover the whole thing in case you didn't know.

The meshbuilder is more inefficient in many ways especially when you would make it dependent from an entity.

Originally Posted by episoder

eats a lil performance for a not so "need to be simulated" effect. but sure it's probably best for gettting some random sprites in front of the player. i just wonder how to attach that to the player's eyes. i didn't do much screenspace stuff yet. :/

I am not sure what you want to tell me by that first sentence, could you rephrase that?

I don't know of any good way to attach it either without code, but if you can attach a model then you can attach particles too, especially when the particles are compiled into the model.

[episoder]

yeah okay. the drawpolygon() is basicly the same as a DrawPrimitiveUP() in native d3d. that would do. but where to setup a topology. does it split that pile of quads? if not and in case you have say 256 droplets on screen you loop thru droplets and have 256x the call overhead of the function. doing with meshbuilder is doing a batch of droplets in one vertexbuffer and one funtion call.

2nd: particles do collision. even tho you can limit it. that's what i thought.

[Biohazard_90]

Originally Posted by episoder

yeah okay. the drawpolygon() is basicly the same as a DrawPrimitiveUP() in native d3d. that would do. but where to setup a topology. does it split that pile of quads? if not and in case you have say 256 droplets on screen you loop thru droplets and have 256x the call overhead of the function. doing with meshbuilder is doing a batch of droplets in one vertexbuffer and one funtion call.

As you can see it's just a single polygon. The performance improvement from batching all geometry would be negligible to the overhead from using the dynamic mesh interfaces and the builder, a static mesh (with the builder of course) would be useless for this.

And again, doing it the way you said would require all sorts of unnecessary calculations (and networking) related to the viewmodel thing.

Originally Posted by episoder

2nd: particles do collision. even tho you can limit it. that's what i thought.

And that means that it would cost more? You can just disable it? Your alternative was a skeleton based animation, it's way slower than particles.

[aVoX]

Don't mind me talking between, but thanks for all the hints and tips to both of you. Right now I am epically failing to create some drops in the particle editor... hopefully there will be a result asap.
However, thanks

[episoder]

meh. what you need networking for a client screenspace or viewmodel effect. orthogonal projection, a custom material with a good shader and a dynamic vertex buffer. and spit the stuff on screen. ahh foo complicated interfaces to search for thousands of functions. i actually hate it. native is easier.

and skeletal animation. nah. look at the citadel destruction. fake that kinda generic and looping animation and done. no particle calc just some vertex stream frames and a shader to blend the positions.

[Biohazard_90]

Originally Posted by aVoX

Don't mind me talking between, but thanks for all the hints and tips to both of you. Right now I am epically failing to create some drops in the particle editor... hopefully there will be a result asap.
However, thanks

Before spending too much time with it you should try to parent an info_particle_system to the player entity and use a default effect for testing .
If that works out well I guess doing it that way would be a good option (if you don't want to/can't code anything).

Originally Posted by episoder

meh. what you need networking for a client screenspace or viewmodel effect. orthogonal projection, a custom material with a good shader and a dynamic vertex buffer. and spit the stuff on screen. ahh foo complicated interfaces to search for thousands of functions. i actually hate it. native is easier.

Well I don't know why you want to network it either, but you suggested to use an entity and draw it like a viewmodel.

Also, if you do it with a projection, then your argument about prefering the builder due to batching capabilities and better perfo makes even less sense. Just place stuff with unit cube coords in the client and save some calculations on the cpu & gpu. But an entirely dynamic mesh with a load of vertices that is set up each single frame is just relatively slow, especially if you need to recalculate the actual vertex data.

Originally Posted by episoder

and skeletal animation. nah. look at the citadel destruction. fake that kinda generic and looping animation and done. no particle calc just some vertex stream frames and a shader to blend the positions.

If it has an animation it is a skeletal animation. With that many bones (256 in your example) it's not better than particles and it's not even drawn in one go, source does only support 53 bones per draw call (and i think 128 per model?).

Particles are much more flexible too and it's easier to change them.

[episoder]

well. if you say so. maybe you don't picture the same effect that i do.

so... go for your particle approach. i'm fine with it.

[aVoX]

Originally Posted by Biohazard_90

try to parent an info_particle_system to the player entity and use a default effect for testing .

Doesn't work. That's all info I can give you. (I used !player as parent name because the default info_player_start doesn't have a name field)

[Biohazard_90]

Originally Posted by aVoX

Doesn't work. That's all info I can give you. (I used !player as parent name because the default info_player_start doesn't have a name field)

Did you do it via the SetParent input? I could imagine that using the parent field would cause it to try parenting too soon (before the player is available).
Furthermore, are you actually intending to do this in a singleplayer mod to begin with? If not, all of the hacky ideas are pretty much useless anyway and it should be coded.