Transform and Rigidbody View - Occasional strong stuttering, no lag

Hi,

I've achieved so far quite good result in my physics-based game using Transform and Rigidbody Views combined.

However, we sometimes experience strong stuttering of physic objects even though no lag is displayed.

Example: This is how well the game runs 80% of the time. The physics are calculated on the throwing player's side. Hope you see what I mean
https://giphy.com/gifs/l378BfzorxhwWwTAc

However, sometimes this happens
https://giphy.com/gifs/l378Ajp1r1MskvXMI

It's like a massive lag. I've recorded this playsession from both players sides and on no side I can see an increase in lag.

Can someone give me an idea what else might be causing this and how I can proceed to assess this further?

Thank you!

Comments

  • Spaggi
    Spaggi
    edited October 2017
    Is there no edit function here? I meant increase in Ping, from the Photon Stats Window, not in lag. Sorry, I'm a bit tired
  • Hi @Spaggi,

    the edit function is in the upper right corner of your post, clicking on the gear-wheel.

    Back to your original question: it looks like some messages get lost. Since you already use the Stats Window did you notice something like losing messages happens? The values from the Stats Windows are very hard to read for me and I'm not sure if I noticed some 'jumps' in those correctly, for example in the Traffic Stats' Incoming section. Have you tested this at different times of the day to confirm that it is not a temporary issue?
  • Hi,

    thanks a lot.

    Here are close ups of the Photon Stats Windows at the before, at the time and after the lag occurs:

    Owner, Sending player:
    https://giphy.com/gifs/l378rQUEKaJuD2W0U

    Receiving player where lag occurs:
    https://giphy.com/gifs/26vIebuSujJULCelO

    I'm not noticing any spikes but maybe I'm missing something?
  • No, both stats windows looking good to me, no noticeable spikes.

    How do you synchronize the thrown object? Do you use PUN components or do you use a custom solution? If you have a custom solution, which values of which component (Transform, Rigidbody, ...) do you synchronize?

    Another thing: I assume the object itself gets instantiated via PhotonNetwork.Instantiate: is it instantiated directly before it is thrown or is there 'some' time in between? Hard to see on the gifs.
  • Sorry I wouldn't know how to present my issues in a better way.

    Let me describe the Basic Setup:

    In my game, there are 2 characters. Each character is controlled by 3 Transforms head, left Hand, right Hand (it's a VR game). The characters are throwing objects around. These objects are instantiated by Photon.Instantiate but that happens several seconds before they are being thrown and the issues occured.

    The character Transforms are synchronized using PhotonTransformView.
    Objects that can be thrown are synchronized using PhotonTransformView and PhotonRigidbodyView. The objects have a Rigidbody assigned, the rigidbody is set to kinematic on the recieving player's end (the Player that is not throwing)

    What I noticed: once These "Lags" occur, not only the object is stuttering but also the Player (meaning the transform positions controlling the Player are also not transmitted properly and stuttering).

    This leads me to believe that the issues are not due to the Basic Setup, but indeed due to Transmission issues.

    I think a graph displaying the photon stats over time could be helpful. Do you know if it's possible to Display something like that?
  • Thanks for the description. Sounds good so far and it's already proven that it works, so you might be right, that there is something wrong with the transmission. The PUN package comes with a utility script called SupportLogger. Please add this component to a game object of your choice in the scene. When the game runs, take a look at the logging and see if there are values which get strange when 'lags' occur. If you can't see anything wrong, you can try to increase the amount of log message by lowering the 'repeatRate' of the InvokeRepeating call on line 31 of the SupportLogger script. If the logging doesn't change at all (no suspicious behaviour) we need to check other possibilities again. Of course you can also post the logs here.

    Besides that I didn't ask which Unity and which PUN version do you currently use? PUN got updated yesterday to version 1.87, so maybe giving that a chance might also help.
  • Thanks a lot, I'll try that out in the nex Test iteration! I'll also update PUN.

    I'm running on Unity 2017.1.1f1 but the issue occured on 5.6 as well.
  • Hi,

    when assigning this component, I get messages like this:

    SupportLogger Rtt(variance): 28(5). Ms since last receive: 32. Stats elapsed: 0sec.
    Longest delta between Send: 859ms Dispatch: 2906ms. Longest callback OnEv: 255=31ms OnResp: 0=0ms. Calls of Send: 666 Dispatch: 2130.

    Would you mind explaining what these numbers mean and what I have to look out for?

    Thank you!
  • The RTT (round-trip time) is the time it takes from sending the message until you receive an acknowledgment for that message. Maybe you are more familiar with the 'ping time' term. The variance is - obviously - the variance you have on the RTT. If the variance gets higher or becomes unstable, this might be an indicator that something is wrong. This happens for example if the connection gets bad because of too much traffic or other influences. In this case 28(5) looks really good, if it stays near by those values.

    Longest delta between Send and Dispatch describes the longest time between subsequent calls to SendOutgoingCommands and DispatchIncomgingCommands. Here we might have a problem if the values stay close to 1 and 3 seconds often - both are very high. Both might be indicators for the occurring lags.

    These are the important values in my opinion and we can skip the other. So please take a look at the described values and see what happens to them when the game runs fine and when lags occur. To make sure they display correct results, please reset them after the scene loading is complete. You can do this simply adding a new script to the 'game' scene with PhotonNetwork.NetworkStatisticsReset(); in its Awake or Start function.

    Besides that did you make any changes to PhotonNetwork.sendRate or PhotonNetwork.sendRateOnSerialize? Do you send any messages besides the synchronization of the two characters and the throwing objects which might influence network performance? And another question to the synchronized objects: did you make changes to the PhotonView's observe option? If you changed this to Reliable, this might also cause the issues. If so, please try setting it back to Unreliable and see if this works.
  • Thank you, this is really helpful! I'll get back once I have the results! Great Support!
  • Hi Christian,

    unfortunately, I wasn't able to pin the lags down more. Actually, the opposite ist the case, I am even more confused.

    This is a video of one of our tests.
    The POV player experiences very strong and reccuring lags

    The other player (me) however does have much much less lags. It occurs to me that lags are mostly occuring for the non-master player.

    https://www.youtube.com/watch?v=hWT8q39nVKw&feature=youtu.be
    Very good example is at 22:13. You can see before that there are much less lags (e.g. at 21:42) . You can see that the lag is happening to the player model and to the object he has thrown

    A basic description how the game works with PUN:
    - 2 players, which are throwing physical objects in turns.
    - The player whose turn it is becomes owner of ALL objects
    - So lag can be only apparent if the other player is throwing
    - The objects are Kinematic for the "watching" player
    - For the player: The player model is done with IK that is linked to 3 transforms. These transforms are synchronized via PhotonTransformView
    - For the objects that are thrown: PhotonTransformView is enabled once the player "Releases" the object. Before, the object is being syncronized using joints

    Log Master Player
    https://drive.google.com/open?id=0B9T6admd4AgIVVdhbjIxQmpaTHc

    Lol non-Master Player (POV)
    https://drive.google.com/open?id=0B9T6admd4AgIYktpTGpHTG85V1U

    As suggested, I added the Supportlogger script but lowered the interval to 3 seconds.

    I browsed these logfiles, and I cannot find any indication of lag. If you look at the end, the following entries are written:

    non-Master
    SupportLogger Rtt(variance): 65(12). Ms since last receive: 62. Stats elapsed: 929sec.
    Longest delta between Send: 157ms Dispatch: 141ms. Longest callback OnEv: 200=31ms OnResp: 0=0ms. Calls of Send: 17343 Dispatch: 116699.

    Master
    SupportLogger Rtt(variance): 33(5). Ms since last receive: 62. Stats elapsed: 901sec.
    Longest delta between Send: 219ms Dispatch: 219ms. Longest callback OnEv: 200=16ms OnResp: 0=0ms. Calls of Send: 16982 Dispatch: 127944.

    if I browse trough the rtt entries, I can see they are quite good with little variance.

    This leaves me completely buffeled. Do you have any suggestion what I could do to analyize this further?
  • I just wrote a long comment and edited it - it seems to be now waiting for approval (after the edit)?
  • Update from my side - it seems that I was having some bandwith issues as a download was going on around the time of test.

    However: I believe this should have affected my stats, right? But from what I see, those look pretty fine....
  • Hi, sorry for the late response, I have been on 'vacation' for a few days.

    Thanks for the video. I honestly need to admit that I didn't watch it entirely. Are the occurring lags at 22:13 the only few during the entire video? In this case I would say that this is 'okay' because you will always have some package loss - of course it doesn't look nice when they occur. If we can finally say, that package loss is the reason (not something else) we can try to find a solution, that the visual representation isn't that much affected as it is now.

    What I have noticed while looking through the logs: There is a 'Longest callback OnEv' entry stating the event code 200. Event Code 200 is a RPC, so the entire entry tells us that the longest OnEvent callback was a RPC. One example from the logs is 234ms, which is definitely too much. Since I don't know if there is still some loading time included in this value, I'm asking you to redo the test with a SupportLogger, that resets every time a log is printed to the console. This way we will see, if there might be a problem with one the RPC calls. To reset the traffic stats you can simply add PhotonNetwork.NetworkStatisticsReset(); after the SupportLogger prints to the console - should be something nearby line 50 in that script. When having new logs, feel free to share them here. I'm also interested in how the 'Longest delta between Send and Dispatch' are affected.

    A question: what options do you use for the PhotonView and PhotonTransformView components of the character and the throwing objects? For the PhotonView components please try setting its Observe Option to 'Unreliable on change' if you haven't done this already. For the PhotonTransformView components please check if the 'teleport' option is enabled. If so, try to disable it and see, what it looks like afterwards - check if it's better or even worse.