What's the different between ProcessTick and InterpolateTick?

#1 Interpolate tick is in fact what EXECUTES between ticks. If you want it to render something, you could as well ;).

#2 John, good questions.

You are on the right track, though. Interpolate tick will interpolate between two fixed time steps wherease process tick will compute the next time step (so time step == tick). The tweening is of it's state variables, doesn't actually render (but called just before rendering).

Scene object automatically handles position and rotation. If you do something else that needs to be tweened then you'll handle it in interpolate tick. Things like animation simply get update animation callbacks, so they advance by time (they don't need to play exactly the same on different computers, so they can be a little lax).

TorqueX actually has 3 modes it can operate in:

Variable time steps. Won't get interpolate tick and process tick will be passed variable dt. You will find inconsistent results across machines, but sometimes that's ok. If you want this you would set UseFixedTimeStep to false in the torqueSettings.xml file.

Fixed time steps with interpolation. You will get both interpolate tick and process tick callbacks. Process tick will be called with constant dt. Interpolate used to tween frames, as described above. If you want this you would set UseFixedTimeStep to true and UseInterpolation to true in the torqueSettings.xml file.

Fixed time steps without interpolation. This one sounds crazy but might be the best choice (not the default, though). The way it works is the system only renders on the tick boundaries. You save all the time spent processing interpolation. Since you are always rendering on the tick boundaries, you are always "on time" which is more important than rendering more frequently. If you want this you would set UseFixedTimeStep to true and UseInterpolation to false in the torqueSettings.xml file.

Hope that helps.

#3 Thanks for the replies!

I've actually posted a more detailed version of my initial question in the TGB forums:
http://www.garagegames.com/mg/forums/result.thread.php?qt=57439

If you get a chance, can you take a quick look at it?

Basically though, I still have two questions:

1) When using fixed time steps with interpolation, is the physics engine always one-step ahead of the rendering engine? That would make sense because then interpolation could interpolate between those two points (eg. the values from the previous tick and the current values). If this is true, then I would guess that TorqueX stores the previous position AND the current position. Is this true?

2) If I'm correct in my understanding of the above question, does interpolateTick store it's values somewhere to be used for rendering? I'd guess it would have to do this... (eg. have an "interpolate position" and a "real position")

Thanks!!

#4 Oh, one last question...

3) Are you saying that sceneObject handles position and rotation interpolation automatically? Does it do simply linear interpolation or something like that? Also, if it does indeed handle position/rotation interpolation, what else would need to be interpolated?

Thanks again!

#5 1) Yeah, stores previous and current tick. Not quite one tick ahead, though, since if you are rendering at the half way point between two ticks you are actually only 1/2 a tick behind.

2) Object stores previous and current tick data, but all the accessors get "current time". So if you use Position property during render, it will be interpolated, if you use it in tick, it will be previous tick (i.e., we call interpolate(0) before a new tick).

3) Linear interpolation. Other than position and rotation, very little else needs to be interpolated. If you are animating a mount point, you might want to interpolate that, depending on how you are using the value. If you are using it only for rendering then it won't matter because you will do that in update animation, but if you are using the mount rotation for wheel turn on a vehicle, e.g., and you are "over-clocking" the tick rate to get a better sim, then you would probably want to update the rotation on the tick and interpolate between ticks. If you use the process component, then the interpolation of this parameter is handled automatically. BTW, when I say "over-clocking", I mean running the sim at 100 hz or something, even though you only render at 60 fps.

#6 BTW, I'll leave the TGB thread alone. Although TGB and TX have a common philosophy and history, they are a little different on the ticking and I'm not sure what Melv implemented.

Traditional TGE, in particular, stores current position, last position, and render position on the object. TX only stores previous, next, and current location. Not that much different, but all the engine code uses one accessor to properties in TX whereas in TGE you use GetRenderPosition if you are in render code or GetPosition if you are in physics code. Also TGE/TGB do not have the fixed time step no interpolation mode. TGE does not have the variable time step mode.

I think Melv implemented something more similar to TGE, but not 100% sure.

The downside for TX is that we have to call interpolate(0) before ticking. The upside is code clarity. I prefer the fixed time step no interpolation mode, so I'm not killing myself over the extra interpolate(0) (which results in maybe 2% loss, which is all due to spatial database updates, something we will tackle later on). The no interpolation version gets all this lost cpu back and turns it into an equal gain.

#7 Awesome replies! Thank you very much!

Just curious, but why not store a render position and current position instead of calling interpolate(0) during every tick?

The only thing left thats still a tiny bit fuzzy is how the process component works as far as handling the interpolation automatically. By handling everything automatically, do you mean that position and rotation is automatically interpolated? ...and if I don't use the component (eg. implement my own component that registers for tick callbacks) then I'll have to manually interpolate?

Thanks again Clark, you really cleared things up for me!

#8 Glad to help.

The reason we don't just store the render position is that it isn't the interpolation back to that position that is time consuming. Rather, it's the re-filing of the object in the spatial database (so storing the position wouldn't help). But the re-filing isn't dog slow or anything and in the future we can speed that up with improved spatial database.

The process component isn't for handling of position and rotation. Those will be interpolated whether you use the process component or not. What it does is let you manipulate a float on the tick via a process node. Most of the process nodes that are built in handle processing input from a move and passing it down stream (so, e.g., you could take a thumbstick and hook it up to the rotation of a link point this way). By doing so using the process component, the float you are processing will be interpolated automatically.

The process component isn't really there so much to make coding easier. The things it does are pretty easy to do by hand. But by adding a series of these guys you can create player objects in the editor with no coding at all (because link point rotations are exposed as float interfaces, as are force strengths). This is where the notion of the TorqueInterace which is exposed by TorqueComponent starts to pay off.

#9 From what I remember TGE/TSE do indeed call Interpolate(0) before a tick so you shouldn't beat yourself up too badly Clark ;)

#10 @Robert. Ah, that's right. But it's unnecessary. I removed it for ThinkTanks and dRacer. It is only there to support legacy classes.