PartCache, for all your quick part-creation needs

Sounds like something that would depend on how your code is all setup, but I think use of the Touched event and Anchored property will help you with that.

When you put a trail on the part you can see it being sent down and returned. How would you fix this?

I had the same issue with the intended use with fastcast. My solution was to disable the trail when the bullets are put away and reenable them when they spawn back in.

Edit: Here is how it goes which uses the fastcasthandler approach. I had to coroutine a yield to guarantee the bullet gets moved into position then the trail activates but turns out it’s not that necessary just there if it happens.

Fastcast fire function which enables the trail if it finds one
		local fastcastHandler = {
			fastcast = castComponent,
			velocity = bulletVelocity or 1000,
			ratePerMinute = ratePerMinuteFire or rpm, --second per bullet
		function fastcastHandler:Fire(origin, direction)
			local activeCast = self.fastcast:Fire(origin, direction, self.velocity, fastCastBehavior)
			local bullet = activeCast.RayInfo.CosmeticBulletObject
			local trail = bullet:FindFirstChildWhichIsA("Trail")
			if trail then
				trail.Enabled = false
					--Prevents the trail glitch from occuring
					trail.Enabled = true
Clean up function disabling the trail using cast terminating like a good boy
		local function cleanUpBullet(activeCast)
			local bullet = activeCast.RayInfo.CosmeticBulletObject
			--Debris:AddItem(bullet,1)--normal clone
			local trail = bullet:FindFirstChildWhichIsA("Trail")
			if trail then
				trail.Enabled = false


It can be more optimized using bullet.Trail instead of FindFirstChild but I’m lazy :warning: so thats to avoid the fact that not all my bullets have a .Trail so just be aware of that.


Do I need to remove any connections and remove any parented instance in the part before using returnpart() or does the module revert the part automatically?

1 Like

The module does not dispose of any connections to the part’s events. You will need to track these yourself. Its not possible for the module to do so, unfortunately.


How would I be able to get old part caches made previously in the games runtime (possibly from its parent folder, etc.) I’ve been having difficulties trying to do so with the usage of fast cast with it. To specify, I don’t know if will always make a new one, and even if it does or doesn’t, if there’s any way to grab it and store it into a variable from a complete seperate script.

I really can’t tell if this module is actually increasing FPS.
I ran 3 questionable tests and got mixed results

  1. I fired 1,681 projectiles at once that disappeared in 8 seconds with PartCache and without it. PartCache dropped to ~47 FPS and normally it dropped to ~44 FPS. However, cleaning up the projectiles dropped PartCache to ~57 FPS whereas normally it’s ~59 FPS.

  2. I fired 6,561 projectiles this time and I honestly couldn’t see a difference in FPS when spawning the projectiles in for both methods. However, PartCache had a very noticeable stutter when cleaning up the projectiles.

  3. I fired 121 projectiles every 0.1 seconds. PartCache was at ~59.5 FPS whereas normally it was basically 60 FPS.

I’m not sure if I’m using it wrong or something, but I’m pretty sure that PartCache suffers a lot when cleaning the parts. It does seemingly improve spawn FPS but not enough to entirely rely on it.

Maybe some other people can do proper tests instead of my “look hard at the FPS in view >> summary.”

1 Like

I feel so lucky to have found this topic. Currently, I am working on infinite two dimensional terrain generation. One optimization that I want to add is part caching. This is something that I planned on making myself. Luckily, I found this system which is exactly what I am looking for.

PartCache seems to be mainly made for faster creation / destruction of parts (as the part CFrame is the only property that replicates unreliably, which makes it faster), it doesn’t seem to be made to increase the fps when creating / destroying parts.

I was just trying to say that “returning” the parts takes up more performance than calling :Destroy() on the BasePart. However, it’s undeniable that caching the part vastly improves performance over calling hence PartCache.

For me, however, I found that CFraming the parts far away actually took more performance than making the object parent nil. Plus, I didn’t like how PartCache only cached BaseParts and wanted more freedom with what :ReturnPart() did, so I made my own InstanceCache.

By the way, a micro-optimization would be using :PivotTo(CFrame) than basePart.CFrame = CFrame now that pivots are here

It might be more performant to disable CanQuery, CanCollide, CanTouch and CastShadow for cached parts. I have not tested this, but maybe this works.

is this better than debris service?

Short and simple: Yes.
CFrame works best.

Sorry for the bump, but oh wow. This module is simple yet soooo effective. It made my part rain script run waaaay much efficiently. I can now have over 300 moving rain parts on screen with maximum performance!

Just found this bug (it will never reach the assertwarn function call if it is == 0):

I’m trying to make it 0 parts big so it will auto fill up as needed. I don’t want to start with a value which seems sort of arbitrary. Is it better to start with a super small value and let it fill up automatically or have some random large number so you never have to worry about auto fill but possibly have excess parts. I would really prefer the former.

I don't know what I'm doing wrong here but, Apparently parenting objects is alot faster than this module.

Here's my code:
local camera = workspace.CurrentCamera
local altitude = 78

local tweenService = game:GetService("TweenService")
local replicatedStorage = game:GetService("ReplicatedStorage")

local partCache = require(replicatedStorage:WaitForChild("Modules"):WaitForChild("PartCache"))

local F_prefabs = replicatedStorage:WaitForChild("Prefabs")
local PF_ambience = F_prefabs:WaitForChild("Ambience")

local P_rainDrop ="RainDrop"), 1, camera)

