I use a lot of parts for hitbox, how can I make a hitbox without using parts?

[xccosanxcc]

I am making a game with sooo much pixels and the pixels are cuttable, I use 1 pixel one by one to make them cuttable, for example there are 4 pixels(1x1 size) in 1x4 pixels, if I make it 1 pixel but 1x4 size, this time there will be 4 pixel something to detect when the cutting tool touches it, no? (the cutting tool cannot cut 1x4 pixels at once, it cuts one by one, it can cut many pixels at the same time (onTouched event))

If I use Region3 instead of pixels for the hitbox, for example, if there are 3 thousand pixels, I think 3 thousand region3 will be required and this will strain the code… If the code can handle 3 thousand region3 or even more, then, for example, I could handle 1x4 pixels with 1 part instead of 4 part.

My main goal is not to tire the physics engine, while testing the game, there is a momentary lag or freezing during cutting and character summoning, the reason is because there are many pixels, but there is not much I can do? At least as far as I know.

Remember, many pixels are cut at the same time for 1 second. thousand pixels are created at once while the character is being added!

some gif about it: (Yes, the game is not original, but I am thinking of changing it or playing the game only among friends.)
https://gyazo.com/080f8b8bd22462ba3ec4120fed1b4f98
(There may have been a little more fps drop because I was recording gif.)
Hey, I’m still working on the bugs.

in short:
What I want: (just 1 pixel for 1 part and so much hitbox without onTouched and no fps drops)

What I am using: (512 pixel for 1 part and so much hitbox with onTouched, low fps)

After Cut (Result): (I want the same result in both)

What I want: use less pixel, Hitbox count must not change, let the results be the same, no fps drops and high fps (pixels are generally moving because from character)
Another problem that comes to my mind: If we use a part with 1x3 size without too many pixels and use region3, how will the script respond if 2 players try to cut the 2 end pixels at the same time?

(Sorry for writing so long!)

[MilkyFiend (Demonic)]

Why not use raycast ?

This is what I mean :

Make a big hitbox let’s say 2x8 pixels for example. When the tool hits the box, do a raycast function to determine the closest pixels and if there’s nothing blocking it then destroy the nearest pixels to the tool accordingly.

[xccosanxcc]

If you have seen the gif, how can raycast work when the sword is inside the pixels? sword touches more than one pixel at a time, we choose the middle point on sword to determine the distance, but this does not happen exactly, the sword is not a regular rectangle
And even after touching the box, there are still parts that it does not touch and the sword continues to slice, so it is necessary to question it every once in a while when the touched event is triggered.

Did I misunderstand you? Did you mean use overlayparams?

[MilkyFiend (Demonic)]

I don’t get the problem here as you would probably be wanting to just remove the front pixels and not the hidden ones so you can try raycast through the very bottom of the sword (where the blade starts and not the handle), and maybe also determine it with using a raycast from the player look vector.

But yes I meant to see the parts inside of the hitbox (touching parts) and use ray cast on them. Tho I don’t have much knowledge with overlayparams.

[xccosanxcc]

I think I explained it wrong, using too many pixels is a problem for me. I want to use fewer parts, but I do not want the number of hitboxes to change, example: 1 part(1x1x1) but hitbox is 0.25x0.25x0.25 that means 64 hitbox then a sword when touched part using raycast but detect just 1 part? note hitboxes…
I don’t want make 64 pixel I want 64 hitbox

[MilkyFiend (Demonic)]

Then what you can do is to render new parts. On the hitbox. I am currently on mobile so I may not be able to explain it well but I’ll try to explain the best I can.

When the tool touches the hitbox get a chunk and make new parts like destroy the old part surrounding the hitbox then make new parts while not filling the touches hitbox while trying to use as little parts as possible.

Also you might not want to render parts or hitboxes that the play won’t see or won’t do anything with from his distance.

[xccosanxcc]

I’m confused, what do you recommend I use as a hitbox? Because, for example, I can’t use something like region3 or raycast for 3 thousand hitboxes, right?

[MilkyFiend (Demonic)]

Well don’t use raycast. Use region 3 instead.
And no we are not gonna use region3 for 3000 parts.

Try to determine when the tool stops touching parts like inside of a zone and store all the hitboxes the tool touches in a table then get the middle hitbox and use region3 from there. Now do you work with rendering and destroying.

But keep in mind this many is not necessary as you could reduce the amount of hitboxes and other parts and just do region3 or ray casting.

[MilkyFiend (Demonic)]

If you won’t be able to find a solution in 6h then I’ll try to explain what I am trying to say in a better way. I don’t really have much charge in my mobile and I can’t access my pc for 6h since i am in school. And if I can I’ll try to make a similar system and show you what I mean from that.

[xccosanxcc]

Write when you are available, as long as we find the solution!
Let me give you a code example that slices it down into parts and check hitboxes, maybe it will be useful for you: (For some reason I couldn’t run params.CollisionGroup. I just want it to detect what’s in the “Hitbox” CollisionGroup.)

