MGS 2 style rain?
Blitz3D Forums/Blitz3D Programming/MGS 2 style rain?
| ||
| Just curious, anyone know how they made the rain so realistic in mgs2? I'm not after code, just wondering if they used sprites/particles or a combination..I don't have a ps2 anymore so can't check myself.. |
| ||
| It looks like sprites in a particle system for the main rain. The splashes are just a matter of taking any triangle that is facing "upwards" and creating random splash effects on it. |
| ||
| Ah..here I am trying to think up clever ways of making the rain collide in real time for the splashes.. never considered just making it random. Worth a shot.. |
| ||
| Well, that's my theory. I could be wrong, but I really can't imagine that they're tracing down to every surface and simulating actual rain drop strikes. That would be insane. |
| ||
| Yeah I tried it with sota once, way too slow with striaght linepicks. But on the other hand, without it it's going to be an equal nightmare preventing the rain from falling through objects..like walls... Maybe one pick when the rain drop forms along it's inertia...though that means no wind. back to square 1. |
| ||
| *cough* http://www.blitzbasic.com/codearcs/codearcs.php?code=474 |
| ||
| But on the other hand, without it it's going to be an equal nightmare preventing the rain from falling through objects..like walls... I'll bet if you looked closely at MGS2, you'd find that they don't handle it. They probably get around it with clever level design or just keep the camera in places where you can't see it screwing up. |
| ||
| Fred: That uses camerapick though. You don't wanna use that. Too slow. Figuring out where it is okay to put splashes, and doing it fast, is trivial if you make all the floors that you want rain to fall on a seperate mesh or surface from the rest of your level. And you are likely to do that because outdoor areas generally use different textures from indoor areas, and floors generally have different textures from walls. If you do that... Or keep a list of polygons which you want rain to fall on, then you can easily generate random points on those polygons. |
| ||
| Just a sidepoint: I was reading a magazine article which mentioned MGS2's rain used some very PS2-specific coding (read, it was crazy!). Justification: When they converted it to Xbox, they didn't take the time to adapt the rain effect for the system, which leads to slowdown in that first outside tanker scene, but never again in the game. |
| ||
| Yeah, it does look nice Fred, but it's only running at 27fps here. I can't devote that much time to one aspect of the fx. Plus this is for something I'm writing in vivid.. Swwift, the problem isn't so much finding where or deciding where to make the splash(Even if it's not random, vivid's linepicks go through an octree to cull any polys outside of the view frustum.) it's more finding a fast, non-demanding way to integrate the rain into the scene without affecting sheltered areas. (Without having to manually set up occluders.) I could do bounding boxes I suppose. Or maybe create a second mesh just for polys facing up like warren first suggested..still wouldn't be bullet-proof though. Bear in mind I'm doing this in vivid guys, so suggestions don't have to fall under what b3d can do..anything's at my disposable. But i'd like to avoid vert shaders, as I want the tech demo to run non shader cards. Warren, you might be right, but in all honesty I couldn't live with that, I want rain to heighten the suspension of disbelief, not diminish it...though a selective process wouldn't hurt..like lod...more checks the closer rain is, further away =no checks... |
| ||
| Joe I read that somewhere too. Makes you wonder what they really did if it wasn't possible on a xbox with vert/pixel shaders... |
| ||
| Warren, you might be right, but in all honesty I couldn't live with that, I want rain to heighten the suspension of disbelief, not diminish it. Well, a word of advice ... you sound like you're searching for the perfect world solution when something that looks "good enough" would do. Is accurately simulating rain the most important thing to your game? If not, just go with something that gets the job done and looks reasonable. |
| ||
| Well bear in mind this is for the tech demo/game to show off vivid.(don't think spinning cubes will impress too much)..so my quest for perfection aside, bad glitches will give people the wrong impression. Vivid's certainly fast enough, just never really needed rain before(Sota's got too slow in the end.) |
| ||
| Important thing is, make the raindrops thin and whitish. Bluish and thick raindrops just don't look right, and make light rainfall look much more heavy than it is, and heavy rainfall just looks awfull. Also, whiteish colours make for a nice sort of fake distortion effect (from my limited experience anyway). |
| ||
| Add in textures that move down planes in eyespace for the raindrops themselves, and for the planes create a special mesh or array or whatever you prefer and spawn a random amount of splashes on triangles stored within it. Simple solution, and if I recall correctly this is, for the most part, how Splinter Cell does it. Wouldn't be suprised if MGS2 handled it the same way, but I haven't played it since my PS2 died (6 months ago). |
| ||
| Just add zones like inside a box where the rain can exist and make the splashes bounce up off the lower part of the box ... have multiple boxes if need be instead of using the custom geometry if it's too complex. It could be cool though to use the geometry and have the rain and it's following particles bounce of the surface normal. Definitely use sprites though. |
| ||
| you could just do a linepick above the camera once every few seconds, if there is nothing above the camera then alllow rain to be viewed(however you create it) |
| ||
| RifRaf: Well then doesn't that kindof mean that if you go under a shelter that all the rain around you would instantly stop? |
| ||
| Sounds like the best bet is warren's method with a proxy mesh. |
| ||
| You'd almost think I had experience developing games or something. :P |
| ||
| In a few games I've played the rain appears to be particles, and to stop it raining inside buildings they simply force the rain to render before the buildings (You could do this in Blitz by using EntityOrder on the rain or maybe by a multi-pass render). I'm sure it's not quite that simple but it's something to consider at least. |
| ||
| Does the rain drop position have to be random? could you not have a 64x64 array containing local splash heights calculated with linepicks. Then when you move a certain distance shift the array down once and recalculate heights for only 64 rain positions. 4096 particles for rain seems more than enough and with a random droping order it should seem random enough. It is then only the initial 4096 height calculations that may take some time, but if the rain slowly starts say over 10-20 seconds you could randomly pick positions from the array over that time until it was filled. So the rain doesnt look like it is on a regular grid a small random offset could be added when the linepick is done. And for people standing still in the rain each time round the main loop 1 or 2 random drops could have their small random offset and heights recalculated. |
| ||
| That sounds like a whole lot of work to simulate something that wouldn't end up looking any better than the canned solution proposed above. |
| ||
| Calculating hit point isn't the problem.It's knowing when to calculate it. If that makes sense... I can't exactly cast a pick from last to current position of each drop... though, that said..I could optimize the oct-tree pick system to check the destination cell first..no polys = no collision checks needed.....ooeh..that'll work.. God bless the vivid! :) |
| ||
| Ok, I didn't read throught the whole thing, so I might say nothing new.. Anyways, I think they made the splashes part of the character animations (part of the character mesh) and just played that particular animation when being out in the rain.. I believe I saw this on a behind the scenes thingy.. long time ago though. |
| ||
| Spaced It still sounds like you're doing too much work for the end result. But it's your time, so... AshMantle That wouldn't explain the splashes on the geometry. |
| ||
| Ash, i doubt it unless it was a seperate entity, otherwise the splashes would jump whenever snake's anim changed. But it would be possible...even on geo warren, imagine if each vert was simply read into the engine as a location for a splash. hell you could just scan the level geo, devide the polys by the number of splashes you want, then use that as a step value and place the splash emitter at the centre of the poly. But anyway, w the oct_linepick system is a part of vivid..so, to add this new feature is simply 'if not destnode\hasGeo return'. Octrees are great for speeding up complex collisions/shadows and what not. |
| ||
| ok, this is a funny read. i have the metal gear substance editoion and if you watch the making of video they tell you that the rain on the characters (and probably on the tanker as well) is just an animation. so when snake walks into the tanker he just switches to another (set of) animation(s). |
| ||
| Again, that doesn't explain the splashes on the geometry. The PS2 is highly limited in memory. I would be amazed if they had a whole other set of animations and geometry in memory JUST for rain splashes. |
| ||
| if it's just one big "model" where a couple of rainsplashes move around real fast? seems very feasable to me... |
| ||
| Still sounds like a ton of wasted memory. But I don't have any facts, so... |
| ||
| just a little extra polygons.. no big memory hog there? (compared to all the other things going on in that game) |
| ||
| exactly, a couple of polygons and a load of keyframes, should not use that much memory. |
| ||
| So ... we're talking about storing special geometry which is what was suggested in the first place? I'm lost now. |
| ||
| mh, maybe i am confused too. i probably misunderstood what you meant in the first place... |
| ||
| Ok, I just ran through the special behind the scenes dvd that came with my copy of the game.. I recorded this section from the effects talks. www.poly.no/mgs2_raindrops.mp3 |
| ||
| Ahh, now if they were part of his model and were simply hidden when he went inside, THAT would be somewhat sensible. However, it still leaves the geometry splashes unexplained... |
| ||
| The video won't download. |
| ||
| > The PS2 is highly limited in memory. It's not that limited in memory. Besides during that part of the game very little of anything else happens which would certainly allow that effect to hog a lot of CPU and memory with no slowdown. |
| ||
| It's not that limited in memory. Four megabytes of graphics memory and 32 megabytes of conventional ram isn't 'that limited'?! |
| ||
| Memory is every companies biggest problem when trying to do a PS2 port. Doing the Unreal Tournament port, we had to rip half the content out of the levels for them to even have a prayer of loading... |
| ||
| IIRC, and I probably don't, Kojima and his team were down to the last few k of free mem come release. However, you're overloking the fact the level geo has to be in memory anyway, so it wouldn't take up extra memory, just cpu time.(I.e for tri=0 to leveltris step 40 : doSplash(tri,Centre_of_Tri) : next) That would explain the slowdown on xbox,as xbox/dx = vertex buffers, not that fast at all to read from, yet ps2 = software vertex processing, so to read the geo data = much faster. Just a guess.. |
| ||
i was thinking something like this:Graphics3D 640,480,16,2
campiv = CreatePivot()
cam=CreateCamera(campiv)
MoveEntity (cam,0,0,-20)
RotateEntity(campiv, 45,0,0)
l=CreateLight()
p=CreatePlane()
EntityPickMode(p,2)
For i = 1 To 100
c = CreateCube()
ScaleEntity(c, Rnd(1,3),Rnd(1,3),Rnd(1,3))
RotateEntity(c, Rnd(360),Rnd(360),Rnd(360))
PositionEntity(c, Rnd(-20,20),0, Rnd(-20,20),1)
EntityPickMode(c, 2)
Next
For splash = 1 To 2 ; use higher values for more intesive rain
s = CreateSprite()
EntityColor(s, 255,0,0)
EntityFX(s, 1)
For frame = 0 To 200
LinePick(Rnd(-20,20),50,Rnd(-20,20), 0, -100, 0)
PositionEntity(s, PickedX(), PickedY(), PickedZ())
SetAnimKey(s, frame, 1,0,0)
Next
seq = AddAnimSeq(s, 200)
Animate(s, 2)
Next
While Not KeyHit(1)
TurnEntity(campiv, 0,0.1,0,1)
RenderWorld()
UpdateWorld()
Flip
Wend
the only problem is (in blitz) that i can't turn off the interpolation between keyframes, when you slow down the animation you see the splashes slide from one position to antoher. but that's a minor detail. |
| ||
| As proposed above, just create a blanket proxy mesh which dictates where the rain must fall. Then, access this mesh whenever you spawn a rain splash. You get the area of a random triangle near the player and spawn a particle. Why is this so hard for people to use/understand? it requires only a tiny overhead. |
| ||
| Something just occured to me. Why do people opt between quads and sprites, why not just use a polygon isntead of a quad, a triangle. The shape of a triangle compared to a quad isnt that important if you size it right, and its 1/4 vertices less, and 1 less poly. Rain drops can fit inside a triangle like that. |
| ||
| Because you can define a quad/point sprite with a single call to the gpu, triangles require 3.(Not in b3d, but with what I'm doing anyway) Koe, I'll be using linepicks.(See above) just vivid's super-speedy ones..;) But what i'll be doing is casting down lines pre-runtime,to create a map of splash locations, and mix real-splashes with random ones. |
| ||
| Something just occured to me. Why do people opt between quads and sprites, why not just use a polygon isntead of a quad, a triangle. The shape of a triangle compared to a quad isnt that important if you size it right, and its 1/4 vertices less, and 1 less poly. Rain drops can fit inside a triangle like that. On all gpu's a textured triangle is slower than a quad because the extra vertex doesn't really matter to it. In contrast, when you use a triangle, you use at LEAST 4 times the fill rate to compensate for fitting a square texture inside it. Try it in a modelling package and see... It's a LOT slower. If it's untextured and you need an untextured triangle then fine... |
| ||
| No, modern gpus merely convert quads into two tris at the rendering stage. Texture mapping remains the same. The gain comes from only having to define 4 verts/normals/colors per quad, rather than six per quad using triangles. |
   |