Toggle for Doppler shifting can't work

[capnrefsmmat]

The checkbox switch for Doppler shifting and the keyboard shortcut are no longer possible to implement with the demo system. Each object gets its own options, and the defaults can only be set while the demo is being loaded. This means changing the Doppler setting requires reaching into every object in the scene, even though the Doppler setting seems less meaningful when independent objects may have Doppler on or off independently.

@Schroedingers-Hat: Is this an acceptable tradeoff? We get much more flexibility in demos at the expense of some user control. If you would like the Doppler switch to work, how should it interact with demos that have multiple objects with different settings?

[Schroedingers-Hat]

what about my previous suggestion of having two variables alwaysDoppler, neverDoppler then the test can be: alwaysDoppler || ((!neverDoppler) && this.Doppler)

[capnrefsmmat]

That works. I'll just have to make a magic button to handle three states rather than two.

[capnrefsmmat]

@Schroedingers-Hat: You currently have hotkeys for displayTime, showFramePos, and showVisualPos. Which of those do you want to function like the Doppler-effect switch, and which can I remove?

[Schroedingers-Hat]

interface is up to you As to my scheme, I tried to pick keys near wasd that had some mnemonic to what they did x shows position at current time (showFramePos) v for visual effects, or c for speed of light related something (one of these was showVisualPos) t for displayTime (put a time beside each object) will need to get more complicated/be removed with use of extendedObjects z is often used for doppler in literature, maybe make that the toggle for doppler effects

[capnrefsmmat]

Well, I was thinking we should remove a few of the switches for simplicity, and let the options be driven by the demo system. displayTime can certainly be handled by the demo system so extendedObjects can be accommodated. How important are user-controllable showFramePos and showVisualPos options when running a demo?

[Schroedingers-Hat]

not very for pre-recorded things? The main reason I wanted to have manual controls available was so that when a student thinks 'what if ....' they have a fairly good chance of being able to find out. The more general the controls, the more general the questions they could answer for themselves. Otherwise it may as well be pre-recorded.

Maybe just have a 'enablemanualcontrols' option or something? or did you want to avoid having to write in overrides for everything?

[capnrefsmmat]

Hm. So I think I agree that we should provide the options. We can certainly fit the buttons in our control box in the upper-right corner, I think. Perhaps we can provide a way to hide the controls for basic scenarios (make "advanced controls" a separate click-to-view, maybe), but we should make the controls work everywhere.

[capnrefsmmat]

29a8213226 creates a showFramePos switch. Just need one for showVisualPos now.

Or do we also want switches for showGamma, displayTime, and so on? That information may prove useful. We could simplify it by just doing on/default. No "force off", since giving people slightly too much information isn't catastrophic.

[Schroedingers-Hat]

That sounds good

[capnrefsmmat]

8e4c993 begins adding showTime. Question: If I draw the current proper time of the object in drawPast, aren't I being misleading? After all, the version of the object I'm seeing is in the past. Rather than this.COM.tau, what can I use to get the proper time as it was when the light was emitted that I now see?

[capnrefsmmat]

I'd guess this.COM.viewTime, although inertialObject's calcPast does strange things with this.viewTime and then thisViewTime. Bug?

[Schroedingers-Hat]

that's an.....interesting line, it's def supposed to be this.viewTime. That if block is there to handle the case where it's stationary/at the origin, so it probably hasn't come up very often. I should have set it up st you can use XView[3] The logic (inside the if block) is slightly flawed though, once I wake up a bit i'll fix it. edit: I see that's still slightly unclear, what I'm saying is: Use XView[3]...I think it's in metres right now so XView[3]/c.

[Schroedingers-Hat]

No, I remember now. That's the section that I did some complicated equations in seconds out of habit -- sure I mentioned that somewhere but can't find it. XView[3] is in seconds. This makes it technically incorrect, but as X0[3] is 0 most/all of the time it is having no effect. Assume it's in metres. It'll be wrong for now, but I'll re-derive that equation to be have the right c's

[capnrefsmmat]

I've taken the liberty of adding some documentation to inertialObject in 15ed966 so in the future I'll be able to understand its workings more easily. (I'd like to do the same for extendedObject soon.) Please fix any errors in my comment and keep it up-to-date so we don't lose track of things, like inertialObject.radialV, which appears to be entirely unused.

I'll use XView[3] for the showTime display. Why is X0[3] often 0 when XView[3] gives the current visible time? Shouldn't X0[3] be tau to match?

[Schroedingers-Hat]

X0 is slightly mis-named I guess, it should be x.By the time I'd figured out when I was keeping the particle it was already all over the shop so I didn't change it. It's constantly updated to be at t=0 and represents the four coordinates of the event that you see with showFramePos tau would be totally incorrect, unless you want the proper time of the object, in which case that's what you should display

[capnrefsmmat]

Makes sense. Implemented in b304742, assuming I've understood you correctly.

[Schroedingers-Hat]

hmm, now that I'm awake I think you do want tau. Or maybe both perhaps elaborate on what you want it to display? tau == what a clock on that object would be displaying right now -- probably what you want a user to see X0[3] == the difference between the reading on your clock, and the reading on your clock -- supposedly at least. useful for debugging XView[3] == the difference between the reading on your clock, and the reading that it had when the light from the object left it -- useful for debugging and somewhat informative as yet uncalculated but doable quantity (pastTau?) == what you would read off of a clock -- probably what you want for a user to see

[capnrefsmmat]

Now that you've done tauPast and viewTime, I think this bug is finished.