Skinned MeshParts are live!

You have to look at the joints themselves. Skinned mesh parts eliminate seams. 3 examples in that picture:

  1. The gap on the knees and shoulder go away, because the joint now bend.
  2. Bends like the elbow look more natural and curved.
  3. The bottom of the jacket is no longer covered by leg.


But that isn’t “realistic”, so why would they change it?

The “new” is on the left, so they changed it to be more realistic. Not sure I understand.

1 Like

I have gotten my first tool attached and one working animation. No videos yet, as I need 3 animations to show it off.

From a technical standpoint, this is what I did. I will experiment to see what steps I can eliminate:

  1. Built the tool in blender, separate file.
  2. Appended the tool to my character’s blender file, and animated it. (same origin as chracter file)
  3. Imported the entire model, with tool, into Roblox.
  4. Imported and saved the “with tool” animation. Set it as default run.
  5. Moved the tool parts to the starter character (this step is important for me. The tool must be separate from the player at some point)
  6. In the Motor6D that was already there, set Part0 to the starter character’s HumanoidRootPart.

This method worked, but is not ideal. I do not want to measure the origin of the tool every time. I will try other methods.

1 Like

What are you trying to achieve with the tool? Are you trying to make it the same as any roblox tool or are you trying to have an animation that moves the tool around your characters body aka animating the weld(or hinge) between the tool and character
If you are trying to achieve the later then I would suggest creating another bone blender for you rig(name it something like grip)make it parented with keep offset, and go into weight punting and remove everything from that bone. Then animate that bone in blender or roblox as a action priority with only the keyframes for that bone. Put a hinge constraint between the part RightHand and the grip bone. For your animate script use a tool.equipped function to play it(on a loop) and a tool.unequipped function to remove that animation if the only keyframes that you have on the animation are the ones for the grip bone than it will overlay with your other idle and movement animations.
I honestly am not very good at blender but for tool animation you would want to add a constraint to align the tool and your grip bone together(parenting?!?! or a weld-like constraint) then you can rig your tool in blender and actually see how it is the character and tool fit together.

1 Like

What am I trying to do with the tool? All of the above.

In the left hand, there will always be a source of light, or nothing, depending on whether the player has entered the dungeon.

In the right hand, I want a normal tool. I can code this if I have to, but it sounds like there are changes coming that will make this a lot easier. I’m willing to postpone any efforts here for a while.

What am I trying to do right now? Restore the left hand to full functionality.

  1. Left hand starts empty.
  2. Player touches torch on the ground, torch moves to left hand. Animation changes.
  3. Torch, when clicked, ignites and produces light. When clicked again is extinguished.

I have run across a few problems in doing this.

First, when I run the game, the script parented to the mesh part does not copy over to the player instance, and subsequently, does not create a ClickDetector. Thus the torch cannot be lit with script. This is possibly an old issue. I would not have seen this before, because previously I could just weld the torch to the lefthand after the game is loaded, and everything plays nice. I’m still trying to perfect how to do that with a skinned mesh… and here we are! :slight_smile:

The other problem is that some things are (simply put) not skinned meshparts… They have their own rules. Even if I get that script transferred over, the actual location of the ClickDetector will be the original location of the torch. And then there’s this:

To me, it seems like some of the problems you are having are server/client issues. Try seeing what it looks like on the server. Then you may be able to fix the torch particle problem.
For getting the left hand torch to work, I would suggest having it as a model. Then create a part that works as a hitbox(can collide off and transparency 1) that overlaps all of the parts in your model(weld it to the base part of the torch). Then create a clickdetector under your hitbox part. Create a part that works as a handle under your torch model and create a hinge constraint under the handle and set the part 0 to your handle and don’t set the part1 and turn enabled off(the handle should also be welded to your base part of the torch) .Put a normal script under your torch model and use something like

local model = script.parent
local handle = model.handle
local hitbox = model.hitbox
local fire = —wherever your fire is

local equipped = false
local player

    if part.parent:FindFirstChild(“humanoid”) and equipped== false then
local character = part.parent
model.parent = character
player = game.Players:getplayerfromcharacter(character)
equipped == true
handle.Hinge.Part1 = character.—put pathway to your lefthand bone here
handle.Hinge.C0 =,0,0)*CFrame.Angles(math.rad(0),0,0)—tweak this until
—play grip animation here
if player and clickplayer ~= player then—does not continue if the torch is being held and someone who is not holding it clicks it
fire.enabled = not fire.enabled

that should be good. If you want to be able to unequip the tool then I can help with that, I was thinking of using coroutines to check if the model is parented to a character and binding a clickdetector to keyboard input to drop the torch(not sure if that works)

wrote this all on a phone, it took a while…


The point is not to be “realistic” the point is to have better looking player models and mesh distortion this allows devs to make custom characters without having to break them a part with ugly joints

1 Like

Code is my weakness. This will take a few days to manipulate. I do see some elements I have already incorporated.

Adding this update:
Got Robie’s script to work! The flame follows the rigid part just fine, which means the ClickDetector should now work too. I don’t have anything left to do here but code it all together! WOO!


