Naming ordinals (directions/sides/faces) in the presence of 3D rotation?

[BrowserUk]

With apologies, this is essentially the same question as I attempted to frame in Refactoring technique?, but I finally think I've got enough of a handle on the problem to ask the right question; but not yet the solution.

(Please excuse (or ignore) the presence of JavaScript code in the following; the question pertains to all languages, and I'm bored with mocking up Perl substitutes.)

In the code I'm refactoring I've (mechanically) abstracted out three recurrent conditions, without (previously) understanding what it was they really tested:

    var condX = ( ( this.Parent.Fi < 90 ) || ( this.Parent.Fi >= 270 )
+ );
    var condY = ( this.Parent.Fi >= 180 );
    var condZ = ( this.Parent.Th <= 0 );

Obviously, condX, condY & condZ are not great names. I've finally worked out what it is that they control. (For those coming to this fresh, the code constructs 3 reference grids around a graph (chart) that is rotatable in all 3 dimensions.)

1. condX determines whether the front or back face of the bounding box is drawn depending upon the current rotation.
2. condY determines whether the left or right face of the bounding box is drawn depending upon the current rotation.
3. condZ determines whether the top or bottom face of the bounding box is drawn depending upon the current rotation.

First off; those names were my "best guess" before I'd tied them down, and are not right.

But they demonstrate the real problem: All our words for ordinals/directions/etc. are tied to a point of view and our expectations

• Up is Top is Above is North is MaxHieght is ...
• Left is East is MinWidth is ...
• Back is MaxDepth is Away is ...

And ditto for terms like X-axis/horizontal and Y-axis/vertical, etc.

But when things can be rotated in all dimensions, left can become right; up, down; back, front, min, max; so naming things in code that can be called with stuff in any state of rotation becomes a nightmare.

Often, you can get around this problem by naming variables in terms of the model view: that is, pretending you are standing on the 'floor' of the bounding box and rotate with it (without gravity messing things up) and name them in terms relative to that viewpoint.

But equally often, and as is the case of the conditionals above, the ordinates being represented are relative to the viewer's perspective; ie. world coordinates. That is, the decision of what faces to draw is determined in terms of which faces are 'behind' the model, thus not obscuring the model (graph) from the viewer.

And that I think is the key. Whatever the orientation, the faces to be draw are the three of the six that are 'furthest' from the viewer; but even with that insight, I'm still stuck for how to name them. And as each of those conditions is reused 4 times each, I think they definitely do need to be named.

So to the question: what would you name them?

div

[Anonymous Monk]

use nautical terms that are the same related to each other regardless of orientation/rotation

bow, the front of the boat

stern, the rear of the boat, opposite the bow

port(left) when facing from stern to bow

starboard(right) when facing from stern to bow

keel, the bottom of the boat

mast, the top of the boat ... not exactly right but close enough :)

[davies]

"Fore" and "Aft" are used on aircraft, too, and thus might be more familiar than "bow" and "stern". But I think this is excellent. You might name your rotation operators on the same basis - ISTR that spacecraft call them "yaw", "pitch" and "roll". I think it's the same at sea.

Regards,

John Davies

[tye]

I might use some of Anatomical terms of location as I'm familiar with many of them for various reasons and they serve a similar purpose in giving precise language for talking about position relative to the body you are discussing regardless of that body's orientation or the relative position of you or the others you are addressing. Even those with nearly no experience with anatomical study are likely to be at least somewhat familiar with terms like "anterior", "posterior", and even "dorsal".

[Anonymous Monk]

Quaternions? Some 3D game programming tutorial might be of assistance.

[BrowserUk]

1. The nautical/aerospace/anatomical terminologies deal with the model-relative ordinals:

   and as such are the same as the man standing on the floor of the model and rotating with it; and they suffer from the same problem, namely: which end of the model is the bow/fore/face. If the model was a boat/plane/car/house/human, it would be (mostly) obvious, but for a chart?

   In addition, the anatomical terms have extra confusion that either the terms change, or their meanings change depending on whether you are dealing with an upright (human) or supine (dog/horse) vertebrate. And it starts getting really confusing when dealing with weirdos like flat fish.

   And finally, the terminologies are often verbose (Anteroposterior, rostrocaudal,craniocaudal, cephalocaudal), and mostly unfamiliar. I always have to look up port & starboard for instance

