I’m really excited about this feature. I can’t wait for it to be implemented…
I’d be very happy if, in addition to specifying the number of bits, we could also specify a range.
For example, integers from -10 to 10 or floats from 0 to 1 (with the resolution displayed based on the number of bits).
In particular, the 0 to 1 float range is used by the Radial Puppet, so this would allow us to avoid wasting 1 bit on synchronization.
WOAH!! So much cool avatar stuff ^o^ The Int going about 255 would be SO USEFULL for making more complex prefab stuff X3
Is this ALLL going to be quest compatible (specifically the material contacts?) <3
ALSO!! Since the parameters are getting a mini glow up- would there be an option to control float rounding? one MAJOUR issue I’ve had is using rotary wheels to control stuff, say a shadier changer that switches out a shadier, with 20+ options, but due to how floats round differently locally and non locally, sometimes since the values are so small, if you put it on the edge between an animation change, other users see differently to what you see. Its a rounding issue, but one I sadly cannot control. Having a way to control this rounding issue would be amazingly useful!! <3
It’s technically just parameters set to shaders same as oyu can do that globally in Udon (in fact this potentially doable via Udon scripts already), so should be easy to work on quest, but ofcorse not on avatars as you can put cutom shaders on quest on them.
Rounding is dictated by local CPU behavior due to how float points are encoded in memory and that behavior can’t be really controlled by code:
Same goes with GPU and shaders. This could be more fixable if they allow larger float point ranges as whole numbers should be more stable.
1 Like
It would be great if the Action Driver allowed toggling not just the object’s active state, but also the component’s enabled parameter. Judging by the screenshot, though, it looks like this is already planned.
Thank you!!! I did that material shader contact thing with my Latex Ultra shader when I released my Living Goo update, so this is gonna be CRAZY to see this working better than my implementation!!
Give us support for unsigned floats too, most floats are used in radials so the sign bit is completely unused and cuts precision in half.
1 Like
The first gift isn’t the glasses is it? Means I’ll have to be on to 4 am. orz
And how do you get the gifts, they just pop up in your inventory?
> Action Drivers
Could this be a replacement for Avatar Menu Creator for MA!?
I’d really love it if you could make it possible to transition _AlphaMaskValue over 0.5 seconds when turning a GameObject OFF!!
about the Variable Width Avatar Parameters, if we really want to be frugal about synced bits:
radial puppets only affect the 0 to +1 range, so would it be possible to have synced ufloats to save that mostly unused sign bit for either more precision or to use it for something else?
as an exemple: a 7bit ufloat would have the same pressision for the rotation as an 8bit float for a radial puppet but also leave a bit free for the radial puppet’s “active” parameter
Variable parameter size is very cool, that’s something I’ve been thinking about for a while. This will help reduce the parameter size, and maybe free up space for FT parameters. Unless VRC-devs decide to also make those “built-in”, without taking up Parameter space?
Also, Action Drivers is a neat idea. I know VRCF and MA have something similar, but those use animations. Will “Action Drivers” only be able to toggle objects on/off? Because, for example, many of my own toggles also require changing like over a dozen blendshapes and material properties.
That’s a bit of a double edge sword. On one hand it makes sense with regards to shader stuff as things needs to be updated in real time, especially given that Material Contacts could used for more than just contact interactions given _Self has a local to world matrix. On the other, I’m hoping that the method of triggering contacts is still at a fixed rate for network syncing purposes (unless we should start listing the contact’s parameter on the parameters list). Either way, I’m praying that this feature comes sooner.
1 Like
Is the syncing of the parameters over network working well for the wider ints ?
I feel like if FT was built-in, It would make it so much better. Smoother and Wouldn’t have to take up so much Space, Since i feel like even with this new addition, It’ll still be a lot.
The correction here would be Renderer instead of MeshRenderer as the demo used to show this off uses SkinnedMeshRenderer.
I’m am very excited to see the Action Drivers & Variable width parameters. I’m hoping this can remove a lot of things from the animators and improve performance.
Great developer update! 
Wasn’t there supposed to be a change to chatboxes where the automated messages would self flag themselves, or did I hallucinate that? I’ve seen chatboxes that state what VRChat world a person is in.
Something I neglected to ask with the variable bit widths - is cross platform parameter sync going to change at all with this? Currently we’re required to keep parameters in the same order, with the same type (due to bit width, but float/int are probably interchangeable, though untested), I’m presuming the only new caveat is same bit width too?
Also on the topic of bits, any chance we could get new Parameter Driver operators to set/unset bits (if it’s one entry, it should display up to 32 bits as this may be used locally as well, and for synced parameters highlight the “synced” bits in some way like an alternate background), as well as the option to copy parameters from X bits to Y bits, this could be used, for example, to “pack” multiple parameters in multiplexing systems.
Right now without horribly inefficient animator logic it’s practically impossible to set every bit in an int by a bool or set multiple bools via int bits (it’s possible, but it spans multiple frames due to multiple transition evaluations, or requires defining hundreds of transitions, one for each possibility, instead of nesting them), requiring us to create multiplexing int(s) alongside multiplexing bool(s), with these options we could slow down updates to as little as 1 bit per parameter update regardless of type, or reduce wasteful allocations and instead allocate just the the largest bit width used, and fill it with smaller types when the “large” types aren’t currently being synced.
An alternative to defining specific additional operations, though I suspect far less likely (especially since you don’t want to encourage further uses of animators for logic, but I’d hope that any alternative we get would support this in the future so this work could be translated whenever the animator exodus happens), maybe an expression operator, where a parameter list is converted to variables (since parameter names aren’t always valid variable names conversion in some form would be necessary, I’m imagining A through Z), and an expression could be performed using them, i.e. C = A + B; D = (B & (1 << 3)) != 0; E *= 3; This would give us access to a lot of mathematical operations that are either impossible, impractical, or require complex (blendtree) setups.
Also yes this should probably be a canny, but given the discouraging comments towards continuing to use animators for logic (despite not having an alternative yet), I have no reason to believe this would be considered unless it’s confirmed otherwise, so I rather ask here while it’s on topic.
Oddly enough the vrchat docs don’t say what happens when you mismatch variables at the parameters file. They just assume that you’ll use the same type on all versions (PC android iOS), and then clarify what happens when you use them in animators with specifying different types on the animator
But yeah, parameter width will need to match. Only the 256 bits of sync data is sent across the network, how to encode(your local avatar) and decode(remote viewers) is left to the avatar, no other information is communicated
Pretty great update! Material contacts are going to be huge.
Just one thing:
Sigh…
I get maybe that this is to gauge some level of feedback, but it’s exhausting. Can you just… wait to announce features until you’re at least doing Closed Beta or Open Beta testing?
This is just throwing another un-released feature onto the pile.
Or at least, I don’t know, move off Canny or move towards something that allows a little more coherency or transparency with the state of things?
Maybe this is all just me being jaded because of what happened with Udon 2. I’m just tired of seeing cool things dangled in front of my face but then being entirely demotivated to create anything since they don’t get released.
2 Likes