Any math geniuses here want to check my math?

[oshunluvr]

My lead programmer - who was a spacial relationship genius - quit and of course I really need him now.

Here's the situation: I have 12 monitors arranged in a circle that depict a Horizontal Field Of View (HFOV) of 360°. The initial setting is 30° per monitor - 360° ÷ 12.

These monitors have bezels. To compensate for that, we enlarge and trim the image slightly so that moving objects appear to pass behind the bezel rather than jumping across.

In the current 12 screen configuration, this results in the 12 screens showing 29.22° of a 30° image - a "zoom" amount of 0.78°.

I want to increase the monitor count by 2. 360° ÷ 14 = 25.714° But what number do use for "zoom" to have the identical effect? I assume it's some percentage of the original equation.

Using that logic I come up with 29.22 ÷ 30 = 0.974%. Finally, 25714° x 0.974 = 25.406° gives me the proper HFOV per screen.

Questions:

Is the logic correct?
How would I apply a smaller number of total degrees, like a 315° view?
Assuming a fixed bezel size, is a "total solution" equation (one usable with any number of monitors and HFOV) possible in either batch or bash language?

I'd like to have input from others to compare my results to. Thanks

[GreyGeek]

When my kcalc divides 360 by 14 it gives me 25.7142857143
Also, how was the 29.22 value determined?
Another question I have is "what is the total distance across a monitor, including the bezel, AND, what fraction of a % is the bezel compared to the entire length?"

[oshunluvr]

The 29.22 number was derived from 30 by trial and error from a visual perspective.

Yes, your 25.714 number is correct. Applying the 0.974% gets me 25.046. The number above was bad math from using the previous number of degrees applied to the new HFOV. Fixing that now ...thanks

[oshunluvr]

As far as the monitors, I don't have one in front of me at the moment. They are 75" diagonal Samsung displays mounted in portrait mode.
Here's one I was working on awhile back:

[Snowhog]

What set up runs that many monster sized monitors!

[oshunluvr]

Right? The one in the pic "only" has 10 big ones, but I'm working on one with 14! Each 75" has it's own computer and the smaller screens are 2-3 to a PC.

[jhonny]

I want to increase the monitor count by 2. 360° ÷ 14 = 25.714° But what number do use for ZOOM....

[GreyGeek]

I want to increase the monitor count by 2. 360° ÷ 14 = 25.714° But what number do use for ZOOM....

My thought was that you measure the outside horizontal distance (OHD) across a monitor and then the distance between the left and right bezel edge (IHD). ((OHD - IHD)/OHD) * 100 = zoom percentage.

[jlittle]

With this sort of thing it can often be useful to extrapolate towards infinity, to see where it will go in the limit. I think here that this shows the proportion of the viewing circle taken up by the bezels does not change, once you have enough screens to approximate a circle. So maybe the zoom doesn't change.

If you've got enough of them, it might be feasible to overlap the bezels, thus nearly halving the space they take. A bit like a clinker-build boat.

[oshunluvr]

If you've got enough of them, it might be feasible to overlap the bezels, thus nearly halving the space they take. A bit like a clinker-build boat.

No changes to the physical arrangement is allowed. The bezels are actually a benefit to the simulation and the monitors must be arranged in a circle and edge-to-edge. The diameter of the circle is less than 20 feet so the user is standing quite close given the size of the display.

Yesterday, I was thinking about it this way: I need to hide some number of pixels, but I have to do it by percentage of HFOV.

30° minus 29.22° (the current 12 screen configuration) equals 0.78°. 1080 pixels(p) ÷ 30° equals 36p per degree or 28.08 pixels hidden (36p X 0.78°).
However, if I zoom in (use smaller HFOV per 1080p) I have less image in pixels to hide.
14 monitors results in 25.714° per screen, a difference of 4.286°.

So I think the answer is to use the same percentage of change in the HFOV. So the equation is:

29.22 ÷ 30 x 25.714 = 25.045° and 0.669° is hidden.

To get pixels hidden; 1080p ÷ 25.714 = 42p. 42p x 0.669° = 28.08 (the same number of hidden pixels above).

Still not sure this is right :/

[woodsmoke]

Hi all

Very impressive!

[GreyGeek]

...

Still not sure this is right :/

The proof is in the pudding!
What's the worse thing that could happen if you made your changes to try them out?

[oshunluvr]

The proof is in the pudding!
What's the worse thing that could happen if you made your changes to try them out?

Yeah, that's pretty much where I'm going with this. I'll try my "best guess" and see how it looks. I'll be on-site in Charlotte in a few weeks to try it out.

My real goal was to nail down the math so I could build a "one size fits all" application to allow the user to pick any random HFOV regardless of the number of image generators. Currently, if a client site wants a different HFOV I have to "build" it for them and install it.

I have to update the registry on 14 Windows PCs to make this change, but I've already mostly automated that task. I just have to edit one file on the master, then run a batch file that pushes the changes out to each PC via a reg file and executes it remotely on each PC. This ain't amateur hour! LOL

The end goal would be a Linux bash script (the file server is Centos) on the file server that sends the calculated numbers to the master and executes the batch file on the master remotely. I already have the ability to change the HFOV remotely, but only to a fixed set of degrees. Currently 360, 315, and 270 on large systems or 270, 240 and 180 on small systems. I just thought it would be neat to let the user custom tune the HFOV without assistance.