fulldome.org

immersive projection environments

Stereoscopic domemaster images

Hi everybody,

I'm posting here some tests renderings using a domemaster lens shader for mental ray that allows for 3D steroscopic images.

It's still a work in progress, and I'd like to make this an open effort, posting all the info, research, user interface, and the source code (later on).

A quick intro about myself. I've been working on computer graphics for too long now, and while I used to be a developer (15 years ago), I'm now mainly doing 3D content. I started evaluating the possibility of steroscopic domemaster images after I was asked by Terry Galloway at the Chabot Space and Science Center in CA to do some research.

I started with Daniel F. Ott Angular fisheye shader, and expanded (a lot) from there.
Daniel's shader can be found here, and it is also included in the DLL I will post soon.

This shader starts from the camera position, and creates two virual cameras (left and right, renderable one at a time) that rotate, constantly looking at the specific point of the dome matching the current rendered pixel.
The shader supports horizontal and vertical domes, and any degree of tilt in-between.

Here are two samples of Center, Left, and Right images, in vertical and horizontal mode.

It's not easy to see the differences here, but look below at the test stereo pairs.

The Center image would match Daniel's shader, but it has a different orientation, as I use some tricks to rotate the coordinate system 90 degrees. The current orientation matches the camera viewport, so it's extremely intuitive to setup the camera.

Of course, withouth some restrictions, this system will creates distortion points and areas where the 3D effect is wrong, reversed, or misaligned. The shader allows the use of maps to control the cameras separation (reduce or eliminate 3D effect), head rotation (force some areas to be looked with the head looking straight), and head tilt.

These are sample maps that I'm using for testing.

Using the Turn and Separation maps above, you can see what happens when rendering a simple grid (Red=Right, Green=Left).

The image above is something I would consider for horizontal or slightly tilted domes, where above/behind the viewer head the 3D effect is eliminated to allow the top of the dome to be looked at without turning the head, and the back with fully turned head.

But maps can be used creatively to control any area of the dome. Here, the Turn map above is used in combination with a simple gradient as a Separation map to have 3D only in the front part of the dome.

I think the math is almost there. The User Interface might need some adjustments, and maybe some automatic correction of distorted areas can be used instead of the maps, but the major issue now is to find a way to create proper maps.

Unfortunatley, I don't have any dome at home to try it, so I rely on simulated previews using a 3D concoction in 3ds Max, but that won't let me verify if the head tilt and rotation is set correctly. I think those values can be only found by experimentation on real domes.

These are some samples from the horizontal and verticals samples above. Relax (don't cross) your eyes to see the 3D effect. It helps is you are a bit shortsighted and take you glasses off :)

Horizontal:

Vertical:

I will post more tomorrow. If you have any comments, please post.

Rob

▶ Reply to This

Replies to This Discussion

Permalink Reply by Roberto Ziche on March 5, 2011 at 6:46pm

Hi Michael,

Yes, I do. I should have posted it earlier.

Here are the versions for max 2009. (2011 in the next post).

Attachments:

domeAFL_max2009_32-bit.zip, 28 KB
domeAFL_max2009_64-bit.zip, 70 KB

▶ Reply

Permalink Reply by Roberto Ziche on March 5, 2011 at 7:00pm

And the max 2011 ones.

Note that you could use the 2009 version in 2011 or 2010. It will work for these simple shaders.

See the install instruction earlier in this thread. Daniel's shaders are included in these DLLs, so you might want to remove the old DLLs to avoid conflicts.

Ignore the fact that the dll in the 2011 zips are called "2009". My project file doesn't rename them properly.

If you use my stereo shader with the "Center" camera it will work as Daniel's one (it will not do any extra calculation or try to use any of the 3D specific parameters).
It's likely to be even more optimized than Daniel's one as it has some extra optimizations for the parameters evaluation.

In the DLL there is also a simple debug shader (rob_lookup_background) that can be used to check the maps used for the 3D multipliers in Screen space.

On another note... I'm working on three 30-seconds clips in anaglyph 3-D as a test that I should be able to view at the Chabot planetarium in late March early April, once the new equipment is up and running.

Rob

Attachments:

domeAFL_max2011_32-bit.zip, 28 KB
domeAFL_max2011_64-bit.zip, 73 KB

▶ Reply

Permalink Reply by Roberto Ziche on April 11, 2011 at 1:15pm

Small update...

This week is rendering time. I have three 25-45 seconds clips ready and some idle computers :)

