If I’ve got an object that’s already at an angle, but then I want it to be a block, the block base isn’t quite right. So I have to rotate the object first, create the block, then rotate it back.
Is there any workaround for this? It seems it’s using world Z as the direction.
I tried changing the Cplane prior to defining the block, but it didn’t change anything.
I’d Love to be able to select the block base, then choose another point for the Z direction.
Hello - I’m not following yet at all - can you post images or an example file?
-Pascal
I think he means that he wants to define a Block out of a “tilted” object as if it was aligned with World, but orienting a CPlane to the object instead (mimicking World).
In this way he would not have to rotate the object to World before making a Block our of it.
Well, this is my guess.
// Rolf
Yes, In this file, The knob centered on the floor would be fine. The knob created in place at an angle has only world space coordinates. I created a line through the center, in blue, that should be the object’s Z direction as a part.
If I have the object in place, in order to create a block with the proper direction, I have to rotate the object so that the orientation of the object is world up. It would be much faster to simply specify a second point after the base location.
Does that make it more clear?
The reason is animation. Keyshot reads the part orientation. So when you go to rotate things, they aren’t on world, but rather uses it’s local axis. If an object is perpendicular or parallel to one of the world planes, no big deal. They will share an axis. But as soon as you rotate an object just a little bit off plane, the local axis needs to be used for rotation. But unless you use a block (or part in other software) then all parts are imported with world axis applied.
I’m just looking for a fast way of defining a local axis for a part that’s already modeled/oriented in place.
It is very likely, even if I set something up correctly, that someone would explode a block without knowing it, edit the model, join things up, and hand it back to me.
So, you’d like to define a block from the object in its current location and orientation but have the actual underlying definition in world space and the relevant transform applied to the new instance that you ‘create’ so that the instance does not move… Right? That is probably possible in a script… I’ll have a look if I get a chance.
-Pascal
That is exactly it Pascal.
Currently, I create a line through the center, then create another line perpendicular to world. I then rotate my object from it’s current orientation to the world orientation. There, I define the block. Then I rotate the item back to the intended angle for rendering.
It’s not a Ton of work, but often people like to give me what most people would consider unrealistic deadlines. If I can fit in defining something like a knob rotation in that time, I would. Because someone will change graphics on me and say, “Shoot…can you real quick rotate that knob in the rendering?” Ok, clearly they don’t understand the limitations of 3D space in Photoshop, but I’ll keep the illusion alive that I am capable of all sorts of wizardry. If I failed to set that up, I have to go All the way back to Rhino, rotate it, import that into keyshot, render the knob, and then photoshop that knob render into the render.
Speeding up the workflow for defining a block with it’s as-built space quickly would end up being a huge time saver.
Pascal, you always seem to be able to create a script for anything. I get called wizard in photoshop, and oddly enough, powerpoint, but you are definitely a rhino scripting wizard.
Hello - here’s a crude start - see if it does anything good and we can clean up the UI.
Probably the best way to test is to set a CPlane on the blue line and at the prompt in the script for three points, use the plane origin, X and Y axes - we can make this better, I just want to see if I am getting the basic process correct.
Hm - never mind - not quite there yet…
@kalamazandy - ok, I think this will work…
BlockWorld.py (1.2 KB)
I could just make it always use the current CPlane and not ask any questions, that is probably better. Changed, above - Insertion point is the current CPlane origin - up to you to set the plane ahead of time…
-Pascal
ok Pascal. I give up. I’m not finding the information I need in order to actually use a python script in Rhino.
It seemed like I should just be able to use it in Rhino 6, but I am finding that to not be true. I couldn’t even get the hello world to do anything. So I’m guessing I’m missing something, but my google and help searching is proving to be useless.
So embarrassingly, I need help in finding the direction to get this to work.
Hello - sorry - RunPythonScript and point the command at the saved py file to test.
! -RunPythonScript "Full path to py file inside double-quotes" as a more useful macro that you can put on a button or alias.
Any luck?
-Pascal
Ha, yup. I was just being dumb. I definitely had, staring me in the face, RunPythonScript. And yet, I started to type Run…saw RunScript, and went with that instead, Somehow not making the connection.
So after my morning break hiccup, yes, the script works fine.
I tested the angle and it worked as I expected.
I did _Cplane _Surface, selected the surface of my cylinder, and chose to place it at the center.
Then I ran the script, and voila.
Thanks so much
It is the computer that is being dumb. It just doesn’t get it. 
// Rolf
