VRCHeadChop is useless, is NOT CLEAR on how to use it properly.
complete
BluWizard
- The entire head is shown when the headchop component is added, which should be the opposite.
- Hiding the head weights hides everything else, overriding any other values set (e.g. showing ears, halo or nose)
My issue here is that headchop is meant to scale the head to 0, and then the user can add exceptions. This isn't working at all.
Log In
StormRel
complete
This post was marked as
available in future release
StormRel
tracked
K
Krazen
I fully agree on this. I was hoping for a solution that would be easier to use than constraints, but somehow this is even more confusing.
After reading the documentation 3 times and doing 6 test uploads, I still struggle to figure out how this works and why I am getting the behavior I am seeing.
Scout
Hi everyone,
Thanks for the comments. We're planning to invert how this component works so it can be used to list the transforms you want to see by default. The originally intended way of using this was that the head would become fully visible if you used this component and you would then list the transforms that you do not want to see instead.
We're now aiming to keep the head hidden by default so you can just list the bones you want to keep visible, which will then be scaled back up to compensate. We still want to allow the head to be scaled up for users that would prefer to do it that way instead, as well as allowing transforms that are not children of the head to be hidden.
We'll also be replacing the "weight" properties with scale factors that will hopefully be a bit more intuitive to use, where a scale factor of 1 means the transform uses its original scale, and 0 means it's fully hidden. The documentation will be updated to match these changes.
Seedsy
Scout
Kazy
Scout Will the inverted way allow children of the head to be shown while still hiding the head?
ʙɪɢ․
Scout Thank you :]
I'm glad to hear that we'll still be able to hide non-head bones!
Myrkur
Scout Could the docs also be updated to reflect the components limitations, currently it doesn't mention that the MaxBoneCount is 15, and that should be reflected in the documentation.
Furriest
Scout
bd_
Scout It's my understanding that the head bone is currently scaled to near-zero - am I to understand that Head Chop will change to 1) scale to the inverse of the head scale, and 2) set a local position which compensates for this scaling? If so, how will this interact with transform animations?
Dexvoid
bd_ Yes, by default this component will scale the head to almost zero and then apply the inverse of that scale to child bones to make them visible again. The child bones will also be repositioned to move them back to where they were on the original armature.
Regarding animations, this component applies its affects after animations have been processed, so any animations changing the position or scale of the affected bones should be applied on top of what this component does.
Dexvoid
Kazy That's right - any bone configured to be visible that is a child of a bone configured to be hidden will have the inverse scale of the parent applied to it to make it visible again, while also being moved back to its original position on the avatar's armature.
Kazy
Dexvoid it doesn't seem to be scaling children back up as of 1433 if the child is part of the body mesh.
e: Seems my muzzle was still assigned to its parent Head bone as well as the new muzzle. I had to clear that assignment so it was only marked as Muzzle, otherwise it would get eaten by the Head scaling.
ʙɪɢ․
Just adding my two cents that I personally am glad that VRCHeadChop allows you to specify what gets chopped rather than what doesn't, because it allows for chopping things that aren't just on the head. I think that part of it is great and I don't think this should change.
That being said,
I'm very much on the same page that I'm having a really hard time understanding how to use this component. If I want to keep something on my head in view, but not my head, then my head is getting chopped and taking all its children along with it, leaving nothing left in view. Intuitively, to combat this, I'd think to use constraints to make the object not a child of the head......but isn't this what the component was introduced for? To avoid using constraints in this context?Is the implication that we should keep our heads un-chopped and just look through the backface culling if we want to see objects on our head? That seems really odd to me. I'm not claiming that this issue is implemented poorly or that it doesn't work, I'm just genuinely confused about how we're expected to use it.
b'owow
ʙɪɢ․ I don't think the implication is that they want you to have to look through the culling of your head, but rather that you may need to do some setup to avoid that if you want to accomplish what you're trying to do with the component. You only have to move your head's weight painting to a bone that is an exact duplicate of the head bone and is a child of the head bone. You could leave any existing bones (eyes, ears, etc) in the same place in the hierarchy to avoid rewriting any animations. Then in the VRCHeadChop component, you would select the child of the head bone you just created as well as anything else you want to hide (eyes, ears, etc). This would hide your head mesh from your view. Anything you place directly on the regular head bone would not be hidden (and if you wanted it to be hidden, you could instead place it underneath the new bone you made to avoid having to add more stuff to VRCHeadChop).
In Blender its real easy to make this minor adjustment to your model if you wanna try it (and it's also really easy to reverse this too):
- Select the armature, go into edit Mode, select the head bone
- Shift+D to duplicate and right click so it ends up in the same exact place
- Rename it from Head.001 to something else (if you want, not required)
- Go to the bone properties on the right side and set the parent of this new bone to "Head"
- Go back to object mode and select your body mesh (or head mesh if your avatar has a separate head).
- Go to vertex groups on the right in the Properties area (Green triangle thing) and rename the Head vertex group to Head.001 (or whatever you renamed the new bone to).
That's all you gotta do, and there is no need to edit the humanoid rig in Unity or anything else, and it shouldn't require you to re-do any animations or physbones or anything else.
Kazy
b'owow But if you have any physbones or any gameobjects on the head armature in Unity, those will disappear since the hierarchy changed.
Also if you have anything animating the ear bones, those animations won't work either.
b'owow
Kazy They shouldn't with the way I mentioned. Maybe I'm not explaining it well enough. If you have a Physbone pointing to Armature/Hips.../Head/Ears, that still stays in the same exact path with my suggestion. Any animations that control that bone don't need to be changed either. You don't move any bones that are currently under the head bone over to the new bone.
The only thing that changes is a single new bone is created that is a duplicate of the head bone, and that bone gets made a child of the existing head bone. Then you rename the existing Head vertex group to the name of the new head bone, which moves the weight painting of the head bone to it.
I attached some pictures of how I have my avatar setup. I hide pretty much everything except the nose doing it this way. All the physbones work and I didn't need to change any animations either. Anything put directly on "Head" would be visible in first person, and anything put under "HeadScale" (or directly selected in the VRCHeadChop component) would be invisible. The head weight painting in this example was moved to the HeadScale bone, and having that selected in VRCHeadChop along with the other bones on my head makes the head invisible in first person.
Seedsy
i have to re write a whole bunch of animations to accommodate the backwards-ness of head chop
i was fully expecting head chop to be put this script of the things you DO want to see, thats how my armature is set up to be because i previously used a scale constraint. Head chop script you put on things you DONT want to see in your local view port which is weird and backwards
b'owow
Well, it's called "head chop", not "head show". I think it would be weird and backwards for it to control things I do want to see when it's called "head chop"
The way you want it to work is probably not possible with how Unity processes scale. If head bone is scale 0, then the scale for everything under it is a multiple of that scale. A child object with scale 1 is actually scale 0, because 1 times 0 is 0. Even if you somehow do scale the child of the head bone up, it would not appear in the correct location since the head bone's scale also affects the scale of position transforms of children.
Seedsy
b'owow by default afaik the head bone is scaled to .001 locally so ive been using a scale constraint to scale back up a second bone that holds all the children i want to see in my viewport. maybe they could have a check box like chop this or dont chop this or something.
b'owow
Seedsy that's a good workaround for that use case, though I encountered weird issues with physbones not processing correctly locally for me when doing something similar. You can definitely do what you want to do with the new system, but it does require armature changes as you mentioned. Maybe the devs can chime in on if it's possible to do it the way you prefer, or if not then a technical explanation of why not.
b'owow
Calling it useless because it doesn't line up with your use case is a bit silly. It is very useful for my use case. You state that "headchop is meant to scale the head to 0" but that's not true. One of the main reasons this feature was announced is because the devs unintentionally broke scale constraints on the head with an update. People were using scale constraints to see things like their own snout, which is part of the head. People wanted there to be a way to NOT scale the head bone automatically and instead specify which bones get scaled. This feature fills that goal, though I agree that it could be improved or the documentation clarified a little better to explain the use cases and limitations of the feature.
The way you want it to work specifically may not even be possible without issues because of how objects in Unity scale relative to the parent. The way your head is hidden from local view is by having the bone scaled down to 0.0001 for the local client. What you're asking for means it would need to scale the head bone down to 0.0001 as normal, but then scale the next bone back up so it's normal size (so scale 10000 relative to the head bone to equal a normal scale of 1). It would result in issues such objects under the head bone not appearing in the correct place for you locally, and also physbones glitching out.
For now, you could work around the current limitation in a way that doesn't require constraints at all. It would require some Blender work and possibly for you to update the paths of any animations affecting any children of the head that you want invisible. Open your avatar in blender, duplicate the head bone, parent the duplicate bone you just created to your head bone, rename the head vertex group to the name of the new bone (to move the weight painting), and then reparent any bones that are weight painted to things you want to be hidden to that new bone you created. You would have to update any animations in unity that affect any children bones of the head bone that you moved to reflect the new path. This would allow you to use headchop to hide everything on the new head bone (which will now also hide your head). Anything you put on the "normal" head bone will not be scaled.
Furriest
b'owow Understandable solution, unfortunately parent constraints don't work on Quest [Which means your solution is not cross-compat for the time being], which is what [I believe] VRCHeadChop would've also helped out with.
b'owow
Furriest My proposed solution wouldn't use any constraints at all. When I say parented, I mean in the hierarchical sense, not as a constraint. The duplicate head bone with the head weight painting moved to it would be parented in blender to the regular head bone (in other words, it would be underneath the head bone), and so it would move exactly in sync with the humanoid head bone - no constraint needed.
Adeon Writer
Headchop needs more time in the oven, most people want the normal live behavior of the head going invisible but not hiding specific child bones (pony tails, rabbit ears, etc) of head needs to be streamlined and easy. This most common use-case is not possible without changing the armature, which is the kind of setup this feature was supposed to avoid.
BlueTera
Yea it needs some more baking.
Furriest
Was in deep debate in #open-beta, found these two with BluWizard, some worlds use avatar replication like Avatar Testing Chamber which create incompatibilities such as seeing your entire face.
Load More
→