Allow Limited Camera Component Functionality Across Clients
HardLight670
In light of the recent and unfortunate removal of selfie cameras in the latest update, I thought I'd open up the discussion on ways to bring them back.
Additional cameras in Unity require additional render passes for all objects in the scene which is a costly operation, so it is understandable why they are disabled across clients. However, this cost could be mitigated significantly if drawing were limited to single burst shots as opposed to continuously recording.
One possible approach would be to provide a new script VRC_CameraCapture as part of the sdk. This script could be attached to a camera object and would expose a toggle that - when toggled with an animation - would trigger a single Render call on the camera for all clients. This would allow images to be captured and shown to other players across clients while keeping unwanted performance loss at a minimum.
Notes:
- Unity docs on Camera.Render method: https://docs.unity3d.com/ScriptReference/Camera.Render.html
- Cameras still operate normally on the local client, so aspiring photographers would still be able to "line up the shot" before triggering the CameraCapture script and causing the image to appear for other players.
- The Render call cooldown would have to be aggregated across all cameras on the avatar to prevent players from bypassing the limit by using multiple cameras in sequence.
Log In
L
LeviiA
Where is the new script VRC_CameraCapture？
GotoFinal
Or just add option for everyone [X] enable camera on avatars, or even give everybody option to disable cameras on selected avatars of other people... such simple thing to do, but they just removed them :<
HardLight670
GotoFinal: The main problem with this solution is that it introduces a disconnect between what different players can and can't see. You would have no idea whether the other person can see what you're trying to show them.
Additionally, there's no good default for this option. If it defaults to on, then it comes with all the performance problems mentioned above with the minor bandaid of being able to turn them off only after your performance drops. If it defaults to off, then many players wouldn't even know that the feature exists and leave it off, so attempting to show other players your pictures would be a crapshoot as to whether they could see it or not.
As closed minded as it may sound, sometimes it is better to commit to no solution at all instead of committing to a half-baked one only to have it rolled back at a later date.
GotoFinal
HardLight670: Then we will end up with all features removed, as with current code that is bad in all places performance will be low all the time, and they will remove one feature after another, like pedestals, cameras, what next?
Another option would be option to select how many cameras should be enable, with default to like
1
, and only closest ones are working (with pretty slow check rate like 1 seconds).And people should just choose from predefined settings at start, from low to high, like in every game. and if they want than change it manually to less/more. Also when disabled camera can show some picture indicating that there is a camera but you disabled it - everything can be done good way, just here no one want to do that.
HardLight670
GotoFinal: Are you telling me you'd rather have the game be completely unplayable? Because that's exactly what we saw with the constant server outages caused by avatar pedestals. Without that cut, you wouldn't be playing right now. We'd all be waiting on the VRChat devs to come up with that perfect solution you so desire.
Cameras present a near identical situation. At a certain critical mass, every time you logged into a world your framerate would tank. This would render VR unplayable, and desktop not much better.
Distance based cameras is discussed above and is widely regarded as a good potential solution. However, these implementations take time. Everything you mentioned - allowing players to choose a number of cameras to enable, deciding on which cameras to render, throttling the render rate - all take time. Time that could be better served on higher priority tasks.
I too would love to see these features return as soon as possible. Perhaps if VRChat were still it's old '400 users max in a day' self, then I could see the devs keeping them in while they work out some better solutions. However, that's not the case here. Some decisions have to be made.
Electro
Would really love camera usage back. I hate spending hours coming up with ideas, working with models and stuff trying to make things work only to find out that only I can see my creations and everyone else just sees black which makes me feel sad and look like an idiot. Was really hoping to fix my sniper scope and make a news reporter character...
Anything which could impact a toasters performance should be made as a toggle-able option like how some people complain about particles, polygons, and mirrors instead of limiting what the rest of us can and can't do. What's next, no object spawns?
Hell I would even pay for access to the feature. I mean VRChat is already free.
Whisper
Electro: Same, ive said it before id love to support this game. Im just weary about paying for features, as i wouldnt want to limit creativity behind a paywall.
Whisper
Another way to perhaps prevent abuse is to only allow one rendered texture of a specific size or lower per model, that way you dont have people become walking balls of mirrors essentially
HardLight670
Whisper: As mentioned above, the bigger problem concerns what happens if you get a room full of those avatars. A 12 player limit is about as small as most worlds come and can be handled even by most low end machines. 12 cameras on those avatars would almost certainly lead to a performance hit.
Kalthramis
Agreed wholeheartedly. Additionally, cameras on player models could be a togglable settings option.
This unnecessarily limits community creativity.
Joakim Eriksson
or just ban people who abuse it, dont disable it overall. Please
HardLight670
Joakim Eriksson: Mentioned this in the discord, but it's less a problem about abuse and more to do with the consequences should everyone start using them. A single extra camera might be alright on most machines, but as you start adding more of them, framerates will quickly drop for everyone - which is unacceptable for VR purposes.
Joakim Eriksson
HardLight670: i do agree, but there is ways of fixing this im sure. like limit the range were u can see a camera and so on, so if ur 10 meters away the camera dont render (if its on a character) and so on. I've not experienced a problem so far with it, (mostly cus not alot of people are using it as you said) but removing it just like this could've been handled abit better, they could've tryed making it work (with some sort of SDK script or whatever u said) i dunno
HardLight670
Joakim Eriksson: Limited viewing range does sound like a good solution. That's what many world authors are doing with mirrors these days for the same reason.
With how VRChat fads have been catching on like wildfire, I can't blame the team for erring on the side of caution with this one. Today is still day 0 for the patch, so I'm sure they just need a bit of time to get things figured out.
Whisper
Joakim Eriksson: I too like the idea of having it only render within a specific distance. That way you can keep interactivity between players without effecting the whole world
Shanie
HardLight670: they're definitely focusing on server stability until they can even rethink this idea but the whole limited viewing angles and distances part sounds like a valid solution.
tupper
Joakim Eriksson: Moderating this is essentially impossible.
HardLight670
An alternative and perhaps more robust solution would have a single VRC_CameraCapture script be placed on the root of the avatar. The script would expose a method that could be invoked via Mecanim's Animation Events system and would perform the Render call on the Camera passed into it. (https://i.imgur.com/4lNpENU.png) This would make managing cooldowns easier as there would be only one instance of the script to deal with.