I don’t see that with my simple GH definition here even at X 500,000 | Y 500,000 | Z 10,000… Or even with Z=500,000. The frames stretch without a problem.
BoxFrame.gh (17.6 KB)
As in your python script, there must be something else in your GH definition that is causing the inaccuracy.
In any case working that far from the origin is always somewhat hazardous.
ok, i have to look into it more carefully, since it doesn’t happen all the time.
Thanks again @Helvetosaur for creating the request.
And here’s a nice frame example 
ok, @Helvetosaur those small deviations are the horror! In some situations curves in Rhino seem to be planar, PlanarSrf works well, generating surfaces… still, when imported into Revit they become a problem.
Look, I have to write another dodgy script in order to planarize those programmatically.
#Replace all Z coordinates of a polyline with the Z of start point)
import rhinoscriptsyntax as rs
curves = rs.GetObjects(message=None, filter=4, group=True, preselect=True, select=False, objects=None, minimum_count=1, maximum_count=0, custom_filter=None)
for curve in curves:
points = rs.CurvePoints(curve)
startpoint = points[0]
startpointZ = startpoint[2]
curves_explode = rs.ExplodeCurves (curve)
newsegments =[]
for curve_explode in curves_explode:
points = rs.CurveEditPoints(curve_explode)
new_crv_points=[]
for point in points:
newpoint = point[0],point[1],startpoint[2]
new_crv_points.append(newpoint)
if rs.IsArc(curve_explode):
arcmidpoint = rs.ArcMidPoint(curve_explode)
arcstart = rs.CurveStartPoint(curve_explode)
arcend = rs.CurveEndPoint(curve_explode)
newarc = rs.AddArc3Pt(arcstart, arcend, arcmidpoint)
newsegments.append(newarc)
else:
newpoly = rs.AddPolyline(new_crv_points)
newsegments.append(newpoly)
rs.JoinCurves(newsegments,delete_input=True)
rs.DeleteObjects(curves_explode)
#print startpointZ
rs.DeleteObjects(curves)
I honestly think that this problem should be fixed somehow in R8, Is there anything planned?
I don’t think your script needs to be nearly that complicated.
"""Flatten curves to a plane parallel to World XY going thru the Z coordinate
of the curves' start point"""
import rhinoscriptsyntax as rs
def PlanarizeCrvsInZ():
msg="Select curves to planarize in Z"
crvs = rs.GetObjects(msg,4,True,True)
if not crvs: return
rs.EnableRedraw(False)
for crv in crvs:
plane=rs.WorldXYPlane()
plane.Origin=rs.CurveStartPoint(crv)
xform=rs.XformPlanarProjection(plane)
rs.TransformObject(crv,xform)
PlanarizeCrvsInZ()
Thanks @Helvetosaur but still I’m thinking, why is this happening? Sometimes for import export with Revit I have to use Kangaroo CoPlanar …
Should we have another tool to fix planarization of surfaces? Maybe fix bad faces? Or round up numbers?
A real solution coming from Rhino, not some scripts to patch things up…
Bogdan, Are you transforming your geometry closer to Rhino 0,0 before your import/export with Revit?
Well most architecture is drawn in millimeters and if you have a 200meter tower or a cluster of buildings it is enough to end up in the twilight zone of digits…
Errors in Rhino are very common while moving solid points or edges at this scale, boolean operations also suffer.
Fixing 10- 20 errors per day is common practice. But most rhino users are skilled enough to fix or bypass those issues quickly.
I’m stressing it also because i see some push and pull modelling in R8 under development.
@Japhy , Here’s another file, this time stuff is close to origin, and the geometry comes from Grasshopper.
The idea would be to create a new Rhino command that rounds up the digits for these situations. FixGeometryDigits or something…
22-11-15-BC SolidPtOn.3dm (144.1 KB)
Well, I always say GIGO… no, not Grasshopper In, Grasshopper Out, but rather the original Garbage In, Garbage Out… I would be looking as to WHY your GH definition is producing this kind of problem, rather than trying to put a band-aid on the result…
Nope, I won’t look into why the geometry is bad… that’s because the geometry can be bad because of many different reasons.
Instead, much better would be a fix tool.
Don’t buy it… goes back to GIGO… Geometry is as good as you (the operator/programmer) make it. Grasshopper will create geometry as accurate as native Rhino commands do if you set it up correctly, after all, it’s using the same geometric functions underneath.
Don’t agree… Fix-my-digits tool would be a life saver. After all, we do have Analysis section; Fix Meshes section…
Second, In some situations it might be user fault but it might very well be Rhino fault… as you work, you never know… after 50-70 design variations… nobody knows.
Oh, and third… this “far away from origin” excuse is quite lame…
Oh, and how can I forget, this variation of my model has 850 panels like the one I show above 
Imagine editing the “gigo” 
