-
Notifications
You must be signed in to change notification settings - Fork 202
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
[MAYA-113230] ALab loading speed bottleneck #1624
Comments
Just for the comparison, here is how Houdini is loading this stage. Geo loads in an instant and then textures are quickly loaded in. |
@santosg87 can you link this to internal issue MAYA-113230 ? |
@Xaia the long loading time is caused by texture loading. USD only synchronizes rprims whose purpose is necessary to draw the scene, but it synchronizes all the sprims. When the scene loads in with only proxy purpose displayed the time taken is all the time to load the proxy geometry & materials plus all the time to load the render materials. And the render materials take up most of the time! I reproduce a similar long load time in UsdView. There if I disable every render purpose and load the scene, it still takes me about 40s to load. I logged an issue against USD, PixarAnimationStudios/OpenUSD#1597, to track this. I suspect that Houdini is fast because their texture loading is asynchronous. During the actual USD load step their sprim sync calls are all fast, and so the scene appears right away without textures. Then, as textures load in the background they appear in the viewport. |
@williamkrick thank you for checking what is exactly causing this issue. Would be a bummer to lose all the magnificent USD speed just because of some puny textures ;). |
Yes hopefully we'll be able to find a solution to this problem. I did create a pull request for an issue I found during my investigation which saves syncing rprims which are not drawn. In ALab this doesn't provide a measurable performance improvement because the time all goes to sprims (the materials). There is no similar way to have sprims respect purpose for sync that is easy for me to implement, but we'll keep on looking for a solution. |
@seando-adsk This issue should not be closed as @williamkrick stated in his PR it does not resolve this specific issue. |
I didn't intentionally close this issue. I think because I merged #1633 it was an automatic Github thing. I've reopened this. |
Hi @wtelford , we're hoping to start using textures (much) more frequently in our pipeline soon and this is starting to shape up as a blocker. Would there be a way to give it a priority bump ? |
This is something we are investigating. |
@noWookies One thing worth mentioning here is that we identified an issue in Hydra and logged it as PixarAnimationStudios/OpenUSD#1597. |
Putting a note here: #1980 should help to improve the loading performance. |
I've passed this one to our internal QA to test the async texture loading performance and stability. Once we feel it is ready I'll switch the behavior so that the async loading is on by default. For now you'll have to set the optionVar value to get the performance improvement:
|
@Xaia this should be available on the latest mayaUSD release (0.18.0), are you able to confirm it on your side? |
Closing this issue for now, as we have it fixed internally. if this is still an issue, feel free to reopen. :) |
Describe the bug
Hi there,
I believe there is some kind of bottleneck while loading ALab scene with MayaUSD plugin. Tested on both 0.10.0 and 0.11.0
I feel like Proxy and Render purpose is loading in the same time so the time to first "pixel" is stretched to 38 seconds. This is way too long for such simple scene.
Steps to reproduce
Steps to reproduce the behavior:
Expected behavior
In my humble opinion Render purpose should load only on "demand" or during actual Render time.
Proxy version is low poly and has no textures assigned so it should load in less than a second.
For instance model with 2000 separate objects and 50M polys loads in 4 seconds.
Video with comparison https://www.youtube.com/watch?v=lHjzs4_hENE
Specs (if applicable):
The text was updated successfully, but these errors were encountered: