Meters to Pixels (day 110)

Hello,

Can someone please either point out the error in my thinking to me, or am I right?

Back on day 110 the following line was added to supply a value to convert from the width of the virtual monitor to pixels.

result->metersToPixels = (real32)resolutionPixelsX * widthOfMonitor;

My issue is that the resolutionPixelsX only has units of pixels. It's not really a resolution (px / m or px/m^2), it's just pixels.

I'm only on day 118 so I took a quick peak at some more recent code and saw that the previous line has become:

real32 MetersToPixels = (real32)DrawBuffer->Width*WidthOfMonitor;

which hasn't really changed any, it just moved files (although it looked like a lot of cool stuff has been added since day 117 :)). Anyhow, I don't understand how this value can be called meters to pixels. It is multiplying pixels by meters, (# of pixels of the buffer width) * (width of monitor). Using this conversion to go from meters to pixels would give:
meters * pixels * meters, for a value with unites m^2 * px.

Should MetersToPixels be the number of pixels of buffer width / width of monitor (px / m)?

Doing that change of course requires changing the focal length and distance of camera values to get the same screen shot. I found a focal length of 0.25 and distance above target value of 8.6 to give an almost identical image.

Thanks in advance for clarifying my misguided thinking, or confirming I am right ;)
We'll have to go over this on-stream, but that does look like a bug - it should be DrawBuffer->Width / WidthOfMonitorInMeters, giving the units pixels / meters, which would be the right units for the conversion. Since the choice of WidthOfMonitor is kind of arbitrary, I guess we just never noticed this???

- Casey
Okay, well I'm happy to know that if I am not thinking of something completely obvious, at least I'm not alone :) and you did even say when you typed it in "one over the width of the monitor"

But yeah, it makes sense that since the width it total arbitrary and all that ends up mattering is that focal lengths and widths provide correct ratios it doesn't matter.

Seems like the worst math is when values become arbitrary so that one way doesn't blow up in your face. At least then you know something is wrong!