When objects are really small, selecting them by clicking on them doesn’t work most of the time. My Unit Scale it set to 1, Length is set to Centimeters. When I have a cube with a dimension of 2 centimeters it’s pretty impossible to select it. When I scale it up to 50cm it’s getting better. Also clicking close to the origin works better.
I think this is a “distance from object” thing. So if you are too far away from the origin of an object, or any vertices/edges/faces of the object, clicking to select clears the selection. Getting closer to either an object origin, or element within the mesh causes it to be selected. Same applies in Edit mode by the way - too far away from a vertex causes the selection to clear. I think this is “intended behaviour”…
Here are two examples, the location of the cursor is where I LMB clicked to select:
First one clears selection, or selects nothing, second, where I am closer, selects the object. If I zoom in the effective distances get larger, so it seems to be a function of scale of the view.
I think, I found the culprit. It happens, when the Viewport Clipping is set really high (like 10km). When I lower the value to a few meters, it works again. Might be worth investigating anyway though, just to avoid problems.
And yeah - 10km still is written as “1000000cm”. I wish somebody would take care of that.
It’s the ratio between Clip Start and Clip End that matters. You can have Clip End set to 10km just fine, but then you need to raise Clip Start to a higher value (the ratio between the two should be around 1/10.000 or higher).
Thanks. But I already created a thread about this before discussing the problem with “Adaptive”. When adaptive is used, the default length is “Meters” again, which I don’t want. So when I enter “1” while using “Adaptive”, it’s interpreted as “1 Meter” and I can’t switch this to “Centimeters”.
When working on a Centimeter level, “2” is too high when you need to get really close to a complicated mesh. The whole Clipping-Unit-System is a bit too buggy still. For now I feel more comfortable in 2.79. I’m sure over time these issues will be taken care of.
I’m not an expert on the topic of precision or Blender code but I believe the extreme values you are using are right at the limit of 32 bit floating point precision. With 32 floating point numbers, you get around 7 digits before things fall apart.
Maybe Blender exclusively uses 64 bits and if that’s the case then I’m wrong but I’m certain there’s a mix of both 32 and 64 bit floats floating around in there.
(btw), I realize that question is about Java but floats are defined outside of any particular language. I believe it’s a standard.
Thanks for your answer, but unfortunately I have no way to check that. But maybe that’s a point to start from. Hard to imagine, that Blender would use 32-bit numbers for that though. If so, they must have changed that in 2.80 as it never was a problem in 2.79.
There’s been precision issues with viewport rendering since forever, although maybe someone did make a change that made things worse for your situation.
I didn’t post the link to give you something to check on. I was simply pointing out that if you want to avoid precision issues then you have to avoid extreme ranges of values.
Moving everything to 64 bit floats would cause Blender’s memory use to increase dramatically and there could be a serious performance hit as well.
It’s not always necessary to increase precision and not every programmer will instantly knows exactly when high precision should be used or when it’s a waste of resources.
There’s not always a road-map laid out for these things.
It’s a lot of guess work and experimentation.
The best thing you can do here is file a bug report if it matters to you. You may have to log in before seeing the bug report page. https://developer.blender.org/
It would be great if one of the developers would have given a quick feedback on this before I declare this as a bug. That’s why I like to post issues here before going to the bug reports too quickly. But somehow it’s very hard to get a response from them these days.