Be able to use MeshPart BrickColor in conjunction with textures with transparency

As a Roblox developer, it is currently very difficult to use MeshPart BrickColor/Color in combination with a Texture with transparent holes. Currently, the color of a MeshPart only works if there is no texture and colors the whole part. It would be really cool if you could leave part of your texture transparent, allowing the color of the part to show through (and the part’s material too). Currently, any parts of the texture left transparent are just filled with white.

If Roblox is able to address this issue, it would allow for on-the-fly dynamic color changes of specific parts of your mesh. This would save time if you have meshes that have certain highlights that need to be done in many different colors. There’s probably some pretty neat things you could do with it too that I haven’t even thought of.

Before posting, I just found a post from over a year and a half ago addressing the same concern. It seemed there was a few hacky methods people discovered that already make this behaviour work, but it still hasn’t been implemented properly.


Mostly useless now

I’ve been using the workaround in the link above where you use an R15 Humanoid and name the parts the same name as body parts of a humanoid (Ex “UpperTorso”). It was working fine until I needed to have multiple MeshParts within in a model, which is where things start getting ugly with some really weird behaviours.

  1. To start, one annoyance is that I have to choose a body part name that has the same CanCollide value as what I need. So if I need a MeshPart with no collision, I have to choose a body part from the arms or legs, and if I need a Meshpart with collision, I have to choose UpperTorso, LowerTorso, or Head.

  2. You can only have one of each body part name in the same model, otherwise only one of the parts will be correctly textured. This limits your number of MeshParts, especially in conjunction with the restriction from my first point. You can work around this my putting another model with a humanoid within your model, but that that’s getting even more ugly.

  3. For some reason, LeftLowerArm, LeftHand, LeftLowerLeg, LeftFoot, RightLowerArm, RightHand, RightLowerLeg and RightFoot (8/12 of the non-collidable body parts) don’t texture correctly if there are other “body parts” in the same humanoid model. However, those body part names do work if they are the only “body part” in the humanoid model.

Currently, I have a model (on the left) that contains 5 MeshParts with textures that have transparent sections to allow the part’s color to show through for certain areas. All 5 of these need to be non-collidable, but due to the issue above, there’s only 4 non-collidable “body parts” that will texture properly when in the same model. The model on the right shows the correct texture for the one that’s not rendering correctly in the first model. It has the same name, “RightHand”, but “RightHand” (and 7 others) only render correctly if they’re the only part in the model.

I could still work around this by placing another model with a humanoid inside the first model, same as I said in point #2, but all of this just feels really gross.

The thread I linked to also had another workaround that involves having 2 copies of the meshpart, one with no texture and the underlying color you want to show through, and the other with the texture and a 0.02 transparency (which oddly enough makes the transparent part of the texture become completely transparent, while the rest of it is still 98% opaque). However, in my scenario, these are MeshParts that will be moving around, and each player will control one of these models. Doubling the amount of moving MeshParts sounds like unnecessary lag.

Can we pleeeeaaase just have transparent textures work without having a Humanoid, so I can name the Meshparts whatever the heck I want, be able to properly set whether or not the part can collide, and not have models with a useless humanoid inside another model with a useless humanoid.

EDIT 2: I’m an idiot. yet another workaround that was suggested on this thread is actually not too bad.

I misread the instructions when I originally tried this and wrote it off as a solution that doesn’t work.

Regardless, would still be nice if I didn’t have to do a “work around”