True Custom Decomposition Geometry

(ignore the first part of the post since it doesn’t apply to most games, but it helps demonstrate my point, just the bottom is the part thats most important)

Default, hull, and box are nice and all but sometimes they have limitations.

Take these three columns for example, they are all one meshpart which is good for optimization (since in our game the entire map is moving)

Default physics work fine, but default physics probably triple the polygon count and the physics itself creates lag

Changing the physics setting to box wont work either because now you cant walk in between the columns

What would best is if we had the option to arrange parts and make those the physical properties

Now my one meshpart could look like this, its physics are optimized and are just as functional as default physics.

I tried looking other posts like this, but without any luck. I do remember seeing one post about someone who was making a pipe for a marble game. Although the marble looked like it would fit down the tube, the tube (even with default physics on) became constricted by the physics. There are also tons of cases where doorways wouldn’t work because the physic’s limitations

and CSG/Mesh terrain too gets messed up by the physics.

Also, look at how inefficient this decomposition geometry is, making it hull or box wont fix it

Ive also have come across instances where my parts dont even need physics. Changing them to box and cancolide=false is alright, but no physics would be best.


How do we know for sure that one meshpart with 3 rectangular hitboxes is more efficient then 3 meshparts with 1 rectangular hitbox each?


Maybe for most games its not, but our game (roblox titanic) has the entire map moving. Less parts would be better. Plus for games that transition in maps (like minigames or fps games), they need to load a bunch of parts and unload a bunch of parts. Less parts would help speed up this process.

It also would have other uses as well, such as fixing the physics doorways and CSG/Mesh imported terrain

This floor here for example is really screwing us over, we got extremely lucky in that its not any worse

(this is default physics)

Have you profiled the expense of calculating a part’s physics over a part’s interaction with other parts? As far as I can tell, each of those colored boxes act like a single part in terms of expense. The decompositiongeometry in the first post would have on the order of magnitude of 50 parts worth of collision calculations as opposed to 4 collision calculations for a meshpart and 3 invisible regular parts.

Can’t you just make your own collision boxes via parts? Like the way you did the demonstration?
Edit: Oh, number of moving parts is a problem.

Yeah the first part of the part can probably be disregarded, it probably doesn’t make a difference whether its 3 parts with box physics or one part with 3 physics blocks. But like I said at the bottom and in the last reply, this can be used to fix problems with current physics

yeah, number of moving part for me is a problem. For most games it probably wont make a difference

What is the problem with current physics, aside from the decomposition engine not understanding the important features? What is broken? It seems what you want is to be able to make custom decomposition geometry.

This is whats wrong with the current physics

The physics dont meet the correct specifications, and I know Im not the only one running into this problem. Complete custom decomposition or maybe a more accurate physics system would fix these issues.


It’s certainly not broken, the computer is jut having a hard time reading your mind.

Which is why complete custom physics would be a great way to force the computer to read my mind.

The most efficient way to deal with those 3 columns would be to import the meshid into a SpecialMesh then use three invisible Parts for the hitbox.


Better yet, one of the hitboxes is the part with the columns mesh in it.


The single mesh uses ~3x more memory than three meshes because the geometry of a given mesh(part) is only stored once in memory regardess of how many times it’s copied.


if the parts don’t need to be dynamic, you can just disable collisions for the meshpart and put invisible parts, with collisions enabled, on top of that meshpart. if it needs to be dynamic, then weld the meshpart to the invisible part with collisions enabled. setting custom physics hitboxes like this would involve about the same amount of work it takes to just put an invisible part on top of the meshpart, so i think this workaround would be the best solution.

as for lowering the part count to optimize your moving map, one interesting way to optimize large/complex moving structures is to have every part welded to a singular base part, which acts as the point for CFraming, applying body movers, etc. for whatever reason, complex hierarchal weld structures (a welded to b, b welded to c, c welded to d, d welded to e, etc) are more expensive than simple ones (a, a2, a3, a4, a5, a6, a7, a8, a9, etc all welded to b)