-
Describe the bug. Describe what is happening when the bug occurs. Describe what you would normally expect to occur.
During the timespan of the last year, bricks with Shape set to Ball no longer maintain consistent collision geometry and visual geometry. This is causing confusion for players walking on large-sized ball bricks used as islands.
The bug is related to the visual geometry of the ball bricks, because the bricks we used for islands in a 1-year old game has changed, while the collision geometry remains as intended. -
How often does the bug happen (Everytime/sometimes/rarely)? What are the steps that reproduce the bug? Please list them in very high detail. Provide simple example places that exhibit the bug and provide description of what you believe should be the behavior.
It happens 100% of the time, and is more noticable on large bricks.
Below is a place file showing the bug:
BallBrickVisualGeometryBug.rbxl (13.8 KB) -
Where does the bug happen (www, gametest, etc) Is it level-specific? Is it game specific? Please post a link to the place that exhibits the issue.
It’s happening live - the issue can be seen at Halloween 2016 -DISCLAIMER IN DESC- - Roblox -
Would a screenshot or video help describe it to someone? If so, post one.
-
Anything else that you would want to know about the bug if it were your job to find and fix it.
As mentioned above, it is the visual geometry and not the collision geometry that needs to be fixed.
It’s not a bug, but rather a compromise to cover a common use case: a ball that rolls nicely (also cheap radius-based collision detection). If Roblox did not provide the ball brick with its mathematically-pure spherical collision geometry, anyone wishing to have a ball that simply rolls smoothly would have to script their own physics for it.
But the ball brick does not a planet make, nor was it ever an envisioned or intended use case to have just 0.05% of a giant ball used as a pyramidal island. The exact look of the Roblox ball could also hypothetically change in the future, as part of an LoD or quality setting system, or just quality improvement. What you need here is not a bug fix to ball bricks, but another solution. The island in your example file could be made more efficiently with CornerWedgeParts or WedgeParts, or unions of bricks. Performance and consistency would both benefit.
The collision geometry is fine, and seems unchanged - the issue here is the visual geometry.
The visual geometry for ball and cylinder bricks is generated on the fly, and subject to change at any time. Roblox could, for example, use lower-poly versions on lower-end machines, or improve the shape in the future to keep up with computer capabilities. The ball brick is meant to fulfill the abstract intent of a ball, not provide a particular implementation of, say, 216-hedron (or whatever it is currently). If you need to lock in a specific geometry, a mesh is what you want.
Guess that’ll do, now we have Instancing.
It does seem weird that the visual geometry of the ball is lowered, rather than the collision, though.
That’s because things that are easily represented mathematically are special-cased when there is something to be gained. In this case these are nice rolling behavior and cost of collision checks–a double win! A perfect sphere is one of the least expensive things to collision check: the distance from any point to the center is just compared with its radius (in practice, the square of these things are compared, to avoid square root operations). Any collision mesh representation, no matter how crude, is going to take a lot more time to collision check against (even a box!)
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.