Could this not pave the way to audio sources on Quest/Mobile? If I’m not mistaken, the major source of strain with audio sources is, in part, the existence of multiples of them.
Likewise, per Unity docs, if audio is set to Streaming, it reduces memory pressure, AND plays audio on a separate thread.
This method uses a minimal amount of memory to buffer compressed data that’s incrementally read from the disk and decoded spontaneously. The decompression happens on a separate streaming thread whose CPU usage can be monitored in the Streaming CPU section in the Audio pane of the profiler window
In theory, could not then Quest now theoretically have a limit of, say, 1 Audio Source (for Poor, 3 for Very Poor?), and enforce Streaming Audio Clips at the SDK level, whilst still remaining somewhat performant?
Even more, if the request by dark to add PlayOneShot was added, couldn’t this even go as far as limiting to one audio source entirely at any performance level, without sacrificing functionality?
regarding the Standard Lite, emissions seem to have broken for avatars, i tested it for one of my avatars and I’m getting no emissions in-game despite having them activated on it in unity, any ETA on fix for that (affects both PC and Mobile)?
Maybe. We’re evaluating for this, but there are many unanswered questions.
One of those questions is that Quest 2 and Quest 3 performance is still lower than we like, and turning something new on is always a performance loss (even if negligible). So our current goal of “make performance much better on Quest” would be hurt by enabling it on Quest, if you translate the goal and impacts of this change factually.
But… we might shrug and say “nah audio is fun” if the cost is low enough. Don’t know yet. Again, evaluating. :D
This honestly feel like it’d solve a lot of problems a lot of us have with audio sources. The things I really want to ask is if we are able to control what part of the audio clip plays and if we could animate the pitch and speed of the clip depending on float values within the state behavior? Also why is this a state behavior rather than a component?
Having the ability to dynamically adjust the pitch and speed of clips would be a fantastic addition to this component. Not to inflate the scope, but turning it into a sort of “AudioSource++” could be a way to get people to use a better optimized audio setup for avatars simply by making it more convenient to use than the traditional methods.
One thing I would really hope for is adding emissions the toon lit or matcap lit shaders? Right now standard lite is the only quest shader that supports emisssions, but you can’t make any unlit/flat lit avatars with it.
Another few things that are popular requests are the ability to block by VRAM, see avatar stats/avatar details without enabling someone’s avatar, and an improvement to Quest performance ranks. An avatar could be very poor on quest and you have no idea if it’s like medium on PC or very poor on PC. Just that the category of Very Poor on Quest is too broad to know if an avatar is just slightly performance heavy or going to crash you the moment you turn it on
It’s always been supported via custom shaders (for worlds, where they’ve been supported on all platforms). We’ve just done a bit of work to ensure it’s fast enough to include it with our default shaders in the SDK. It’ll use Bakery, yeah!
(or rather I think there used to be some data structure issue with non-mono SH that doesn’t apply to MonoSH)
Ah oki, I will have to ask a shader friend where to find such a shader to support such rendering options because I would love to use it but I am not a shader dev at all. XD
