Animation
Re: Animation
Got it up to 40fps in the same test. Committed the slightly more efficient handleAnimationTransforms() to a new branch animperform.
Re: Animation
I think I have finally found what is limiting our animation performance, it is the timeIndex function - which I basically took from nifskope. Need to figure out why it takes down performance so much.
- lgromanowski
- Site Admin
- Posts: 1193
- Joined: 05 Aug 2011, 22:21
- Location: Wroclaw, Poland
- Contact:
Re: Animation
I don't know how much it gain, but it would be good to pass times vector as const reference instead of value.jhooks1 wrote:I think I have finally found what is limiting our animation performance, it is the timeIndex function - which I basically took from nifskope. Need to figure out why it takes down performance so much.
Re: Animation
Thanks, didn't seem to help much though.
I think eventually what we may need to do is:
Instead of interpolating each frame while the animation is running, interpolate 100 times per second in the NIFLoader. After each interpolation the bone values--rotation and translation-- would be pushed into a std::vector. When animations run, they pick the value closest to their current time. This would take a lot of memory though and could take a very long time to process.
EDIT: Would take 100*34(number of transformations in a npc)*(12 + 16) * 360 (length of npc running time in seconds) / 1024 / 1024 MB
About 33MB
I think eventually what we may need to do is:
Instead of interpolating each frame while the animation is running, interpolate 100 times per second in the NIFLoader. After each interpolation the bone values--rotation and translation-- would be pushed into a std::vector. When animations run, they pick the value closest to their current time. This would take a lot of memory though and could take a very long time to process.
EDIT: Would take 100*34(number of transformations in a npc)*(12 + 16) * 360 (length of npc running time in seconds) / 1024 / 1024 MB
About 33MB
Re: Animation
I do not know how much it can help, but if you do not need the C memory layout of std::vector (usually used with &v.front() while calling to a C function) consider using std::deque.
std::deque never reallocate, so if you do not know how many elements allocate before starting it might give a performance gain. On the other hand accessing the single elements is a little slower, so only a test can confirm.
std::deque never reallocate, so if you do not know how many elements allocate before starting it might give a performance gain. On the other hand accessing the single elements is a little slower, so only a test can confirm.