2. Yaw, pitch & roll:

   Define axis of rotation rather than ordinals; and do so in a model-relative manner; and whilst pitch & roll are fairly intuitive; I always have to think hard about yaw. (Quick: which way are you turning if you are experiencing negative yaw? And does it change, and if so, how, if you're upside down or climbing vertically at the time?(Rhetorical.))

My current thinking is that for the model-relative ordinals, you imagine standing on the 'floor' of the model facing the 'back' of the model (when in the 'normal' position) and minX/maxX, minY/maxY, minZ/maxZ are best, given that (for charts anyway) the axis ticks are usually labeled such that the min/max are obvious regardless of their orientation with respect to the viewer.

The much harder problem is naming the 3 of 6 faces that are furthest from the viewer, when the model can be rotated in any amount in any of the 3 planes? I still have no handle on how to term them.

Best try so far: farX is the face(left or right side) at either minX or maxX depending upon orientation; farY is the face(top or bottom) at either minY or maxY depending on orientation; farZ is the face(front or back) that is at either minZ or maxZ depending upon orientation. (Not great!)

[davies]

• which end of the model is the bow/fore/face

When you set the model up, "fore" is farthest from the user etc. After that, from the programmer's point of view, they don't change. If you need to give the user a reference, use X, Y and Z because most basically numerate users will have met the X and Y axes on graphs.

• meanings change depending on whether you are dealing with an upright (human) or supine (dog/horse) vertebrate

I find dealing with humans simplest for humans to understand. You don't need to represent every object as a human, just imagine a human standing on or in it or riding it or whatever.

• And finally, the terminologies are often verbose

Agreed. Fore(ward), Aft(er), Top, Under, Left & Right are all short, familiar and all have different initial letters.

• I always have to look up port & starboard

Although I've reverted to left & right above, it's easy to remember port as it's the side the passengers get in. This even applies to cars, except in countries affected by French revolutionary nonsense. Another commonly used nautical pair is "red" and "green". The mnemonic for this is "Port wine is red", hence "green" is starboard.

• Quick: which way are you turning if you are experiencing negative yaw?

Anticlockwise as seen by someone looking forward. It's the old 360 degree compass, protractor or whatever - if you're reducing the number, you're turning anticlockwise.

• And does it change...

Not from the model's point of view, or that of the navigating officer standing on the bridge. Again, I'm not sure whether you're trying to do this from the programmer's or user's point of view, but I think the two should be kept separate with location and conversion code if needed.

• you imagine standing on the 'floor'

Agreed

• facing the 'back'

Whatever fits your brain, but I think you're making problems for yourself here, as this is the opposite of how the user will see (and therefore think about) it.

• I still have no handle on how to term them

This is where I need to know the purpose of the naming. If it's for the programmer, I'd stick to the original "fore", "port" or whatever. For the user, I'd suggest writing to as many potential users as you dare and asking them what they would use. Or even allow each user to name their own via a config file or whatever.

As I've indicated, I think the answers may change depending on what the purpose is. I understand that commercial confidentiality may preclude giving more details in a public forum.

Regards,

John Davies

[BrowserUk]

When you set the model up, "fore" is farthest from the user etc.

But the model rotates in 3D. The programmer using the library may choose to initially display the chart with any orientation; and the user may rotate it to any orientation.

I find dealing with humans simplest for humans to understand.

The point is, anterior means in-front for a human being; but means below, towards the ground for a horse; so the obscure terminology would be ambiguous even to those few who are familiar with the medical/biological/anatomical terms; depending on whether the come from medical/veterinarian/piscean fields; and more so for programmers.

Anticlockwise as seen by someone looking forward.

I did say it was rhetorical; but ... the lookout on watch on one ship calls down to the helmsman: "The ship coming towards us on the bow is yawing to port. Take evasive action!".

Does the lookout mean the other ship is yawing to its port; or the port of the ship he is on?

And if the same message is being sent to the helmsman from an observer on shore, does that observer mean "your port" or "his port"?

And if teh observer is in a helicopter overhead; does he mean the helmsman's port, the other ship's port, or the helicopter's port?

And is the rule: pass the port to the right? Or left? :)

facing the 'back' -- Whatever fits your brain, but I think you're making problems for yourself here, as this is the opposite of how the user will see (and therefore think about) it.

Hm. Didn't you just say: "fore" is farthest from the user. And isn't fore the same as front the same as your nose. Ie. Facing the same direction as the viewer.

This is where I need to know the purpose of the naming. If it's for the programmer

