I was hoping for a shrink to 0.1
I feel 0.01 is too far
1 Like
I don’t think we should limit the capabilities of the whole engine solely because size 0.01 parts are hard or impossible to build with. There are programmatic uses as well, such as scaled modules for 3D GUIs, tool viewmodels, or small detail parts from meshes or wherever. 0.1 is still too limiting for some use cases, usually for models that appear very close to the screen.
Addressing building and selecting difficulties:
It can be set up such that, by default, it’s not possible to resize a part below 0.2 with the resize tool or the properties panel. A setting can be made to change the minimum part size for build tools.
Addressing script backwards compatibility:
Some scripts may have been setting part sizes below 0.2 previously, with the expectation that they would stop at 0.2. I don’t think this is very common, and those scripts somewhat breaking sounds like an alright consequence for improving the engine. If it is determined that the consequence is too great, then there can be a setting for backwards compatibility that limits the ability to programmatically set part size.
I really don’t want to see the whole engine limited because of problems that are easy to work around. I’ve been hoping for unlimited part sizes for a long time. If the tools don’t work with it, then limit the tools, not the capabilities of the engine as a whole.
9 Likes
I think you summed up my view really well. We have been needing small part support for a while now and I’d rather not see it limited. Like you said, if anything just limit the tool’s abilities but please give us the option to change that limit so that those of us who are more experienced can use the default tools to their full potential.
3 Likes
I’d argue that’s the developers fault. Especially considering this isn’t the first time the minimum size has been changed.
5 Likes
That should be quick for any active developer to audit and fix. And that is a good example of what is definitely non-future-proof coding, as opposed to a legacy pattern we’d expect to have special-case backwards-compatible support for. As I’m sure you know, it’s not usually the best practice to wantonly supply out-of-bounds values to functions or properties, knowing they will fail validation and be subject to corrections you don’t have control over and can change with any update. It’s perfectly within the right of an API developer to change from clamping the values to rejecting the property setting altogether. That’s not going to happen here, just general software dev advice about why it’s best to not rely on undefined behavior of API calls.
Could you elaborate on this concern? Would it be something that affects your personal set of tools, or something you publish? Just to be clear, a new lower part size limit would not ever force you to make a 0.01 part, and if you use the quantized move and scale tools, you could continue to work in 0.2, 0.5, 1 increments, etc. If you’re modifying the source code of your plugin, couldn’t you also just add your own constraint if you wish to keep 0.2 as the lower bound?
Anyone wanting to work with parts this small is likely doing so already with imported meshes, and just accepts that you can’t click on sub-pixel things, you need to select them in Explorer or with a marquee drag that catches them. Or get really close… 
That isn’t unique to Roblox either.
3 Likes
That’s a good idea. A value in File->Settings…->Studio for smallest part dimension could address the concerns of people afraid of accidentally making things too small to click on.
4 Likes
Why are we even keeping minimum part size around if we can resize to 0.01? The practical physical difference between a part sized to 0.01 and one sized to 0 is negligible. For reference, look how small a 0.01 size part is:
It’s so small that it can fit through any sort of gap possible. Rounding size=0 parts to 0.01 would produce no detectable difference, if there was even a reason developers needed size=0 parts to be physical actors in the first place. I don’t want to have to union parts just to get size=0 – use cases are the same as on the union size=0 thread which caused unions to remain unconstrained in size.
4 Likes
I’ll definitely use this. Small parts are important for anything close to the camera.
As always, the change will break someone’s workflow. Concerns about novices losing small parts can be addressed by implementing larger size restrictions in studio’s default tools. Like AllYourBlox and EndorsedModel said, it would make sense to make it a setting.
Code that relies on the current limit should be considered fair game to break.
@EchoReaper If 0 and 0.01 are close enough, why do we need 0?
There’s a few stability issues regarding parts with zero volume right now. I recall crashing last time I tested them in water.
1 Like
There would be no distinguishable difference to using a size=0.01 part over a size=0 part, but min size is a silly idiosyncrasy. It’s weird to push dealing with engine limitations onto users instead of dealing with the limitations in the engine that’s responsible for them.
Same fix as unions with zero volume. Min size has already been dealt with for unions – not sure why parts/MeshParts have to lag behind.
1 Like
I think what @EchoReaper is trying to say is that a 0.01 size part is so small that Roblox may as well cut the crap and go ahead making 100% flat parts. One major advantage I can think of with using 0 size parts instead of 0.01 is that 0 size parts can easily fit between two parts, whereas 0.01 size parts would have a, well, 0.01 stud offset, completely throwing everything off.
Fair enough, but at that point Roblox should just fix issues with totally flat parts for the sake of making the physics engine more robust, i.e. it shouldn’t be an issue.
The main reason I want it is for 3D GUI effects.
Parts have to get really tiny and really close to the camera to avoid clipping issues.
2 Likes
I will be testing a lot of these user stories and examples over the coming days. Appreciate all the feedback so far.
It’s non-negligible to a lot of devs in a couple of ways. A 0.01 part can be a meaningfully visible particle, laser beam, piece of metal, or wire, etc. If a Roblox avatar were the scale of a person, that would be about 3mm or 1/8" to them. That’s not paper or sheet metal thin, it’s more like cardboard box walls or diamond tread plate thickness. Devs are importing 0.01 and 0.02 things already for laser beams, wires, pencils, projectile trails. There are a lot of cases for which 0.2 is just too thick. I experienced this when making electrical arcs, 0.2 looks good from 100 studs away, but a spark from a few tens of studs away really needs to be about 0.025 thick to look realistic and not like blocks. 0.2 studs to the scale of the character is like 2.5 inches, great for a soda can, but not a pen or straw, or anything you want to look actually thin.
The real issue though is that a 0.01 part has volume, so it has mass and can be physically simulated, accelerated, pushed. Roblox is first and foremost a 3D physics simulation based game engine. Letting parts go to 0.01 doesn’t make them degenerate or cause singularities, or calculations to crash throughout the existing system. Actual zero would have a lot of issues. It would require special case code all over the place to tolerate zero-mass, zero-volume things and not subject them to calculations that assume positive, non-zero physical and geometry properties. This is not a limitation that someone just doesn’t want to deal with, it’s the consequence of properly implementing a Newtonian physics model as the top priority and core component of the engine.
4 Likes
Most uses <.2 don’t need physics really anyway.
Just turn it off.
Meshparts is my answer here. Please let us have this restriction removed.
2 Likes
Iam building my CSG models with part sizes far below 0.2 since end of 2015 ; and i neither noticed any selecting neither physics issues .
Same for all my meshparts which i simply scale in Blender to the needed roblox size → Since 1 square of the Blender floor grid is exactly 1x1 studs in dimension :
now when exporting the mesh with scale 0.01 it can have even a ingame scale of 0.01 if not even beyond.
i only once had a thin blade mesh with the size of 0.098 or so …physics worked pretty fine …even tough i used hull collision which made collision bit wider.
I cant imagine how and if physics ;of a part which is far smaller, work.
I maybe suggest a limit of 0.05 ? since i can still see and select it ^^
Also those smaller sizes and even the current limit of 0.2 finally need a camera which is easier to handle so close up .
The new closer clipping plane helped a lot BUT : as i already told in a suggestion post : WE NEED major improvements for the part tools dragging handles .
Even while working with parts of the size 0.2 the dragging handles are way too far away from the parts center !
also in order to not fully overwhelm building beginners ; and to not totally break even the workflow of an advanced builder i suggest making this new limit in studio a optional thing ;
meaning some button that has to be clicked in order to activate the new min size …or rather to deactivate the 0.2 limit.
1 Like
Just got a spontaneous but maybe great idea in order to help ppl finding even current small parts 
Someone here know games like borderlands where stuff like dropped money and weapons got marked by some sort of colored light beam ?
maybe we could press or click a button in studio which shows something similar coming out of every part ? some thin optically easy noticeable line which maybe could even end at its top with a thick ball :
Which we could click in order to select even the smallest part 
or maybe even some other highlight function to show some sort of circle or ball at the parts center which scales based on camera distance ; so when clicking this optical highlight the part gets selected (:
This could be really useful for many things.
I agree with that it may be difficult to select those small objects as @Mistertitanic44 explained. His solution sounds fine as well.
Anyway making the small / thin things e.g chains, blades for swords or daggers, belts, belt buckles, etc. can be really difficult if you can’t go smaller than 0.2.
I think the priorities of this subject should be the MeshParts and UnionOperations. I think it’s okay to have regular parts have the same behaviour as well though.
And if some people dislike this, perhaps make an option to enable / disable the size restriction in Studio?
1 Like