I spent hours on trying to work with cplanes [move, manipulate, reorientate etc] I finally figured out the issue and wanted to share but bottom line is: OneView does not work with cplanes. Regular perspective does.
So for example, in OneView [orientated so “bottom” shows as the active view, select “cplane from surface” and follow prompts. When you finish the cplane in OneView/bottom does not move BUT if you change the viewport to bottom, front, side etc. it shows correctly.
Attached is an example screenshot where:
In OneView I executed the “cplane from surface” and picked the bottom surface of the plate.
After execution there seemed to be no change in the grid.
However, if you change the view to “bottom” you see the changes.
This is confirmed by creating a box in both views as shown in the picture.
You can see the box results in different placement the first box in green was created while in the “bottom” view and both the view and the cplane are correct. The second box was created in oneview and they do not match
Thank you for the added info. I could not figure out when to use mobile plane vs the other cplane options. I tried the option [in oneview] and it seems like you have to hit refresh to use and see the plane. The “show” option only shows the coordinates and it disappears as soon as you move the model. In fact if you rotate within oneview to the point where the view changes [ie. top view] then try to get back to the mplane you cannot. To to this I have only found that you have to select the part, select mplane option, then hit the inline command to refresh even if the option is set to automatic.
At least now I can use it when needed so thank you so much for your help.
sorry for reply here, I had to set a custom origin there is no way to use _ oneview with that custom origin? I was trying but always back to the original 0
establish project origin which would be in translational relationship with world origin. everything would be then calculated according to project origin and world coordinates would only be calculated. this would solve far from origin problems. internally it could work that project origin would be defacto shifted global origin and all things like imports would then just ask if it should be imported in world or project coordinates …
The term “world” when applied to a coordinate system in Rhino may be getting in the way of a relatively simple solution of the problem of how to deal with a project which involves an external coordinate system with it’s origin far from the geometry. My understanding is what is termed the “world” coordinate system in Rhino is just the coordinate system used internally for all calculations. It is not inherently linked to any “real world” coordinate system.
But for many users “world” as the name of a coordinate system implies it is a “real world” coordinate system; for example a geographical grid system. This leads to the assmuption that the “world” coordinate system for their geometry needs to be that “real world” system.
@ivan.galik suggestion is currently possible, at least partially, with the geometry near the Rhino “world” coordinate system origin, and a user Cplane with the origin offset so that geometry is at the desired “real world” locations. Geometry could then be imported/inserted and exported using that Cplane origin when the “real world” coordinates need to be used. Improvements in the user interface and help for importing/inserting/exporting with origins are needed and possibly some additional capablilities. My guess is this could be relatively simple and low risk to implement with some careful planning.
Perhaps a new thread on this topic would be appropriate.
