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
Malacomb
I only see this as a big positive, would help with avatar bloat
choccccy
the tag matching info would be useful to a lot of stuff I'm up to, +1
DecoyOct
Could someone with an understanding of this ask give some of the negatives of implementing this? I think showing both sides would help convince people, like me, who aren't knowledgeable enough in the subject. Is it just an effort issue?
Aspǝn
Massive contact reduction? Wouldn't that kill haptic wear and abilities? I use B haptics stuff couldn't there be a work around like people got for unlimited parameters? I can give a template of things. I have made for be haptics stuff if its wanted to look at see how there set up so its not affected. If it is of any sort of help. Its controlled by a AV3 animator not entirely sure how there system works its not a vrc fury item.
SenkyDragon
Aspǝn I think you're misunderstanding the topic. This would allow us to use fewer contacts in many cases, it has nothing to do with changing the limit. Local contacts like bhaptics don't even count toward the perf limit.
Aspǝn
SenkyDragon Oh ok i probably miss read it.
Smash-ter
I feel we should also add Ints in there as well as a third option that would have the contact turn on for remote users locally
Krysiek
I really like the idea of parameter suffixes with collision tag names for contact receivers. This would instantly reduce contacts components required by CuteDancer (and probably other spin-offs like SyncDances) by half.
Dor․
"Matching tags of the nearest collision" that could be an int to the tag index too, though I do like the bool idea since they could possibly give us the option to check multiple tags with one contact, technically less optimized (as they can't interrupt execution on the first match, but that could be an advanced contact setting), but not any less optimized than having multiple contacts like we'd need to right now.
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.
Load More
→