Renzatic on 11/12/2016 at 06:13
It's funny. The more I delve into Unity and C#, the more their damn keyword guide starts to make sense. I've spent the last three days buckling down on it, studying the syntax, structure, and all that good stuff, and now I'm getting to the point where the help page is actually starting to be helpful.
I feel like I've reached a milestone.
Fafhrd on 11/12/2016 at 08:41
Starting to set some groundwork for my upcoming (
http://whiskyneatgames.tumblr.com/post/154152679226/holiday-break-project-announcement) One Man VR Game Jam, I've started messing around with making OpenVR work in a C++ application pretty much from scratch. It took me a couple hours, but I finally have an application that initializes OpenVR. Yay. End goal on this is to have a simple command line application that'll spit out the positions of the Vive headset and controllers 30 times a second, then I can dump that output direct to CSV and then write a Blender script to turn that CSV into animated empties, which I can then use to create some canned animations for a baddie for Lightsaber Fighting Thing (also maybe use it for recording gestures for Air Traffic Controller Guy? I need to do some research into how gesture systems work).
henke on 11/12/2016 at 14:24
qolelis, thanks for the feedback. :)
Yakoob, I played through your game, couldn't get the survey to open tho. Also I missed the hint about zooming at first and had to restart the game to see the instruction on how to do it. Overall, the game felt pretty good. Only problem is that the pacing was slightly odd. Felt like everything was building up towards the festival, and when the game continued going beyond that I was like "oh man I thought this was about to end. New Year? How long is it going to go on for?" Almost quit the game right there, but decided to give it one more day to see if it really was going to go on for a long time, and then it ended. Maybe try to wrap up the story on the evening of the festival.
Renzatic on 11/12/2016 at 19:26
Hey, I'm trying to annotate all the code I've written so I can use them as reference later. One thing I'm having trouble doing is explaining to myself exactly what time.deltaTime does.
Like explaining what:
transform.Rotate (new Vector3 (0, 0, 100) * Time.deltaTime);
is a bit difficult when I'm not sure what deltaTime does.
I read it as "rotate this transform on Vector3 Y axis (ignoring X and Z) at 100 * normalized something or other".
I do know that deltaTime acts as a normalizer, allowing for a consistant clip of movement regardless of framerate, making it more fixed in time, rather than frames. But I want to know exactly what it's doing, not just what the end result magically produces. Also, I'm still not 100% sure what 100 is a unit of, only that a higher number produces a faster spin.
Fafhrd on 11/12/2016 at 20:10
deltaTime is the difference in time between this call and the last time it was called. That's why you call it from fixedUpdate instead of Update, as fixedUpdate gets called on a timer instead of on framestart.
Renzatic on 11/12/2016 at 20:26
Weird. The first tutorial on Unity's website had me slap it into a regular update method.
Though I'm think I'm getting it. If FixedUpdate refreshes every, say, 15ms, then Time.deltaTime will multiply anything running within FixedUpdate by whatever value you feed into it. So my code above would read like "rotate this transform on Vector3 Y axis at 100 * 15ms", giving you consistent results, regardless of the framerate, right?
...though what would it do if it were under a regular Update method? Since not all frames are always rendered at the same speed, Time.deltaTime would be rendering at, say, 100 * 10ms, then 100 * 25ms then 100 * 120ms then 100 * 25, depending on how long it takes to render the frame, right? Which means that it'd be entirely useless for what it's intended for, correct?
Nameless Voice on 11/12/2016 at 21:13
I don't know about Unity, but basically:
Suppose you want your object to rotate at a speed of 30 degrees per second.
Each frame, you update the rotation.
Since frames happen more often than once per second, you want to multiply by the time since the last update, which should be a fraction of a second.
So, if your frame rate is a constant 50fps, then the deltaTime should be 0.02, e.g. 1/50th of the amount to rotate in a second.
Since deltaTime is the exact time since the last frame, it will also adjust correctly as the framerate rises or falls, always maintaining a consistent speed regardless of your framerate.
Pyrian on 11/12/2016 at 21:21
Time.deltaTime in Update is simply the amount of time that passed between frames. It's much more used in Update than in FixedUpdate, since its basically a constant in the latter (still useful sometimes, especially if you're messing around with the "fixed" value). Generally speaking you don't put animation - including most forms of movement - in FixedUpdate, because then it won't move in some frames, making it look jerky. You also don't put Input checks in FixedUpdate because you'll miss some, seemingly at random. ...Honestly I don't use FixedUpdate at all.
So, let's say you want to smoothly increment a value by one every second. If you just add "value += 0.01" every Update, then its speed will depend on the frame rate; long frames will cause it to move more slowly and short frames will cause it to move more quickly. Instead, you can add "value += Time.deltaTime". Now frames that come in late or early won't break the smooth continuous movement, since their different time periods are accounted for by the Time.deltaTime component. It allows you to keep a constant speed over time. Put another way, if you add up Time.deltaTime each frame, it always adds up to a total of 1 each second. If you want to speed things up, you just multiply: "value += Time.deltaTime * speed".
Having the move go further in long updates and shorter in quick updates is exactly what you want it do be doing to look smooth.
Renzatic on 11/12/2016 at 22:00
Alright! Thanks. I feel like I'm about 85% there, but there are still a couple of things I'm not quite clear on.
I think the one hanging point for me is what exactly constitutes the last frame.The way I'm currently envisioning it, it assumes the time of the last frame in a cycle (say, a second), but unless that last frame is always consistent itself, it could still issue changing results over a period of time, just not nearly so often. How does that last frame work as a basis for normalization?
