Snow/Rain that stays outside where it belongs

#1 EXCELLENT!!!!!!!!!

#2 Excellent Ken, looks like it works well.

#3 cool. now if only we could get snow to stick to the ground as it falls and rain that turns the ground into mud... =)

#4 Ahhh nice work Ken!

@Ian: actually that might not be terribly difficult. You could blend in the snow texture on top of your other terrain textures slowly as it was snowing. Would be easy to create the effect that snow was building up like this.

#5 At last!
great stuff... works perfectly :)

#6 Hehe.. wow. sweet hack. I like the sheer simplicity of tossing a ray out to see if it should keep going or not.

#7 This is great! It even keeps snow/rain from appearing under buildings!

#8 Wonder if maybe this could be made standard in Torque...

#9 I don't know -- casting a ray per precip piece sounds pretty heavyweight (if that's 'per particle', that is...). I'd be happy to try and work it into a future release, but I'd want some performance tests, and it sounds like it could use some optimizations. But, I don't know much about the precipitation system, so I could be way off. Feel free to email me offline.

#10 Easy enough to add a switch to turn on/off detections. CastRay could also have one or two low-res modes as well.

#11 Ray casts per frame per particle are unnecessary...

At particle creation time, calculate the travel vector, cast a ray along this vector getting the hit location ... calculate the time it will take to travel to this location... and control the particles lifetime via this...

Or... use the portal system.

-J

#12 I like Josh's suggestion... basically, set the timeout on the particle based on a raycast at creation time. That should do the trick.

However, if you're getting into really complex situations, like wanting the particle system to be affected by aerodynamics and such, you'd want some kind of bsp/octtree breakdown of the system to optimize when to do what level of tests. I could see some cool things in a driving game where driving through the snowfall causes swirls and such...

#13 Can lifetime calculations be robust enough to deal with network lag ? If the server resynchs the player's position, what happens to the particles ?

And Josh, unfortunately, you're the only person I've found for whom portals seem to work to keep precip out from under bridges, etc.

David, others may want aerodynamic particles, but my objective is simply to keep the player 'dry' when he's standing under cover :-)

On my measly 800 Mhz PIII with GeForce 2 I don't see a visible drop in fps with precip on using my method above. It's good enough. There's plenty of other undone things to worry about :-)

#14 Ken,

I agree the effect is nice, though it could use some optimization. For instance, there isn't a check if the particle is .stillFalling before the ray cast...

The performance loss of raycasting obviously depends on how many particles and how many interiors are in close proximity. If there are no/few interiors or they are mostly being trivially rejected there won't be much loss. The opposite is also true.

On the networking comments... this is a client side effect... Regardless, raycasting per particle per frame inside the render loop certainly isn't any more "robust" than efficiently using a lifetime variable inside the render loop... in fact, the same thing is being accomplished... though, on one hand one ray cast is being performed and on the other hundreds or even thousands.

I do in fact need this functionality... and you are right some interiors do not lend themselves well to portals. A good solution is to use raycasting, though as little as needed.

-J

#15 Josh - good points. I realize this is a client side effect, but a precip particle is affected by the server indirectly via the player's position, which is determined by the server, hence the resynch remark. For example: when the client thinks the player is at a location which happens to be exposed, a one-time predictive cast for a particle will 'clear' a path to the ground/player character. This may turn out to be actually invalid once the server tells the client, "oops, actually you are over here", and 'over here' happens to be 150 cm away, under cover. So then you have several hundred or even thousand particles falling inside the outhouse in which you took shelter.

In addition to the above, I've employed the same raycasting per frame/per particle technique to place rain underneath a moving nimbus cloud. The rain only appears beneath the thundercloud, and of course doesn't get inside or under structures. Again, on my computer - which is no Olympic champion - there is no noticeable framerate loss (measured 3 to 4 fps drop) during a thunderstorm which also included lightning and Tx audio efffects.




Here is the code from above modified to make sure the drop is still falling before testing for interiors & stuff per Josh's suggestion above:

mFallingObj[x].stillFalling = false;
               }
            }
         [b]//-----------------------------------------------
           if (mFallingObj[x].stillFalling)
           {
               RayInfo rInfo;                                                           
               if (gClientContainer.castRay(  mFallingObj[x].curPos, 
                                              Point3F( mFallingObj[x].curPos.x,                                            
                                              mFallingObj[x].curPos.y, 
                                              mFallingObj[x].curPos.z + 10000 ), 
                                              InteriorObjectType, &rInfo) )
                      mFallingObj[x].stillFalling = false;
           }
         //-----------------------------------------------[/b]
    
            if(mFallingObj[x].stillFalling)// && mBox.isContained(mFallingObj[x].curPos))
            {
               coordX = mTexCoord[mFallingObj[x].texIndex].x;

#16 Ken,

The particles don't warp as the player moves around... they run their present course and get reused. The situation described above will never take place.

Finding the particle's hit location isn't prediction, it is where the hit will take place... whether you do it once or per particle per frame the result is exactly the same...

The code involved to do this isn't involved, and the data structure already supports it... if it doesn't exist by the time I get around to writing it, I'll post the code.

Though, if I am called upon for a demo beforehand, I may very well stick the code from here in :)

Cheers,
-J

#17 Update on this even though it is old.

The solution above still has it rain under water or under the Terrain should you go into fly mode and go under the ground.

To fix that change:

InteriorObjectType
to
WaterObjectType|TerrainObjectType|ShapeBaseObjectType|InteriorObjectType|StaticObjectType

#18 Hmmm... None of these refference lines seem to be in TGE 1.3.x. Anyone know how to fix this these days?

thx,
Raven

#19 dang I really need to know how to fix this problem in the new version of torque

#20 @Jesse P: TGE v1.5.2 seems to have this already implemented as per Josh's specs. This is a defunct resource.