Crysis - Mass Physics

  • Thread starter Thread starter 4p
  • Start date Start date

4p

4p

Soldato
Joined
20 Jun 2006
Posts
8,411
Location
Capital of The North
http://uk.youtube.com/watch?v=VaHS-y_mapQ

Nice

THIS IS NOT GAMEPLAY FOOTAGE!

a lot of people are opening Crysis, putting in the code and expecting physics to run smoothly like in the video, it won't.

It's for rendering a video with capture_frames, actual gameplay will be extremely low frames per second, capture_frames isn't affected by low fps but the physics having their own framerate do.

The song is "Aberdeen City - Pretty Pet", I've recently checked them out after having an urge to listen to their song "God Is Going To Get Sick Of Me" that's in Saint's Row and I started listening to their other stuff and I really like them, nice to hear a band sticking to one genre (in this case indie) rather than going all out and putting all kinds of crap in their songs to appeal to a wider audience or staying to a single genre by not being original and sounding like any other band in that genre.

Thanks to "poomuckel" from the Crymod forums for inspiring me to make this video/render lots of physical interactions by making the giant robot looking thing made from boxes that he posted on page 4 of his "Physis" map thread (http://www.crymod.com/thread.php?thread id=10448) which is also pretty fun.

I used the very high settings tweak for DX9 and the commands I used ontop of that for this were:

sys_physics_CPU 0
fixed_time_step 0.033333
e_particles 0 (all those particles when a box would collide with something killed my GPU)
r_motionblur 4 (need the very high tweak if on DX9)
r_useEdgeAA 2
r_displayinfo 0 (get rid of the white text when in devmode/sandbox)
cl_hud 0
capture_frames 1 (to take a screenshot at every frame so you can add them all together to make a smooth motioned video).

Yes, there is still some physics lag when sys_physics_CPU is set to 0, but it's SOOOO much smoother than if set at 1 when there's that many physical interactions going on and I think it's an actual physics engine problem where they can lock when colliding, they can't get past what's infront of them rather than it actually lagging like when it's set to 1. If there was nothing in the way of a moving object, it won't lag on 0 but can on 1.

The last clip wasn't anywhere near as massive as I wanted it to be, unfortunately my GPU couldn't handle rendering all the boxes when I doubled the amount of what is shown in the video so I left it as that rather than trying to find an actual limit of what it could handle incase it needs power to render the motion blur and stuff.

I'm tring to get a high quality version on filefront or stage6 but I recorded it in not the highest of quality .jpg format at 640 x 480 as it was only planned to be uploaded here and my PC seems to hate DIVX so I might just make a .wmv for filefront.

I PANT3RA I approves of this video.
 
Last edited:
could you explain what that sys_physics_CPU 0 comand does then? and if physics is more smooth with it off, why is it on in the first place?
 
could you explain what that sys_physics_CPU 0 comand does then? and if physics is more smooth with it off, why is it on in the first place?

The physics isn't "smoother" as in you get a better framerate, but it should be more precise at low framerates.

The quote explains the difference - sys_physics_CPU 1 locks the physics update speed to the GPU framerate, whereas sys_physics_CPU 0 allows them to work separately.

In real game terms, when a game scene is CPU limited and that CPU limitation comes from physics:

a) setting 1: physics timestep is increased, and so collision accuracy is reduced.

b) setting 0: physics timestep stays at it's fixed level. The rate of the passage of time must slow down to compensate for the calculation time. Ie, the game 'runs' slower.


Both settings will have a similar framerate in "real time", but setting 0 will remain smooth in "game time". Hence the reason setting 0 is better for making these movies where they compile them frame-by-frame. When actually playing the game, you don't want time slowing down and speeding up on you, so setting 1 will be better.



As an aside, he says:

and I think it's an actual physics engine problem where they can lock when colliding, they can't get past what's infront of them rather than it actually lagging like when it's set to 1.

This is not actually a bug, but an unavoidable consequence of using the method behind setting 1:

When each physics object calculates its trajectory for the next frame, it does not communicate with other physics objects (to do so would cause an exponential increase in the cost of doing physics as you increase the #objects). So, each physics object has clipping accurate to one frame. When you're talking ~50fps or so the distance an object moves per frame is small, and clipping problems don't occur. When the physics framerate drops right down, objects can move a lot between frames and can reappear right inside each other. This will 'break' the physics engine in one way or another, resulting in either crash or un-physical objects.

Anyway, this is unavoidable (we call it numerical instability in my field), and is the price you pay for trying to maintain a consistent real-world passage of time in an evironment with rapidly changing computational loads. No free lunch - trade off accuracy for speed.
 
Yet another reason why someone needs to come out wit a cheap very powerful PPU for us all. With a decent PPU that should be possible in a game realtime.



“Heh, reason #410249 not to buy an Ageia PhysX card! “
Considering the extremely low frames per second with the CPU I dont see how its a reason not to buy a Ageia PhysX card. Not that I see it as a reason to buy the card either. Just it shows CPU's are rubbish as physics and PPU's are needed.
 
”Now your avoiding the edit button aswell as the quote button, shame on you Pottsey, shame on you.”
I don’t understand what your on about. I edit my posts all the time. When ever I spot a mistake its edited.

What do you mean I am avoiding the edit button?
 
Yet another reason why someone needs to come out wit a cheap very powerful PPU for us all. With a decent PPU that should be possible in a game realtime.



“Heh, reason #410249 not to buy an Ageia PhysX card! “
Considering the extremely low frames per second with the CPU I dont see how its a reason not to buy a Ageia PhysX card. Not that I see it as a reason to buy the card either. Just it shows CPU's are rubbish as physics and PPU's are needed.

Well, a PPU would not be rendering that smooth aswell so I dont think there is any reason to buy a PPU yet.
 
“Well, a PPU would not be rendering that smooth aswell so I dont think there is any reason to buy a PPU yet.I think”
That’s because the PPU isn’t supported. But what if a good PPU came out and was supported. Then it should run smooth.




”he was referring to your posts above his where you typed the same message twice.“
It wasn’t the same message twice. The first part was about PPU’s in general and how it shows we need a powerful cheap PPU. The 2nd part was about the Ageia PPU.
 
Back
Top Bottom