Interface idea Minkowski diagrams

[Schroedingers-Hat]

Display x,t y,t x,y graphs and allow the user to draw dx/dt, dy/dt and dy/dx are also doable maybe even go second derivative this will allow most demos to be created in seconds with no mucking about it also allows many demonstrations of basic physics concepts, orthogonality, basic kinematics etc Problem: calculating tau is non-trivial

[Schroedingers-Hat]

Problem solved: Calculate interval squared, take square root. Do this for each node, result is proper time Will have to restrict drawing outside of light cone

[Schroedingers-Hat]

Well, we've got the output for x,t now

[Schroedingers-Hat]

putting this here:

minkowski.js is in the minkowski branch. For now I just added another canvas further down the page, feel free to move it around/make it pretty There's not much info on what's going on, but it shows a blob for the object (later some icon or representation at t=0, and draws the object's world line over top.

If you feel like adding pretties, it needs: line at y=origin1 line at x=origin[0] lines demarking speed of light for a light cone (passing through origin with a slope of c)

Features I might add later: Another icon of the object, doppler shifted and displayed where it hits your light cone.

Light cones for other objects (have to think on exactly what this means a bit).

Intersection with forward light cone (ie. version of object that sees you)

Your world line (this will probably come with arbitraryPaths or interactiveObjects)

a button for swapping x with y (or second minkowski diagram?)

[Schroedingers-Hat]

Another feature: check marks on the lines demarking proper time.

[capnrefsmmat]

Do you intend to make the Minkowski diagram show the full shapes of each object? That'll put the burden on extendedObject and friends to draw in the Minkowski diagram and force each of them to have knowledge of how wide the diagram is, what it's scaled to, and so on. I think it would be significantly cleaner code if we could show a more traditional Minkowski diagram with colored lines, and move the drawing code to a separate class. Agree?

[Schroedingers-Hat]

They have to know most of this to draw the lines correctly. I was thinking scale the y coords by the timeScale, and the x coords by zoom. That way if the diagrams are top-bottom the x coords for both views line up (providing a slightly better intuitive handle on what's happening). My long-term plan was to save a simplified version of the original (non-contracted/rotated/aberrated etc) shape when the object is created (or generate/pass a bitmap sprite? I gather this is much cheaper) and put a small icon where the blob is now. Otherwise just drawing a blob with a line through it is fine. I was also thinking of adding some kind of 'interestingVertex' value to extendedObjects, this would have its own blob, along with an extra blob at the time that was simultaneous with the COM (ie. the event representing the front of the ship, according to the captain right now). Drawing all the vertices would be an an-neccesary tax on resources as most of them would overlap and you'd wind up with a line.

[capnrefsmmat]

They have to know most of this to draw the lines correctly.

I was thinking that we could significantly simplify code by just displaying generic shapes with labels (or just lines, as in a normal Minkowski diagram) and move the drawing code elsewhere.