Rotate in Three Planes

[jpolding]

Is it possible to provide rotation parameters in three planes? If I was asked that same question I might just say a quick 'yes, of course'. Then I tried it. Here's the scenario (it's not for the feint of brain)...

You have a book on your desk.
The book is facing you so the spine is on the left.
You tilt the entire book on the spine as if you're opening it. Keep that angle.
Now you tilt the front up so that the only point touching the desk is the top left corner of the spine.
Now for the third direction,side to side.
Really, it all comes down to being able to keep that top left corner of the book on the table(and static) while moving the book around.
Make that parametric. The book can't warp or change size. AHHHHH!

Good luck. This one is definitely worth a pint at AU to one who gets it first (hope it's me:lol:).

[rkitect]

I have a theory...


.. we'll see if it works.

[twiceroadsfool]

It takes three families, work plane based, nested, and hosted on Reference Lines in one another. Do s asearch for Rotatable Speaker. Youll find it here. :)

[rkitect]

Enjoy... (http://screencast.com/t/NWU5ZGQz)

It's been done before and probably in a much simpler manner. I used face based families instead of work plane based.

[jpolding]

Thanks Carl and Aaron. You both seem to be on the same track with nested families and ref lines...

Carl, yes the box rotates in 3 axis but none of the points are static.

Aaron, I couldn't find anything on Rotatable Speakers. That's in AUGI right?

[twiceroadsfool]

Im pretty sure the thread on this forum where it got started was a speaker example... But i may be wrong. i hadnt had enough coffee, LOL.

[jpolding]

Thanks Aaron, I found it.
http://forums.augi.com/showthread.php?t=52253&highlight=rotate+speaker&page=3

This does help and I need to pull it apart. Still, it only rotates in 2 planes.

[rkitect]

Carl, yes the box rotates in 3 axis but none of the points are static.

So rotate it the way you want, and then move the point. Shouldn't be too hard to modify the family to do so. But then the problem becomes when someone wants a different point static.

[twiceroadsfool]

Thanks Aaron, I found it.
http://forums.augi.com/showthread.php?t=52253&highlight=rotate+speaker&page=3

This does help and I need to pull it apart. Still, it only rotates in 2 planes.

Yes, but once you understand the concept of Nest it in to another family, host it on the workplane, and tie the parameters together, you just keep adding a level. Another family, another Reference line in another direction, another level of nested parameters.

Its the exact same steps, just repeated to get the third direction.

[jpolding]

Pints all around at AU:beer::beer::beer:. Thanks for your help. I ended up nesting the speaker into a roof-based family. Then when I bring it in I can alter the roof pitch associated with it. It is part of a roof so that's fine. I alter the pitch(es) and then move the thing again into place.

I'm still a little bugged by not being able to achor a point. I think Steve Stafford recommended that in a post a couple of years ago. How about a PIVOT POINT object that you can place on a Workplane? You could snap objects to this and then lock them to the pivot point.

Thanks again!

[twiceroadsfool]

You know for a roof based family you dont have to do any of that, right? A roof based family thats not set to remain *always vertical* will automatically find the pitch of the roof... So will a face based family....

[dbaldacchino]

You can do it per the attached file with no nesting. However one of the ref. lines is reversing itself for some reason (plane reversing from positive to negative or vice versa).

[twiceroadsfool]

Thats a great example, David... As long as the item itself isnt parametric. If it is, thats going to be an assache to constrain. :)

[dbaldacchino]

Well perhaps, but not necessarily. It would be similar to one constrained to the ref. level for the most part. The important thing is to set the correct active workplane and go from there. I've done some crazy stuff like this for some special ceilings hehe. Also one could work around the "flipping" issue by changing the extrusion value when the rotation value causes the reversal (ex: extrusion to -3' instead of 3' when Rotation 2 = 0).

[twiceroadsfool]

Oh, im sure. I just tend to promote the Nested family method since eventually, there is a case where you have to end up there anyway (parametric arrays). I try to only teach one method for all, instead of this method for sometimes.

But im not kocking your method. ive never gotten it to work in a single family. Go texas!

[dbaldacchino]

Wohoo! Yeah i understand. I used to nest whenever there was the need for rotation but once I learned how to deal with multiple ref lines, I started nesting less. Always in pursuit of minimalism and small file sizes :)

[jpolding]

Yes, the roof based family does snap to the pitch of the host roof. The pitch I'm referring to is the pitch of the family. It has two pitches plus it's alignment with the roof pitch. Also, to make matters more complicated on a Friday afternoon, the outside fascia line (which is rotated in two directions) needs to be parallel with a wall below. Can you say nasty trig...

Problem is I can't show this right now because of confidentiality etc...

Thanks for your help. I'll see if I can post something for you to look at.

[jpolding]

Okay, if anyone out there is still following this I've uploaded the file in question. After much hair pulling I was able to make the family which rotates in three directions. Now for the final touches...

I'm trying to drive an angle by another angle while maintaining coplanar z angle. I was able to make a logorythmic equation but it's not as perfect as a trig formula.

The question is too complicated to be explained other than looking at the file. I've established all of the parts of the equation but just can't figure out the trig...

Any takers? I'm going to up the ante and add another AU beer to the table.:beer::beer:

[Alfredo Medina]

You can do it per the attached file with no nesting. However one of the ref. lines is reversing itself for some reason (plane reversing from positive to negative or vice versa).

I know this is an old post, but I was searching here if this challenge had been solved. In my opinion, this family posted by Dave does not rotate the object in three planes. It provides only 2 rotations, because the "Rotation 1" parameter and the "Rotation 3" parameter both do the same thing, rotating the object in plan view along the z axis. If you go to the left or right view, none of the parameters makes the object rotate along the x axis. To comply with the specs of the challenge, the family has to make the object rotate like this:

1. From the plan view, at the x-y plane, along the z axis.
2. From the left or right view at the y-z plane, along the x axis.
3. From the front or back view, at the x-z plane, along the y axis.

[dbaldacchino]

Well, my version achieves total 3D rotation as far as I can tell. It will rotate along the longitude and the latitude and along the element axis. Doesn't that achieve full control? Think of a hanging speaker for example. What other rotation cannot you achieve with the above family? Regardless, this illustrates the concept of doing it all with ref. lines and no nesting. You can keep going and adding parameters & ref. lines, which will eventually become redundant, with this method. So if you're missing a rotation, you can achieve it.

[Alfredo Medina]

Hello, Dave! I didn't expect you to reply to a year-old thread so fast!

My comment is that when I go to a floor plan,"Rotation 1" and "Rotation 3" do the same thing. Set all the angles to 0; then try entering 30 degrees for "Rotation 1", apply, set back to 0. Now enter 30 degrees for "Rotation 3", apply. What's the difference?

Think of the 3dRotate command in AutoCAD. Remember that icon with the 3 circles in 3 different planes? A true rotation in 3 planes would need to do that: rotate in plan view, rotate in left/right view, and rotate in front/back view.

[dbaldacchino]

Haha I had a few free seconds so I replied :)

They seem to do the same thing because the other parameter is zero. Once you enter a value for all, you'll see that rotation IS happening on a rotated plane. Since the other rotation was zero, the planes were co-incident. Look at it in 3D and I think you'll see what I'm talking about.

[Alfredo Medina]

Yes, but it does not rotate the object by the 3 planes (as in the icon shown above). If it was, any value in either one of the 3 planes should cause a different rotation, regardless of the value of the other two parameters.