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

Optimizing and cleaning out the callback hell #28

Open
sirpalee opened this issue Nov 15, 2018 · 1 comment
Open

Optimizing and cleaning out the callback hell #28

sirpalee opened this issue Nov 15, 2018 · 1 comment
Assignees
Labels
enhancement New feature or request

Comments

@sirpalee
Copy link
Contributor

At the moment we rely heavily on callbacks to get the scene updates propagated, but it's causing significant slowdowns with many (5000+) animated objects, which can be easily the case in production.

The issue is easy to reproduce, create a small hierarchy with a few animated transforms (5 or 6 nodes), then duplicate the hierarchy 1000 times and keep the input connections. Hydra draws objects very fast (faster than VP2), but once animation is played back, the framerate drops to ~3fps compared to 30. Though VP2 is doing some sort of caching (the first playback is slower than the second one), but we should still be able to do better than 3 fps. I suspect simplifying the transform related callbacks could be an easy win. While there are simpler ways to track transform (MDagMessage's world matrix changed callback) changes than tracking parameter changes, we still need to deal with visibility in an efficient way.

@sirpalee sirpalee self-assigned this Nov 15, 2018
@sirpalee sirpalee added the enhancement New feature or request label Nov 15, 2018
@sirpalee
Copy link
Contributor Author

sirpalee commented Nov 26, 2018

The idea is to move tracking changes on transform matrices to the SceneDelegate and pass dirtied bits to the adapters for further processing. This way we can share callbacks and avoid duplicating them, and have cheaper options to build the transformation matrices than using MDagPath::inclusiveMatrix.

The reason we still need the adapters for marking prims dirty, rprim types can have their unique set of dirty bits, or you need to do additional processing / pre-calculating data (like shadow matrices for lights).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant