I have a complex model at a specific, geo-located point (far away from the origin). I understand that this might cause problems, though that in itself seems like a significant bug to be fixed.
I found this topic from 2019, but I’m hoping that six years later there’s a solution.
Is there any way to avoid destroying an object by manipulating its sub-objects? I’ve seen this behavior moving edges, faces, and corner points. Creating a new file then re-linking it with a block as per the wiki is not a workable solution, since I have many hundreds of objects in this model, any of which is liable to be changed by a client request like “make this piece 1” longer."
Right now my best workaround is, for this example, building a second object and union-ing them together. Much slower and clunkier than just moving the corner.
Any help would be appreciated! Screenshot and sample model below with a simple extrusion.
Far from origin issues exist because of the limitations of floating-point arithmetics.
google/read about it.
I do not expect a solution - only workarounds.
whats the precise workflow / edit you are after ?
if you _shrinktrimmedSrfToEdge and remake / (re)build the trapezoid surface with _srfPt then it is possible to edit the corner:
I’d like to know ho you got this error. I opened your 3dm file and move the corner points on the left object in Rhino8.21, but the error shown in your screenshot did not appear. Could you record a gif or video of the process that causes this error? Thank you.
Just coming back to this – seems like @Tom_P covered it but just in case, here’s a video and my systeminfo.
And re: the floating-point problem – it does seem like a gnarly one, but I’m confused as to why it would matter where in space a given object is: wouldn’t the transformation (and therefore the underlying arithmetic), in this case of that point by ~1" along the x-axis, be the same regardless of where the object is?
Re my specific workflow – it’s just an issue I’ve been seeing a lot lately. Recently I tried to stretch out a complicated polysrf by moving the lower 1/3 of it (subselected points / edges) down and it broke in a similar way.
Rhino uses floating point numbers for all geometry information, with locations in the “world” coordinate system. Floating point means the total number of digits is fixed, so the more digits to the left of the decimal point the fewer there will be to the right of the decimal point. The world coordinate system means that when an object is far from the world origin its coordinates will have more digits to the left of the decimal point.
…seems like there’s gotta be a better way than losing precision with distance, though.
My use case can’t be that uncommon: working on a small portion of a much larger architectural project, which requires geolocating everything. Of course there are ways to get around it with blocks, but having things at their proper locations makes importing and exporting way easier for everyone on the project.
