I really hope they do not do this. But, it’s Roblox. They only care about what their investors want, not what their actual developers want, and will probably completely remove them. If they do this (really hope they wont because this will break literal millions of games), then they will only deprecate it for like 2 months, then it will be gone.
This is like how they removed outlines, didn’t just set the default to off, allowing people to actually use a feature that they want, but instead completely deleted it so nobody is able to use it.
I get your point to an extent but you are definitely exaggerating a bit. There has definitely been times when Roblox didn’t listen but lets not minimize them to those only and also remember their good things like this. Also, it seems that a lot of people have being throwing the “They only care about investors” term lately without actually considering any other actions of Roblox
The last time they listened was what? mid 2021? Uncountable other effective updates have happened since then. The only reason they will listen is if it’s like a REALLY noticeable change. Like for instance if they deleted specialmeshes.
Outlines were a completely different branch in the rendering pipeline as far as I understand it. Supporting them long term would have increased maintenance tenfold. Please take the tinfoil hat off with the investor stuff. There’s more going on behind the scenes than you or anyone else on twitter or the forum can even begin to speculate about. Everything done has a good reason. Roblox is not making irrational engineering decisions.
Thank you very much. Glad to know I’m not the only one that feels this way. Seriously though, why do so many people act like they’re an employee at Roblox and are completely aware of their rational behind the decisions they make
Good reason. Yeah, if you’re talking about games made after 2021, then yeah. It’s fine and nothing will change. It’s still more effort to completely remove loads of features than to update them once a year. Especially when people ask to keep them just about as much as people want them removed.
It appears the geometry is made this way to fit precisely with the sphere, since Roblox uses a cube sphere in comparison to a UV one.
Although I think this also gives a good reason to add a ‘Cone’ Enum.PartType, since it would be both uniform with the cylinder’s bases and also allow for more accurate collision.
SpecialMeshes do not relate to selection boxes, lighting, scripting, icons, animations, nothing apart from rending and very close(and I mean very) components. I’m sure it’s hard to maintain loads of features on the app, but not SpecialMeshes.
We actually care quite a bit about backwards compatibility. Let’s keep it on topic and stay respectful. Please move this discussion to a separate thread.
This is great!
I personally believe roblox should expand its library of presets to include more advanced shapes, allowing newer developers who do not use use 3rd party modeling softwares to create more intrecate models, whilst being a real time saver for others who do use modeling softwares.
This is unrelated but since Size has been mentioned, I’ll shamelessly take the opportunity to ask:
Has there been any consideration towards reducing the performance impact of part Size change operations? A lot of coders create animations where they continuously resize parts every frame, and this causes severe performance impacts when carried across many parts. The easiest example I can think of would be animating the BodyHeightScale inside Humanoids to create shrinking and lengthening animations for the character. If you were to create a global event, let’s say, where everyone’s characters get shrunk in that moment, this leads to severe lag spikes unless you give up animating the transition entirely.
Changing .Size is many orders of magnitude more expensive than setting .CFrame, especially if you use BulkMoveTo. My speculation is the .Size operation involves some sort of physics recalculation to sort the part into an acceleration structure, or something like that. This is definitely a big ask but I would be extremely happy if you guys could somehow give BaseParts a state where they are entirely ignored from all physics calculations, so they can be resized inexpensively just as one can modify the Scale property of a SpecialMesh basically for free.
The change for wedges and cornerwedges would’ve been super handy to me… oh dear, 12 years ago… I wonder if I still have that script that listed off every single property that Part and WedgePart had in common at the time on my hard drive anywhere (even the stuff that was deprecated even then, such as all the weird motor stuff), but it’s certainly an interesting move regardless. I think I’d rather just be able to change ClassName and have the engine convert applicable properties, though that’s probably a lot more work for less benefit.
Also, on the sub-topic of SpecialMeshes: Any chance for the old Torso shape to get a return in the form of a Part.Shape enum entry? I used to use it a lot for things like ingot items.
Minor edit because I only just noticed ten days later that I misspelled “Part”
While your at it can you make parts and wedges more optimize as there is extra triangles on normal parts and wedges that are completely Un Optimal as well as the density of spheres
I Guess Corner Wedges Are fine
By Simply Removing these Triangles
you Reduce the Amount of Vertices In games with just parts as builds by a factor 2
Dramatically increasing the performances of games
And I believe we’re still underappreciating this boy here.
The truss parts are still weird and behave in a locked manner.
Plus they are not even a part of the shape menu.
-- knowing physics simulations, i’m pretty sure this is a deliberate limitation since sphere colliders detect collision using a distance formula and by design can’t be stretched on just one axis (assuming roblox uses primitive colliders at all which i imagine they would). for an ellipse to work it would need to use a mesh collider which at that point just use a meshpart
-- no offense but like please make sure you know what you’re talking about before you post things like this. in most graphics engines literally everything is made up of triangles, quads and ngons are split into triangles at runtime. even in programs like blender shapes other than triangles are split into tris (look at the shading) and quads only really exist for the convenience of modeling
-- also even if they were to remove this somehow that would not reduce the vertex count at all. triangles are allowed to reuse vertices, cubes still have 8, wedges still have 6, so on so forth
It’s true that you could get yourself into trouble stretching spheres / cylinders due to the significantly increased cost of computing collisions, however if we were building the engine from the ground up today we likely would allow them to stretch regardless because the content authoring simplicity would be a big win.
It mostly comes down to backwards compatibility. There’s a lot of non-uniformly sized cylinders out there (and not quite as many but still a lot of spheres) which would get unintentionally stretched if we changed the behavior for existing content.
We could diverge the behavior for new and existing parts but that would create a separate nightmare for the tooling ecosystem, with tools now having to recognize that both behaviors exist and needing to know how to handle them differently.
The likely long term solution is to make it easier to work with meshes in Roblox, as a lot of the use cases for stretched spheres involve approximating rounded surfaces with a combination of many stretched spheres – a pattern better handled by mesh editing or voxel sculpting.