local function newDrop(position)

		local rainDrop = P_rainDrop:GetPart()
		rainDrop.Position = position
		rainDrop.Beam.Enabled = true
		rainDrop.Ripple.WaterRipple0.Size =,0,0,0)
		rainDrop.Ripple.WaterRipple1.Size =,0,0,0)
		rainDrop.Ripple.WaterRipple1.UIStroke.Thickness = 10
		rainDrop.Ripple.WaterRipple1.UIStroke.Transparency = 0.7
		rainDrop.Ripple.WaterRipple0.Transparency = 0.5
		local RCP_physics =
		RCP_physics.FilterDescendantsInstances = {camera}
		local RC_physics = workspace:Raycast(position,, -5000, 0), RCP_physics)

		if RC_physics then

			local tweenTime = ((RC_physics.Position - position).Magnitude/270)

			local animation = tweenService:Create(rainDrop,, Enum.EasingStyle.Linear), {Position = RC_physics.Position})

			rainDrop.Beam.Enabled = false

			local T_waterRipple0 = tweenService:Create(rainDrop.Ripple.WaterRipple0,, Enum.EasingStyle.Linear), {
				Size = UDim2.fromOffset(150,150);
				Transparency = 1
			local T_waterRipple1 = tweenService:Create(rainDrop.Ripple.WaterRipple1,, Enum.EasingStyle.Linear), {
				Size = UDim2.fromOffset(130,130);
			local T_waterRipple1Stroke = tweenService:Create(rainDrop.Ripple.WaterRipple1.UIStroke,, Enum.EasingStyle.Linear), {
				Transparency = 1;
				Thickness = 0;


while wait() do
		local seed = math.random()

		for x = -30, 30, 15 do
			for z = -30, 30, 15 do

				local basePosition =, altitude, camera.CFrame.Position.Z)

				local x_noise = math.noise(x/15,z/15,seed)
				local z_noise = math.noise(z/15,x/15,seed)

				local position = basePosition +, 0, z) + (, 0, z_noise) * 16)



Im using CFrames to actually and FINALLY make Occlusion Culling a real thing. Initially i thought reparenting is the best option but i guess im wrong.

Now this is how it works, I’ll be using Camera: WorldToScreenPoint() to check if the player can see the parts/models or not. If they can they will stay at their original position, if not they will be CFramed away.

Thank you @Xan_TheDragon for letting me realize this as a solution.\

The problem is bringing the models/parts back, thought of replacing those with invisible parts.

1 Like

Man I’ve been looking for this for a week only to click the link and realise I had already gotten the module. :sweat_smile:

1 Like

Is this still the case? ||char||

So does that mean we don’t have to use PartCache because its already in the FastCast module?