SDK Bug & Feature Requests

The laser pointer that is used in world UI or to point at an interact/pickup currently does not have a native way of checking where that is nor what VR hand is showing the laser. This requests for a function or event to get the hand and Ray (to be used with a Physics Raycast) that references where the laser pointer is and a way to request for the Ray in the off-hand. This would be extremely helpful in creating pointer based controls (like click drag) for 2D color pickers, showing both lasers for an in-world keyboard, custom interactions, drawing on a 2D canvas, etc. I made an Udon prefab that's able to estimate these pointers but it would be nice if this was a native SDK feature: https://bobystarvrc.booth.pm/items/5007241

In the latest version of the SDK (3.10.3-beta1), VRC Raycast was added as a component, and while I think it's a really cool component, one parameter I'd like to see added to it is the "QueryTriggerInteraction" parameter. Since Unity lets you set raycasts to not interact with trigger colliders, and some worlds use the default layer for trigger colliders above any real touchable surface, this would allow people to differentiate between, say, a teleporter's trigger collision and the floor it stands on if they're put on the same layer

When physbone rotations are limited, the effects of physics settings such as gravity, as well as pulling on the physbone, will cause the "locked out" rotation to travel up the chain, for example: Making a vertical line of 3 bones and limiting the rotation to 10 degrees, then grabbing the bone at the bottom and moving it beyond 10 degrees will cause the parent to then rotate to follow it (since they're linked together) However this same behavior does not extend to collisions, pushing the bone described above with a collider will only cause it to move and lock out at 10 degrees, and won't travel up the chain to push the parent, I see this as a bug as the behavior differs depending on interaction method. Please allow the forces induced by colliders to travel up the chain (note that some physbones may have depended on the old behavior, so a physbone version bump i.e. 1.2 might be necessary). This currently makes setups like the ones in the attached images only function for grabbing, not collision (hinge rotation on root bone affects the glasses, collision radius set to 0.015 but reduced to 0 on the root bone via curve, dummy bone set to to overlap the glasses frame with collision, to provide a wider point of contact than what would be possible otherwise, hinge rotation set to 0 on the dummy bones, immediately locking out their rotation, which should cause any force induced on them to travel up the chain).

Once out of beta would vrchat still be open to expanding the suggested collision tags? And if so would it be from canny posts, or when they think a tag is popular enough. with contacts being added to worlds the standardization for tags I think is going to be getting a lot bigger. especially if people design systems that use a bunch of specific tags. To take some of the load off of vrchat, having a way people can either create their own tag list or download a list by someone else. and have it show up in editor would help making standard tags people make easier to use.

In the new SDK 3.7.6, it's now possible to build a world on Linux, but it is not possible to launch a local test with proton. Pls add proton support, similarly to: https://github.com/BefuddledLabs/LinuxVRChatSDKPatch

I'd like a feature when clicking "Select" it guides you to the meshes with said unsupported shader materials to make it easier and quick to fix up when its about converting an avatar to quest version or some other reason too. Having that would be very time saving

An Udon API function to recenter the player to the station's Enter Transform. This would recenter the player's XZ position plane to the station's Enter Transform. An optional parameter (or secondary function) would be given to recenter the player's view as the new reference forward direction. Ideally a call like station.RecenterLocalPlayer(bool reorientRotation = true) would by default do both position and rotation realignment but reorientRotation can be set to false to only handle positional recentering (caused by play-space movement). This would alleviate the problem of a player getting into a vehicle or mounting any station in the wrong direction or moving too much, requiring them to leave and re-enter the station to recenter themselves. This would also give the opportunity for a custom station based character controller to utilize play-space movement as a mobility option without having the feet IK get stuck in one position for VR.

VRC Object Sync by default is a continuously operating script that pings locations to all players even when objects are at rest or behind the player/occluded by the world. As a result, once the object pool reaches higher numbers, over 200, frame times are permanently hindered as the game waits for all these pings. I'd tested in my world the difference between VRChat's default Object Sync script and MMMaellon's Smart Object Sync on about 212 objects. Performance with default object sync raised frame times to 16.7-17ms. MMMAellon's Smart Object Sync brought framerates down to 2.4-3ms, an overall savings of around 4-5x performance improvement. And this is not on a slow PC - this is on a Ryzen 7 7800x3D with a Noctua NH-12s cooler, an RTX 4070, and 64 GB of RAM. You cannot simply add power to fix the problem. MMMaellon's script does a lot to improve performance, but the core function allows objects at rest to stop pinging unless exerted by an external force. They are also developing a newer version of the script that cuts bandwidth in half. As VRC adds more dynamic global objects through the inventory system, I fear this issue will only become more exasperated the longer global sync gets ignored. I highly recommend enabling higher performance syncing methods by default for newer worlds and enabling the older sync system only when absolutely necessary. As many maps feature QV pens, pool tables, grabbable pillows, coffee and drink prefabs, and other grabbable synced objects, this will have an immediate performance impact across the entire game, and it's something all creators need to be made aware. https://github.com/MMMaellon/SmartObjectSync

When building a world using Multi-platform build and publish with the user editor preference of Auto Refresh disabled the next platform will fail to build because UdonSharp cannot compile scripts that have not been compiled by Unity yet. Reproduction Steps Disable Auto Refresh in Unity Editor Preferences > Asset Pipeline. Attempt to multi-platform build and publish with at least 2 platforms. Notice the current platform will successfully build and upload. Wait for the SDK to automatically switch to the next platform. Notice UdonSharp fails the build and Unity starts compiling scripts after the fail. This was tested with SDK 3.10.1.

Toon Standard's "Rim Lighting" feature is a nice way to add some nice subtle variation to a material -- the only problem is, it has the exact same brightness on screen regardless of any other lighting conditions, which means that an intensity value that's nice and subtle in direct lighting, looks like a permanent surreal neon glow as soon as that same avatar steps into a dark environment. I'm not certain what's happening inside the shader, but my guess is: the "rim lighting" effect seems to be added over everything else with just an alpha blend that totally ignores the lighting that was already on the character? Maybe adding an option to instead use an additive blend would let a subtle rim light be equally subtle in both light and dark conditions? (There's possibly also solutions involving multiplying it by the intensity/color of environmental light sources, but if I'm picturing it right, even just the additive blend rather than alpha blend could be enough to address this.)