i am confused. i couldnot align objects properly then i found out CG does not correspond to gumball position even for perfectly symmetrical object ?
I always thought gumball sits in the centroid or at least at the axis of symmetry
By default the Gumball pivot is the center of the selected object’s or objects’ bounding box.
so if i have gumball aligned to cplane (that object is in principal axes of that cplane) bounding box should should also be aligned to cplane right? then it should concide with center of gravity…
i am pissed because my whole model is messed not because i was alinging things with gumball…
If the object is rectangular and lies parallel to the CPlane axes, and the Gumball is set to CPlane, then yes, by default the pivot should be in the center of the rectangle (as in the midpoint of a diagonal). If you have an example where this is not happening, please post it here.
here you go. I might be drunk or someting but i think there is something wrong CGvsGumball.3dm (75.4 KB)
First, you are some mega distance away from the origin.
-555438966.616,-1278587496.769,125112.499
You are working in mm, and you are more than five hundred thousand Kilometers from the origin. That can led to some floating point math errors.
Second, the object is not rectangular or box-like. So the CG will not necessarily be the center of the bounding box.
However, I ran the command BoundingBox on your object with the CPlane option, I put a point in the center (Between two diagonal corners of the box) and then selected the object to turn on the gumball. As far as I can tell, the gumball pivot corresponds exactly with the BB center point.
BBCenter.3dm (112.6 KB)
seems rather like floating point error … the bounding box is not accurate
i am working in real coordinates. 0,0 is somewhere in the baltic sea i am in slovakia. thats only way how to work in architecure. rhino can handle far from origin EXCEPT sometimes it cant. problem is that you dont know when its ok and when its off
How did architects work with paper drawings before CAD? They didn’t have paper large enough to be make all measurements from the origin.
One way to use Rhino with models far from the origin: Objects Too Far From the World Origin [McNeel Wiki]
next time i will use this proposed approach with linked block.
but still rhino can handle far from origin pretty well the problem is that not entirely, i know there are fundamental problems related to floating point but it seems some operations handle big coordinates and some dont.
there is then this issue you get quite confident you can work far from origin directly but then gumball fails you. when program can calculate centroid correctly why bounding box is not calculated correctly? there is this duality some things are correct some are incorrect which cannot be considered cosher
by real coordinates you mean, GPS coordinates?
If thats the case, how do you convert real spherical coordinates into cartesians without losing precission?
Whats the benefit of working like that/?
i get data from land surveyour and i model my structure in the real position… its of course projected its not gps (spherical)… it is flattened by some type of projection. there are many coordinate systems.
Sounds like something you do just for the sake of it… there is no benefit whatsoever in working like this!
If you wanted to keep a file with all your works, positioned at the relative coordinates… why not import and place them after they are done?!
I see, I was just curious if there was some kind of data that you get out of the modelling after that needed to be 100% aligned with real world coordinates.
i am sending model back to surveyor to mark where foundations will be.
because there is dynamic coopoeration with lot of positioned data. moving back and forth is gonna lead to issues like the bridge will be misaligned. the more times you move stuff there is certainity of mistake.
i dont think it is adequate analogy because Cad should enable completely different workflows than paper and not be limited by incapability of software (besides inherent decrease of precision far from origin). This is legitimate thing to ask. Other software has this resolved (microstation). I even think Rhino could handle it because it already does in some areas. Some software (Revit) deals with this problem that you define world coordinates related to model origin (little faking). How about Rhino would do all geometrical calculations related to selected cplane and global coordinates would be then obtained by adding coordinates of cplane and global origin difference, similar to Revit approach but better. I have been advocating for resolving far from origin problems once and for all since i joined this forum. Instead i am always told to avoid the problem at all which is not always possible and not neccessary.
2 Likes