Special case for point-sized triangles when importing meshes

[Tomarty]

---

Use Case #1

I often run into problem with scaled down versions of character models due to the minimum part size limitation of 0.05:

To work around this I need to add invisible point triangles to a lot of accessories/decoration to increase the bounding box size. With a larger bounding box encompassing the mesh, I can resize it while staying above 0.05.

As you can imagine, I need to do this for a lot of meshes and it’s a waste of time. It’s an especially difficult limitation to work around when developing customizable insect characters.

At the very least it would be nice if that extra bounding box triangle didn’t affect performance. It’s important that these triangles aren’t discarded entirely, because there are valid use-cases for needing meshes to line up in specific ways. It’s also important to note that these parts are purely graphical, and the part size limitation of 0.05 only makes sense relative to parts that need physics.

---

Use Case #2

For my terrain system I decided to cut back on the number of triangles by switching over to MeshParts.
My system processes the mesh to optimize for special concave cases to reduce the number of parts, but it still needs to render up to 14 triangles (actually 18 triangles according to the performance tab) on the underside of terrain to draw a single triangle:

I go into more detail about how this works and why I decided not to use smooth terrain in this post:

What are you working on currently? (2020)

Working on a massively scalable terrain editor. It stores binary mesh data in StringValues and only loads nearby data, which prevents detailed maps from lagging in studio. [image] I still need to design a custom selection system and tools for material painting and editing geometry. The hardest part was making it so a triangle/quad can reference vertices defined in other chunks: Because the geometry is so low-poly, I plan to add a lot of triangle-specific details that load locally …

So I need to create a MeshPart with just 1 triangle that has reliable WedgePart physics. I tried 3 approaches:

MeshPart A’s physics did not work at all, and the bounding box centered around the triangle. MeshPart C looked like the best option because the back face doesn’t render, however, C’s hull physics is sharper than I want, and could cause small characters to fall through the MeshPart’s edges. I really need B’s collision behavior for my use-case. To work around this I saved MeshPart B and MeshPart C to .rbxmx files and manually copied the PhysicalConfigData data from B to C.

Engineers have made it clear that you shouldn’t rely on this because physics data could be re-generated in the future, but the current physics data that gets generated doesn’t work or is poorly optimized most of the time. Often I just want a slightly better approximation than Box, or simply don’t want my save file to be huge and affect performance with complex collision data. Anyways, I’m careful to only copy physics data between MeshParts that share the same bounding box.

This is great, I have a WedgePart alternative that uses 1 triangle and has correct physics. The problem is that according to the graphics performance tab, each MeshPart still has 2 triangles even though one of them is just a point that’s used to get the correct bounding box. I created 10k of each part and measured the triangle count in the scene:

I would like to be able to define the bounding box of a MeshPart using point-sized triangles without the client trying to render them. MeshParts still use about 1/10 the triangles WedgeParts did for this use case though, even with the infinitesimal triangles there.

---

Here are some other use-cases for controlling MeshPart bounding boxes.

• Sharing or copying physics data between similar meshes by manually copying PhysicalConfigData between within a file. This isn’t ideal and won’t necessarily be supported, but there isn’t any other way to fine-tune physics data.
• Changing the center of the bounding box to equal a pivot point so that the part can be cframe’d efficiently without needing a ToWorldSpace operation.
• Creating specialized meshes where all points are coplanar and controlling where that plane is relative to the part’s size.

[PeZsmistic]

This specific requested feature sounds like a hack. You should focus more on feature requests for what you’re using this hack to accomplish, because this specific feature will never happen.

You want to be able to resize bounding boxes, size parts smaller than the limit, set pivot points / origins, and change meshparts’ collision mesh apart from their render mesh. These are separate feature requests that should not be implemented via enabling a hack by adding a gross special case.

[Tomarty]

Pretty much everything I’m requesting is already supported without adding anything gross to the developer experience. I simply want point-sized triangles to be removed from the final mesh so it doesn’t try to render them, without affecting the bounding box. I really can’t imagine any other way for defining bounding boxes on specialized meshes.

You are correct that working around the part size limitation is a gross hack. I would really like to see this addressed separately, but I think it’s reasonable to request that these tiny triangles don’t count towards the scene’s triangle count.

I would also really like to see advanced tools for manipulating physics data on meshes. Even something as simple as a slider for changing how approximate it is, and a supported way to copy data between similar meshes. I’ve been hiring 3d artists to work on structures, and I’m worried the physics data will bloat the game:
(This is a physics test so it’s not textured yet)

I really wish I could go in and start combining the convex shapes to get a rough approximation, or specify that the object will be anchored and doesn’t need accurate mass. I’m also required to upload meshes with manifold topology to get the best physics, when performance could benefit from cleverly removing triangles in certain places. I could also save a lot of memory and add more variety if MeshParts had a mirror property that mirrored the graphics and physics data.