Camera orientation jumping from 2.5° to 25°

When I set the X-Value of the camera orientation in my scene to 2.5 (or any other value with something after the decimal point), it works fine at first, the viewer updates correctly. As soon as I select another layer though, the orientation value immediately jumps to 25. Setting it to 5.5 will jump to 55, so it just seems to lose the decimal point and make a whole number out of it. Very weird behaviour, most likely a bug.

This might be an issue with the integrated gpu I'm on right now (not at home), but I'll check that as soon as I get home.

Other specs:
Microsoft Surface (awesome device by the way :3 ), i5 4300U with integrated graphics, 8GB RAM, Windows 8.1.

Comments

  • Robin,

    I don't see this issue at all, unless I'm missing something. Maybe you could upload a project or something but I'm having no luck looking for it here.

    Cheers,
    Ady

  • Hi Ady! I can now confirm that it also happens on my main machine. And it just got weirder... The steps for me to reproduce the issue every time are:

    1. In an empty composite shot, create a new camera, then create a new plane.
    2. Click on the camera, and in the controls panel under the transform group change the x orientation to 2.5, confirm with Enter.
    3. Click on the plane in the timeline.
    4. Click on the camera, and again in the controls panel, type in 2.5 and hit Enter.
    5. Click on the plane - the orientation will jump to 25.

    From this point on, I can't seem to set the orientation to any value with a decimal point without it jumping back upon clicking another layer. Interestingly enough, if I open the layer controls on the timeline, the value still shows as 2.5 there - the viewer suggests that the value from the controls panel is being used for rendering, though. Also, changing the value directly on the timeline doesn't show this behaviour, and correctly updates the controls panel.

    I think this might have something to do with another phenomenon I just started recently noticing, which is the general input of values with a decimal point. In the interface, every decimal number shows with a point as the separator, so it's 2.5 in the interface. Upon clicking on that value, it stays 2.5 and gets highlighted so I can type something else. Now comes the quirk, in Germany, the default decimal point symbol is actually a comma, and not a point, so when writing on paper, I'd naturally write "2,5" instead of "2.5". It seems that the input checking method is localised, because I have to use the comma for decimals, I can not input a point - hitting the period key does nothing.

    At first glance this is only mildly confusing, as it seems to work fine - input with a comma, which will then be displayed as a point once the value is set by pressing enter.

    On second thought, it can cause weird behaviour, because as I mentioned, upon clicking on such a value, the input field gets pre-filled with that value, using the point separator - which I cannot manually enter with the keyboard. If I then just confirm that value without changing it, the decimal point gets lost, as the input field only accepts a comma as the separator, so instead of 2.5, I now have 25. To keep the 2.5, I have to manually change the value to 2,5. I think this automatic switching could be the issue that's causing the original problem, and is also why you're not seeing this, as I guess in England you also use the period character as the decimal point.

    Whoo, long ramble. I hope you got the idea, if I was unclear anywhere or you need more info, please ask!

  • @Robin - I cannot reproduce it unless I use commas, then it does as you state but I don't need to click on any layers. If I use decimal points it behaves fine.

    You say you can't type a decimal place into a property? How long has this been going on?

  • @Ady That's right, I can only input digits and the comma character into the decimal input fields, the period character gets blocked. Pressing it on the keyboard does nothing. This is the case at least since the release of HitFilm 3, I can't say it for sure because I never consciously thought about it. Comma is just the way we Germans input decimal places for the most part, so I never noticed it until now, when it didn't work the way I expected it to. When I'm back home again I can also check if this behaviour was already present in HitFilm 2.

  • edited February 2015

    Also, I know for sure that German systems are set to use the comma character for decimals, as simple command line programs also need commas when entering decimals, points will crash them if they're not handled separately. Change the region setting of the pc, and the exact same program now only takes points and crashes on commas. So, if the HitFilm input fields are from a standard library but displaying values and pre-filling input fields with values use another library or are written by the HitFilm developers themselves, this is probably the issue.

  • @Ady Okay, just checked it - nothing of this appears in HitFilm 2. I can input both 2.5 and 2,5 and both are working fine, neither are causing any strange behavior.

  • @Robin, I've logged this as a bug as this behaviour is wrong. I'm sorry for the inconvenience caused.

    Ady

  • edited February 2015

    @Ady Awesome. This is why I love FXHOME. Thank you very much!

    Just as a side note, out of curiosity, I decided to check this issue in other programs - after effects lets me input both commas and periods, but it only keeps the commas. Periods are simply ignored here as well. So you're not alone with this weird comma/period stuff :P

  • @Robin - Yeah that's something I looked at too. The guys will fix it, hopefully it can make it into an update in the not too distant future. :)

Sign in to comment

Leave a Comment