Full preview of the desert chase scene (Credits to Autodesk for the original assets).

A crop of the star cluster flythrough, with actual orbiting stars.

And a crop of the Saturn flyby with pool balls... (no time to do proper moons)

Since I had no idea what the 3D effect would look like once projected on the dome, and no chances to do testing on any real planetarium, I concocted a simulator that allows me to predict the apparent position of any object with specific rendering parameters.

This simulator opened my eyes on two things that can actually be used to our advantage to create manageable finite size worlds. First, the non-linear movement of the apparent object. And this can be used to establish areas closer to the camera that have enhanced depth effect. Second, the presence of a point where objects will appear at infinite. Knowing that point, we can have objects set at reasonable distances from the scene center for our background.

A snapshot of the simulator...

I will post more on this tool once I verify that my math and my predictions are actually working.

Rob

▶ Reply

Permalink Reply by Matthew Mascheri on April 13, 2011 at 4:24pm

Hey Rob,

Great work, thanks for sharing this!

Matt

▶ Reply

Permalink Reply by Michael J. Narlock on April 13, 2011 at 5:46pm

Rob,

Did you get the star cluster model from autodesk??? And thanks for the files. I just got them now...ning didn't inform me you replied to my post!

▶ Reply

Permalink Reply by Roberto Ziche on April 13, 2011 at 10:17pm

Only the desert scene is from Autodesk (my employer, and I got clearence). It was an old demo that I heavily modified. All new materials, new optimizations, different animation techniques.

The cluster is a particle system with each particle rotating around the center. Speed is inverse proportional to the distance, and direction is random. Orbits are circular. More than enough for this demo. I'm not trying to do the real thing :)

Saturn is an old model I did a while ago and finally I get to use it for something. Below are two comparison of the model with Cassini images (top ones).

Not perfect, but good enough for the purpose. I already fixed that noise in the bounced light.

Rob

▶ Reply

Permalink Reply by Michael J. Narlock on April 14, 2011 at 6:31pm

Hi Rob,

Thanks for those shaders. I'm wondering if you happen to have an idea why in your dll/mi, Ott's shaders rotate the iamge 90 degrees?

▶ Reply

Permalink Reply by Michael J. Narlock on April 14, 2011 at 6:58pm

Ok, I must be a dullard. The globular cluster. Did you use pflow and a maxscript to get the orbits to be perfectly circular? Am I missing something simple here?

▶ Reply

Permalink Reply by Roberto Ziche on April 14, 2011 at 8:36pm

Daniel's shader uses the standard XY coordinate system, with the zero angle on the positive X axis.

I tried instead to match the camera orientation, and swapped a few things around to have the zero angle oriented to the "front" of the domemaster image.

The cluster uses PFlow and script operators. One script initializes the particles with a speed and direction values.

Another script updates the particle "orbit" at each frame. It's a simple rotation around the center using the speed and direction assigned to each particle.

There's another script operator that adjusts the particle size based on the distance from the camera. I used it to be able to keep the stars bigger than one pixel no matter how far they are.

There is a control value in the script that allow them to get bigger when closer to the camera up to a max % of the original size. In my case, they can grow only 50%.

I uploaded a low-res 15fps test on youtube.

Rob

▶ Reply

Permalink Reply by Michael J. Narlock on April 18, 2011 at 11:36pm

I guess I'm confused. You're saying the optimizations that were made to Ott's original plugins are supposed to make everything turn by 90 degrees? I guess the point is moot as your plugin works very nicely indeed. I just want to make sure nothing's wonky on my end.

▶ Reply

Permalink Reply by Roberto Ziche on April 19, 2011 at 1:52am

Yes, my shader is 90 degrees rotated when compared to Daniel's one. Sorry if I wasn't clear.

Rob

▶ Reply

Permalink Reply by Steve Harford on June 8, 2011 at 6:01am

On a more basic level, what forms of 3D will produce 3D effect a non-3D digital dome system like Digistar 3? If I simply made a red/green video in a circular frame at a decent resolution and projected it onto a dome, what would it look like? What would be the quality/quantity of 3D around the dome?