3 ms·

Combining meshes will reduce the cpu usage hugely (assuming you are talking about hundreds of meshes) but you may end up sending lots of offscreen geometry to t

Combining meshes will reduce the cpu usage hugely (assuming you are talking about hundreds of meshes) but you may end up sending lots of offscreen geometry to the Gpu. Depending on your scene this may or may not be an issue. Some engines will do this behind the scenes or use indirect rendering (which gives the speed benefit of combining meshes without you manually combining). You should also be careful of monolithic Uber shaders especially if they branch as shader divergence can really kill gpu performance on some hardware. There is no one solution, just the one that best fits your usecase, hardware and coding time budget.

moron4hire 6y ago
Thanks. My requirements are pretty low, but I need to run on some pretty low-spec hardware, with VR multiview. Right now, everything is in WebXR, so perf is about half of native. And if I'm on a non-Oculus standalone headset, the only browser that is available is Firefox Reality, which has some perf issues of its own. There should be enough perf to run everything I need in this setup, especially of I can get some of my loading and texture transform ops running in Workers (again, with Firefox being the pain point here). But with dynamic content loading over the 'net and teleconferencing and corporate authentication and general Unity update fuckery, it just got to be too much to manage. A lot of my users can't have Facebook accounts, so I need to support as many other headsets as possible, and Unity's tooling for that is way too constantly-in-an-ever-shifting-landscape-of-broken. With OpenXR starting to really take off, and upcoming .NET 5 promising much more robust multiplatform support, I might be able to go back to .NET with Veldrid. Though I'd still have the teleconferencing and authentication bits being a lot harder to pull off outside of the browser, and having a native app would mean we would have to deploy through the Oculus store, which I definitely don't want to do.

moron4hire 6y ago

Thanks. My requirements are pretty low, but I need to run on some pretty low-spec hardware, with VR multiview. Right now, everything is in WebXR, so perf is about half of native. And if I'm on a non-Oculus standalone headset, the only browser that is available is Firefox Reality, which has some perf issues of its own. There should be enough perf to run everything I need in this setup, especially of I can get some of my loading and texture transform ops running in Workers (again, with Firefox being the pain point here). But with dynamic content loading over the 'net and teleconferencing and corporate authentication and general Unity update fuckery, it just got to be too much to manage. A lot of my users can't have Facebook accounts, so I need to support as many other headsets as possible, and Unity's tooling for that is way too constantly-in-an-ever-shifting-landscape-of-broken. With OpenXR starting to really take off, and upcoming .NET 5 promising much more robust multiplatform support, I might be able to go back to .NET with Veldrid. Though I'd still have the teleconferencing and authentication bits being a lot harder to pull off outside of the browser, and having a native app would mean we would have to deploy through the Oculus store, which I definitely don't want to do.