Efficiency of Align Position / Orientation vs. Lerp

Help and Feedback Scripting Support
#1

Hello all!

I’m working on a pet system for a game w/ a partner. I’m currentely in the dilemma of the performance benefit / change of using the Align Position and Orientation instances for each pet, versus just using a Lerp function.

While I know it’s generally looked down upon, I don’t see any real FPS differences when testing until I reach about 1000 or so pets. In order to amplify the potential performance decrease, each pet also has 6 decals, 1 for each side.

Realistically, there wont be more than 400 pets in one server. Is this something to be worried about? Besides this, there won’t be any other server-heavy code.

Here’s the current code I have;

RunService.Heartbeat:Connect(function(dt)
	for i, player in game.Players:GetChildren() do
		if player:IsA("Player") then
			local char = player.Character or player.CharacterAdded:Wait()

			if char:FindFirstChild("Pets") then
				local playerPetsFolder = char:FindFirstChild("Pets")

				local columns = math.floor(math.sqrt(#playerPetsFolder:GetChildren()))
				local offset = Vector3.new(-columns / 2 * spacing + spacing / 2, 0, 4) 

				for i, pet in playerPetsFolder:GetChildren() do
					i -= 1
					local x = i % columns
					local z = math.floor(i / columns)
					pet.PrimaryPart.CFrame = pet.PrimaryPart.CFrame:Lerp(char.HumanoidRootPart.CFrame * CFrame.new(offset + Vector3.new(x, 0, z) * spacing), 0.05)
				end
			end
		end		
	end
end)
#2

I would use CFrame (Lerp) if the Pets aren’t supposed to be interrupted by physics.

1 Like
#3

If the game can still run with 2.5x the maximum realistic amount of pets in a server, you should be fine.
But Lerp() shouldn’t be too expensive to use.

Also is the script server or client sided?
If it’s server, handling all the pets on the server might cause some minor freezing issues if the server FPS gets low.

#4

Script is server sided.

Max pets in a server will be around 200, I got it wrong in the post.

I only see FPS issues on the server at around 1200, although I can see it becoming a problem in the future when I try to do other server things. I guess we’ll see :slight_smile:

Edit: I’ll also likely add an option to disable rendering of other pets to the game for lower end devices

#5

Alright.
Had a lot of issues with server replicating everything to clients when I was working on my game so I had to find some workarounds.
But 1,200 pets being looped per frame is actually insane. Roblox memory might not be that bad after all.

#6

You could run the pets on the client and have invisible blocks on the server acting as the Hitboxes and just stop the code and delete them when the players get too far away. I believe this is what Pet Simulator 99 is currently using I COULD BE WRONG.

#7

Yeah, PS99 uses client sided pet replication since you can disable the viewing of pets.
It was a pretty nice upgrade.

1 Like
#8

Yeah, I’m not really sure how it works, but I won’t complain :laughing:

I do have to wonder though, what is the difference between using this and something like the BodyMovers (alignorientation, etc). I mean, is this not just doing the same thing but instead of doing it in the shadows of the untouchable functions, it’s doing the same?

#9

Sorry, I don’t really understand.

Are these hitboxes used for the other players pets, or solely the players?

#10

I mean it doesn’t hurt to use them it’s just their quite buggy during certain situation since they are unanchored parts being moved by physics.

#11

In terms of using AlignOrientations or Lerping?

#12

Every pet. Have a coroutine run code on a pet hitbox (so you can always stop it anytime) and then the client just runs the animations, and effects.

#13

Alignorientation. Lerp uses CFrame to move parts, while alignposition/orientation uses the physics engine.

1 Like
#14

Huh. That’s not a bad idea.

Might be abit overkill for my situation, but I’ll keep it in mind.

#15

So alignorientation uses Roblox physics instead of scripts I think.
And server sided physics is (usually) literally detrimental to memory usage.

Oops, Lakota already answered it, mb.

1 Like
#16

This is partially correct. While it doesn’t exactly cause the server to lag imagine having to send like 200 mb of data to the client and apply it instantaneously at once. The main reason for Servers Crashing due to physics is having to send all this data to clients

1 Like
#17

Ahhhh OK that makes sense now. I forgot a lot of the black magic which is Roblox physics, so I’m trying to touch up on it now. I assume this could become a problem in the future if I was to have a few hundred pets in the game, all moving at once. I’ll do a little stress test tonight and see how it pans out.

(Ofc I plan on doing the animations, effects etc on the client)

#18

This is especially true if players are running on mobile networks or slow providers.

1 Like
#19

I think you should probably use Tweens/Lerps (Whatever your more comfortable with. I support tweens since their easy to use and have worked for all my projects)

Also. Instead of just going through all the players, and then going through every single players pet. You should just make movement and stuff synced when the pet is first created with a Coroutine. And then when it’s deleted, you can just close it.

#20

Yeah, so a little bit more on Roblox physics and server stuff:

Setting NetworkOwnership for an unanchored part to a player makes the player responsible for calculating physics but the server still has to replicate to all players (usually my go-to)
-also BodyVelocities and normal physics will be smoother on NO’s client view and rougher on other clients’ view

Mass of unanchored parts without NO or NO as server will kill the server :skull:
(Also you can only set networkowner to unanchored parts on the server so it doesn’t really apply here)

Also try to reduce functions that leak memory or the server will degrade over time and eventually crash.