by xccosanxcc
local BaseP = Instance.new("Part")
BaseP.Position = Vector3.new(1,1,1)
BaseP.Size = Vector3.new(1,1,1)
BaseP.Orientation = Vector3.new(0,0,0)
local aCube = 0.25

-- Create OverlayParams
local params = OverlapParams.new()
params.MaxParts = 1
--params.FilterType = Enum.RaycastFilterType.Include
params.CollisionGroup = "Hitbox"

local pixels = {}
for i=1, BaseP.Size.X/aCube do
	for p=1, BaseP.Size.Y/aCube do
		for r=1, BaseP.Size.Z/aCube do
			-- Create Pixel
			-- local nP = Instance.new("Part")
			-- local X,Y,Z = BaseP.Position.X-BaseP.Size.X/2+(i-aCube*2)*aCube, BaseP.Position.Y-BaseP.Size.Y/2+(p-aCube*2)*aCube, BaseP.Position.Z-BaseP.Size.Z/2+(r-aCube*2)*aCube
			-- nP.Position = Vector3.new(X,Y,Z)
			-- nP.Size = Vector3.new(aCube,aCube,aCube)
			-- nP.Anchored = true
			-- nP.Name = (i-1)*BaseP.Size.X/aCube*BaseP.Size.Y/aCube + (p -1)*BaseP.Size.Y/aCube +r
			-- nP.Parent = workspace.Folder

			local X,Y,Z = BaseP.Position.X-BaseP.Size.X/2+(i-aCube*2)*aCube, BaseP.Position.Y-BaseP.Size.Y/2+(p-aCube*2)*aCube, BaseP.Position.Z-BaseP.Size.Z/2+(r-aCube*2)*aCube
			local count = (i-1)*BaseP.Size.X/aCube*BaseP.Size.Y/aCube + (p -1)*BaseP.Size.Y/aCube +r
			pixels[count] = Cframe.new(X,Y,Z)
		end
	end
end

while true do -- if have 1000 pixels, that means repeat 1000 times per 0.01 second!!!
	-- for _,Pixel: Part in pairs(workspace.Folder:GetChildren()) do
	-- 	local hitboxs = workspace:GetPartBoundsInBox(Pixel.CFrame, Pixel.Size, params)
	-- 	if #hitboxs ~= 0 then
	-- 		print(hitboxs[1])
	-- 	end
	-- end
	for i, cf in pairs(pixels) do
		local hitboxs = workspace:GetPartBoundsInBox(cf, Vector3.new(aCube,aCube,aCube), params)
	 	if #hitboxs ~= 0 then
	 		print(hitboxs[1])
	 	end
	end
	wait()
end

[JohhnyLegoKing]

I remember hearing about a technique that Minecraft-like games use where they group multiple blocks together and only ungroup them once the player is in the region. I suggest you do something similar where the Part is only divided into sub-parts once the action that does so happens. I wish I could help you more but I never made something similar to this before although if the end goal you’re looking for is the ability to slice a Part like a loaf of bread, then this YouTube video by @5uphi should work

[xccosanxcc]

There will already be thousands of pixels near the player and you may have misunderstood cutting a part, you can understand it better by looking at the gif (at the top).

[JohhnyLegoKing]

Oh I see you’re making a pixelated game which is pretty cool! If you only need the ability to cut characters then I suggest using meshes for the decorations around the world to reduce overall part count, and I also recommend that you try combining the pixels inside the characters into chunks instead that fall out randomly when hit by the blade to further reduce the part count if you wish

[xccosanxcc]

I do not fully understand? I cannot use mesh because every pixel of the character can be cut.
The decorations may already be in mesh, but since there will be pixels in the decorations, there is no need for mesh.
The sword can only cut 1 pixel in a single pixel touch, it cannot cut 2x2 pixels in 1 pixel touch.

[JohhnyLegoKing]

The reason for my suggestion is because the more pixels you have, the more hitboxes you need to accurately detect which pixel gets destroyed and hitboxes require a lot of processing to work correctly which is most likely the cause of the fps drops you’re experiencing

[xccosanxcc]

I know but I don’t understand your suggestion exactly
I think it’s because of google translate

[JohhnyLegoKing]

What language are you most comfortable with? (If you wish to keep this private, I understand so there’s no need to tell me)

[xccosanxcc]

what do you mean combining the pixels? For example, let’s say there is a leg model, I divided that leg model into pixels of the same size.
and what do you mean chunks? every pixel must have each hitbox, example: 1000 pixel = 1000 hitbox

[JohhnyLegoKing]

I think an image would help explain what I meant much better so please wait a bit while I draw an example

[xccosanxcc]

I don’t understand why, but I put 3200 overlayparams, but it works fine with a very small delay, but I’m still not sure…
Actually, the easiest way is to test each pixel of the sword(sword made by pixels too), as if there is an imaginary pixel inside the character(because don’t want to tire physics.) and whether it touches that pixel, but how can we do this? maybe to do this, I have to take the cframe and size of the sword and query it every Runservice.Stepped, which confuses me because the sword can rotate…

that is, to understand whether a turned sword touches a virtual pixel or not… (virtual pixel for detect if sword inside specific chunk)
When I think about it again, it seems like it goes the same way