"Tell me what's goin' on. I ain't got a clue!"
-
How were we meant to know that you had defined 'plane' as a method, let alone a variable - which it seemed it might be at first glance, there were no clues in your published code ???
If you publish half of the story you'll get a lot more 'answers' than you need...
-
@tig said:
If you haven't defined 'plane' then it's taken to be
nil, so the test isif nil==somethingifsomethingis alsonilthen it'strue!!!
TIG, plane is defined.
attr_reader ... :plane ...is equivalent todef plane() return @plane endedit: and this being Ruby
planeis alsoplane()- maybe not Matz's best decision as this discussion shows.All of which is to say I've got good working code that produces faces facing the positive end of the perpendicular axis and it does this by reverse!() for everything not in the 'rb' plane and I've no clue why and the standard answer "SU draws upside down in the rg plane when z=0" is true but it's not an answer to my question.
-
@tig said:
How were we meant to know that you had defined 'plane' as a method, let alone a variable - which it seemed it might be at first glance, there were no clues in your published code ???
If you publish half of the story you'll get a lot more 'answers' than you need...My apologies.
-
So, what does the plane() method look like?
-
@jim said:
So, what does the plane() method look like?
There is none. He used
attr_reader(:plane)which is the same as:def plane() return @plane end -
Yes, well, I see that now.
So it's just a string anyway. -
Seems this is making it all too complicated for its own good
What's wrong with testing @plane directly ? -
-
@jim said:
Yes, well, I see that now.
So it's just a string anyway.No - it's nothing. it's
niluntil a value is assigned. it just makes the instance variable available to the outside scope.but in the context of Martin's code - yes @plane is a string.
-
@thomthom said:
but in the context of Martin's code - yes @plane is a string.
I was looking back at the original code and just skimmed over the later post. Even so, there is still no clue to what type of object @plane refers since the actual assignment is not given.
-
this is a bit off topic, but I was just curious: how would you handle a rectangle that has a normal of (1,1,-1) or something similar?
-
@tig said:
What's wrong with testing @plane directly ?
That would be best. I forgot the "@" - simple coding goof - but the test got done, the program worked, so I didn't notice.
Would have been better if method calls needed parens so you a) see that it's a method call, b) get a compile-time error for forgetting the "@" and c) fix your simple mistake, instead of publishing it.
But back to the original topic. If you draw your points clockwise ... What's clockwise?
Clockwise above is origin, up blue axis, out on rg plane, right?
Clockwise is origin, out on rg plane, up blue axis, right?
Note that both shots are of the same model, with a wee bit of orbiting to change point of view. Ergo, an unqualified "clockwise" is meaningless.
A bit off topic, the title is Jimmy Buffett in "Everybody's Got a Cousin in Miami" paraphrasing Jimmy Buffett in "Margaritaville." It accurately describes my knowledge re normals after a face is drawn.
-
Clcokwise is where the face's normal is pointing directly back at "you" when "you" draw it. So orientation within the model is meaningless.
-
The 'right-hand' rule: you grasp the normal axis [above the face] in your right-hand with your thumb pointing in the positive direction.
Your fingers will curl in the counter-clockwise direction.
The 'left-hand' rule is the reverse of this...
When you return an array of a face's vertices they are always listed counter-clockwise... right-hand rule...
-
-
'Above' in this context is on the side of the face's front.
If the face is flat and it were facing upwards your hand would be above it.
The that face were facing downwards then your hand would be underneath it...
Advertisement