When executing this code in a server script:
local model=Instance.new("Model",workspace)
local cylinder=Instance.new("Part",model)
cylinder.Shape=Enum.PartType.Cylinder
cylinder.Size=Vector3.new(2,4,10) -- Y ~= Z
cylinder.Anchored=true
model.PrimaryPart=cylinder
model:PivotTo(CFrame.new(Vector3.new(0,5,-10)))
local orientation, size = model:GetBoundingBox()
local part = Instance.new("Part",workspace)
part.Size = size
part.CFrame = orientation
part.Anchored=true
part.Transparency=0.5
part.Color=Color3.new(0,1,0)
I would expect the bounding box to reflect how the part is rendered. Cylinders render using the minimum of Size.Y and Size.Z as the diameter. But GetBoundingBox() does not take that into account and returns the same result as if the part had a Block shape.
I first noticed this today, 2023-07-15 10:00 GMT+1.
The same happens with model:GetExtentsSize()
It also happens if the part has a Ball shape, except the minimum of values Size.X, Size.Y and Size.Z determines the diameter of the part that is rendered.
PS: I also suggest the meaning of Size when rendering Ball and Cylinder shapes should be described here, in the article about parts:
2 Likes
Thanks for the report! We’ll investigate.
5 Likes
this is because the size of cylinders acts differently than normal parts.
this cylinder has a Y size of 1000
and this one has a Y size of 10
the actual “cylinder” that is rendered tries its best to maintain its size and prevent stretching (I have no idea why)
but :GetExtentsSize() & :GetBoundingBox() use the X Y Z of the Size. So I wouldn’t say this is a bug as much as a weird behavior with cylinders
I agree it should use how the part is rendered, not the actual X Y Z size, but I wouldn’t really call it a bug. That’s just my opinion
3 Likes
Maybe it’s more of a quirk or inconsistency. But fixing quirks might also be worthwhile.
Changing the part rendering is not an option, I expect.
For changing GetBoundingBox, if it breaks too many games, it’s also not an option to modify the behavior. However, it requires a combination of four things, for a fix to fail: using GetBoundingBox, using shperes or cylinders, having set the size inconsistently, and finally building code that depends on the current behaviour of returning a bigger bounding box than what the rendered parts. I don’t know if there are other aspects of the engine that also have the behaviour of GetBoundingBox. Touched events, for example. Of course it is up to Robox to assess the risk of any change and decide based on that whether to implement.
If not fixable in the implementation, it might be useful to explain a bit more in the developer docs and implement a change in studio where the Size is set consistently, when changing one of the co-dependent size components. I think me forgetting to change a size component is why this became an issue for me, to begin with.
1 Like
