Just to add onto what dark has said, I find it absurd that you guys decided to artificially limit people being able to access the PCVR client for the following reasons:
the device has barely been released four weeks ago, to say that there’s too little people to support a dedicated build (you may have noticed that nobody is explicitly asking for an official native ARM PCVR build; people want to try this out with FEX instead) is very disingenuous considering that outside the voluntary poll website the userbase of Steam Frame is growing quickly enough that developers are going out of their way to provide official support and hardware (see the entire facetracking and FBT community providing built-in standalone support for Frame)
Steam Frame is explicitly advertised to allow people to tinker however they like since it is running Linux desktop underneath, and I know for certain that the PCVR version works decently without needing to significantly tinker with or mod the client on Linux. There is a significant overlap between Steam Deck and Steam Frame communities who are willing to go out of their way to tinker around just to see what works with zero expectations on performance
Having this suggestion below be implemented as a beta branch for people to manually hop onto would be the best compromise
People seem to forget easily that the Snapdragon 8 Gen 3’s Adreno 750 GPU found in a Steam Frame uses tile-based rendering, like any other mobile GPU from Qualcomm found in a VR head mounted display. These have the same limitations as the Snapdragon XR2 Gen 2’s Adreno 740 GPU found in Meta Quest 3, etc.
To echo @kazy above, I think many of you are overestimating the Frame’s hardware capabilities and architecture. Discard in tile-based rendering is slow, and overdraw has particularly bad performance issues on the Steam Frame standalone on a constrained mobile GPU power budget, to deliver the necessary 72+ FPS with stereo rendering.
The mobile restrictions in place (including restrictions on support for alpha transparency) on the Steam Frame standalone seem to be sensibly justified on technical merits.
On a platform where the average user is seeing 30-50 FPS in any decent instance due to world and avatar performance?
If we used this same argument for PC, VRChat shouldn’t exist on PC because the average user can not maintain their headset refresh through the majority of experiences. Even me with a 5700X3D and 3080 can’t.
This solves exactly the bone-driven jaw use case I was looking at, keeping the high-fidelity viseme blendshapes for the mouth while using the viseme data to drive an actual jaw bone, so child transforms like a PhysBone tongue can follow correctly.
It should also let me replace my current Viseme + Voice approximation/state machine with a single high-fidelity jaw value.
Then, if a local avatar supports native face tracking, does that mean all UE face tracking keys will be sent across the network, even if the avatar is configured to use only some of them?
(Personally, I think it would be better not to send the values of keys that we know won’t be used.)
At the risk of starting a full blown EAC argument I do have a question.
What if non EAC clients were allowed but restricted in instance types they could access? Like maybe allow people to fire up the PC vrchat and hang out in an invite or invite+ home world and see what happens?
I ask this as I kinda want to touch the hot stovetop metaphorically with my steam frame, but I’m not sure how complicated it would be to otherwise test this. I suspect I can open vrchat without EAC if I’m loading into a local test world. I just doing know how complicated that would be. I’m not really familiar with containers. I’ve been hoping somebody makes a separate post on either here or Reddit.
