Lite-C Workshop confusion O.o

Hi all,

I've recently returned to 3DGS and am going through the workshops for Lite-C.

I've gotten through the first 9 workshops well enough. I'll probably go back and re-read them a couple times just to help them "sink in", while using the information... Important thing is I understand them, and they "click".

However, I'm completely lost on Workshop 10, where it gets into using time_step. I've read that section over at least 8 times now... and it's just not clicking. It's probably because I'm less-than-good at math, but I can usually at least understand the concept fairly quickly, even if the functionality takes a little longer to grasp.

I'm fine with the concept here - making certain things, like a plane rotating - rotate at the same overall rate, independent of frame rate.

Where I get lost is the math involved. Even with the excellent job the author does of explaining things elsewhere, I'm still lost on this time_step thing. Sadly, this has always been a weak point for me... explain concepts to me and I'm fine. Start throwing numbers and equations as part of that explanation... and I'm lost. My brain, it seems, is quite stubbornly locked up in the right hemisphere.

I really want to grasp this, but I'm wondering if there's another, even more plain english way this can be explained?

Thanks a bunch in advance

-MIke

Time_step is used for maintaining the games speed at all frame rates what it is saying is that if you have a frame rate of 30 and a frame rate of 230 you can include time_step in your movement portions of the code and it will move at the same speed. It does this by measuring the time of the last frame and adjusts its self accordingly. Say you have a fps of 15 and ur using time_step.then your fps goes up too 100, time_step will decrease its value so the movement maintains the same speed. That's basically it without using all the math they show u in the tutorial.

Thanks for that

I think that's the part I *do* get, though. Like, I understand in concept what's going on... there's some math happening that does basically what you described. Making adjustments so that, as in the example, the plane completes a rotation in 11 seconds, whether it's 5fps or 200fps.

I understand where it's going.. I just don't get how it's getting there.

To be more specific of what's confusing me, here's the bit I'm trying to wrap my head around that's eluding me:



Even when he's explaining the math... I'm completely lost.

I don't know if there's an easier way to explain all that that would make more sense (to me). Maybe I'm just not cut out for this programming stuff... But I'm assuming there's gotta be some angle I can look at it from where it's just going to "click". I just need to find it.

Ill try one more time but im not sure really how to explain it different than that.

What it is saying in a summery i that u get the value of time_step by doing 16 divided by your fps. If you have an fps of 20, time_step = .8, if fps is 10 time_step = 1.6. So to put this in an example ill just use time_step for the value instead of doing 2*time_step like they did,
my.pan += time_step; Its adding the value of time_step to our pan.

Lets assume that we are running at a steady rate of 50fps. 16 divided by 50 is .32. So in the first frame of that second our pan is set to .32, the next frame it adds .32 more to our pan, know its .64. It is going to do that 50 times per second. So we can know figure out how many degrees our my entity is going to turn each second, by doing that 50 times luckily i got a calculator and its 16.

here is another example that doesn't just use time_step,
assume we are running at 50 fps again we will set our pan to
my.pan += 2*time_step;
In the last example we just used time_step for our value but know we must times that by 2, so instead of pan being equal too .32 on the first frame of the second we must multiply that by 2 so it is .64. Know the pan equals .64. Do the equation again, on the second frame of that second (our pan)is equal to .64 += 2*.32, to shorten the equation we can just do .64 += .64, know the pan is 1.28. Keep going with that and you will get 32 after 50 frames. Know since i used the same example with a different frame rate go to the tut and look at his example, he used a fps of 200 and i used a fps of 50 both were my.pan += 2 * time_step; and we both got 32 degrees a second. Then he just shows you that you can divide 360 a full rotation by 32 to see how long it will take you to turn all the way around.

Sorry if you still don't get it did my best.lol

Thank you for your persistence. It is appreciated. For a bit there, I thought I was starting to get it... then you got into explaining all the math, and it lost me again xD

I think it's because there seems to be 4 things at play.. the FPS, the time_step, the degrees per step and the "per tick" thing.

See, when I'm doing something in a 3D app, and I want an object to complete a rotation in 3 seconds at, say 30fps, I would do the following:

1. Calculate the FPS * the number of seconds (3), which would give me 90 frames.
2. Divide 360 by 90 to get the amount of degrees the object must rotate each frame, in this case it's 4 degrees per frame.
3. Then, to make sure the cube rotates smoothly and doesn't "pause" at frame 1 because the first and last frames of the animation are overlapping, I want to end the animation 1 frame increment earlier than the full 360 degrees.
4. So I would subtract 4 from 360 degrees and get 356 degrees; and I'd subtract one frame from 90 and get 89.

So in 89 frames, the object must rotate 356 degrees in 4 degree increments.

