I do have the desire to loosen the constraints somewhat to allow the viewer to move his viewpoint into the (zoomed) 3D graph
Other than "zoom", what would be a use change in the viewer's position that isn't homomorphic with changing the object's orientation?
| [reply] |
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.
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] |
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
| [reply] |