|
4-26: I'm rewriting the vis from the ground up in a somewhat OO
style. At the core, I have a working Matrix4d and Vector4d, with
matrix inversion. The GuitarString can display the first state,
but I haven't tested animation yet. The BridgeForce graph is also
apparently working but untested. I have a basic Line class that's
just the x-axis from -1 to +1. I'm sticking to my design decision
that all Displayables render into the box from (1,1,1) to (-1,-1,-1).
The class-user moves, rotates, and scales it with GL transforms
before calling Displayable::Draw(). All a line needs to know is
its color. Sweet, huh? It's a bizarre way of programming -- I'm
not sure whether to call it functional (because of the innate recursion)
or procedural (because GL forces a state-based programming style).
To do: make sure that the hacky class I made to wrap glut menus
is really working once I plug in all the features it controls. Get
the mouse controlling scrolling and rotation in the guitar-string
window (which will be a pretty large task) and controlling time
in the force-graph window (which I'll do right now).
Hmm -- I tried to decide where the mouse-click handling logic should
be, and realized that I need whole classes containing each viewport
along with its Displayables and interaction functions. This is the
kind of cheezy old-school object-based design that I hate. "A class
represents a category of real-world objects." So I'm going to go
outside and read a novel and pick this up tomorrow.
5-01: The above TODOs and testing are accomplished, everything
but mouse-rotation of the PerspectiveViewport containing the GuitarString.
Mouse-based shifting and zooming of that view are done. I dealt
with my design problem by allowing the mouse logic to go inside
the PerspectiveViewport, of which the viewport with the GuitarString
is an instance. The viewport can do these manipulations without
knowing what's displayed in it, so all the logic for connecting
objects and their viewports is in the main CC file. I've avoided
the design problem I ended with above—having wrapper classes
that contain the viewports and the objects they display—the
only connection between them is in the CC file:
string_viewport.apply();
guitar_string->display(&string_viewport);
I'm sure I'm gaining some insight into the third goal on my main
page: "Learn techniques for rapidly changing a mid-sized app".
Don't know what they are yet.
|