Closed syoyo closed 6 months ago
That's true. It's especially evident in debug mode, where some scenes run extremely slow even on my 3rd Gen Ryzen CPU. I'll take a look at matrix caching, and maybe try to add some parallelism to improve performance.
I'll take a look at matrix caching
Thanks! For example, adding global_transform_matrix
to Node, then compute it from the root node should work well.
void updateGlobalTransformMatrix(glm::mat4 parentMatrix) {
global_transform_matrix = parentMatrix * localMatrix();
for (auto &child : children) {
child->updateGlobalTransformMatrix(global_transform_matrix);
}
}
thankyou you are good
I added a very basic "caching" algorithm to limit the number of matrix calculations per animation step. While very simple, this greatly improved performance on my side, esp. when running debug with MSVC.
Thanks!
a glTF model containing roughly 300 nodes.
I don't have this glTF model to reproduce the issue anymore, but I think the "caching" fix https://github.com/SaschaWillems/Vulkan-glTF-PBR/commit/2ac4de59e1f9957595270733422fa4f79ee2972c should work well, so closing the issue.
https://github.com/SaschaWillems/Vulkan-glTF-PBR/blob/08cf10dcd7609fa6f7d43b4e79ecca7431d09937/base/VulkanglTFModel.hpp#L511
getMatrix
always loop over parent matrices until it reaches the root.This become quite slow when the scene contains deeper node hierarchies(e.g. 100. such a deeper hierarchies would happen in character skeletons). For example, I get 120 fps(without
getMatrix
) -> 7 fps(withgetMatrix
) slowdown on Threadripper 1950X for a glTF model containing roughly 300 nodes.The solution is obvious. Cache the node's matrix once after updating the matrix of each nodes. Probably we are better to add
updateNodeMatrices()
API before callingnode->update()
(If this change is OK, I can send a PR)