I could not locate this, so I applied for the Beta Program. I thought I already did, but I found no evidence of that lol. Kind of wandering around blind on this one!

Does it work on the server too?, if not check out my post “Tool Holding Followup” and change the bone to your lefthand bone. Also instead of changing the part RightHand’s CFrame, change it to I a part(I guess you would name it LeftHand and parent it under the character) then just script your fake tool so that it will weld to the part LeftHand on the touched event.
I will probably try to replicate what you are trying to do and include those scripts/techniques

1 Like

TLDR: I would have never thought to look! Thanks!

I’m still getting used to the server side stuff. No, Robie’s code didn’t work over there, but your code was very similar to the original. I switched from a WeldConstraint to a Weld, and when in doubt, referred back to the working code from Robie.

You introduced a “Character.RightHand” when I think you just meant “mesh.” You already have the part positioned, welded, with a Motor6D in place. These edits work on client and server. Thanks again for all your help!:

local Character = script.Parent
local hrp = Character:WaitForChild("HumanoidRootPart")
local Humanoid = Character:WaitForChild("Humanoid")
local RunService = game:GetService("RunService")
local boneparent = hrp--or whatever part of your character that your bones are parented to

local mesh = Character:FindFirstChild("FlamePart")--the name of the charactermesh that you are using
local meshweld = mesh:FindFirstChild("FlameWeld")--the name of the weld between mesh and parent 
local bone = boneparent:FindFirstChild("LeftHand", true)--the name of the bone you want to track

local handToPartCenter = CFrame.Angles(0, math.rad(0), math.rad(-90)) +, 0.5, -0.25) --adjust to align mesh with rig
meshweld.C1 =
mesh.Motor6D.Enabled = false
RunService.Stepped:Connect(function(time, step)--if something errors in here make sure it is the right pathway to that instance
	if Character and Character.Humanoid.Health > 0 then
		local partCFrame2 = bone.TransformedWorldCFrame * handToPartCenter
		local C1 = meshweld.Part0.CFrame:ToWorldSpace(meshweld.C1)
		meshweld.C0 = C1:Inverse() * partCFrame2
1 Like

Ya, the purpose of the “Character.RightHand” was to make it compatible with tools. This is what roblox does with tools: When a tool is picked up, (whatever built in roblox script) search’s for two things, a part named “Handle” which is a descendant of the tool and a Part name “RightHand”, which is parented to the character. If both of those parts exist, then the roblox script is will create a weld under the the part RightHand, name it “RightGrip” set Part0 to the part RightHand and part1 to the part Handle. But all of this won’t happen if the part RightHand is does not exist or is not named correctly.

To any people who have actually looked inside roblox, I’m sorry if I was a bit wrong, this is just my best guess

Personally, I would make a part named LeftHand under the character and track that using a script, that way, I can just the same script in all of my fake LeftHanded tools so I don’t have to modify every single one

Ahh, I see. That’s the difference. I want to keep the freedom of the skinned mesh, and track what happens differently for each tool. For example, a whip or torch I might track just the end, where a sword or shield I would track the whole part. I plan on changing the animation up each time. Might be a problem later…

Hello Roblox Dev community.

It’s exciting to see all the amazing skinning work in progress on this thread, nice job everyone!

Today, Roblox will be enabling a new internal code path relating to skinned MeshParts. This change lays the groundwork for some exciting developer facing features coming soon, but in itself should be unnoticed. That said, there is one known issue that we are hoping won’t impact many developers: if you have added joints to your skeleton hierarchy in Studio, that didn’t exist in your FBX import, they may not deform correctly. If your Studio skeleton hierarchy matches your FBX import, you should be unaffected. We have a fix for this in progress, but we want to enable this new code path without it, so we can stress test it as much as possible and get the new features to you as soon as possible.

If you are adversely impacted by this change, or if you notice any other regressions, please let us know, and we will work with you to resolve any issues asap. Thanks for your support and patience, we couldn’t do this without you!

– Your Roblox Avatar Engineering Team


Is there any possibility of adding support for bulk-setting the positions of Bone objects? An issue with my ocean code stems from how I simply cannot update many bones in bulk due to them being somewhat expensive - I have implemented a lot of code such as frustum culling just to try and mitigate the issue by as much as possible, but I believe a bulk-position setter would be the most optimal approach at the end of the day.


We are using skinned meshes in the game that I linked in the bug report you replied to:

Could this new internal code path be causing crashes on that place if it has skinned meshes?

Could you apply the bone animations in chunks and only enable the animations for chunks within a certain distance of the character, doing this locally might increase performance too.
If you are using offset than you could create a algorithm to determine the offset of a bone(bone.transform) and apply them locally with in a range of the character, you could also use these values to calculate physics of the height of waves, so a part could float on top of a might want to do this with a module script so that the module script could take in other info like if there is a storm or not(waves get taller) or if there is no wind(waves are very flat)
I know very little about actors, but to my knowledge they might help

I’ve already done more than enough on my end. Setting a bone’s position takes 85% of the total update time alone - and I perform a whole summed gerstner wave algorithm per every bone, so you can see how it’s quite expensive.

Oh, well I am no expert but at the top of this post, they featured a wave, and it did not look to expensive so there may be a better way