Doppler Red shift With RGB

[Nathan]

Anyone know of a way to show the red shift (or blue shift, for that matter) of objects travelling at relativisitic speeds using the RGB colour scheme?

White objects can probably be reasonably red shifted just by lowering the G and B colour coefficients. However, I would really prefer to be able to use more than one colour. Anyone got any brilliant ideas?

 

[bloodbob]

I guess you could write a pixel shader to conver the RGB space into HSV and alter the hue and convert back to RGB but I still doubt that would produced very scienctific result really it has to be done in software.

 

[3dilettante]

This is an equation for redshift that I found:

(Observed wavelength - Rest wavelength)/(Rest wavelength) = (v/c)

It looks like this would have to be calculated in software, since there would have to be a bit of transforming frequency into an appropriate color.

Theoretically, one could find a red-shifted frequency and find where it would fit on a look-up table for frequencies for each color. It could be a small table with poor granularity, or a larger one for a more continuous range.

 

[Nathan]

Doing it in software isn't a problem.

A look up table would be nice, but I think finding one thta does the job might be quite difficult.

 

[3dilettante]

Here's a link to a page that seems to detail a mathematical way to convert a frequency to RGB, but I'm not versed in linear equations.

http://research.microsoft.com/~hollasch/cgindex/color/freq-rgb.html

 

[Nathan]

Thanks 3dilettante, apparently it wasn't that hard to find afterall. One of these days I'll learn how to use Google properly.

 

[3dilettante]

No problem.

 

[PSarge]

Anyone know of a way to show the red shift (or blue shift, for that matter) of objects travelling at relativisitic speeds using the RGB colour scheme?

White objects can probably be reasonably red shifted just by lowering the G and B colour coefficients. However, I would really prefer to be able to use more than one colour. Anyone got any brilliant ideas?

How about having three 1-d texures, one for each primary colour (RGB), that describe what colour the primary shifts to. You then sum them up to get your result. Maybe a little pseudo-code is required:

R, G, & B = incoming fragment colour (pre-shift);
v = relative velocity to viewer (scaled by some constant);
s = v +0.5; // Create a texture coordinate bias around 0.5 so we can do Red and Blue shifts

ShiftedRed   = texture1d(RedMap,  s);
ShiftedGreen = texture1d(GreenMap,s);
ShiftedBlue  = texture1d(BlueMap, s);

OutR, OutG, OutB = 0;
OutR += R * ShiftedRed.R;
OutR += R * ShiftedGreen.R
OutR += R * ShiftedBlue.R

OutG += G * ShiftedRed.G;
OutG += G * ShiftedGreen.G;
OutG += G * ShiftedBlue.G;

OutB += B * ShiftedRed.B;
OutB += B * ShiftedGreen.B;
OutB += B * ShiftedBlue.B;

Use the maths that 3dilettante posted above me to calculate the texture maps offline.

If fact....thinking about it. The red shift per object will be constant, therfore s is constant per object, and ShiftedRed/Green/Blue will be constant. Hence there's no need to do the texture look ups every fragment. Have the R, G, & B texture maps on the host as lookup tables. At the start of each primitive load the red shifted R, G & B into fragment shader constants, and then the program just becomes 9 Multiply-Accumulate instructions. (Which might be able to be written as DOT3's, but I can't be bothered to work it out)

Could be a nice effect

Edit: Grammar

 

[Colourless]

You are just doing a 3x3 matrix multiply on the 3x1 colour vector.

Using 3 dot3 is the way you'd do it, you've just got to construct the matrix correctly. Since the matrix will be constant as you said, you would just put it in the PS constants.

 

[Nathan]

The red shift per object will be constant, therfore s is constant per object, and ShiftedRed/Green/Blue will be constant.

The red shift is only constant if the object is moved directly towards or away from the camera. If an object travels past the camera and is offset slightly, then it is possible for the front of the object to be red shifted while the rear is blue shifted.

Unfortunately, I've just realized that this probably isn't going to work. For an object travelling at 0.99C the red/blue shifts are so much that it will shift the observed wavelength out of the visible spectrum. In some situations it will work, and in others it won't.

 

[ehart]

One thing to think about is that if you attempt to red-shift something that is rendered using an RGB color model, you may actually run into color-channel aliasing. It would be interesting to determine how many color channels it would take to avoid aliasing problems.

-Evan

 

[PSarge]

The red shift is only constant if the object is moved directly towards or away from the camera. If an object travels past the camera and is offset slightly, then it is possible for the front of the object to be red shifted while the rear is blue shifted.

So you're saying that it's possible for the front to be moving away from you, and the rear to be moving towards you. You'll forgive me if I'm a little skeptical of that. Sound like your object just tore itself apart.
Even if you're just saying that front and back move at different relative speeds to you when travelling at an angle, I still say "Huh?"

Unfortunately, I've just realized that this probably isn't going to work. For an object travelling at 0.99C the red/blue shifts are so much that it will shift the observed wavelength out of the visible spectrum. In some situations it will work, and in others it won't.

Sure, stuff moving that fast wont be visable, which is why you'd have black ends on your look-up tables. Be ok up to about 0.5c though (quick estimate).

Evan has an interesting point though. (Channel-aliasing) Guess you might see the intensity appearing to vary as the object got shifted.

 

[Dio]

Stand next to a train. The front can definitely be moving away from you while the back moves towards you...

 

[arhra]

So you're saying that it's possible for the front to be moving away from you, and the rear to be moving towards you. You'll forgive me if I'm a little skeptical of that. Sound like your object just tore itself apart.

It's entirely possible, and indeed unavoidable, if you're dealing with anything other than single-dimensional points. Consider the following situation:

t:
      <----  object
      .      observer
     
t+1:
     <----   object
      .      observer

t+2:
    <----    object
      .      observer

t+3:
   <----     object
      .      observer
     
t+4:
  <----      object
      .      observer

The front of the object is moving away from the observer, while the rear is moving towards the observer. Obviously, for smaller objects, the time period during which opposite ends are shifted in opposite directions is smaller.

edit: bah. beaten to it. my explanation comes complete with bad ascii art, though

 

[Nathan]

Sure, stuff moving that fast wont be visable, which is why you'd have black ends on your look-up tables. Be ok up to about 0.5c though (quick estimate).

Unfortunately, the really interesting distortion only really occurs at the higher end of the scale. Since that's the thing I'm really interested in, I guess I'll have to live with non-red/blue shifted objects.

Anyway, thanks for the help guys.

 

[Simon F]

Sure, stuff moving that fast wont be visable, which is why you'd have black ends on your look-up tables. Be ok up to about 0.5c though (quick estimate).

Unfortunately, the really interesting distortion only really occurs at the higher end of the scale. Since that's the thing I'm really interested in, I guess I'll have to live with non-red/blue shifted objects.

Anyway, thanks for the help guys.

If you're going to be modelling photons at relativistic speeds, I wouldn't have thought you could use the 'simple' models that are employed in most CG anyway.

 

[PSarge]

Stand next to a train. The front can definitely be moving away from you while the back moves towards you...

OK. I get what you mean, but that's gotta be one BIG train to be visible for more than a single frame while going along the tracks at 0.5c.

 

[Nathan]

If you're going to be modelling photons at relativistic speeds, I wouldn't have thought you could use the 'simple' models that are employed in most CG anyway.

What I'm actually doing is showing how objects appear to distort as they travel past an observer at a relativistic speeds. Since the vertices of the object are at varying distances from the observer, the time light takes time to travel from each vertex to the observer varies. At relativistic speeds, the light must leave the further away vertices earlier in order to arrive at the observer at the same time as the light from the closer vertices. The end result is a very funky looking object at 0.99C.

I was hoping to apply red/blue shift to the object as well, but I'm not sure I'll bother now.

 

[Simon F]

I was hoping to apply red/blue shift to the object as well, but I'm not sure I'll bother now.

I'd agree with that. The 'warping' would be fascinating enough, and you'd otherwise have to have it emitting infra-infra radio waves as it approached and ultra-ultra XRays as it went past.

It'd be one "hot" object but, I suppose, if it were travelling at that velocity it's very likely it'd also be emitting a bit of energy!


On a very tenuously related subject, a guy presented a paper at Siggraph that was using the VS/PS to model real-time fluid flow. For a joke he put in a model of the Star Trek Enterprise to show "how the flux gets into the warp core". He then showed how awful the Klingon vessels were.

 

[Dio]

OK. I get what you mean, but that's gotta be one BIG train to be visible for more than a single frame while going along the tracks at 0.5c.

I was thinking about doppler sound. I assumed that the light shift was going to be overexaggerated, for use in a demo or similar, not that we were actually talking about the speed of light