1Byte Bone Limit affecting material elements

Development Asset Creation
,
1

Hello,
Im coming to you to get clarification/consultation on a rather big problem we are facing now in our project.
We are working on a VR project with extremely detailed characters, there will only be about 1-2 characters visible on screen ever and mostly be viewed fairly close-up.
Our current rigs have 390 bones in the skinCluster. We are also using (or attempting to use) realtime subdivision for the body using the skin material.
The problem here is that for some reason the material elements for the character model skin get split when we import the skinned version.
So We have element0 with skin affecting like half the faces, and element1 with the same shader affecting the other half,
Ive made some tests with different amounts of bones and it appears to be related. Around the 255 bones it starts to split the material element for the skin.
Now If we werent using the realtime smooth I probably wouldnt care too much, but it really breaks the mesh as it is right now.

Im not sure what I want from you guys (devs @ Epic or people that just know the engine and its workings really well)…
Either a technical and detailed explanation as to why you have to solve the exceeding of the 255 bone limit in this particular way (which to me feels quite hacky). I really want to understand the reason in case its not possible to do it differently.
Or the confirmation that you guys can look into this and potentially find a solution that doesnt involve using material element splits to handle 2byte bone counts.

Right now we only have 2 soltuions on our side:
Either try and reduce the bone count by about 130-140 bones to get to about 255 (which I am actually quite tended towards since I kinda like working under limitations like these, but it will take quite the time to optimize the whole rig by those ~35% - time we dont have right now)
Or do a ‘physical’ subdivision of the body mesh (will be around 45k verts then) and just not use the smoothing shader. This would also take some time tho as it will require quite a lot of skinning to be adjusted.

There is a third option which is to just ignore this as of now and just work with the current base resolution model (11.5k verts) and no smoothing applied.

Im happy about anything you guys can contribute here, thanks

-S

2

What in the world are you using that many bones for?

I could see that in the animation rig where controls get duplicated a lot but not in the final in game models.
Are using any morph targets or blended normal maps for subtle details?

To answer as best I can directly: the new verts created on a hardware subdivided mesh do not always weight correctly based on their neighbors especially when they are on a material seam. I don’t know the technical details as to why, but I know its a problem which has been attempted to be solved. One initial fix is to be sure you have crack free displacement enabled on your material settings. That should help, but it may not be perfect.

3

Hey man, thanks a lot for the reply.

We plan to use morphs for the details, but thats really just the details. By that I mean subtle muscle flex action, wrinkling and minor sliding.
For all the broad deformation systems we are using this rather detailed skeleton. These cover large area muscle deformation, volume preservation, low details for contact push, twist volume preservation, etc. etc.
In addition we also have our facial joints in there. Ive made an evaluation and as mentioned I could get rid of some bones, but that would lose us for example any toe details, and such secondary things.

You refer to this inside the engine?

I meant that we subdivide the mesh in the modeling software and copy the skin over from low. But yes, that doesnt turn out good out of the box, it requires a lot of skinning massaging to get the model to look as smooth as the low res with a smooth preview (or turbosmooth) on.

Im only asking for a technical explanation, and maybe (If the gods so desire) an evaluation of the current method of handling large skinClusters.