Improve Minkowski diagram UI

[capnrefsmmat]

So when I was preparing for my presentation on Friday, I thought about using our Minkowski diagrams for illustration. I ended up deciding against it and just using the 2D view, but while I prepared I realized our Minkowski diagrams are hard to read.

I committed a couple changes while I prepared, and you can see my restyled diagrams on master. I made the axes less prominent and brightened worldlines, so the diagrams would be easily understandable on a low-contrast projection screen. I eliminated the light cone background for contrast as well; I think we need to show the light cones, but I'll play with a better way to do so.

Other things to improve upon:

• Light circles are depicted as light going in only one direction.
• I've had some complaints about the Minkowski diagrams moving the worldlines, rather than simply moving the line depicting "now". We could pick a representative time interval for each demo and show a static view of that interval, redrawing when the simulation runs past that time. We'd need to make the "time zoom" feature user-accessible for this to work well. And redrawing the diagrams only occasionally would fix issue #99.
• Could we draw a faint grid showing scale? Even if we don't get a 1:1 aspect ratio so light is perfectly diagonal, a grid would make it easy to tell what speed an object is traveling at.
• We need a way to depict the spatial extent of objects. For the relativistic train demo, I draw separate "front" and "back" extendedObjects so they're visible on the Minkowski diagram, but we could use the bounding box of objects to draw two parallel lines, and perhaps shade the region between them lightly to be clear.

@Schroedingers-Hat: Any feedback on these suggestions?

[Schroedingers-Hat]

All of them sound good. Lots of the code I wrote is slowly turning into a clusterfuck of almost-redundant code and interdependance on things that could be modular. This has been one of my disincentives for working on it lately. Things like holding time still and moving a 'now' through the minkowski diagram work well with that change from a local to a global coordinate system I was talking about. That entails overhauling a large portion of the way the maths is done (essentially building a 3+1D or 2+1D camera in much the same way as 3D cameras in traditional CG are built), which seems like a good opportunity for a clean break from some of the stuff I would have done differently in hindsight.

[capnrefsmmat]

I'm going to implement static Minkowski diagrams with moving worldlines. I'm just adding scene.t to coordinates in drawXT, making it yet more complicated and nasty. Oh well.

[capnrefsmmat]

The above commit starts on this. It mostly works, apart from a defect in the relativistic train and Han/Greedo demos on the second step. For some reason the frame change messes up the worldlines -- the dots indicating present location are correct, but the worldlines are in the wrong places.

I'm probably doing something horribly wrong, but I can't be bothered to figure it out at the moment.

[capnrefsmmat]

@Schroedingers-Hat: I'm not sure what's going on with the diagrams during frame shifts. It looks like something related to the treatment of COM.initialPt during frame changes. At least, that's the only thing used for drawing worldlines that's not involved in drawing dots. Do you know what the problem might be?

[capnrefsmmat]

Somehow if I increase c from 3 to 20 or 100 the diagrams look perfect.

I'm figuring out more of the drawXT code as I go along, so perhaps I can get somewhere. This is strange.

[capnrefsmmat]

Changing c makes perfect sense, because high c makes the scene no longer relativistic and changing frames doesn't change time very much. So the problem is something with initialPt being at the wrong time. Hmmmmm.

[capnrefsmmat]

@Schroedingers-Hat: Any ideas on fixing worldlines after frame shifts? I thought you had come up with something, but haven't had a chance to talk since. We're looking to use the code in a few days.

[Schroedingers-Hat]

I effed about for a bit with something I thought would work but I hadn't taken something into account. The only way I can think of is to insert an event into the world which all minkowski diagrams reference, will poke at it now.

On Tue, Sep 11, 2012 at 6:02 AM, Alex Reinhart notifications@github.comwrote:

@Schroedingers-Hat https://github.com/Schroedingers-Hat: Any ideas on fixing worldlines after frame shifts? I thought you had come up with something, but haven't had a chance to talk since. We're looking to use the code in a few days.

— Reply to this email directly or view it on GitHubhttps://github.com/Schroedingers-Hat/jsphys/issues/128#issuecomment-8436361.

[capnrefsmmat]

So why is it that the present time dots appear to trace the correct trajectory, when the worldlines don't? (I probably already asked you this, but I forgot the answer.)

[Schroedingers-Hat]

Because they are subtly off by a factor of gamma, once you trace the worldlines you see the trajectory is still drifting a little, alternatively you can have the dots travel one proper second per real world second, but then they do not match any given 'now'. You could do a bunch of calculations to re-create the discarded (or non-existant) information about the state of the world after the first transformation each frame, but that would be a massive kludge fest and require tangling the code even further than it already is.

Basically it all comes from the poor decision to think of objects as things which need updating, rather than descriptions of a line, in the first place.

Simplest is to add some kind of logic to the main loop (such as an event which is transformed)

There is something a bit special about the initial state (before a transformation into one of the object's frames) as this is where all the initialPoints are specified (unless they have a time specified :/). This information can be used fairly easily to create a view centred on the event that was at the origin in the initial frame (basically tau == 0 for all objects) but this will not represent now in any different frame.

When was 'a few days' by the way?

On Fri, Sep 14, 2012 at 12:12 AM, Alex Reinhart notifications@github.comwrote:

So why is it that the present time dots appear to trace the correct trajectory, when the worldlines don't? (I probably already asked you this, but I forgot the answer.)

— Reply to this email directly or view it on GitHubhttps://github.com/Schroedingers-Hat/jsphys/issues/128#issuecomment-8529322.

[capnrefsmmat]

If the diagrams are static, how about we draw them once, at the beginning of the animation, and then leave them be? We'd only need to respond to zoom events and sudden frame changes. Perhaps inertialObjects need a realInitialPt which is the base for their worldline.

"A few days" would be around now, as it happens, although the prof has been out of contact.