This really drives me crazy - if I wasn’t already from start.
I’m inserting a Block letter (“V”) into the model,
and then I want to Orient that very letter to the surface (with the upper left corner of the letter in the intersection of the black curves).
Then I pick my points, but no matter how I try (defining the “reference points”), the letter “V” somehow ends up getting rotated, and… I’m entirely lost on this one.
I’ve tried inserting the Block “V” rotating it along the World Y axis, and as pictured, along the World X axis, but same thing - the letter ends up “hanging”.
Scratching head. I don’t have a clue even after looking at the example clip in the help file.
Fig. 1. The non-selected letter ends up “hanging” (rotated). The CPlane is World.
So my question is,
exactly how should the object be oriented when starting the command OrientOnSrf
and exactly where should I define the first point (on the object? If so, where? I’ve tried in the upper left corner, and in the middle, but to no avail, it gets rotated as pictured)
and exactly where should I define the second point (on the object?, or where relative to the object?. In the Help file clip the 2:nd point is placed outside the object, supposedly along the “X direction” but “X” - relative to what? Doesn’t Rhino know which direction is X? Anyhow, if the Help is referring to the object’s X direction, then what is “X” in terms of UVN, which should b e the only thing relevant? .
In any case, I’ve tried pointing the 2:nd ref point in all directions, but every time the V ends up “hanging” as pictured, the non-selected one, that is).
I’m really lost on this. I feel stupid and I probably should.
Hi Rolf - the command takes the current CPlane normal as the direction to map to the surface normal. If your V does not sit in the CPlane you can set a CPlane to it or it to the CPlane to get things more understandable.
If instead the V is sitting on a surface and you want to orient it on that or another surface, use the OnSurface option before picking your base points.
Yes, I picked that one up. And I also succeed every time to align the “object normal” with the “target surface normal” (by selecting a mid point of the object). But, why is the object rotating (“hanging”)?
This is the best I could get after trying since you replied, which is only “hanging” to the other side :
It doesn’t really matter what I’m doing wrong, or even whether I’m stupid or not - the command OrientOnSrf simply doesn’t make sense, and it’s not intuitive, and it does things that doesn’t seem related to any known circumstances (the rotation).
Why is it rotating although I set rotation to “0” in the last dialog showing up?
(Btw, that dialog is useless without a preview function (and the dlg also must allow mouse movements in a semi-modal kind of mode), because there are way to many parameters affecting the result for most people to intuitively foresee what result you are going to end up with. This is the typical stuff you need to clean up in Rh6, before anything else. The existing UI works, if it doesn’t explicitly hide or outright trick you, regarding what Rhino intends to do, like in this case).
// Rolf
Edit: A test model, if anyone can explain to me how to get the upper edge of that little nasty “V” to align itself also along the horizontal curve, not only to the surface : PV Front 011 - Upload OrientToSrf.3dm (3.2 MB)
Hi Rolf - start OrientOnSrf. Select the V, set the base point at your point CC (at the V end of the line) Set the reference point in the X axis (Ortho) Set the rotation to Prompt and scale to 1. Click on the Surface end of the ‘cc’ line. Rotate the V until it lines up nicely… http://screencast.com/t/RKkL3ReuJi4A
Actually, I guess using the Pos location rather than cc is better- you can then use the target curve to snap to when rotating.
I didn’t have the Rotate option checked in the dialog, since I expected the given angle value in the Editbox to be forced on the end result (any guessed value would give a twisted angle in that stage). Therefore I never realized I could manually adjust the rotation after the object had aligned to the surface, regardless of the Dlg angle value.
So there it was.
May I suggest that that angle field in the Dlg be separately “disabled”, by default at that, because then one wouldn’t intuitively expect that angle to force the object to rotate (to whatever angle which won’t be the correct one anyway).
With that field only explicitly set activated, one would expect to be able to adjust the rotation as you demonstrated in your clip. That intuitive aspect you know…
Thank you very much. Now I can go to sleep in peace.
I don’t think I can emphasize enough how important it is to get rid of such “simultaneous complexity” - like one option seemingly concerning only one option, but in reality that one option controls two (or more) options, and so it changes the playing field entirely.
Notice that I mean that the existing UI isn’t only bad (it’s not that bad at all), but it would be X times better if only getting rid of all those “anti-intuitive patterns” making newbies confused at best while causing others (like me) to follow false leads to dead ends.
My problem isn’t that I’m a novice on computers. Because I’m not. I actually designed one of the top notch transport logistics / business systems out there[*] (used by Volvo Cars, and it was recently
evaluated by Scania as one of the three top logistics systems on planet earth). As a chief designer of that mega-project I designed the entire system from scratch, and I also myself programmed most of the backend (although of course, having a team of 5+ programmers assisting), plus - and this is relevant to this thread - I “had strong opinions” on the overall approach about the UI stuff (although I appointed another guy to take the lead on UI). The system has several hundred forms, many of them very complex, and we did only the “right thing” with every one of them. I had promised the product owner (a private company at that point in time), that no more groaning from the users, aso.
THE POINT
And my point is that when I use a dialog or any UI I expect things to be logical, or intuitive at some basic level at least. Due to my well founded expectations I was so grossly mislead this time by the dialog.
Rhino already “has it all” but it deserves better regarding the anti-intuitive stuff. Get rid of it.
@pascal,
all the letters are now in place, but I’m having problems making the middle “L” to form itself after the surface (“Rigid” option).
Since the underlaying surface actually consists of multiple patches (splitted along the middle, etc) I made a temporal “patch surface” to attach the letter to, like so :
The I run OrientOnSrf as usual, using OSnap “Between” on both the object and the target surface, but the Block “L” won’t form itself after the surface, regardless of if I check the option “Rigid” or not, the letter remains “flat”:
So I exploded the Block letter “L” and again tried attaching it to the surface, and this time the letter formed itself to the patch surface, but in my taste the letter looks less than perfect :
I gave up on Rigid with OrientOnSrf. As a workaround I exploded the letter L and CageEdited it to form after the notch of the surface and then OrientOnSrf:ed as usual. Thus I have no idea why it didn’t work as expected.
Hi Rolf - just looking at the image, the L appears to extend past the red surface - maybe I am reading the image wrong - the red is your target, right?
Yes, the red “patch” surface is the target. And as a result of the command OrientOnSrf the object is extending beyond the surface. That’s not expected since the object is smaller before attaching it.
You can see from Fig 2 in a previous post that the letter kept its size when it wasn’t “rigid-formed” to the surface, so something strange seems to be going on here.
Brb.
Edit: OK, back again. Here’s the model. I tried again attaching the Block version of L with Rigid, but no go.
Anyway, in this test model I restored a new (flat) Block L and made the Block L local. It’d be nice to learn what you find when trying Rigid for both the Block version and exploded version. (BTW, the forum web server seems to be struggling, uploads are very slow since an hour or two. Something bad going on?)
OK, let us conclude some facts now, but first of all, the surface actually WAS larger than the object, and so it should have been working, but it wasn’t.
Furthermore, I just tried expanding the surface “significantly” (more on that below), and with the “Rigid” option set, the letter is flat, but not distorted (this does not indicate that the surface would be “too small”) :
Fig. 1: The target surface is large enough, since the object aligns without deformation :
Then I tried exploding the Block and set the Rigid option to OFF, and it still didn’t work as expected. Fig. 2 below illustrates how the L was grossly distorted, again.
Now the facts:
Inserting a Block will not adapt to the form of the target surface, it’ll stay flat regardless of the Rigid option. I would have expected that it’d adapt. Fact: Block doesn’t work as expected, at least no mention of this limitation in the help file.
OTOH, if exploding the Block it aligns nicely to the surface, with Rigid set to ON (suggesting that the target surface is large enough, as indicated by Fig 1 above.)
Exploding the Block and applying it on the same surface as in §2 with Rigid set to OFF, will result in a grossly distorted result (see Fig 2.). The only difference between §3 and §2 is Rigid being toggled from ON to OFF
Given the facts of §2 and §3, the full and correct answer is not “make the target surface larger than the object”. The correct answer (the size) is unknown, and so the problem must either be fixed or an answer provided explaining how much larger the surface must it be in order to work as expected.
Fig. 2: Here’s the result of the same operation that resulted in Fig 1. Only difference is that here the Rigid options is set to OFF whereas in Fig.1 it was set to ON :
I think this is reason enough to enhance both the command itself, and to add some more documentation to the help file about whatever limitations will remain with the command.
I also think this thread can provide useful info for making this command produce better (expected) results, and for making it more intuitive for newbies (that’s the benefit you have of newbies like me).
Moreover, your two videos (in this thread) should definitely be included in the help file as well, since they illustrate very well what the two initial “reference points” actually means (which is not made very clear in the current help file), which in turn would do away with most uncertainties for newbies. Then I think that at least experienced Windows users would get it right already in their first attempts.
At last, thank you very much for your help and patience. Newbies like me can be a strain on the nerves.
