Search Unity

Physics: Webplayer vs Standalone question.

Discussion in 'Editor & General Support' started by kinl, Aug 4, 2008.

  1. kinl

    kinl

    Joined:
    Jun 1, 2008
    Posts:
    355
    I have created a simple demo of car driving around a default setup of a terrain.

    http://www.kinelco.com/unity/ExtremeTaxi.html (p.s. Its a very very early demo, lots of things to fix)

    Within the Unity editor and as a OSx Standalone (even set to fantastic and at 1200 x 1900 fullscreen) I get 100 - 150 FPS and very smooth physics, when I export to the webplayer (which is playing in the standard 600 x 450 window) I get a framerate of around 50 with some noticable stepping in what I think is the physics (at least the FPS counter does not show a drop where visually it can get very stepped, this is more pronounced when falling or jumping large distances - This is on my IMac, Nvidia GeForce 8800 GS 512 and 3ghz processor.

    Running the webplayer on my PC with an Nvidia GeForce 8800 GTS 512 and 3 ghz processor I get a framerate of 40 - 45 with very noticeable stepping, this is exactly the same result as my 256 ATI graphics card on my 2 ghz machine, usually there is a noticeable difference in performance between these machines with other engines.

    I can not test my PC's with a standalone as we haven't gone Pro yet.

    I have also noticed this in other Unity games, raptor safari also does the same thing when the jeep is falling or jumping a long distance.

    Is this something that could be fixed by optimisation or is it an issue with the webplayer?

    Thanks

    Kinl
     
    kinl, Aug 4, 2008
    #1

  2. drJones

    drJones

    Joined:
    Oct 19, 2005
    Posts:
    1,351
    in windowed mode for the webplayer the framerate is capped at 50.

    the stepping you see is the lerp in the camera script is trying to keep up i think (try parenting the camera to the car and it goes away - but that kills the nice follow effect IMO) - and for me it happens at anything below around 60 fps (!) - much more drastic when the editor is running too. (and yes before anyone asks rigidbody interpolate is on ; )

    funny but i was just going to post about this as well - i've known about it for a while now and even posted a bug in the past - now i'm at the point where i'm revisiting the issue to no avail.

    there must be some way to fix this, does anyone have any ideas? - i've tried everything i could think of...
     
    drJones, Aug 4, 2008
    #2

  3. kinl

    kinl

    Joined:
    Jun 1, 2008
    Posts:
    355
    Interesting that the webplayer is capped at 50, I would have thought my PC setup would be able to keep up with that, afterall it played Crysis relativity well :)

    For interests sake I've tried the parenting the camera to the car.

    http://www.kinelco.com/unity/ExtremeTaxi2.html

    Personally I think it still does the same thing its just harder to notice with the car not moving in relation to the camera.

    I do hope this is no major issue as its the webplayer that brought us to Unity, maybe the webplayer is up for an update???
     
    kinl, Aug 4, 2008
    #3

  4. drJones

    drJones

    Joined:
    Oct 19, 2005
    Posts:
    1,351
    i really don't think its the webplayer specifically - i can get it to happen in standalone and on my mac the effect is worse in the editor - its just more noticeable because of the capped framerate i think. actually i can't see it in either of your players on my mac but i know exactly what you're referring to.

    i really think its solely an issue of the follow script. seems to me if it uses lerp or anything similar - you will get stuttering at high speed elevation change. none of my attempts (like fooling with execution order) have worked but that's not surprising as i'm not much of a programmer.

    hopefully someone will chime in here soon ; )
     
    drJones, Aug 4, 2008
    #4

  5. jashan

    jashan

    Joined:
    Mar 9, 2007
    Posts:
    3,307
    Nice - I was just about filing a bug report on this ;-)

    The behavior itself I find not so nice, though, since I'm doing some "optimizations" based on FPS, i.e. when the framerate goes really high, I add details and "nice stuff", when it goes really low, I remove details and sugar...

    I don't consider 50FPS "really high" ... but ... I guess I'll change that now - at least for Web players ;-) there's probably a good reason to have it capped at 50 FPS, AFAIK, this wasn't the case with 2.0.2...

    Sunny regards,
    Jashan
     
    jashan, Aug 4, 2008
    #5

  6. drJones

    drJones

    Joined:
    Oct 19, 2005
    Posts:
    1,351
    its always been capped i think - though i always wondered why not at 60 fps, seems like a better number ; )
     
    drJones, Aug 4, 2008
    #6

  7. kinl

    kinl

    Joined:
    Jun 1, 2008
    Posts:
    355
    Is there a way to cap the framerate yourself in Unity so this could be tested on a standalone?

    Its alittle worrying that a PC which plays most things very smoothly not being able to keep up with a pretty simple setup.

    I'd expect some of the more advanced features to have issues but I'd really need this to work well, afterall I'd say most browser based game users computing power is less than this setup.
     
    kinl, Aug 4, 2008
    #7

  8. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    32,401
    It should probably be noted that it's not Unity doing the capping, it's the web browser itself that won't let content run any faster than 50fps. The behavior in 2.0.2 was no different since it's nothing to do with Unity. :) If you want to cap fps in a standalone, you can turn vsync on, which with most LCD screens will limit you to 60fps. Or you can use this script.

    --Eric
     
    Eric5h5, Aug 4, 2008
    #8

  9. kinl

    kinl

    Joined:
    Jun 1, 2008
    Posts:
    355
    http://bubblemark.com/silverlight2.html

    This silverlight demo (running on firefox) gives me 500+ fps.

    However 50fps is ample for webgames, I'd just like to see better performance out of the Physics, fingers crossed its something I can fix at this end.
     
    kinl, Aug 5, 2008
    #9

  10. David-Helgason

    David-Helgason

    Moderator

    Joined:
    Mar 29, 2005
    Posts:
    1,104
    500 FPS?

    On my MacBook Pro with Leopard, Silverlight crashes my Firefox 3 consistently (after displaying only 1/3 of the viewport, not including the FPS counter). On Safari I get 25-35 FPS (and a bit higher with the other methods, like Java and DHTML.

    I could imagine that Silverlight is better supported (and optimized) on Windows, but still.

    d.
     
    David-Helgason, Aug 5, 2008
    #10

  11. kinl

    kinl

    Joined:
    Jun 1, 2008
    Posts:
    355
    I've just tried the silverlight demo on my Imac and get around 160fps.. I'm still on Firefox 2 and I had no crash.

    On my slower PC with the ATI card and FF3 I get 250ish fps... I did get a crash on install but worked fine after the restart.

    kinl
     
    kinl, Aug 5, 2008
    #11

  12. drJones

    drJones

    Joined:
    Oct 19, 2005
    Posts:
    1,351
    does anyone from UT have any comment on the stutter issue?

    i posted a bug a while ago (16527) but admittedly at the time i didn't describe it all that well ; )
     
    drJones, Aug 5, 2008
    #12

  13. Thomas-Pasieka

    Thomas-Pasieka

    Joined:
    Sep 19, 2005
    Posts:
    2,174
    I'd like to hear something on that matter as well as I ran into a similar issue lately.

    Thomas
     
    Thomas-Pasieka, Aug 5, 2008
    #13

  14. dock

    dock

    Joined:
    Jan 2, 2008
    Posts:
    605
    I seem to be getting 42fps capped on both of the fast machines I've tried the 3d platform demo on. It's a bit weird, and yeah - I'm surprised it isn't capped at 60fps.
     
    dock, Aug 5, 2008
    #14

  15. kinl

    kinl

    Joined:
    Jun 1, 2008
    Posts:
    355
    Bump

    It'd be great if we can get an official explanation from one of the Unity team?
     
    kinl, Aug 7, 2008
    #15

  16. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    5,203
    We cap the framerate in the web player to 50 fps.
    Beyond 50 fps, higher framerate is not very important and in the browser it's not a good to gobble up the machine completely just because there is one window with Unity content running.

    The main point is that if your framerate is below 50 fps it's not slower or faster than in standalone. It just never goes above 50 fps. So unless you are doing a benchmark this is not a real world problem imho.


    In regards to physics stepping. Physics is run at a fixed frame rate. For that reason whenever you have a camera tracking a rigidbody you should make sure the rigidbody is using interpolation, that makes any stepping artifacts go away. (It's a drop down in the inspector of the rigidbody component)
     
    Joachim_Ante, Aug 7, 2008
    #16

  17. kinl

    kinl

    Joined:
    Jun 1, 2008
    Posts:
    355
    50fps is not a problem at all, it has only been suggested that under 50fps the physics stepping issue arises and not down to the webplayer as I first implied.

    This stepping is not down to interpolate being turned off on the followed rigid body, or at least it is turned on in this demo.

    http://www.kinelco.com/unity/ExtremeTaxi.html

    In this example to see the issue you need to travel at high speed towards something that will throw you in the air once launched you see stepping before and after you reach the apex i.e. the stepping is worse the faster you are travelling in the Y, you can also see it if you fall a great distance (off one of the big cliffs for example), again seems to be worse the faster in the Y you are travelling.

    I'm not sure if this is a "real world" problem or not as I've never fallen through the floor or had any weird physics effects after it, but it does happen and it is a bit ugly, whether it would affect anything like hit detection I dont know yet, but I hope it doesn't!

    If it doesn't affect gameplay I could probably live with it, but it isn't ideal.

    I personally think the webplayer aspect of Unity is a big draw and would love it to be the best option for 3d content on the web.

    Kinl
     
    kinl, Aug 7, 2008
    #17

  18. drJones

    drJones

    Joined:
    Oct 19, 2005
    Posts:
    1,351
    thanks for the reply Joachim but as kinl notes above this does not fix the issue. attached is a video showing it just in case you are not seeing it on your end (the video is a bit jerky itself but this will still clearly illustrate the effect as the car is falling). this is basically the same example project i sent in my bug report (case# 16527) just with a bunch of trees in there to bring the framerate down some.

    hope this helps : )
     

    Attached Files:

    drJones, Aug 7, 2008
    #18

  19. drJones

    drJones

    Joined:
    Oct 19, 2005
    Posts:
    1,351
    sorry for the impatience but...

    badda-bump! ; )
     
    drJones, Aug 9, 2008
    #19

  20. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    5,203
    First of all, the whole point of Fixed Timestep physics is so to make it independent of framerate. Thus it will not affect game play, when you hit a low framerate for whatever reason.


    Secondly the camera jitter is in no way related to physics. It's related to the camera model you chose in your scripts, not being fit for tracking a flying car.

    In DrJones project folder, you have used the Smooth Follow Camera which is not a good camera model to use in this case.

    1) It does damping on the height. This means that as the car flys with big altitude changes, the distance between camera and car will change back and forth each frame. Because it uses lerp instead SmoothDamp for damping, the jitter is made even wrose.

    In the case of a camera following a car it would probably be better to lock the camera to be at a fixed height relative to the car. This way the position of the car on screen will never change.

    I think by fixing 1) You can get rid of most jitter.




    2) When the car starts tumbling in air, the target yAngle changes all the time and worse if the car does a 180 flip the y-Angle will also make a discrete flip. This is a problem called gimbal lock and one of the reasons why we use quaternions in Unity and not euler Angles. The camera code uses euler angles though. So it suffers this problem.

    The real problem with the camera is that it tries to place itself behind the car's forward vector when in air. This is usually what you want when you are driving, because you want to look in the same direction the car is facing. For example if you are sliding on a track you would still want to look forward relative to the car and not in the direction you are sliding around a corner.


    I think when your car goes in air, you should probably switch camera model and base the camera offset on the rigidbody velocity instead of the transform.eulerAngles. When in air the rigidbody velocity is going to be pretty stable, while the car might be turning around violently.


    So it's not related to physics. It's related to the camera model you used not being well suited for cars that fly. Below I pasted a script that fixes the jitter on the camera if you replace the camera code.
    It doesn't implement any switching of camera model based on in air. So it still does some silly looking rotations when the car starts tumbling around.


    -----

    // A simple smooth follow camera,
    // that follows the targets forward direction
    var target : Transform;
    var smooth = 0.3;
    var distance = 5.0;
    var heightDifference = 2.0;
    private var yVelocity = 0.0;

    function Update () {
    // Damp angle from current y-angle towards target y-angle
    var yAngle = Mathf.SmoothDampAngle(transform.eulerAngles.y, target.eulerAngles.y, yVelocity, smooth);
    // Position at the target
    var position = target.position;

    // Then offset by distance behind the new angle
    position += Quaternion.Euler(0, yAngle, 0) * Vector3 (0, heightDifference, -distance);
    // Apply the position
    transform.position = position;

    // Look at the target
    transform.LookAt(target);
    }
     
    Joachim_Ante, Aug 9, 2008
    #20

  21. kinl

    kinl

    Joined:
    Jun 1, 2008
    Posts:
    355
    Thank you very much for that, I'm so glad its something that can be fixed.

    The camera on our Taxi demo (Smooth Follow Camera) did need tweeking anyway and with your suggestions we should be able to get to a good solution faster than on our own.

    My problem is that I'm an Artist and not a programmer and I only have a theoretical grasp of game programming. My programming partner has finished on our last game and is about to come on board, so hopefully you'll get more informed questions from us from now on and I can stick to my colouring in ;)

    Thanks Again

    Kinl
     
    kinl, Aug 9, 2008
    #21

  22. drJones

    drJones

    Joined:
    Oct 19, 2005
    Posts:
    1,351
    thank you Joachim ; )
     
    drJones, Aug 9, 2008
    #22