Decomposition Geometry API

The Issue…

As a Roblox developer, it’s currently too difficult to figure out what makes up an object in the world programmatically, specifically geometry. When working with custom collision systems, or in general, anything that requires a sufficient amount of geometry data, there is no reliable or in-game way to figure out what that actual geometry is. More specifically, it’s hard to know the geometry of meshes, terrain, and perhaps unions too – typically it is trivial to find what makes up a “part” or a wedge but not meshes. It might be possible to come up with some solution that works on simple meshes but it’s not trivial when working with non-simple meshes. I have yet to find a practical and efficient enough way of doing so. Most potential solutions are just hacky and unintuitive. For example, one might be able to download mesh data externally, parse it, then send it to a game/studio session through the HttpService. However, that would of course require meshes to be saved to the library as an asset, and in many cases isn’t at all practical. In very specific cases maybe you could also utilize raycasting, but certainly it wouldn’t scale well and would fall short of the actual solution.

Proposal


In short, it would be quite helpful if there was API or a set of methods that would help us achieve this. In a theoretical sense there could be read-only methods of the base part class that would roughly look like:

BasePart:GetAllSurfaces() --- array: return all surfaces/faces of part
BasePart:GetAllVertices() --- array: return all vertices of part

it would essentially give us some information on a wedge, parts, and in particular meshes. These methods would allow us to read Mesh data at runtime. Which would be extremely useful in many different use cases.

Use Cases


There are quite a bit amount of use-cases for the proposed API–but here are some I’ve initially thought of:

Let’s say I were needing to make something–where I wanted to overlay a part on a meshes, surface how would I do that? Or more specifically, how would I do that efficiently or without troublesome workarounds. If I wanted to make a holographic effect of a mesh how would I achieve this? How would I achieve something like this without using tons of ray casts? Well, the methods I proposed above would in theory make it quite easy to do and allow it to be done with little to no manual effort.

Maybe a better example would be for intersection/collision tests. The touch events and GetTouchingParts are nice and all but when wanting to create/use a custom nonphysics-based algorithm for this and making it accurate for meshes is where it gets difficult. The proposed API would also make it much easier to do this as well.

Right now, my personal use case, while definitely niche, is that I need to get some info on meshes for custom navigation mesh generation. As far as I know, there is no way to do that in-game or in a plugin. As mentioned it might be possible to use external programs and software and whatnot, but to me, that’s pretty impractical. I also could again use ray casting, but I’d prefer not to do that either. it would make it much easier to be able to get info like this using a simple API method.


General Use-cases:

Here are some other use-cases, that other developers have mentioned:

  • Plugins like @iGottic’s Performant Builder would be able to support automatically “manipulating” mesh geometry. Such as a face removing feature. So, In the grand scheme of things, you would be able to break down a mesh and remake it with changes applied.

  • Grappling/placement systems would largely benefit from the flexibility of being able to interpret mesh data.

  • While I did not originally mention Terrian, I think if the feature were to be expanded to include terrain meshes, it would also open up a larger realm of possibilities.

Conclusion


I have a strong feeling that mesh data and other information on the geometry of objects is stored or can be grabbed from somewhere. While I’m not an engineer, I don’t think that this would be too hard or impossible to implement.

Overall i think that this would both improve my development experience and others’ experience as well because it would allow the implementation of numerous algorithms, effects, and such. I would :heart: if it were implemented, thanks!


Older, Related request: (BasePart/Union/Mesh):GetVertices(bool relative = true)

21 Likes

I don’t agree with this - there are a few use-cases for reading mesh data on the client. For example, if I wanted to create a planetary gravity mechanic for player’s characters, I could make it accurate by raycasting down and getting the current mesh surface that the player is over, and rotating them to the normal of that surface. Super mario galaxy does this, and that game has great planetary gravity.

5 Likes

i’m guessing you meant server, if so yeah i definitely do see your point! , the only reason i said server was because of the potential that it might make it easier for people to steal to “steal geometry” . i was thinking, for example, if the client needed to know something about the surface of a mesh, they would call a remote event to get mesh data and cache it instead of being directly exposed to method, but hey i might be over thinking it a little.


i’m also now realizing that if the mesh were ever moved or resized or something, calling a remote event for ever time that happens might be bad, so yeah good point.

Another solution would be adding a Vertex and Polygon class, allowing developers to fully read but also write mesh and hitbox data. They’d also need to add a Hitbox class where the vertices and polygons would be parented to

1 Like

If someone is dedicated to stealing your geometry, it’s much easier to just grab the asset upon loading since the format is well documented. This would be much more useful on the client as this isn’t exactly a simple operation, so performing it on the sever, when it is only required for one client is a waste of CPU time and bandwidth. Another issue with your proposal is that collisions are based on convex surfaces, not vertices, so it would return the mesh’s model data, not its collision.

2 Likes

Huh, didn’t think of that, yeah another good reason why the methods shouldn’t be limited to the server, i was only really saying that it could be because it was an “at least” thing, if for some reason it couldn’t be exposed to the client.

yeah, the whole collision fidelity thing was a last minute thing i was thinking about, i might end up removing it from my request or less likely adding a method to return the convex surface instead.


@gillern That would also be really cool

Note: It’s not necessarily true there aren’t uses for this feature on the client. Sometimes I need to snap instances to each other for building, and sometimes I want to compute the moment of inertia, or other properties. Having this data would be great while Roblox fills in the API (and for snapping objects, we’ll probably get a comprehensive enough API past reading geometry data, since it’s so game specific).

1 Like

Nope, I definitely meant client. :slight_smile:

1 Like

That’s not what I said though – I said “there are a few use-cases for reading mesh data on the client”.

2 Likes

Finding the surfaces of meshes may be possible by downloading assets on a server and parsing them, however this method isn’t possible for terrain. I’m working on building a navigation mesh pathfinder again and it will be very difficult to work with terrain.

Here you will find a issues other developers had while raycasting to even determine the floor in a terrain cave:

Also mentioned in that post is the difficulty in determining good grapple hook positions on terrain. Really the only currently solution I see to all of these problems is reading in the voxel data and estimating the terrain mesh.

2 Likes