Expose more information to contact parameters (resulting in massive contact reduction)
SenkyDragon
In many scenarios, we could reduce the number of contacts required for systems by a factor of 8x or more if receivers exposed more information about the current collision. This is very necessary to avoid the undocumented vrchat "hard nearby contact limit."
This additional information could be exposed as parameter suffixes, just like _Stretch on physbones.
Specifically, these parameters would be very, VERY useful, and allow for an ENORMOUS reduction in contacts:
* X, Y, Z offset of the nearest collision in world units but LOCAL rotation (for example, z should be "forward" of the contact)
* Whether the nearest collision is self or others (or world?)
* Velocity of the proximity (change in collision proximity since last contact update / time delta, this is very difficult to calculate in animator since contacts do not always update every frame)
* Velocity of the sender (change in sender position since last contact update / time delta)
* Matching tags of the nearest collision. This could possibly be exposed as multiple bools <receiverparam>_Tag_<tagname> = 0,1
Log In
TB_HyDra
Look, im not gonna say i understand this but the way it was explained to me... less bulk on avatars = good!
kitlith
For a lot of this data, I have a single question: What happens when there are multiple senders interacting with the same contact? closest sender wins might work, like (iirc) proximity, but you are inviting much more accidental discontinuity than with proximity.
In general, though, I like that this only gives us data we can already access, but using less contacts. I don't know if contact limits are intentionally geared to limit the amount of information you can extract at any one given time, though.
One additional piece of data that might be useful to have, that we can theoretically already calculate using 5+ proximity contacts for combined position + radius, is the contact sender radius. (for spheres and the endcaps of capsules, at least.)
Pointing out use-cases/questions that jump to mind:
- x/y/z offset: which point are we getting the offset of?
- the center point? how does this interact with capsule senders? would take contact trackers from (at minimum) 4-6 points down to 1, and make them more accurate, reduce the amount of math that needs to be done inside an animator controller, or both, all while removing any issues caused by the contact sender overlapping the center of the receiver(s)
- The point used to calculate distance for proximity? potentially useful if you care more about the surface of a contact instead of the raw position of it. what happens when the center of the receiver is inside the sender? does the offset become 0? offset to closest surface? feels more niche, but I'm sure someone would want it.
- sender position velocity seems like what haptic pancake wantsfor its velocity mode, but is making do with calculating parameter velocity, for the moment.
- radius would allow you to detect the size of the sender (in relation to the receiver?) & adjust accordingly.
-CMC-
Add it. Meta shouldn't have to fund a 'milly for this for y'all to do it, like camera/skeletal tracking. Benefits everybody.
Deltro-X
This is definitely a good idea i will agree on this feedback
NotSynced
Personally I would like this. As I uses multiple contacts to send info in a binary way in some of my assets.
Using 8 contacts, I send info to communicate between avatars I have worked on for unique interactions and toggles. If contacts had more info on them, I sure I could narrow it down even more. If even one option was added that let you check 2 bools to choose the contacts state, you could easily turn 4 contacts into 1 (0,0/0,1/1,0/1,1)
toaste280
Seconding this. Currently, spawning a manipulable object from your avatar requires 6 overlapping contact receivers. Here’s a prefab and documentation on the technique https://github.com/ThatFatKidsMom/Avatar-Prop
This prefab frequently fails to operate in populated worlds, as other users sometimes have large proximity contact receivers on their avatars that will put it over the hard limit.
This could be achieved with just one physbone and a single contact receiver, if it were possible to get a vector to the contact for rotation.