SDK Bug & Feature Requests

Override Kaiser mipmapping with Detail-Preserving Image Downscaling (BETA) checkbox resets to disabled state every time after restarting Unity Editor. Using Avatars SDK 3.7.3

SDK Version: 3.7.2 Description of the bug: So I noticed a problem while making a clone of my avatar with vrc constraints; when you try to freeze bones with vrc constraints of any type (that affects rotation) to the world if the scale of the parent is set to -1 on the X axis, it seems like the constraint is accounting for the parent's scale incorrectly and in the example explained below, leads to it setting the Y and Z axes to their respective additive inverse, when they should be unchanged, which results in weird rotations. (see first photo) This seems to only affect rotations, and naturally, the further the rotation of the bone is from 0,0,0 the more "off" the bone ends up being, so for the sake of consistency, I'll be attaching the constraints to the (left lower arm) of the models, it is worth noting that I have a constraint on all the bones however. Steps to reproduce: Import any humanoid model into the scene. Duplicate said model and parent it to Model 1 (see second picture). Set the scale of Model 2 to -1 on the X axis. Attach any vrc constraint (I recommend a vrc parent constraint) on the left lower arm bone in Model 2 and set the source to the corresponding bone of Model 1 (left lower arm, see third picture), and now press Activate on the constraint. Enter play mode, and rotate Model 1's left lower arm bone to any rotation. Activate the "Freeze To World" feature on the constraint and the left lower arm of Model 2 should snap to another rotation and the Y and Z axes should be changed to their negative value.

In UnityEditor, VRCConstraint component inspectors have "Activate" and "Zero" buttons, which calculate rest value and offset value internally. When it comes to adding them from C# script, we have to calculate offset value manually since the "Activate" method is not public in API. The calculation process is not obvious and a bit complicated, so providing existing implementation may be helpful. Is it possible to expose the procedure as a public method like “ActivateAndPreserveOffset”?

If the Unity UI unity package is not installed, the vrcsdk fails to compile, and it does not define a dependency on this package. I'm not totally certain why it's required anymore at all, since I believe it was used for the legacy play mode upload GUI, but in case it is still needed, a dependency should be defined.

An occlusion strength of 0 should look identical to a material without an occlusion map but in this case it looks identical to an avatar with a pure black occlusion map this is because in the shader the occlusion map is multiplied by the occlusion strength when instead it should be lerp(1.0, occlusion_map, occlusion_strength) the issue can be seen in the first attached gif as well as the comparisons with no occlusion map and a pure black occlusion map the second attached gif shows how this should look by using the unity built in standard shader

Been running into an interesting bug relating to vrc constraints. I will be using this avatar as an example: avtr_c32b6dbf-e8f8-46a4-a338-4828d68e307e It uses VRC Constraints for twist bones in many places. For some reason the lower arm twist bones start to drift out of alignment over time in some circumstances. They have only one axis (Y) frozen, but somehow they slowly drift more and more along the other two axis. Once the bug starts, they seem to very very slowly "orbit" around their pivot over time. The furthest I've seen them go is completely backwards (wrist pointing towards elbows), though usually the effect starts quite subtle. The constraint still appears to function otherwise perfectly, the weight slider even offsets it towards the resting position (though with the bugged rotation it is still in the wrong place). The strangest part is that it only seems to affect these two constraints on the lower arms, despite there being many more very similar constraints all over the avatar. I suspect it has something to do with gimbal lock and floating point precision. Resetting the avatar or doing anything that reloads the avatar fixes it instantly, until the next time it occurs. Repro: Wear this avatar avtr_c32b6dbf-e8f8-46a4-a338-4828d68e307e Go to this world wrld_66431182-f46c-45c9-9c8e-ba7f47c10177 Sit in any chair on the vehicle. Wiggle / move around in chair, like your having a convo, or practically anything to move the avatar After a bit, check to see if the lower arm joints no longer line up at the elbow. If arms not separated, continue step 4.

As it says in the title (SDK 3.6.1) [UdonSharp] Assets/Prefabs/aoiyu_/Workarounds/Text2TMP.cs(17,51): Udon runtime exception detected! An exception occurred during EXTERN to 'UnityEngineComponent.__GetComponent__T'. Parameter Addresses: 0x00000006, 0x00000007, 0x00000003 The given key 'TMPro.TMP_InputField' was not present in the dictionary.

A guess someone suggestion to this problem is a "Rounding Error". This issue seems to cause the position to update despite there being no reason for it too! This causes issues where prefabs don't play nice and it acts like it doesn't apply. This is due to the position constantly changing when it shouldn't.

Discovered that on SDK 3.7.0, VRC Parent and Position Constraint cause the object to move away from the source if the object size is 0, which can be fixed as long as the object size is not 0 (can be 0.0001). This problem show up on VRC because it automatically convert Unity Constraint into VRC Contraint which causes player Nameplate/Nametag to be really high up.

Burst compile warnings like below consistently appear after script compiliation. It happens even in completely new project (i.e. no other VPM package is installed). Unity Verison: 2022.3.22f1 SDK Version: Base 3.7.0 + Avatar 3.7.0 -------- Full log message: Compilation was requested for method UnityEngine.Jobs.IJobParallelForTransformExtensions+TransformParallelForLoopStruct 1[[VRC.Dynamics.WriteTransformJob, VRC.Dynamics, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]], UnityEngine.CoreModule, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null::Execute(VRC.Dynamics.WriteTransformJob&, VRC.Dynamics, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null|System.IntPtr, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089|System.IntPtr, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089|Unity.Jobs.LowLevel.Unsafe.JobRanges&, UnityEngine.CoreModule, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null|System.Int32, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089)` but it is not a known Burst entry point. This may be because the [BurstCompile] method is defined in a generic class, and the generic class is not instantiated with concrete types anywhere in your code.