How can I remove a model without causing lag?

Help and Feedback Scripting Support
#21

That was one of the only solutions I could think of.
Another way of handling this lag is by allocating a table for each model, and when a child is added/removed, update the table with that information. Since you aren’t calling GetChildren() on a model, and the table is allocated before the model has been loaded or etc, you can then use a for loop to delay each destruction of children.

for Index, Child in pairs(AllocatedChildren) do
    Child:Destroy()
    if Index % 10 == 0 then
        wait()
    end
end
#22

What would AllocatedChildren look like?

#23 
local AllocatedChildren = Model:GetChildren()

Model.ChildAdded:Connect(function(Child)
    table.insert(AllocatedChildren, Child)
end)
Model.ChildRemoved:Connect(function(Child)
    table.remove(AllocatedChildren, table.find(AllocatedChildren, Child))
end)

This is a method I use a lot to not lag everything out every time I want to alter a child.

#24

Yeah it’s been done before using CFrames, To add on there is a community resource for this, the solution is to not actually delete the model but move it far away so Roblox doesn’t actually render it I believe.

#25

I’m firing a remove event with a part to remove (don’t worry, already exploiter proof. this is for a food placement/removal system)

Would this work if I just did …?

for Index, Child in pairs(model:GetChildren()) do
    Child:Destroy()
    if Index % 10 == 0 then
        wait()
    end
end

Thanks!

Also, would it cause less lag if the model was moved away before removing all the parts?

#26

Probably, what kind of lag is it? FPS lag? Or ping? You should be fine if it’s just FPS lag - the latter, I am not entirely sure.

#27

I’ve implemented it and we’re receiving the same amount of lag. Just a major FPS drop, about 3FPS for most ppl.

#28

What if you tweened it to a farther position then? Does it still do the same?

1 Like
#29

I’ll give it a shot and get back to you.

#30

Might reply late since I"m working on a project, but I’ll promise to reply.

#31

Are you looking to reuse this model destroyed?

#32

Nope.

#33

Just an idea, Maybe you could union some parts that are not in direct reach of the player to reduce the part amount?

Edit: Don’t forget you can’t union different materials

#34

I am just making a wild guess, could you try making the parts transparent, also in your loop you could add a good wait time probably to make it better.

Anyways I am just guessing what can be causing it, as there isn’t really any code you have provided in the post.

#35

I don’t believe that it would cause less lag if you moved it away, since I’ve tried that with my image rendering program and it lagged the same.
If you did use :GetChildren(), there would be a stutter before removing the model’s parts, which is why I did my method of the children table.

#36

I’m afraid OP has already attempted that.

1 Like
#37

You could delete a few parts at a time and wait in between. Like this: GetChildren() on the model, Destroy() x amount of those parts, wait(), Destroy() x amount of those parts, wait() and so on until the model is fully deleted. That way its spread out so that it doesn’t lag. Say you have 100 parts, dstroying 10 of them at a time and waiting would be a lot less laggy than destroying all 100 at once.

I hope that helps, I just thought of that and have never tried it so I have no idea if it works well.

EDIT: This is almost the same as what @Winky_y said

#38

I read somewhere that moving the parts/model to a place that can’t be seen (setting CFrame) is the best way to avoid lag in this circumstance.

#39

OP already attempted that and they still have the same issue with lag.

#40

The reason that I can’t use a :GetChildren is that the model is deleted on request of a RemoteEvent, and there are models constantly being added and removed from the game. For example, the plate removal remote fires with the argument being the plate to remove, then the script removes it.

Already exploiter proof, please don’t mention the fact that exploiters can also trigger remote events.