Moving and resizing small parts causes geometry to lag

[Oseday]

In my cape simulation, it has 1v1v1 wedge parts with wedge meshes in them. I resize the meshes to fit the desired size and update their CFrame. It runs every frame on the render sequence. The parts are located in a model in camera instance. They are local.

Images

When it’s broken:

When it’s working fine:

You can see the issue in the images. It drops the frame rate. It happens randomly for a random duration of time. Every 1 to 20 seconds lasting for 1 to 10 seconds. Nothing else seems to be broken. I’m 100% sure that the issue is not within the scripts math/physics.

Microprofiler when it is bugged. Seems that updateGeometry is the thing that makes it.

I use it in this place, currrently only two people can have it. The bug occurs here:

TEE //: Zakuul Swamps

I believe having more triangles shown on the screen makes it more common to happen? I can’t reproduce it, it’s quite random.

I’ve put it into this place to test on others:

Cape Simulation

In this cape sim place, the bug doesn’t happen. In that place, I tried to put 10,000 parts to reproduce:

Image

and moved myself 100,000 studs up and it still doesn’t happen there.

Specs:
i5 3570
GTX 1060
16GB RAM
Windows 10

[Tomarty]

Setting properties like part.Size, mesh.Scale, color, etc. causes batch updates which can cause lots of lag and delays when set often. Setting part.CFrame is very fast though, so if we could set part.CFrame to a cframe with scaled matrices we could scale and warp parts extremely efficiently without setting .Size. This could be used to do everything from scaling character models, to efficiently drawing size-changing triangles without delays, to animating stretchy foliage.

It would be as simple as doing something like this

local function ScaleCFrame(cf, sx, sy, sz)
local px, py, pz, xx, yx, zx, xy, yy, zy, xz, yz, zz = cf:components()
return CFrame.new(px, py, pz, xx*sx, yx*sy, zx*sz, xy*sx, yy*sy, zy*sz, xz*sx, yz*sy, zz*sz)
end

part.CFrame = ScaleCFrame(partCFrame, sizeScale.X, sizeScale.Y, sizeScale.Z)

Old suggestion that could resolve your problem: http://devforum.roblox.com/t/the-power-of-malformed-cframes/19150

I also suggested this at RDC last year but I remember @zeuxcg saying that .Size should just be more efficient. Maybe setting .Size every frame could transform the cframe automatically so less updates are required; this wouldn’t let us do part warping though.

This is one of the few things that hold me back on roblox. I could animate my character’s height changing at full 60fps, I could make characters squished/shorter, or stretch them in cool ways, I could add skirt physics, animate my character’s pupils better, and just create fluid polished animations for all kinds of things.

[Oseday]

Yeah, I see. I also found this thread:

Event that fires when rendering finishes

Ah yes, changing the CFrame causes the clustering system to use dynamic clusters for moving parts, which have far less capacity… So if you try to force updates by wiggling the parts, that will also proportionally increase the number of draw calls, and no, it won’t solve the geometry generator throughput problem.

in which @maxvee and @zeuxcg said:

@maxvee

It’s not a bug, you are simply submitting more work than the clustering system is able to process. The “there’s no lag” part is because the clustering system is working as intended on a tight time budget. Realtime is real.

@maxvee

Ah yes, changing the CFrame causes the clustering system to use dynamic clusters for moving parts, which have far less capacity… So if you try to force updates by wiggling the parts, that will also proportionally increase the number of draw calls, and no, it won’t solve the geometry generator throughput problem.

@zeuxcg

That’s correct - CFrame currently is the only “fast” property in that you can change it every frame without really heavy code kicking in. Everything else is expensive.

We’re working on a new system that would make most properties cheap to update. But for now you’ll have to live with the limitations of the existing system.