I know the classic has been forever - “No, you can’t do that.”
However… Based on my recent post on hatch rotation and scaling, I discovered that ExportWithOrigin does precisely that - it ‘moves the origin’ and then exports the geometry relative to the moved origin. It even takes into account not only translation, but rotation of the CPlane. Pretty useful for solving a few situations.
OK, I’m sure internally it simply moves the Geometry before exporting, or perhaps runs a transformation on all the numerical data that actually create geometry. Whatever. If that can be done for Export, why can it not be done internally?
The large advantage of a command like that over simply moving/rotating all your geometry with Rhino commands is that it could act on the whole file, no matter if objects are hidden, locked, on off layers, etc. Like changing the units of a file now does.
I assume there are probably a lot of worms in that particular can. But it could be quite useful and I know I’m not the first person who has requested it… So I’ll just toss it out here. For V8.
I think it’s just a matter of user interface.
We might see that as moving the coordinate system or as moving the geometry in the file.
It’s the same thing …
Then I see nothing weird (or sacrilegious ) in asking for a command to transform anything in the file.
… Whatever it might be called …
There are a number of ways to look at this. We are working on moving the basepoint so the internal math of Rhino can stay accurate. Here is another discussion on this: Far from origin
Does that process work in your case. It is better to move the current origin then move the model if you want to keep accuracy.
What is the specific workflow you are looking for?
Note, it’s not just a translation, but actually a transformation including a possible rotation of the coordinate system as well. The main issue is that this would work on EVERYTHING in the file be it visible/selectable or locked, on an off layer etc.
Sure, but if you had describe what the interface might look like, what would it be? I see all the things that want to be changed at the same time. Units, z-up orientation and origin? What does that look like?
We kind of combine State plane coordinate issues with any origin move. But, in you case you are looking at global reorientation from and imported file?
Also, if this is not a far from origin problem but a smaller translation, the rules are different? If it is only a few thousand out, then the tolerance issues are not bad.
Well, I’m thinking of a general solution of resetting the world coordinate system from the current to something else. It could work like RemapCPlane for example - have the user create a custom CPlane and then choose remap the World coordinate system to that.
The most important thing is that it does not rely on selecting anything, it transforms the whole file - as I said, like changing the unit system via DocumentProperties. Otherwise, any number of existing methods could be used to do more or less the same thing by actually moving the geometry.
I think the tolerance problems will be the same as when moving geometry. One other thing to also deal with will be non-geometry items such as custom views, texture mappings, etc. Also all named CPlanes would need to update etc. Don’t know what might happen with Layouts. As I said, lots of worms in that can…
Yes, I understand what you are saying. But let’s walk through this in specifics on how it might work. It get’s complicated in practice.
Units are easy. What units is it in, what unit would you like to go to. DWG and DXF are the worst, because technically they do not have units, so guessing is the only way. There are many hints and we try to use those when we can.
Transforming the geometry is not bad. What is complicated is how to specify it. Take the facade model. How would you want that process to go? The original position of that facade is drawn at an odd angle. How do you specify the new origin point? How do you specify the new X axis and the new Z axis? There must be 3 points. There is no telling if that is a North, West or South facing facade?
Oh yeah, there are lots of worms in the can. But to simplify the discussion, let’s take this example we already have.
Scott, if I am reading all this correctly, the world is simply transformed to a user specified plane, just like RemapCPlane, it should all be pretty straightforward. The user tells the machinery what the target plane is- that is all that’s needed UI wise…?
How is the user specifying a plane to start any different then Orient3Point command? Is the difference that I specify my 3 points exactly like Orient3point, then specify one of the default Named Cplanes as a target? Then I get the result in the previous replies. The bottom corner of the facade at 0,0,0.
I don’t follow - the starting plane is always WorldXY, there is no input for that, the target plane is user defined - however planes are defined, including existing cplanes.
I get the intent, but the details are blurry. And so is the goal in specifics.
What is the prompting that needs to be done? And what input collected specifically? On screen by picking?
What is the desired output? Specific 3dm example of that model…
Does the user tell target plane by specifying Top, Right, Front? Or do they pick any name Cplane? Or do they pick 3 points?
Is this Facade meant to be rotated up into 3d space? Or is it it meant just to be aligned in the top view only Orienting in 2d space from its imported location?
The facade was just an example. I am looking for a general case. However, to answer the question, I was looking for it to stay flat on the XY plane (it will be laser cut) but be able to rotate/translate to the world origin with the principal lines parallel to X. To do that I would first set a CPlane aligned to the object - origin where I want - then Remap the World coordinate system to that.
This kind of operation would probably not go into the Undo stack.
Just keep exploring this issue. If I use Universal Cplane, I get everything to lock into the Plane I set on the objects.
Then after setting is set, simply set what plane you want to be the new world. All the viewports update. Is that closer to the behavior you are looking for. You can draw and specify in those coordinates. Everything you unhide or unlock will also be in the correct space?
Yeah, but Universal CPlanes suck because as soon as you change the local CPlane in say the Perspective viewport all the other viewports update their view and CPlane to that. I do not want (or like) that. I just want to remap the world coordinate system and be done with it - then have Rhino behave like before with Standard planes.
The underlying mechanics seem potentially more problematic than any UI or behavior expectations - that all seems pretty straightforward to my three remaining brain cells, but I can imagine that implementation behind the scenes might involve constant application of transforms from Rhino’s ‘real-world’ - I dunno - but I could see how that might bog things down. Probably we should ask a real dev… @Dale, any thoughts on this one…?
But it could be quite useful and I know I’m not the first person who has requested it… So I’ll just toss it out here. For V8.
) in asking for a command to transform anything in the file.
