Demo system concepts

[Schroedingers-Hat]

Explain to me a bit better how you want the json/demo system stuff to work. Do we want to elegantly handle incorrect input, or assume the user know what they're doing? Define exactly what you mean by shape, do you want this to be the non-contracted shape as 3d points? Do you want some facility to input a contracted shape? List all the options you think would be useful per object. Do you want some facility to input times (the train left station x at time y type of situations)? If so, metres, seconds or optional (something like METRES and SECONDS in the variable names)? Do you want units as above? How much separation do you want between scene and extendedObject acceleratingObject type classes? I can probably make everything except creation (which will vary quite a lot) and something along the lines of update(timeStep) and draw(scene) the responsibility of the respective classes.

What about shapes? I've written a general purpose function for padding straight lines which can be used in object creation. Do you want a number of primitives -- sphere, circle, polygon, some kind of smooth curve (filled, non-filled) etc? Or perhaps some kind of external editor and just save vertices/triangles/quads?

Haven't written much, but I have had some thoughts on arbitrarypaths. A method which is looking feasable will involve a series of events, and a list of how you want the object to behave between events. May as well plan how we want to handle that while we're at it. From the demo creator, I'll need a list of four-vectors (events), and some kind of option flag for every connection (ie. 3 events, 2 flags for 1,2 and 2,3). Possible options: Constant velocity -- object will move from one event to another in a striaght line (inertial) constant proper acceleration constant home-frame acceleration For the constant accelerations, an additional parameter is needed to define the path. This could be acceleration or final velocity. The initial velocity could also be set manually rather than taking the last point's final velocity.

We need to decide what to do if the events listed are a space-like interval apart, as the object cannot be created and presumed to behave sanely.

I still haven't gotten around to reading up on how to use the object model efficiently, but I'll try and work that in, too.

[capnrefsmmat]

Do we want to elegantly handle incorrect input, or assume the user know what they're doing?

The demo JSON includes optional parts, but if they screw up the syntax, the JavaScript won't run. That's not my choice -- that's how JS works.

Define exactly what you mean by shape, do you want this to be the non-contracted shape as 3d points? Do you want some facility to input a contracted shape?

Currently I think non-contracted shape is the way to go. Objects are laid out in a reference frame coordinate system, then the demo "frame" option is applied to switch to the frame of an object, and then the objects are set in motion.

List all the options you think would be useful per object.

So far, showVelocities, showGamma, and showDoppler seem useful. Labels are exceedingly useful. The rest of the options should be for specific object types; for example, mainSequenceStar can take a Lum option to determine its luminosity.

Do you want some facility to input times (the train left station x at time y type of situations)? If so, metres, seconds or optional (something like METRES and SECONDS in the variable names)? Do you want units as above?

For an option named, say, "motionStartTime", I'd expect to provide it seconds. However, we could provide constants to translate between units, so for example a METERS constant would provide the conversion factor from meters to seconds, and so I'd write 4.3 * METERS. Likewise with position and momentum vectors, the default unit should be meters, but I should be able to specify 7 * LIGHT_SECONDS or whatever.

How much separation do you want between scene and extendedObject acceleratingObject type classes? I can probably make everything except creation (which will vary quite a lot) and something along the lines of update(timeStep) and draw(scene) the responsibility of the respective classes.

That's probably a good idea. extendedObject-type classes should present a minimal common interface (init, update, draw) which scene uses, and handle the rest of the stuff themselves.

What about shapes? I've written a general purpose function for padding straight lines which can be used in object creation. Do you want a number of primitives -- sphere, circle, polygon, some kind of smooth curve (filled, non-filled) etc? Or perhaps some kind of external editor and just save vertices/triangles/quads?

If extendedObject just wants vertices, I'd provide vertices. But then I'd make a few functions which generate vertices, like triangleAt(position, base, height) or whatever. So I could specify shape: [[34,52,1],[1,5,2]] or shape: [triangleAt(), squareAt()...].

[Schroedingers-Hat]

Do you want to define momentum or velocity, 3 or 4? Ie. which of these: dX/dtau, m * dX/dtau, m * dX/dt, dX/dt, dx/dt, m * dx/dtau, dx/dt ? Is kinetic energy and direction as a method of defining this worth implementing? Which units? Relevant fact: for massive objects the timelike component of dX/dtau or dX/dt is defined by the other three components.

[Schroedingers-Hat]

If extendedObject just wants vertices, I'd provide vertices. But then I'd make a few functions which generate vertices, like triangleAt(position, base, height) or whatever. So I could specify shape: [[34,52,1],[1,5,2]] or shape: [triangleAt(), squareAt()...].

What about polygons vs lines? Do you want it to stay as a stroked path or define triangles/quads. If I write something for polygons, do you want stroked as an available option? A common type of primitive (and one supported by openGL) is a strip of triangles generated along an array of vertices. One advantage of using quads might be that we can apply textures using simple methods in canvas. Use multiplicitive compositing to apply color and combine placing a transformed grayscale image with fill() This will also work with triangle strips in 2D (just place the quadrilateral image over two adjacent triangles). If you want multiple strips, that probably isn't too hard either, I'm fairly sure the slow part of drawing is fill()/stroke(), so having lots of beginpath closepath pairs hopefully won't be an issue.

[capnrefsmmat]

Do you want to define momentum or velocity, 3 or 4?

Probably 3-velocity.

Ie. which of these: dX/dtau, m * dX/dtau, m * dX/dt, dX/dt, dx/dt, m * dx/dtau, dx/dt ?

I want to be able to say "I've got an object approaching me from the left at 0.9c, one from the right at 0.9c, and I'm moving up at 0.5c" and have that be what I see in the demo. Then, with the frame option, I want to be able to switch from my frame to any other frame. As I understand it, dX/dt or dx/dt is what I want here, but I'm not familiar enough with the variables.

Is kinetic energy and direction as a method of defining this worth implementing?

I suppose if we want to simulate a particle accelerator to show how length contraction can be verified there, it's be nice to say "14.3 MeV" and get the right velocity. That's a bonus feature, though.

Perhaps we can make velocity mandatory and KE optional. If KE is present, the vector specified for velocity will be taken to be the direction of motion, and will be scaled to the correct magnitude to create that KE. Sound good?

Which units?

For velocity, the default should be m/s, but we should support units of c easily. (Just type 0.9 * c, I think.) For kinetic energy, KeV, MeV, and GeV. For momentum, I have no idea; what's contentional?

What about polygons vs lines? Do you want it to stay as a stroked path or define triangles/quads. If I write something for polygons, do you want stroked as an available option?

Sure. I should be able to specify stroked or filled when building objects.

[Schroedingers-Hat]

Idea: Form based demo builder, choose different objects from drop-down menus, fill in parameters for said objects with more menus, or text boxes for position with options for units etc.

Another one: Saving the current state as a demo, and editing captions/properties after. Allow the user to cruise around and place objects, then once they are happy click save/edit and the contents of carray are exported to the format demos.js uses -- also useful for answering questions students might have, they can save a certain state and set the caption to 'why doesn't the first twin age more from the second twin's perspective?' or similar.

[capnrefsmmat]

To support those features, I'd have to rebuild the demo system to load demos from independent JSON files, so one could easily add new demos without having to work in demos.js. (If the program has to modify itself to run new demos, something is wrong.)

To do that, I'll need to rework the demo syntax. The static JSON can't use extendedObject or linesPadder to construct itself. It has to indicate to the system "build a sphere" and let the demo loader fill in the points.

Any preferences on the syntax to do this?

[Schroedingers-Hat]

No real preference, something like "shapeType" : "aSphere", "shapeParams": [100,1] seems sensible unless you think of something else. Would break rasteroids, but we can make that some kind of separate thing, or support procedurally generated objects later.

[capnrefsmmat]

I'm going to close this and create new issues for specific topics, like using independent JSON files loaded with XHR for the demos.