Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

optimize 3D animation key frame search #5508

Merged
merged 2 commits into from
Mar 8, 2019

Conversation

mgsx-dev
Copy link
Contributor

this is a replacement for #4377

It's mostly inspired by the original PR with overall improvements and fixes to not break previous behavior.

It performs a kind of binary search with an heuristic based on time range.

Junit tests included. I had to change method visibility in order to test it.

Don't hesitate to tell me if you think it should be more documentated or if you think i missed some test cases.

@Darkyenus
Copy link
Contributor

Looks nice. Out of curiosity: have you tried to measure how it compares to the old linear version? (or how much does the midpoint heuristic help? )

@mgsx-dev
Copy link
Contributor Author

mgsx-dev commented Jan 15, 2019

@Darkyenus to be honest i didn't benchmark anything. Out of curiosity i made some benchmarks and it seams that heuristic is not usefull, worse it is slower! nice catch!

Here is some tests i made : the first one is with minimum entropy (one key frame every seconds), the second one is with more entropy (one key frame every randomly 1s to 100s). Results are is milliseconds.

frames samples With Heuristic Without heuristic Linear
2 120000000 2154.0 590.0 527.0
4 60000000 1092.0 358.0 250.0
8 30000000 355.0 216.0 208.0
16 15000000 178.0 126.0 176.0
32 7500000 97.0 81.0 170.0
64 3750000 34.0 48.0 174.0
128 1875000 17.0 30.0 172.0
256 937500 9.0 17.0 175.0
512 468750 5.0 10.0 208.0
1024 234375 2.0 6.0 165.0
2048 117187 1.0 4.0 169.0
4096 58593 1.0 2.0 164.0
8192 29296 0.0 2.0 167.0
16384 14648 0.0 1.0 169.0
32768 7324 0.0 1.0 170.0
frames samples With Heuristic Without heuristic Linear
2 120000000 2151.0 585.0 544.0
4 60000000 1502.0 399.0 329.0
8 30000000 312.0 165.0 217.0
16 15000000 159.0 110.0 175.0
32 7500000 79.0 77.0 161.0
64 3750000 68.0 57.0 169.0
128 1875000 28.0 29.0 176.0
256 937500 19.0 18.0 175.0
512 468750 8.0 10.0 170.0
1024 234375 4.0 6.0 169.0
2048 117187 3.0 3.0 170.0
4096 58593 1.0 2.0 167.0
8192 29296 1.0 2.0 172.0
16384 14648 1.0 1.0 177.0
32768 7324 0.0 1.0 172.0

edit: result updated since benchmark last code fix

Benchmark code available here : https://gist.github.com/mgsx-dev/290d06ef3d5e966725a6600000f5411a

I'll update my PR since it's faster and less code.

@mgsx-dev
Copy link
Contributor Author

Side note : Due to binSearch algorithm, it changes previous behavior in case of duplicates by not returning the first one. However, duplicates would raise error in interpolation code (zero division) anyway, so i decided to just remove this kind of tests.

@Darkyenus
Copy link
Contributor

👍 for benchmarking it. I think that there are some minor problems with that benchmark code, like keyframes.size actually being around 2x the expected size because it is not cleared, but nevertheless the result seems valid and pretty interesting.

I didn't know what the result would be, but it makes sense in retrospect. When it misses, the search space is not cut in half, but, in the worst case, made only very slightly smaller. Though it is still surprising that it would flop so badly, especially in the low randomness case.

By the way, I have been searching around and there is an search algorithm which does what the heuristic attempted to do. It is called interpolation search and has O(log(log(n))) best case and O(n) worst case, depending on the uniformity of the array.

@mgsx-dev
Copy link
Contributor Author

@Darkyenus oh, sorry about the benchmark code, i just read it again and you're right, i forget to clear keyFrame list 😬 but yeah, it doesn't change the conclusion.

About interpolation search, thanks for the link, i didn't know it and i think my implementation wasn't right at all. Anyway, since we can't predicte time distribution of the keyframes, classical binary search is the best choice IMO.

Thanks again to put me on the right track!

@intrigus
Copy link
Contributor

I can't reproduce your findings with my benchmark(https://github.com/intrigus/gdxbenchtest/tree/master).
Please try it.
Note that getXXXLinear may be extremely slow.

@mgsx-dev
Copy link
Contributor Author

I fixed benchmark code by clearing keyframes before each run.
I updated result in my previous post as well.

@PokeMMO
Copy link
Contributor

PokeMMO commented Mar 8, 2019

Initial testing looks good here, long animations now run smoothly.

@NathanSweet NathanSweet merged commit cad0f95 into libgdx:master Mar 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants