[PATCH] Sim interpolation optimization

[sbte]

I wrote a patch that make sure we don't reinterpolate if the position of a component does not change. This gives me a speedup for the sim interpolation of 6 ms/frame to 3.6 ms/frame. Thanks to quantumstate for the suggestion.

[sbte]

Sim interpolation speedup patch

[sbte]

There are a few issues with the above patch.

At least two trivial ones:

• Buildings don't follow the mouse before they are placed
• Buildings don't raise from the ground when they are built

And two harder ones:

• When units move from a to b in a turn, they never actually reach b, but only a+(b-a)*lastFrameOffset
• In Atlas, raising the ground level does not raise the objects that are on the ground.

I already have a working patch, but that one is a lot slower than the original one 5ms/frame vs 3.6 ms/frame. I will try to improve this.

[sbte]

Sim interpolation speedup patch v2

[historic_bruno]

How does this affect stationary units that are animated?

[sbte]

Replying to historic_bruno:

How does this affect stationary units that are animated?

This is handled by the call to m_Unit->UpdateModel(frameTime);

[sbte]

By the way: the new patch handles all cases I mentioned previously and still has the 3.6 ms/frame speedup. The Atlas bug is fixed by only allowing skipping interpolation only after a turn has completed. This will not happen in Atlas (as far as I understand).

[Jonathan Waller]

There is still and atlas bug. You can play the simulation in atlas (on the left panel there are buttons) so your detection stuff from there breaks. Your current approach doesn't seem very robust, perhaps there is a better solution? Doing special things for construction progress doesn't look pretty to me.

One idea is to store m_PrevX, m_PrevY and m_PrevZ. Then check if the current values match the stored in the GetReinterpolate() function. At the start of each turn update m_PrevX, m_PrevY and m_PrevZ.

Another option is to add something to the setters for m_X, m_Y... and again use a new turn event to clear the dirty flag. I think I prefer the other idea though.

[sbte]

Replying to quantumstate:

There is still and atlas bug. You can play the simulation in atlas (on the left panel there are buttons) so your detection stuff from there breaks. Your current approach doesn't seem very robust, perhaps there is a better solution? Doing special things for construction progress doesn't look pretty to me.

Sorry, but I have not used Atlas before, so I did not notice this. Is there maybe a way to detect whether we are in Atlas and in that case disable this optimization?

Replying to quantumstate:

One idea is to store m_PrevX, m_PrevY and m_PrevZ. Then check if the current values match the stored in the GetReinterpolate() function. At the start of each turn update m_PrevX, m_PrevY and m_PrevZ.

This would break the JumpTo method, because this method sets m_PrevX and m_PrevZ to be equal to m_X and m_Z. Instead, we need the possibility to be notified from AdvertisePositionChanges, so that is what I do now.

Concerning the Y value: I tried this, but then lost 2 ms/frame again mostly because of the extra work that has to be done to compute the correct Y value (which, AFAIK, actually has to be done only in Atlas and when construction is in progress). I don't really see a way to speed this up even more.

Replying to quantumstate:

Another option is to add something to the setters for m_X, m_Y... and again use a new turn event to clear the dirty flag. I think I prefer the other idea though.

This would still mean it is a lot slower because of the extra Y computations.

So basically, disabling this optimization in Atlas would be ideal to avoid having extra computations for the Y value (and would hopefully fix all bugs). If you know a way to do this that would be great.

[Jonathan Waller]

Ah yes I was forgetting about the terrain modification stuff. One things that could be messy is flattening the ground near buildings which is a proposed feature. I think it is probably ok to write a comment in that ticket though mentioning this (which I will do).

leper helpfully found if(!g_AtlasGameLoop->running) which should do what you want. I would still like it if you try and avoid as much special case stuff as possible, since it makes maintenance easier. Terrain height changes sound like a reasonable special case though.

[sbte]

If anyone needs to actually force an update, they can call JumpTo or MoveTo using the same x and z position. An alternative to the special cases is that methods that actually change terrain height call some method that sets m_PositionChanged to true. Maybe that's a cleaner solution?

[sbte]

Sim interpolation speedup patch v3

[sbte]

I again added a new version of the patch, which now disables the modifications I made in Atlas.

[Jonathan Waller]

In 13223:

Only use interpolation for moving objects in VisualActor. Patch by sbte. Fixes #1846.

[Jonathan Waller]

Thanks for the patch.

[Jonathan Waller]

In 13243:

Fix rotation interpolation. Refs #1846.

[Jonathan Waller]

In 13244:

Better fix for the angle interolation issue. Thanks sbte for spotting it. Refs #1846.

[ben]

In 13500:

Reverts interpolation changes from r13489, r13323, r13251, r13244, r13243, r13223. Refs #1846, #1858, #1865, #1906