Ideally, if all is done right (that's off the top of my head), when looped it will simulate a smoothly rotating object.

That's how I would look at it and it makes sense because there's only 2 things I'm really concerned about.. the total number of frames and how many seconds I want it to complete the rotation in. From there, the math is easy.

But this whole time_step, FPS, per-tick and rotation thing is really messing me up lol. I realize you can't "hard code" a FPS on every computer (thus the entire point of the workshop), but that's clearly the bit that's throwing me off.

I do appreciate the effort to explain it.

I think it's just going to have to "click".

Actually...

I think I can identify one thing that may be contributing to my confusion...

This bit:



If I'm reading it right, he's saying 1 divided by 16 seconds = 62.5 milliseconds...

.. but then goes on to say time_step = 16 divided by the FPS...

... Huh?

That doesn't even make sense to me. Where is the 16 coming from and what does it represent? It's sorta introduced out of the blue and then used as "the standard" for the rest of it without explanation of what it is or why it's being used. It seems rather arbitrary.

Maybe that's what's throwing me off?

Probably this is confusing you:

1 tick = 1 / 16 seconds = 62.5 milliseconds.

It means that one second has 16 ticks. So 1 Tick is one sixteenth of a second, which is (1/16) second = 0.0625 seconds = 62.5 milliseconds.

I guess the strange "tick" unit stems from old times where games used to run with about 16 fps.

Ahh okay, so that part makes sense... I thought it was an equation (1 divided by 16).

Although, after taking that and trying to apply it to the rest of the author's explanation, I'm still completely lost. I just cannot make sense of what's going on.

One thing I don't get is what is the relationship between FPS and the time_step value? What influence does one have on the other?

The whole thing just seems so arbitrary and obtuse to me right now because so long as I don't understand what
time_step is doing, I can't understand how it's doing it or why.

Maybe I should just chalk it up to not being wired for programming and stick to the creative stuff?

By another token, should that workshop just make perfect sense to someone who hasn't programmed before? Or is some knowledge of programming assumed when reading it?

Quoting Preypacer.


time_step has no or little influence on FPS directly, but FPS 'influences' time_step.

time_step ('duration') is lower with a greater FPS (rate)
---faster machine?
---frame finished faster = lower time (time_step)
---code is executed more often
---my.distance += 5 * time_step; // (<- less time has passed; move less, more often)

time_step ('duration') is greater with a lower FPS (rate)
---slower machine?
---frame took longer to finish = greater time (time_step)
---code is executed less often
---my.distance += 5 * time_step; // (<- more time has passed; move further, less often)

No need to make it exceedingly complicated.
Maybe, for now, just remember to multiply by time_step for entity translation (movement / rotation).

If something won't 'click' (information & comprehension):
---If possible, continue, and maybe after more time, or more data, it will click later.
---Does it have to 'click', or 'click' that way?


Understanding varies with the individual, but certainly, an individual with prior greater interests in math and programming might digest such material faster than an individual with alternate prior greater interests in art.
Of course, guarantees might not be offered for prior interests and understanding, and no doubt, comprehension of all information at the deepest level is probably unnecessary.

Okay, thank you all for your replies.. I do appreciate it.

I *think* I'm starting to get it, and I think the confusion was in how I was perceiving - or what I thought I was perceiving - of time_step's function.

It kinda boils down to time_step controlling how far an object will move/rotate per frame based on the FPS, compared against the duration of one full "time_step cycle" (for lack of a better term).

Basically 1 second = 16 time_step ticks = CurrentFPS

It then divides 16 (one time_step "cycle" in ticks) by the CurrentFPS. The result is how much (what percentage) of a full time_step cycle was required to complete a single cycle/frame. It then takes that result and multiplies it by the amount the given object needs to move/rotate per cycle (or, per FPS), thus adjusting the actual distance the object moves or rotates per frame.

So if you are getting 60FPS, and you want that plane to rotate 2 degrees per cycle, it would, on its own rotate 120 degrees per second. Whereas, if you're getting 20FPS, it would be rotating 40 degrees per second, which is obviously not what you want.

So, at 60FPS, the time_step comes into play like this..

- What percentage of a full time_step cycle was required to render the last frame?
- At 60FPS, it took .27 (16 divided by 60, rounded up from .2666...) of a full time_step cycle for the last frame to render.
- So, we then multiply the base amount of rotation (2 degrees per cycle, or frame) by the amount of time it took for the last frame to render, which was .26 of a full time_step. 2 * .27 = .54
- So, at 60FPS, the object will rotate a total of .54 degrees per cycle/frame.

Note: With these numbers it actually comes out to 32.4 degrees per second, not 32 even.. so I guess I was a bit off somewhere, or will that happen at certain FPS?)

If it were running at 20FPS, it would then be:
16 divided by 20 = .8
2 degrees per cycle/frame * .8 = 1.6

So at 20FPS, the object is rotating 1.6 degrees per cycle/frame.

So... if I'm understanding it right, the function of time_step is to control how far the object in question moves/rotates per second, based on the current FPS.

If that's so, then that's what I wasn't getting. I was trying to wrap my head around it as a function of controlling time... not distance. Maybe not the most accurate way to describe it, but if I have the basics right, then I guess it's good enough for me for now :-p

Correct.

An analogy:

You have two planets, planet A and planet B. Planet A has strong gravity and planet B has weak gravity.

Say I were to drop two equal sized steel balls at some altitude on both planets, somehow at the same time. And let air resistance be equal as well. Now in this case, the ball on planet B hits the ground sometime after the ball on planet A because of the weaker gravity.

If I wanted both balls to hit the ground at the same time, I'd have to somehow increase the speed of the ball on planet B or decrease the speed of the ball on planet A.

Time_step is this change in speed, and FPS is gravity.

That's actually an excellent analogy. I'll have to remember that

Whew... okay.. got that one conquered...

On to the next challenge!



Thanks again all

/bow