Just something to be aware of before fully releasing the feature in every game…
What I recently experienced in Studio:
While having the cage mesh beta feature turned on, resizing the animated skinned mesh custom rig broke the animation (Mainly for rig with more than 1 part; the bones moved, but not the model). Turning on this feature also broke some current skinned mesh custom rig (mainly for rig with more than one part; some parts are not where they supposed to be). Turning off the cage mesh feature fixed the problem.
Hi!
Ever since Skinned mesh was announced as studio beta last year, I’ve been making a skinned clothing specifically for my rig.
It basically works the same way as how layered clothing works (only 1 layer, though) where i have a clothing mesh that covers the s1 rig.
My problem is, I saw somewhere within this post that cage deformer will eventually get a feature to hide vertices under other vertices, which I would like to take the advantage of.
With my already established clothing system, how would i apply this?
It would be nice if there was some sort of slider to manage how much deformation is brought to wraplayer, which I can then make it to 0% to not deform but still take the advantage of hiding vertex.
Sure thing! The issue has been mostly resolved through my own restructuring as explained in my earlier edit, but here’s a look of what it looks like in the explorer.
Some relevant implementation info:
The custom avatars are composed of sections of different meshes all created using the same bone structure standard. They’re then swapped in and out to create custom outfits combinations.
The head and hair are dynamically placed by a script to hover over neck bone.
The entire rig is fully client side
The RootParts are anchored as the character uses custom physics for navigation
And as you can see from the explorer view, it uses an AnimationController
I’m having a similar issue to this, The current rig I displayed is a bit outdated so I’ll have to do testing with the updated rigs but here’s a comparison between disabled and enabled.
I don’t think realism reduces the blocky identity of Roblox. If anything, I think it gives developers reason to be even more proud of their work. Features like this are not forced–spawning in a default R6 rig will not come with fancy meshes. It is still up to the developer to make use of these features. And when they do, it provides shock value because people will look at a Roblox game and think, “wow, I thought Roblox was a lego game for children, but they can have graphics like this? They can have models like this? Games like this?” To me, the games Phantom Forces and Sound Volblox gave me these reactions. I didn’t realize the same platform that contained Build to Survive the Zombies could also be used to create such a unique FPS game. I didn’t realize that the legos used to make Survive the Disasters could also be used to create a visually stimulating and interactive rhythm game. So when developers start making use of these new features and create even cooler stuff, I believe that that adds pride to the Roblox developer community, because people will always recognize Roblox’s blockiness and be able to contrast that with games today and upcoming.
So using the method he used fixes it during playtesting but I’d have to assume that’s to animations overriding it but when I’m in edit mode it kind of stretches it out in height and squishes the legs together
I dont really see the problem in migrating from the blocky roblox style, there should be an option for realism if the reputation of the platform wants to improve, too.
Will the properties of WrapTarget and WrapLayer continue to have script write access restricted after release? I’d like to manipulate these values ingame for realtime effects
Generally mesh properties (including MeshPart.MeshId) are restricted for a good reason: Expensive information about the mesh’s use in context is pre-computed and saved when set, which would make those properties problematic to set in a real-time context anyways.
I’m also encountering some weird issues with beta enabled. When using weld, the problems described above occurs where it uses weld’s c0 and c1 property instead of the origin set in Blender.
Moreover, when I use WeldConstraint, I get this rather horrendous result: https://streamable.com/5f8uvm
Wow, I honestly can barely tell what I’m looking at, I’m not sure if I should be impressed or concerned.
One thing that I can’t quite figure out though, does this serve to make objects, uh, “bendy” if you will? If it’s just pre-set deformations I can’t really see the value of not just pre-making the crushed versions of things in Blender or whatever other 3d modelling program of choice ahead of time.
Definitely could’ve phrased this better if it wasn’t so late at night in this time zone.
Is there any sort of timeline to the release of this feature? We’re not actually using it directly, but enabling the beta feature seems to fix other issues we’ve had with mesh deformation. I’m assuming that whatever bug we’ve been encountering was fixed in the core code of this feature, but isn’t live in experiences yet.
After playing around for a while, I found out that the problem was on my end where I didn’t set the cframe / position of the skinned mesh to the root part with bones parented before setting p0 and p1 of weldconstraint, which resulted in this visual glitch.
I do, however, hope that this behaviour will be differed / rolled back because I would rather not go through a process of finding perfect cframe so the clothing and object meshes are in correct position, in favour of utilizing the position property set within 3d software like blender.
