Matthew Tippett wrote:
Yeah, I know. There is a project called Projection Designer http://orihalcon.jp/projdesigner/ which tries to automate these calculations for a variety of projection geometries and deals with other stuff like compensating for brightness differences caused by overlapping projectors. However, it hasn't seen any action in the last year. I've thought that a similar program for based on OpenSceneGraph would generate a huge amount of interest and fill a need.Thanks.I guess the frustum calculation is possibly the most difficult part (at least investing some more effort) and dusting off the maths.
With the original shear code that you implemented first there did appear to be a project of some sort - the far left and right screens exhibit a level of perspective or distortion. I'll see if I can provide a camera layout that demonstrates it.
That's just the normal distortion you see in a wide-angle frustum.
How many monitors do you have (so I can see if I can demonstrate that way).
1, unfortunately :)
Attached is a somewhat stupid diagram of one screen that is not symmetric with respect to the eye point. The black dot is the eye point; the line with the arrow is normal to the screen and is considered the viewing direction. The other rays project from the eye point into the scene "behind" the screen. This isn't different from the situation with a big symmetric screen, except we've taken a very small chunk of the field of view and are drawing it on one screen. The rendered scene will look correct from the eye point, but will of course be distorted if you look at the screen head-on. This distortion wastes resolution, which is why you would turn a screen off to the side to face the viewer. It will also be less distorted and thus look more normal to observers who aren't right at the designated eye point.I am guessing that I am missing something on the projection side. My mental model says that if the screen is not perpendicular to my eye, I need to somehow encode that.
If you can get some measurements of the corners of the monitors with respect to the eye, then I can show you how to derive the view and frustum specification.Unfortunately with the standard multiple monitor stands (2x2) you have some the screens at about 170 degrees to each other - not quite flat. I'll see if I can get something in blender to suit to show what I am using. Even a simple 2x2 layout doesn't quite sit too well at the moment - I'll send some photos later.
One thing that's a bit more complicated than it needs to be is that the view direction is specified as heading-pitch-roll and the frustum then described as a near-plane value and 2D coordinates in the coordinate frame of the view direction. It would be more convenient for multi-screen setups to accept the 3D coordinates of the screen corners directly and calculate the view direction and frustum from those.
Tim
Regards... Matthew On 11/26/08, Tim Moore <[EMAIL PROTECTED]> wrote:Matthew Tippett wrote:Hi, I have been wrestling with this for a few weeks now. As some of you are aware, I am slowly preparing a new multi-head demo with around 8 GPUs in it (so up to 16 heads). The new camera support is great, but there are some problems with the way the frustums work. My understanding is that the fundamental controls are for a direction for the camera. With large numbers of monitors this begins to fall apart. The view frustums will overlap when you don't create an offset and begin to creat monitors in both the horizontal and vertical directions. With offsets you will have to stack the views on top of each other and in theory get the bottom of one frustum to align with the other, but then you end up having visual issues since the cameras are separate. So what I would like to be able to do is take the layout of the cameras, determine their angles to the camera, and define a frustum that has a non-orthogonal face.You can't have a frustum with a non-orthogonal face unless you render to a texture and project it, which we don't do. Actually, you don't want to do that unless you're projecting the image unto a screen. OSG does have some builtin support for rendering on domes and such, but I digress. What you need to do for each screen is determine the direction from the eye-point to the plane containing the screen and encode that in the <view> parameters of the camera for that screen. Then you need to determine the frustum dimensions, which don't need to be symmetric, that place the screen properly in that plane.The first camera code that Tim released seemed to do this (which meant there was some visual quirks for monitors far out to the sides (like verticals being at angles and so on), but for the person sitting in front of all the screens it looked about right. Are there any other "magic" options that would allow me to get to that? (7+9 is my current plan).Not much magic other than getting out a tape measure and protractor. It might help to build a model of your rig in Blender or another 3D modeling program and make measurements of the model. You could also simplify your geometry by arranging the screens in a cylinder and following the curved monitor example in README.multiscreen. Tim ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
<<inline: skew.png>>
------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
