"Tell me what's goin' on. I ain't got a clue!"

TIG

As TT says if you make faces and the points are ordered appropriately the normal is fixed as you expect... EXCEPT if Z=0 and the face is flat in the XY plane then the face will always have normal.z=-1 no matter what you have set it to be - It's a SUp built-in foilble - draw a Rectangle anywhere and the normal in fixed sensibly - BUT if it's on the ground plane the normal will face down no matter what you do...
So check for flat faces where Z=0 and ALWAYS flip them if you want normal.z=+1...

MartinRinehart

What you guys are saying and what I'm seeing are not the same. I'm flipping faces in two of the three planes. And I'm flipping regardless of the z value.

Here 'r' creates a rectangle instance.


# /r/rects.rb

rec1 = r [0,0,10], [20,20,10]
rec2 = r [10,0,0], [10,20,10]
rec3 = r [0,10,0], [20,10,10]

This is the result:

I've got three faces, outsides all facing the positive direction. rb was not flipped. The other two, rg (z == 10) and bg were flipped. (SU 7.1, PC).
@tig said:

As TT says if you make faces and the points are ordered appropriately the normal is fixed as you expect... EXCEPT if Z=0 and the face is flat in the XY plane then the face will always have normal.z=-1 no matter what you have set it to be - It's a SUp built-in foilble - draw a Rectangle anywhere and the normal in fixed sensibly - BUT if it's on the ground plane the normal will face down no matter what you do...
So check for flat faces where Z=0 and ALWAYS flip them if you want normal.z=+1...

Jim

Because the order of the vertices matters when creating a face? (with the possible exception when drawing on the rg plane at z=0.)

swapping verts 2 and 4 (index 1 and 3) might reverse the normal.

MartinRinehart

@jim said:

Because the order of the vertices matters when creating a face? (with the possible exception when drawing on the rg plane at z=0.)

swapping verts 2 and 4 (index 1 and 3) might reverse the normal.

I gave that a really quick try and didn't see a difference.

Jim

Hmm. Just throwing things out if anything sticks.

@martinrinehart said:

Sorry TIG. This is working code in a working class.

TIG's right about the plane variable. It is a variable local to the get_corners method, and is never defined in get_corners before use. You will get an undefined variable exception if you try to run the code. If you are not getting an exceprion, you have another problem.

@martinrinehart said:

The box class commits to having a positive pushpull value pushpull in the positive direction.

What does "positive" mean in this context? Ruby pushpull uses the face normal as "positive", no matter its orientation globally or in the Group context.

If you draw a face with a normal in the same direction as an Axis, then pushpull the face in the positive direction, the face is going to reverse automatically.

Edit - I'll generalize that last statement to: a face pushpulled in its positive direction (its own normal direction) will reverse.

MartinRinehart

@jim said:

TIG's right about the plane variable. It is a variable local to the get_corners method, and is never defined in get_corners before use.

Oh dear. Should have been "@plane". Now my question is, why does it work as written?

@jim said:

@martinrinehart said:

The box class commits to having a positive pushpull value pushpull in the positive direction.

What does "positive" mean in this context?

Toward the positive end of the perpendicular axis.

MartinRinehart

@martinrinehart said:

Oh dear. Should have been "@plane". Now my question is, why does it work as written?

No more question, except maybe, "Why could we all be so foolish?"

From the constructor:


attr_reader ... ;plane, ...
...
@plane = ...

It's not a local variable, it's a method call. This is Ruby.

TIG

If you haven't defined 'plane' then it's taken to be nil, so the test is if nil==something if something is also nil then it's true !!!

TIG

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...

MartinRinehart

@tig said:

If you haven't defined 'plane' then it's taken to be nil, so the test is if nil==something if something is also nil then it's true !!!

TIG, plane is defined. attr_reader ... :plane ... is equivalent to


def plane()
    return @plane
end

edit: and this being Ruby plane is also plane() - 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.

MartinRinehart

@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.

Jim

So, what does the plane() method look like?

thomthom

@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

Jim

Yes, well, I see that now. So it's just a string anyway.

TIG

Seems this is making it all too complicated for its own good
What's wrong with testing @plane directly ?

Jim

@tig said:

Seems this is making it all too complicated for its own good

There is no doubt of that.

thomthom

@jim said:

Yes, well, I see that now. So it's just a string anyway.

No - it's nothing. it's nil until 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.

Jim

@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.

cjthompson

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?

MartinRinehart

@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.

&quot;Tell me what's goin' on. I ain't got a clue!&quot;

"Tell me what's goin' on. I ain't got a clue!"