Welcome to the Oculus Developer Forums!

Your participation on the forum is subject to the Oculus Code of Conduct.

In general, please be respectful and kind. If you violate the Oculus Code of Conduct, your access to the developer forums may be revoked at the discretion of Oculus staff.

Avatar Asset Loading in Unity - Avoid blocking main thread with GPU texture upload?

StefDevsStefDevs Posts: 4
NerveGear
For the past day or so I've been working on reducing the framerate hitch upon loading assets from the native API. I've been fairly successful in dealing with mesh assets by limiting the amount of time spent marshaling vertices each frame, but the other major contributor is the texture assets which are taking up to ~500ms for one texture upload on my system (highest LOD).

From what I've gathered, Unity has no good way to load a texture asynchronously if it's not included in the project build. The best shot I can see is to upload the texture in a native plugin and pass a handle to the texture to unity (using Texture2D.CreateExternalTexture()?), but this is likely out of scope for my current project and it seems like quite a bit of necessary complexity to build a middle man for this. Although maybe I could achieve this in C# only...

Are there any plans to solve this problem in the Avatar SDK? Could we get the native native SDK to upload the textures asynchronously for us? I would love to achieve zero dropped frames in this experience.

Thanks,
- Stef

Comments

  • StefDevsStefDevs Posts: 4
    NerveGear
    Thanks for your response @imperativity .

    After some testing and debugging I've found that the extremely long upload times only occur when forcing mobile textures. DXT formatted textures (as apposed to the ASTC) only take up to 7.5ms (1.2ms average). 

    I imagine the extreme upload times are due to some conversion taking place, but I wonder how fast I can expect these texture uploads to be on mobile as I intend to target Quest.

    Anyway, this is no longer a serious concern until I get my hands on hardware to actually test on. While still potentially useful, my suggestion is now much less interesting assuming that mobile performance turns out to be sufficient (as I suspect it will be).
Sign In or Register to comment.