Please post any issues you encounter.
There are some known problems with physics stability for non-anchored parts under 0.2.
66 Likes
Are there any plans to continue to lower this? E.g. once the physics instability is sorted out. The limit specified on this thread was “possibly” 0.01.
0.05 still pretty visibly extrudes out. One of my primary needs for small parts is plane-like objects which I currently use unions for since they can go down to size=0.
5 Likes
May be reduced again in the future depending on developer feedback. Will likely not be reduced to 0.
6 Likes
We want to continue to push the platform and create amazing features for developers. Right now there are some engine limitations that prevent us from reasonably going any lower, but the goal is to get this down to .01.
17 Likes
Understandable with parts since they use exact physics and size=0 is not physically possible, but what about:
###MeshParts
Like CSG, MeshParts’ physics is approximated. They use very similar / the same physics, and CSG supports size=0.
Why do we need size=0 MeshParts? 
Same use cases for size=0 unions
How do we implement size=0 MeshParts into the physics engine? Same way it was implemented for unions
###Attached Parts
There are parts that are attached to another, so even if they’re size=0 they won’t be a physical body with mass=0. We’ve already seen steps in this direction (massless hats) where attached parts that shouldn’t affect physics are beginning to move away from affecting physics.
Why do we need size=0 parts? Same use cases for size=0 unions
1 Like
The ability to use attachments for particles will eliminate a lot of the size = 0 use cases.
See this thread:
3 Likes
Particles are not “a lot” of the use cases. That was only the first posted uses case, and it never came up after that. There are a lot more use cases other than particles.
1 Like
A lot more than Particles will be used with Attachments in the future.
1 Like
None of the other use cases involved anything that would be affected by attachments.
1 Like
I’ve been linked!
Nonsense!
My Studio tools evidently disagree, I’m able to hit sizes of 0 with the stock resize tool on Studio version 0.296.0.130667.
3 Likes
Did you set a flag locally? Can’t get this to happen myself.
Try quitting and restarting studio.
1 Like
Restarting fixed it, I hadn’t played with any flags.
Or more likely, 0.05 with the display of the value truncated to 1 decimal place 
2 Likes
I dunno about that, when the part wasn’t selected it looked like it had no width to it. It’s fixed now either way.
1 Like
Certainly a possibility. If it happens again, maybe see if it persists being saved to a file? Do you happen to recall if the resize tool was had an interval set, or if it was freely resizing?
Size=0 CSG was an oversight. MeshParts/CSG at small sizes are way worse than standard parts at small sizes, because the “approximated” physics is using smaller convexes compared to the actual part size.
We have discussed this internally and decided that instead of going all the way down to 0.01 or whatever number we choose, we should start with a more modest decrease and observe the issues, and at some point later reevaluate the limits again.
2 Likes
Thank you for the response. In the past when I’ve provided unions in response to requests for use cases, it’s just been met with silence. Knowing that “we’re not really a fan of size=0 unions either”, I can stop being a broken record.
All of the use cases for size=0 parts I’ve seen don’t require physics (or are attached to another part), so out of curiosity, why are the physics issues a concern? We can control the limit of part size set through the resize gizmo and properties window so users don’t accidentally set part size below an unsupported amount, but if someone sets it to a small value through the command bar/scripts they can be responsible for not using very small parts for uses that cause problems.
1 Like
In general we don’t like broken features/feature interactions. We started from the premise of “parts at minimum size should work”. Then we evaluated the issues that come from small parts and concluded that we have some stability issues even with current limit, so that by itself shouldn’t be a blocking factor.
However, long term we want physics to be stable at all sizes and in all constraint/collision combinations. Currently this is not the case.
We have discussed just dropping the limit, or just setting it to be really small; the danger is that since we currently don’t have a very deep analysis on the problems with small sizes and possible solutions (we spent some time researching this, but not enough time to conclusively set the realistic bounds for primitives in a real-time simulation), so if we go 0 or 0.01 now and then a year later discover that it’s physically impossible for us to maintain fidelity at this size, the dream of physics being stable in all cases will become impossible.
As such, we picked a compromise where we’d relax the limit to a certain extent but not as far down, and the hope is that as developers start building content for the new limit and as we solve some other issues, we’ll get a better understanding as to whether we can solve the issues at 0.05 or 0.01 or lower going forward.
6 Likes
Are CSG parts going to be given a min size other than 0 in the future? I don’t want my gun builders 300+ weapons to suddenly turn wack.