Announcement

Collapse
No announcement yet.

Blueprinting/Axis Mapping Rotation Rate: Android/Samsung S8 issue?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

    Blueprinting/Axis Mapping Rotation Rate: Android/Samsung S8 issue?


    Greetings everyone!

    I've run across an odd issue when using Rotation Rate Event node in blueprints(BP) or setting an axis mapping to Rotation Rate, in a deployed android app, on a Samsung S8. I do not remember this occurring on an IPhone 6s with engine version 4.8-10, but it has been about a year since.

    The issue seems to be that the rotation rate regularly returns all 0's every third of a second or so. The 0'ed rotation rate makes a rather noticeable hitching/stutter effect when the phone is rotated.

    The first method I used to capture rotation rate was through axis mapping Turn to Rotation Rate in Project Settings -> Engine -> Input -> Axis Mappings.

    The second method I used to capture rotation rate was through BPs. I made a simple BP addition to the FPS BP template. The BP flow follows like this:

    [Event Rotation Rate:Axis Value] -> [Break Vector(Axis Value):X] -> [Add Controller Yaw Input(X)]

    In both cases, the stutter in rotation rate was present. The stutter only occurred when the app was played on the S8. It did not occur when using a remote control app (Mustafa's Remote Control) to relay motion data in an editor play window.

    I noticed the issue might stem from motion data returning 0's. After making a BP that captured the rotation rate data, split the vector, made checks to see if all three (x,y,and z) floats were equal to 0, and then printing the values out in different colors, an oddity appeared. I noticed that every third of a second or so, and for a period of about a third of a second, rotation rate would be all 0's for all axes. Even when greatly moving the phone, all 0 vectors would occur very frequently when the app was played on my phone. In contrast, when having motion data relayed from my phone to an editor play window, the phone had to be placed on a table to yield only a few all 0 vectors.

    Am I going about this wrong, or is this an engine/phone issue? I have not tried this in C++ yet or an older engine version.

    Any help on the issue would be greatly appreciated, thank you!

    #2
    With some further testing it seems this issue persists even when c++ is used. I’ve gone and started a bug on this (https://answers.unrealengine.com/que...oid-stutt.html).

    Comment


      #3
      Hello Speedie,

      I got your bug submission, replying here for visibility.

      I was unable to reproduce this on a Nexus 5. (Smooth motion, I recreated the BP to check for 0, 0, 0 data and very rarely saw that to evaluate as true)

      Is rotation rate the only Motion input you have active in your test project? (I saw a bit of weirdness when trying to use "Tilt")

      Anyone with an S8 seeing this as well?

      Comment


        #4
        Hey there! Thank you for taking the time to reply here.

        My plan was to have HMD style input, this provides the rapid response I am looking for in an FPS, and it is most similar to mouse movement. I have tried tilt, but it doesn't have the feel I am looking for. Aside from the feel, it also will take a little bit of trig magic to fix the tilt so that it stays with the orientation of the device rather than the absolute orientation to the earth. I think I explained that right... Hah.

        I've tried acceleration, gravity, and tilt also. None of these reproduce the issue. It only occurs with rotationrate. This does seem odd, as I believe rotation rate is derived from gravity and acceleration and some basic trig functions, though I could be wrong.

        Interestingly, back when 4.10 was around, I made an even more developed version of this basic gameplay concept for an IPhone 6s. Initially, it too had a strange hitch/stutter, but it seemed to have resolved itself over time. I believe it was related to shaders being compiled(?). This was over a year ago, so I could be partially wrong. Unfortunately, I did not save the project. (This is why you should use version control kids.)

        Another striking thing I noticed is that when this was done on my IPhone, there was a significant amount of jitter. This required a little bit of elaborate float point math, called every frame for smoothing, but this didn't seem to affect the performance of the game play. I bring this particular point up because I wondered if the 0 vectors come from a computational issue. In contrast to the IPhone's jitter, there is none-whatsoever in the S8. I'm not sure if this is because there is a motion pre-processor, if the engine got "smarter", or if it simply is a more accurate sensor that removes noise.

        I've use the show engine and other various console commands and nothing seemed to get anywhere close to unreasonable. I believe the video I provided also showed frame rate with some added movement to try and distinguish the stutter not being connected to a graphical issue.

        On the code side of things, I did do some digging into the engine source. Though I understand a bit of C++, I never really found how/where it calls the API's to gather the motion data, or the math it probably performs to produce the processed motion data in the engine. I did notice that there seems to be a rather simple for loop that runs through what seems to be an array of motion input structs, which seems to have it's members initialized to the four motion values, gravity, acceleration, rotationrate, and tilt. Perhaps the API can't pull data fast enough to initialize the motion input struct, or maybe it's a threading issue for event queues (if they're used?).

        If this helps, the S8 isn't my primary phone and was purchased solely for unreal development. I don't have too many limitations on what I can do in regards to testing. I may have access to a pixel 2, though I am not sure.

        Thanks for the help so far.
        Last edited by Speedie; 03-17-2018, 02:17 PM.

        Comment


          #5
          As a side though on the coding avenue, could the priority of input events be low enough so that other events over run it for a few cycles before input is processed again? The colored debug messages do seem to form a semi-consistent pattern. Lot's of red in a solid block, two or so smaller blocks, then a singlish small block then it repeats. Perhaps the most consistent of the pattern is that there always seems to be a large block followed by separated smaller ones.

          Comment


            #6
            Hey everyone, wanted to give quick update.

            After starting fresh from source, it seems this issue is still present. I have not had the opportunity to have access to a Pixel 2 yet, unfortunately.

            Alex, have you or anyone on the team had a chance to test this on any other devices?

            Thank you for the help and work so far!

            Comment


              #7
              Wanted to check in and see if anyone has experienced this also. Would be super if anyone could provide some input or assitance.

              I’ve tried many of the previous attempts on another computer and still no luck.

              Thanks for the help.

              Comment

              Working...
              X