what would be a use change in the viewer's position that isn't homomorphic with changing the object's orientation?

The data that I'm setting this up to graph -- my reason for doing this -- is large: maybe 1000 or more values wide (X); upto 100 or so deep in the Z dimension; and 16 (or even 32) lines (same Xs different Ys) plotted in each Z-plane.

Far too much data to take in as a single picture, but this is about exploring the data, not presenting it.

The desire is to be able to 'walk-in' to the graph and rotate it about me. To be able to walk down the lines looking for where crossovers occur; and then measure those crossover points reasonably accurately. And (ideally) to be able to click on 'unimportant' lines and have them disappear so as to clarify the view. Perhaps change the color of lines interactively or select and highlight particular sections of lines.

That's why I'm going for vector graphics. I've tried this exercise before several times, most recently a few years ago using Tk and Win32::Gui, but the former is just too slow and memory hungry; the latter too badly documented.

Many years ago I developed something that ran on a peculiar beast called an IBM 3270 PC which was effectively just an intelligent graphical terminal to several million £s worth of mainframe at IBMs uk research lab. It was going quite well, but the project was canceled and I moved on to a completely different project.

But I think that with SVG and the performance of JS in modern browsers, along with a half descent graphics processor, it ought to now be feasible.

I spend a lot of time looking at CAD models and assemblies with multiple coordinate systems, i.e. there's a global and then many of the parts have their own local, even with many instances of duplicate parts all rotated and shifted, each with their own local system, and I've never really thought about this as an issue!

I think in general when each part has its own coordinates one refers to partname->x, partname->y, partname->z (in much the same way you theaters use stage-left, stage-right and house-left, house-right.

For referring to a plane in a particular system it generally is partname->xy, partname->yz, and partname->xz where you'd refer to opposite faces either as + and - or by a coordinate reference on the third axis (e.g. partname->xz, y equals zero plane, partname->xz, y equals 1 plane). For something that's not a part (e.g. a graph of data) you'd use graphname instead of partname.

Things like top, bottom, front, back get really complicated because it's not unusual for the natural way to set a part on its own in gravity can be very different from how it's installed (with or without gravity) and what environment it might normally operate in (may or may not have gravity)

EDIT: to add the "y equals" to the description of plane naming

Okay. I can see that I've made a total hash of explaining this in words; so I'll try with the aid of a couple of diagrams ('scuse the crudity).

The first shows the 3 faces of a bounding box furthest from the viewer, complete with their grid (tick) lines and showing the local coordinate system (at the current rotations):

              +Z
              /________________________
             /\    \    \    \    \    \
            /  \____\____\____\____\____\
           /\  /\    \    \    \    \    \
          /  \/  \____\____\____\____\____\
         /\  /\  /\    \    \b   \    \    \
        /  \/  \/  \____\____\____\____\____\
       /\  /\  /\  /\    \    \    \    \    \
      /  \/  \/  \/  \____\____\____\____\____\
 +Y  /\  /\  /\  /\  /\    \    \    \    \    \
   \/  \/  \/a \/  \/  \____\____\____\____\____\
   /\  /\  /\  /\  /\  /    /    /    /    /    /
 -Z  \/  \/  \/  \/  \/____/____/____/____/____/
      \  /\  /\  /\  /    /    /    /    /    /
       \/  \/  \/  \/____/____/____/____/____/
        \  /\  /\  /    /    / c  /    /    /
         \/  \/  \/____/____/____/____/____/
          \  /\  /    /    /    /    /    /
           \/  \/____/____/____/____/____/
            \  /    /    /    /    /    /
            _\/____/____/____/____/____/_  
          -X  \                          +X
              -Y
[download]

Each of the points (ends of lines) is maintained internally as a 3D point (x,y,z) commensurate with the local coordinate system.

The boundingBoxDraw() code:

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

But, the same, single routine is used to draw the faces and gridlines. So, when drawing face?:

1. The x-coordinate selects the face. (Actually, one of two: either at minX or maxX depending upon the rotation.)

   And the 'horizontal' index counter has to set the z-coordinate of the line segments;

   And the 'vertical' index counter sets the y-coordinate of the line segments;

2. The z-coordinate selects the face. (Actually, one of two: either at minZ or maxZ depending upon the rotation.)

   And the 'horizontal' index counter has to set the x-coordinate of the line segments;

   And the 'vertical' index counter sets the y-coordinate of the line segments;

3. The y-coordinate selects the face. (Actually, one of two: either at minY or maxY depending upon the rotation.)

   And the 'horizontal' index counter has to set the x-coordinate of the line segments;

   And the 'vertical' index counter sets the z-coordinate of the line segments;

This diagram shows the 2D representations of the 3 faces from above:

   +Y                                +Y                               
+ +Z
 -Z +----+----+----+----+----+ +Z  -X +----+----+----+----+----+ +X  -
+X +----+----+----+----+----+ +X
    |    |    |    |    |    |        |    |    |    |    |    |      
+  |    |    |    |    |    |
    +----+----+----+----+----+        +----+----+----+----+----+      
+  +----+----+----+----+----+   
    |    |    |    |    |    |        |    |    |    |    |    |      
+  |    |    |    |    |    |
    +----+----+----+----+----+        +----+----+----+----+----+      
+  +----+----+----+----+----+   
    |    |    | a  |    |    |        |    |    | b  |    |    |      
+  |    |    | c  |    |    |
    +----+----+----+----+----+        +----+----+----+----+----+      
+  +----+----+----+----+----+   
    |    |    |    |    |    |        |    |    |    |    |    |      
+  |    |    |    |    |    |
    +----+----+----+----+----+        +----+----+----+----+----+      
+  +----+----+----+----+----+   
    |    |    |    |    |    |        |    |    |    |    |    |      
+  |    |    |    |    |    |
    +----+----+----+----+----+        +----+----+----+----+----+      
+  +----+----+----+----+----+   
   -Y                                -Y                               
+ -Z
[download]

The drawFace() function (currently) looks like this:

<Reveal this spoiler>

Note that the nomenclature of the 3 minOrMax? conditions from the drawBoundingBox routine, now make no sense in this routine. At this level, the first of the 3 conditions simply selects which position (end) of the face coordinate this face is drawn at.

The other two conditions aren't used at this (drawFace()) level. They are only used at the next level down, -- drawGrid(), which is called twice, once for the 'horizontal' lines, and once for the vertical, and each condition is only needed for one of those two calls -- to determine which end of each of the two sets of parallel lines, the tick marks, values and axis labels get drawn.

This is the drawGrid() (which should probably be called drawHalfTheGrid()):

<Reveal this spoiler>

Note that the horizontal & vertical nomenclature is wrong at this level. Because the same routine is drawing both, the two coordinates (Z&Y or X&Y or X&Z depending upon the face the grid is being drawn on), switch when drawing the two sets of parallel lines; effectively rotating the 2D face in the process.

I hope that explains the problem of naming things such that they make sense each (deeper) level of reused abstraction?

(Final note: I'm still not happy with some of the naming in the above routines, but I'm getting there; however, the general question about finding a good way to deal with the problem remains.)

---

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.

"Science is about questioning the status quo. Questioning authority". I'm with torvalds on this

In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked