Schroedingers-Hat / jsphys

Libraries for physics simulation on javascript canvas
GNU Affero General Public License v3.0
11 stars 1 forks source link

Blackbody-based Doppler-shifting #2

Closed capnrefsmmat closed 13 years ago

capnrefsmmat commented 13 years ago

Add blackbody-based Doppler shifting to the SR simulator. Start with a near-white color temperature, and shift it based on the Doppler factor. Use this table to compute RGB values from the temperature:

http://www.vendian.org/mncharity/dir3/blackbody/UnstableURLs/bbr_color.txt

capnrefsmmat commented 13 years ago

Hm. Doppler-shifting only makes sense if we pick a central location that the objects are moving toward or away from -- the central location of our reference frame, for example.

@Schroedingers-Hat: Does it make sense to define, for the moment, the center of the canvas as the reference point, and objects moving toward it will be blueshifted? When we shift frames to another object, we can manipulate the screen so it ends up at the center.

If so, it's just a matter of computing each object's velocity towards the center of the screen, running it through the Doppler shift code I've committed to the "doppler" branch, and adjusting the fill color before painting each object. Shouldn't take very long once I've finished my exam.

Schroedingers-Hat commented 13 years ago

Cool. the centre of the screen (or rather the point 0,0 with v 0,0) is where our frame of reference is set. You are also free to consider X0 as a vector describing the displacement of an object relative to that point at any time. My plan was to project V onto X0 and use that for whatever is needed. (the magnitude of this result, excluding the time values will be the radial velocity). Bear in mind that V is actually a 3-velocity in that it is equal to the Energy-momentum vector divided by m.

Schroedingers-Hat commented 13 years ago

Changed your code an itty bit so that it worked for non-radially moving objects.

capnrefsmmat commented 13 years ago

Er. Can we stick to working on sane branches? The idea is to develop a new feature on a branch (like "doppler") until it works, then merge it into master. Now I'm not entirely sure where your changes went :-p

There's an excellent freely available book on git usage if you need it:

http://progit.org/book/

Anyway, after my exam today I'll hook this up to actually display colors.

Schroedingers-Hat commented 13 years ago

Thanks. I probably should have done some more reading on git before getting too carried away, sorry. The code on master implements both doppler shift and light delay now. I also cleaned up some sections, and made a bit of a mess of the new stuff. Added rotation and zoom, but they need sane controls (a,b rotate and -/= (backwards) zoom..don't ask)

capnrefsmmat commented 13 years ago

Okay, I've merged everything into the doppler branch and generally tidied up. Your changes ended up in gh-pages, so I had to merge with both master and gh-pages to pick everything up. From here on I'll keep the changes in doppler until everything is working, and we can merge them later.

capnrefsmmat commented 13 years ago

All right, it's looking good. Code's tidied up, merged, sorted, and generally fixed. Pretty fun to watch the redshifts happening live :D

Schroedingers-Hat commented 13 years ago

If we could extend this method to slightly cooler temps and fade to black it'd be more realistic. Thinking about how to extend it to cover the headlight effect is a good plan, too.

capnrefsmmat commented 13 years ago

I could extend the color table to cooler temperatures but I'd need another source for the data. Fading to black shouldn't be hard, though.

capnrefsmmat commented 13 years ago

http://www.fourmilab.ch/documents/specrend/ contains C code for computing the RGB color of an arbitrarily colored blackbody. It is complicated but doesn't look too computationally intensive; in any case, if the system turns out to be computationally intensive, we can memoize.

(That is, round to the nearest 50 or 100 Kelvin, and cache the result, so any star near the same temperature gets the precomputed RGB value rather than going through the blackbody calculations all over again.)

I think I'll try implementing that. We can get any blackbody we want.

I think the headlight effect should be a separate issue; I don't really know how to approach it.

Schroedingers-Hat commented 13 years ago

Had a look around, all I could find was this. http://www.hearth.com/econtent/index.php/wiki/Temperature_when_metal_glows_red/ Whatever we do will be approximate anyway, and the data you have will be based on assumptions about white balance. We could just pick colours that look nice, making sure to put a comment in somewhere. The other option is to wait for general doppler shifting code to be done. Then we can generate some values with the Planck function and doppler shift them ourselves. This http://en.wikipedia.org/wiki/Color_temperature seems to indicate that the colour gets outside the gamut of your usual display before it gets invisible.

capnrefsmmat commented 13 years ago

The Fourmilab code I found (and just compiled to test) seems to compute the RGB value for an arbitrary blackbody in no time at all, so I'll port that to JS. More general than just using a table.

capnrefsmmat commented 13 years ago

I got half of the code working in JavaScript -- it turns a blackbody spectrum into CIE XYZ coordinates correctly, but I messed up my math somewhere in the RGB conversion and it's giving the wrong results there.

capnrefsmmat commented 13 years ago

Ha! Fixed. I had a - lurking where I should have had a *. That was silly.

I'll do a bit more testing and then make the blackbody rendering depend on this, with a cache to the nearest 100K or so.

capnrefsmmat commented 13 years ago

Committed to doppler branch. Headlight effect can be addressed separately. This code will let us handle any arbitrary wavelength spectra as well, by supplying a function similar to bb_spectrum.