3
\$\begingroup\$

As I commented on a post, I started wondering if it was correct or not (the comment, not the answer). And I'd like to straighten that out.

Although not needed as info, here's the link to the question: Scene management for 3D editor

My comment: "Wouldn't mind that much about the framerate, as long as it stays above 60. you can get away with 30 even."

Still I think if the frame rate is over 30, the real time rendering stays as a good animation. But sometimes I read that people restrict the render() to 60fps or 30fps for performance. This could/would remove all unneccecary calculation wich we can't see anyway. Although true, they (sometimes) claim it is an optimization.

When a scene will render more objects, the fps will drop. Think that is normal.

So what's the deal with fps, should it stay more or less the same even when you turn the camera 90 or 180 degrees, or only when keeping (almost) the same view?

Improve this question
\$\endgroup\$
4
  • \$\begingroup\$ Hey, update() has nothing to do with rendering. Did you mean render() or draw()? \$\endgroup\$
    – jcora
    Aug 5, 2012 at 11:47
  • 1
    \$\begingroup\$ The render(), you're right although the context would be the same. Will update() it so the question renders() correct. \$\endgroup\$
    – user18479
    Aug 5, 2012 at 11:52
  • \$\begingroup\$ Cool. (Also, what do you mean "the context would be the same"?) \$\endgroup\$
    – jcora
    Aug 5, 2012 at 12:59
  • \$\begingroup\$ The update is the part wich does the culling and affects the fps, the update just merely draws the scene. However, those cliams I mentioned are about the restricting the update. But the two functions comes in - imho - a pair where you first collect information (update) and then send (render) the data. \$\endgroup\$
    – user18479
    Aug 5, 2012 at 18:27

1 Answer 1

Reset to default
0
\$\begingroup\$

The comment is both right and wrong at the same time. Framerate is very important to a well polished product. You don't want the player to suddenly pop into a view where their framerate tanks.

Having said that, when a game is being developed, there normally is a specific hardware level that is being designed to - ie, the minimum spec that is expected for the game be run on - and you should be looking for a minimum framerate on that environment. If it is higher on bigger machines, great - but never drop below your expected framerate on that built. That minimum framerate is normally 24 (which is what the human eye can pick up) - but that is also not quite true. While the human eye does work on around 24 "frames" per second, switching from a white to black screen is noticed, so the smoother you can make the transition, the better it will look to the viewer.

When it comes down to framerate and you are seeing a drop in a particular scene, the real question to ask is "Is the drop in framerate here worth what the player is seeing?". So, if you are playing a 1st person shooter and the center of a level drops in framerate by 20 fps, but the center of the level is a gorgeous view to an amazing model that will no doubt make the player oogle over, it might be worth it. If you can limit what they see by occluding certain parts of it, then it might be better. If you can reduce the poly size of the model so that it is still as visually appealing as before, but it doesn't tank fps, then even better.

tl;dr fps is always a tradeoff between how good something looks and how quickly you can render the environment.

Improve this answer
\$\endgroup\$
0

You must log in to answer this question.