Do you pay attention to the Component Axis?

todd burch

I'm working on a plugin for wood-related stuff that will be aware of a component's length, width thickness. This translates into x, y and z axis values, or red, green and blue if that's your preferred terminology.

What I've surmised is that there does not seem to be a standard for what axis is width, depth (thickness) or height (length) axis settings. For my drawings, I have settled on x (red) being width, y (green) being thickness, and z (blue) being length. When the component axis are set this way, my plugin works wonders.

I have also been asked to infer a wood component's length based on an applied material (aka, wood grain). This can be done, but I have not tackled that yet.

So my questions are

Do you pay attention to the component axis when drawing assemblies of components?
What axis do you use for length, width and depth?
Is there a standard I'm not aware of?
Would it be reasonable for a plugin to assume the shortest dimension is the thickness of the component, and the longest dimension to be the length?
Thanks, Todd

thomthom

Normally red(x) is width, green(y) is depth and blue(z) is height. But it's only Z I pay strictly attention to. red/green might swap.

dale

ditto on that

Mike Lucey

Todd,

I would agree with the guys and on looking at how SU opens, its reasonable to 'read / look' from left to right so green for length and red for depth.

Mike

Wo3Dan

@unknownuser said:

......For my drawings, I have settled on x (red) being width, y (green) being thickness, and z (blue) being length. When the component axis are set this way, my plugin works wonders.
....
[*]Would it be reasonable for a plugin to assume the shortest dimension is the thickness of the component, and the longest dimension to be the length? [/list]
Thanks, Todd

%(#FF0000)[More than most likely because you wrote that particular plugin.
You may want to change axes depending on what others answer here, I hope.]
IMO by "reading" the screen from left to right:
Red (X) for length (screen length / red points right in frontview)
Green (Y) for width (screen height / green points north in planview)
Blue (Z) for thickness or height
By doing so it's more like SU's conventions. Think of 'Glued to' components where blue takes a special place.

Red and green could be swapped but also take any screen into account.
Anyway, blue for length does not sound logic.
Also, like when drawing on paper planview plays a major role. Length would be left <=> right

Wo3Dan

todd burch

Here's the default returned information from how we get dimensions for a component. (its bounding box)

I see that Sketchup uses the Y axis to infer height, (in this case it is the component's thickness, but that is arbitrary), the X axis to imply width, and the Z axis for depth. That goes against my logic, where Z ("up" towards the sky) would be height, while Y, which is "deeper" (further away) in the standard view, from the viewer, should be depth. Width, as it is implied in bounds.width, makes sense.

I guess what I am hearing is that I have depth and height backwards, and I should be using (because most people do this?) the Y axis reading (bounds.height) to get "length".

Now, for clarification... Thomas, dale and TIG all use:

red for width (which is bounds.width)
green for depth (which is bounds.height)
blue for height (which is bounds.depth)
And Sketchup returns
red for width
green for height
blue for depth
And I have used
red for width
green for depth (thickness)
blue for height (length)

And Thomas and dale TIG pay strict attention to Z for length or height measurements (which is bounds.depth).

And then Mike does green for length and red for depth. I guess width is blue (aka, UP?)

I'm starting to think that Sketchup screwed up the naming of the bounds.height and bound.depth and got them backwards.

I guess I'm getting (I've been? I am?) confused (can't imagine why) by the terms width, depth, length, height and thickness.

In my book, height has always been a measure of unit from the ground (x/y plane) to the sky (up Z).

Now... (thinking and pondering...), perhaps this is the reasoning for the terms. On a 2D cartesian coordinate graph, Y is height, so perhaps it's a carryover into 3D, and it would also make sense to name the measure "depth" to represent the distance from the viewer to the 2D graph, and beyond. So this could possibly explain Sketchup's method names then.

So my stupid question of the week would be... if the depth, width and height terms are indeed a carryover from 2D into 3D, why in tarnation isn't the sky at the top of the Y axis and why isn't the blue axis pointing at my chest when I open SketchUp?

I'm so confused.

todd burch

Sorry Wo3Dan - left you out.

I agree - blue would be height, and red and green can be swapped for the other two dimensions.

If length doesn't make sense to you for height (which it does to me), and you put width for green, the you put red for length, which could also be called depth. Right?

length=height has made sense to me, because width = width, and thickness = depth. But, I am not 6 feet long, I am 6 feet high. My foot is 12 inches long and 3 inches wide, and is probably 2 inches thick from top to sole. But the ocean has a great depth.

Oh geeze.

Someone tell me what to use.

thomthom

I would not bother with what SU labelled the bounds.

I think of the axis as X,Y,Z - where Z is upwards to the sky. Then mentally translate that into these red,green,blue colours.
To me. X is the axis parallel to my face - so I see that as the width, which made Y the depth.

As I mentioned before, I some times swap them around, as all I change axis for is to get inference lock.

If there is a plugin that require a certain behaviour, that's probably be an incentive to me to pay better attention to the X and Y axis. But I can see that how X and Y is interpreted could be different from person to person.
So maybe an option to choose from, what X and Y should mean?

TIG

Ditto - but if you might swap components then you should give them consistent axes - so for 'odd bits' any axes/origin is not a problem, but for trim, handles etc you need a common axes/origin as a wise idea for facilitating easy swapping out etc...

TIG

The SUp bounds method returns width/depth/height in a way that doesn't correspond to XYZ/RGB and commonly accepted conventions...

pilou

And with this that is another story