-
-
Notifications
You must be signed in to change notification settings - Fork 6.4k
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
Conversation
gdx/src/com/badlogic/gdx/graphics/g3d/utils/BaseAnimationController.java
Outdated
Show resolved
Hide resolved
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? ) |
@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.
Benchmark code available here : https://gist.github.com/mgsx-dev/290d06ef3d5e966725a6600000f5411a I'll update my PR since it's faster and less code. |
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. |
👍 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. |
@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! |
I can't reproduce your findings with my benchmark(https://github.com/intrigus/gdxbenchtest/tree/master). |
I fixed benchmark code by clearing keyframes before each run. |
Initial testing looks good here, long animations now run smoothly. |
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.