Gaps on mesh-deformed model when over a specific stud count on the Z-Axis

[Furbygeddon]

Hello Roblox team,

we are currently working on a roleplaying game with custom mesh-deformed player models. These are then cut to allow for various customization and coloring. We noticed that, around a month ago, the model suddenly started to show gaps that hadn’t been visible before or showed up in Blender. Old versions of the Baseplate were also affected. After trying different things, we noticed that this behavior seems to be related to an engine bug: if the model is anywhere above 1.000 studs or -1.000 studs on the map on the Z-axis, it starts to stretch apart further and further. Our map is very large and detailed, with about 5.000 studs in total. This does not happen on the X or Y axis. Provided are screenshots at the end of the post.

Here are some things we tried and investigated:

Things that didn’t fix it:

• Adding a humanoid doesn’t work
• Running the game doesn’t work
• Change render fidelity doesn’t work
• Changing the model to streaming mesh doesn’t work
• Double-sided doesn’t work

Additional information:

• The X-axis works perfectly fine until over 10.000 or under -10.000
• The same holds true for the Y-axis
• Weight paint has been checked multiple times (and it wouldn’t make sense if the weight is working in the given range, but outside it doesn’t)
• Merging two separated meshes in Blender fixes it, but separating it doesn’t work (separation is required for our experience)

As stated above, our map is 4.500 in size both x and z (5.000 with the upcoming expansion), so we have to rely on it being rendered correctly within the range.
It worked perfectly fine before December and it changed all of a sudden, we first thought it was a weight paint bug, but it seems an update has changed something and no one seems to have posted this issue (we are aware our project is a lot bigger than most games on Roblox currently).

Thank you for your time!

Model over 1.000 or -1.000 on the Z-Axis:

Model within the 1.000 and -1.000 Z-Axis:

Model at the origin point of the map:

Model outside of the aforementioned range:

Expected behavior

[drewbluewasabi (Drew)]

Assuming I understood correctly, this is a normal thing in 3D engines (though it varies a little bit).
It’s called floating-point errors, which happens in numbers with decimals. This effect continually gets worse the further that numbers get from 0, in both directions.
Essentially the numbers lose precision the bigger they get

If you move the meshes out much further, you should see a more severe effect.
Here’s a place that displays this:

Break ROBLOX (Floating Point)

I apologize If this is not the issue you are describing

[Furbygeddon]

Not exactly. If this were the issue, then all directions would be affected equally, but we noticed it happening on the Z-axis much earlier (see numbers above). So something is definitely off with the Z-axis.

[drewbluewasabi (Drew)]

It could just be that precision issues on the Z axis are more noticable but I may be wrong

[Judgy_Oreo (DisplayName)]

You need to attach a reproduction file, screenshots aren’t going to be as helpful as figuring out why the bug occurs, compared to having the mesh and the engineers being able to see it themselves in Studio.

You can DM the Private Attachments group with a link back to this Bug Report, and add a link to your DM in this Report. Only Staff will be able to view the attachments you sent in your DM.

[ReechaLoo]

Hey, thanks for posting your problem. Could you provide the placefile and/or mesh for reproducing the problem?

[Furbygeddon]

I’ve sent a place file via the Private Attachments with a link back to this post yesterday. Has it gotten lost?

[ReechaLoo]

Could you send a link to that DM?

[ReechaLoo]

Never mind, I think I found it: https://devforum.roblox.com/t/engine-bug-on-mesh-deformed-models-cuts-opening-depending-on-z-axis-on-the-map/3440955

[Furbygeddon]

Yes, that’s the one! I tried uploading the blend and fbx, but the site gave me errors upon uploading, even after trying 10 times.

[portenio]

Hi @Furbygeddon, the issue seems to be exacerbated by floating-point precision errors, but we also notice that the seams are also visible when the model is near the origin.

The model also contains many individual parts, which is likely to hurt performance if you have many of them.

separation is required for our experience

If you tell us more about your specific use case, maybe we can suggest a workaround.
Why do you need to separate the model?

[Furbygeddon]