As I mentioned in the OP, this is purely for (re)naming the variables within the program. (I think the original author must have had a stutter; because almost without exception, every variable in the code is called xx, yy, uu, vv, gg, pp, mm, nn, dd, ii, jj etc. which makes the function _BoundingBoxDraw() pretty much unreadable.

I've refactored that huge, repetitious function into:

function _BoundingBoxDraw( ) {
    var frontOrBack = ( ( this.Parent.Fi < 90 ) || ( this.Parent.Fi >=
+ 270 ) ); 
    var leftOrRight = ( this.Parent.Fi >= 180 );                      
+          
    var topOrBottom = ( this.Parent.Th <= 0 );                        
+          

    drawFace( this, 'z', 'x', 'y', 0, 0, 1, topOrBottom, frontOrBack, 
+leftOrRight );
    drawFace( this, 'y', 'x', 'z', 1, 2, 3, leftOrRight, frontOrBack, 
+topOrBottom );
    drawFace( this, 'x', 'y', 'z', 2, 4, 5, frontOrBack, leftOrRight, 
+topOrBottom );
}

Where drawFace() is:

<Reveal this spoiler or all spoilers in this node or all in this thread>

And drawGrid() is:

<Reveal this spoiler>

Which I believe is a vast improvement, but there is still work to do. In particular, the variables/parameters named cond1, cond2 & cond3 need urgent attention. And that is the crux of the problem. Those conditions determine which 3 of 6 faces (along with the associated gridlines, axis ticks and labels) of the bounding box are drawn, and that is determined by which of each pair of opposite faces are furthest from the viewer. Thus, any form of model-relative naming scheme is meaningless because which faces are drawn is determined entirely with respect of the viewpoint.

Whilst the names for those conditions work (sort of) for the top level code where the entire bounding box is being considered, once you get down to drawGrid(), the naming convention falls apart because the same routine is called to draw the grid lines on all six faces, so anything X/Y/Z, left/right/up/down/front/back, or any other model-relative terminology doesn't make sense at that level.

Ie. The horizontal and vertical gridlines on the 'back face' flow x-x and y-y respectively; but on the 'bottom face' they flow x-x and z-z; and the 'left face' z-z & y-y respectively. And that's before you rotate the thing and up is down, left is right, front is back; or somewhere in between.

[soonix]

Don't know if this muddies the waters even further, but I think you actually have three coordinate systems:
• the "object" (what you call "model-relative")
• the "viewer", who could look "towards" the object or away from it, or sideways...
• the "room" where both "object" and "viewer" are located. This is where I would use x,y,z, although I think they usually are connected with the viewer...

[BrowserUk]

I think you actually have three coordinate systems:

That makes sense for 1st person shooters and the like; but in this case, the viewer is constrained to looking pretty much directly at the model because looking elsewhere, there is nothing to see.

I do have the desire to loosen the constraints somewhat to allow the viewer to move his viewpoint into the (zoomed) 3D graph, which might present a further challenge, but I'm a ways off that yet.

[karlgoethebier]

"Quick: which way are you turning if you are experiencing negative yaw?"

I assume it's just a jump to the left.

I couldn't resist ;-)

Best regards, Karl

[RedElk]

Your description brought to mind a numbered cube. I would name each variable numerically as a set of parallel planes (e.g. left/right = #1/#3, front/back = 2#/#4, top/bottom = #5/#6), like a die. Thus, roll the die, if var planes1_3 becomes oriented such that it now represents the front/back, I can visualize either var planes2_4 or var planes5_6 as the new left/right.

[BrowserUk]

Okay. So the view you have is:

  +-------+
  | o   o |
  |   o   |
  | o   o |
  +-------+

What number face is point right as you observe it?

In general, substituting numbers/colours/directions/points of the compass doesn't change the problem.

[RedElk]

Well, if I knew the initial layout prior to the applied rotation (e.g. left/right = #1/#3, front/back = #2/#4, top/bottom = #5/#6), then seeing #5 I could reason that the right frame is #3. But, mmm, it's not that easy is it?

[karlgoethebier]

You might take a look at Flight dynamics as well as Roll-Nick-Gier-Winkel ( roll-pitch-yaw angle) for some further inspiration. Unfortunatly the article is in German. Nobody is perfect ;-)

Update: Perhaps i should have read what you wrote above...

Update 2: You might also take a look at Reference Coordinate System provided by AUTODESK

Edit: Fixed wrong link to AUTODESK coord article.

Best regards, Karl

[Don Coyote]

Just some thoughts

• The need to name these positions.
• You are confident these positions need to be named. Do they actually? See next.
• Think outside the box tetrahedron
• there are three coordinates which relate to a point in a system. This does not necessitate that a 3D model inside the system would be a cube. Would you be concerned about naming all the sides of an octahedron. Maybe there is scope for a tetrahedral model to navigate such a system.
• Dimensional viewpoints
• In your explanation, you show a transference of ideas up from the 2D to 3D. How would transferring the 3D to 4D look (or vice versa). Could this line of thinking help break-down the understanding of the 3D co-ordinates.
• GPS already solves something similar to this?
• GPS appears to be a problem with similar facets, using four co-ordinates within a 3D system to locate a fifth position. It would seem that approach uses a semi-octahedral solution. Perhaps look at that solution for inspiration.

In thinking about this I mostly realised that naming conventions tend to be relative. I may be walking forward on the planet, but what direction is that relative to a moving position in the Andromeda galaxy. I like the idea of what you are doing, hopefully this will inspire something in your chain of thoughts.

---

^{just another monk prayer}