- 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
| [reply] |
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:
And drawGrid() is:
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.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
| [reply]
[d/l]
[select] |
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...
| [reply] |
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.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
| [reply] |
| [reply] |
| [reply] |