Hey @portenio, let me give you a bit more insight into our experience and project. The model is the player character and is deeply customizable. The parts are colorable by the player, which is why we have to cut the mesh-deformed model up. These cuts are not visible in Blender and are flush even when moved. In Studio, however, the cuts are visible and worsen with the Z-axis position on the baseplate/map. If the model is at or near the origin point, these cuts are almost almost invisible.

As our map is very vast and we can’t keep the model as one mesh due to the aforementioned game feature, we don’t know how else to fix this issue.

For a more visual representation of why the model is cut as it is and needs to be, you can check out the Experience in question. Please keep in mind that it still has an old model but the logic is the same.
https://www.roblox.com/games/11319046321/Lakeside-Tales-Reborn-Fall-Map-Beta

[portenio]

Thanks for sharing, really cool concept and visuals!

Using the file you shared I do see the seams, but they are always visible. They don’t depend on the model’s position.
At origin

At Z=4000

Have you considered using an EditableImage to color the character on a single skinned mesh? This could be a solution to the seams issue, and would avoid splitting the model into 200 parts. This approach could also work if you wanted to have physical parts; you could use the same EditableImage to texture multiple MehsParts. The downside is that EditableImage doesn’t currently support replication, but for your use case you could do this client-side (depending on how many cat characters you expect to have on screen).

[Furbygeddon]

As our problem seems to have been misunderstood and we’ve since looked into different solutions, here is the summary again:

Around December, we noticed that our model and its cuts (separated parts) suddenly started to have extreme gaps, even though we didn’t change anything on the model itself. Around that time, we hadn’t loaded up our baseplate for a while since we were busy with other model-related stuff.

We troubleshooted and figured it had something to do with the Z-axis at -1000 and 1000. The issue appeared on the X-axis but on 10.000+.

In the recent week, we noticed it appearing on the X-axis too, same stats as the Z-axis.

We have checked our model cuts crossing vertexes and they have the same position and they also share the same weight paint value, so it’s a studio rendering thing.

The editable image doesn’t work with our gameplay features, therefore we can’t use this.

If you wish we can send the blender file so it can be looked over, but this doesn’t work with the DM upload feature, as we already tried.

On a side note: The rig and weight paint has now been looked over and remade by a professional with over 15 years of experience and a degree in 3D Modeling. The weights have been checked by two additional team members, as well as the vertexes.

What we hope to gain from reporting this: As Roblox is growing and evolving, so does the developer base. We want to explore and push the boundaries of what is possible and by having such a massive detailed map, we encounter engine limitations. Now with the highly customizable model, this has been pushed even further and currently, there is no better solution that we could think of or find to resolve the coloring per section. Our wish would be that the axis wouldn’t affect a mesh-deformed cut model or assign zones on a mesh-deformed model to color in without the need to cut it into nearly 200 parts, which would be the ideal outcome.

Working with custom player models is a nightmare in the Roblox engine and further support on that front has been incredibly slow. So we have to resort to hacky solutions.

[Furbygeddon]

Also, I don’t know if you misunderstood our problem but the cuts you sent here are intended (image 1), our problem are the big gaps on higher stud values (image 2). Those cuts might not be visible on first sight, but in our game environment they’re extremely visible and therefore we have to delay our full release even further.

[Furbygeddon]

Additional info: We noticed that the gaps also seem to change depending on the model size. The smaller it is, the bigger the gaps. Two pictures are attached to show the difference. The location is the same.
We need the small size for the game to work properly, which has the same proportions as a normal humanoid player character. If we change the size it will break the scaling of the character to terrain.

[Furbygeddon]

Do you have any news on this? Our testers have noticed this as well by now, and no matter what we do in Blender (apart from keeping the model in one piece, which doesn’t work for our game), the issue persists in Studio and the game. It puts a real damper on our big upcoming update.

[portenio]

@Furbygeddon The root cause of this problem is the unavoidable floating-point precision, as discussed earlier. We’ve investigated it but found no Engine modifications in rendering or instance handling within the specified period that would make the problem worse, so we’re confident this is not a result of a recent regression.

Have you considered extending each mesh-part to overlap with their neighbor meshes?
Representing a character with >200 parts is not optimal, so I was trying to figure out a better solution for your case that is actionable. And that’s why I suggested an EditableImage, let me know if you have more details on why you think it’s not a good tool for your case.