I am creating large planets, they use a custom LoD system to reduce the amount of triangles being rendered. Because these planets are so big and the amount of triangles is relatively low, the triangles need to be big. Because Roblox limits the size of parts to 2048 studs, there ends up being huge gaps between triangles on large planets. If Roblox increased the limit from 2048 this would not be an issue.
Planet with 16,384 stud diameter. This is a “small” planet.
Planet with 131,072 stud diameter. Planets need to be this size for them to actually feel like planets instead of low poly spheres. Each one of these little triangles is 2048x2048
Try putting the Roblox grass texture on there. Or just lower the brightness of the wedgemesh color to match. Either way, it’s better than waiting potentially years for Roblox to address this.
Race tracks can be large. If I want to make a proper racing game, I need a proper race track. And to be honest, modeling a race track within native Studio is not going to cut it. Being able to 3D-model a race track is a huge win. However, I’m currently limited to circuits within the 2048 size. This is a huge limitation that forces me to split up the track into multiple meshes.
Large terrain
In a game I’m making later this year, I am using a low-poly terrain style. It needs to be quite a massive landscape. This is super easy to model in Blender. But I can’t use it because I can’t size it up in Studio.
For both of these use-cases, collisions are important, thus simply throwing it into a scaled-up SpecialMesh won’t cut it.
Yes. Every part you make is added to the spacial hash for collision handling regardless of whether it’s CanCollide or not, and the spacial hash is optimized for character scale things, not absolutely massive parts. Adding a 100,000 sized cube to it would not play nice.
Support and bumping this for extreme measures. I’m working on some “huge-world” game and “open-world” world with a lot of parts that need to be over the maximum limit to create less-lag if it could and don’t have to create more and more parts that are over the limit to stack on every side of a part.
Anyway, I had issues with having a lot of parts have the maximum size of 2048 at the X, Y, and Z sides/axis as I have to convert or select the individual part(s) for a terrain material or brickcolor of a single/individual area for certain games; this would be a problem with games that use more than 12k studs all directions like one of the projects/open-world game that I’m working on that has a lot of area to be filled and made, but using a SpecialMesh doesn’t and does solve the problem with larger areas but also some “lag” issues with using such an instance.
This also creates a problem as you’ve given as an example with a planet that needs to exceed the maximum limit, I also have one example which would be a large apocalypse game/map that would require parts to be > 2048 or < 2048 in most areas.
^ I can just use the new technique that Lua Draggers introduced, but that wouldn’t really matter too much as selecting one whole part instead of individual BasePart(s) to select and change.
I really think that the limit should be 8192 by all sides, which would be a 4x the amount of the actual maximum of that part at the moment, and also to be much easier for a huge limit of the BasePart overall, would improve my development experience a whole!
It is now 2024, and the maximum BasePart size is still stuck at 2048 studs.
This limitation has been around for way too long, and it’s embarassing that this has not been changed to this day.
Why is this still a thing?
I’m working on a project where this cap is really holding me back, and I’m sure I’m not the only one.
It would make a massive difference to many developers out here I am very sure.
