This is great, though is your cube with faced textures a MeshPart or a part with decals slapped on it?
If it’s the latter, I would suggest switching to the former. IIRC Roblox batches it easier if you were to UV map a texture onto a basic rectangle as that’s just one drawcall, but each decal is an extra drawcall.
So, essentially, you’d have one drawcall for all of the parts, but 1 per extra decal, and if you had a decal for each face, that would be 6 extra draw calls per part… which isn’t great. The same mesh with the same texture will be only one draw call for the entirety of the scene.
By the way, how about you try throttling your moving platforms by distance? So, they all update at different rates - something like how you handle fidelity/LOD:
Motor6Ds are even faster than BulkMoveTo by a significant amount. I’m talking 0.001ms per CFrame update.
For every movable part, create a Motor6D. Set Part0 of the motor to workspace.Terrain and Part1 to the part you want to move. The reason we set Part0 to Terrain is so that the Transform property takes CFrames in world space (plus you also don’t need to create an invisible part at 0,0,0 this way; two birds one stone). Then, in your PreSimulation code, instead of updating the CFrames of the parts, you simply update the Transform property of their respective Motor6Ds.
Do you know for sure if you haven’t tried? If there does seem to be a noticeable hit to the physics simulation, then could disabling CanCollide on distant platforms help? I’m not sure if physics simulation is turned off for non-collidable parts moved by motors, so you’ll have to find that out.
Either way I move hundreds of (non-collidable) parts every frame in my game for my instant replay system and it works perfectly, but my system might be less demanding on the physics engine than yours.
Anchored Parts and Parts that are welded are both grounded yes but I do think that welded parts/attached with constraints still have some level of physics processing to them. They do count as physics parts afterall
and based on prior testing ive noticed that anchored parts are way more lenient on performance
Any part that isnt anchored are a part of the physics pool
I see, that makes sense. Then that means that you would be increasing movement physics runtime in return for decreased PreSimulation runtime.
If the increase in movement physics runtime is greater than the decrease in PreSimulation runtime, then the net impact on performance will be negative (slower FPS). However, if the increase in movement physics runtime is less than the decrease in PreSimulation runtime, then that will be a net performance gain (more FPS).
That is probably why it works wonders for my specific case since I’m only moving parts that aren’t welded to anything else, suggesting that the increase in movement physics runtime isn’t as bad for me as it may be for you.
I would still recommend trying this out since there is relatively little overhead in terms of coding with using Motor6Ds this way. Worst case it will be proof that this doesn’t work. If you only had to move 500 individual parts per frame with no welds then I’d say absolutely use motors. I figured it might help since directly updating the CFrame of a part is about 20 times slower than using a Motor6D.
I think the benchmark is unreliable because of the table operations being used. You don’t have to clear the parts or CFrame list - they get GCed automatically if not being used; and, nevertheless, the CFrame list can be written over while the parts table stays the same if the number of platforms never changes (also i believe it’s faster to directly write to indices rather than using table.insert, literally incrementing a variable like index += 1; array[index] = ...))
Transform, for some reason, chugs more. I’m not sure what they’re doing but their parallel transform operation is a larger bottleneck than BulkMoveTo, and I can confirm this from my own testing and benchmarking via the microprofiler. BulkMoveTo is completely fine for this occasion.
(edit: skimmed to the end so I missed the actual benchmark, but my point still stands. BulkMoveTo is still a very efficient operation in comparison; also reduces the instance count by a solid 1 since there’s no Motor6D being manipulated. also, I’m pretty sure modifying transform fires a CFrame property change event, so in this case I would say the assemblies OP is using have a better time with BulkMoveTo)
I wanted to thank you for your help, my project is now saved and i can consistently run 200+ fps, though all my meshes are now 12 vertices cubes with surface appearances
