Replies to This Discussion

Permalink Reply by Roberto Ziche on November 30, 2010 at 5:24pm

Some more info.

This is the current UI for the shader:

Field of View: Self explanatory

Camera: Choices are Center/Left/Right. Selects the camera to use for rendering. Center skips 90% of the calculations and gives you a highly optimized standard Angular Fish Eye shader.

Dome Radius: This is actually the distance at which the cameras line of sights converge, so it's not really the dome size. Maybe I'll rename it.

Dome Forward Tilt: Dome tilt in degrees. Note that this value is not used unless you enable Dome Tilt Compensation.

Cameras Separation: The initial separation of the L/R cameras.

Separation Multiplier: A value between 0-1 that multiples the Camera Separation. of course, it's meant to be used with a grayscale texture mapped to the screen space using the right button. It's used to control teh amount of 3D effect, and eliminate it where desired.

Turn Multiplier: A value 0-1 that controls the amount tof the head turn. To be used with a grayscale texture. Typical use, keep the head straight while looking at the top of the dome.

Head Tilt: A value 0-1 (with 0.5 being the "neutral" value) that tilts the cameras (or head) left/right. 0 means 90 degrees to the left, 1 means 90 degrees to the right (if I remember correctly).

Dome Tilt Compensation: Enabling this option, shifts all the calculations by the # of degrees specified in Dome Forward Tilt. basically, it keeps the cameras/head vertical while the dome rotates forward.
Maps used for the various multipliers and tilt settings will have to be custom made for the proper dome tilt.

Vertical Mode: Enable the vertical dome mode, which automatically adjust the head turn and adds a turn compensation for the upper and lower part of the dome.
It's a simplified and optimized version of the Dome Tilt Compensation with a 90 degrees tilt. Faster and easier to use.

These last two options might need some redesign.


If you use Daniel's original shader, you notice the absence of the Flip and Offset options. They are there, just hidden as the code does not implement them yet.

The Flip implementation should be a no brainer, but the Offset is something I have to think about, as the 3D effect could be affected.

Rob

• ▶ Reply

Permalink Reply by Roberto Ziche on December 6, 2010 at 2:51pm

I'm posting the first compiled version of the beta shader in the attached zip file.
This is the 32-bit version for 3ds Max 2009.

To install:
Unzip it somewhere
move the DLL to:
\mentalray\shaders_autoload\shaders
move the MI file to:
\mentalray\shaders_autoload\include

When you start Max, you will have 3 new Lens shaders:
"Domemaster Stereo Shader"
"domeAFL_FOV"
"domeAFL_WxH"

The last two are Daniel's original fish-eye shaders, and if you already had them, you might want to remove those DLLs to avoid conflicts. The version in this new DLL is the exact same shader (with a small change to use atan2 instead of a slower if-else).

As usual, to see the shader UI described previously, drag and drop the shader from the render Setup dialog to a slot in the material editor.

When you run a render, if you enable information messages in the mental ray message window, you will see the shader version:
PHEN 0.3 info : domeAFL_FOV_Stereo ver: 0.1.0

Rob

Attachments:

• domeAFL.zip, 28 KB

• ▶ Reply

Permalink Reply by Roberto Ziche on December 6, 2010 at 3:00pm

A note about using the multiplier and tilt maps.

The maps are standard black and white images. You can use whatever format 3ds Max supports. Keep them square (even if it's not a requirement), and remember to map them as Environmnet->Screen in the Coordinates panel or you'll spend some time looking at images that makes no sense :)

The sample multiplier images in the first post above have a reference grid, but that was just for display. The map shodul not have anything other than the grayscale image. You can use a grid in a Photoshop layer as a reference, but then disable it before saving the actual map.

You can use 8-bit or 16-bit grayscale images (or grayscale RGB images). Unfortunatley I found that Photoshop with 16-bit images is unable to use some filters. You can use 8-bit if you need those filters, and 3ds Max should still be able to interpolate and give you smooth results.

Also, you don't need to make the grayscale images as big as the domemaster image. You can make them 800x800 or 1024x1024.

Rob

• ▶ Reply

Permalink Reply by Antoine Durr on January 20, 2011 at 5:26pm

Cool!  Do you have a wireframe picture that is your baseline, i.e. no maps applied?  Also, the left eye is usually to the right of the right eye until you get to the convergence point, so your red/green may be swapped.

• ▶ Reply

Permalink Reply by Antoine Durr on January 20, 2011 at 5:30pm

Dome radius seems correctly named.  The use of maps is certainly very flexible, but probably *too* flexible unless you just have a default set of maps that get used, i.e. it's doubtful that this is something that would be changed on a per-shot basis.  Figure it out for the show, and use that from then on.  The typical camera separation should be 2.5 inches, as that is the human interocular distance.  I presume that the separation multiplier would be used for feet-to-inch conversion, etc.?

Roberto Ziche said:

Some more info.

This is the current UI for the shader:

Field of View: Self explanatory

Camera: Choices are Center/Left/Right. Selects the camera to use for rendering. Center skips 90% of the calculations and gives you a highly optimized standard Angular Fish Eye shader.

Dome Radius: This is actually the distance at which the cameras line of sights converge, so it's not really the dome size. Maybe I'll rename it.

Dome Forward Tilt: Dome tilt in degrees. Note that this value is not used unless you enable Dome Tilt Compensation.

Cameras Separation: The initial separation of the L/R cameras.

Separation Multiplier: A value between 0-1 that multiples the Camera Separation. of course, it's meant to be used with a grayscale texture mapped to the screen space using the right button. It's used to control teh amount of 3D effect, and eliminate it where desired.

Turn Multiplier: A value 0-1 that controls the amount tof the head turn. To be used with a grayscale texture. Typical use, keep the head straight while looking at the top of the dome.

Head Tilt: A value 0-1 (with 0.5 being the "neutral" value) that tilts the cameras (or head) left/right. 0 means 90 degrees to the left, 1 means 90 degrees to the right (if I remember correctly).

Dome Tilt Compensation: Enabling this option, shifts all the calculations by the # of degrees specified in Dome Forward Tilt. basically, it keeps the cameras/head vertical while the dome rotates forward.
Maps used for the various multipliers and tilt settings will have to be custom made for the proper dome tilt.

Vertical Mode: Enable the vertical dome mode, which automatically adjust the head turn and adds a turn compensation for the upper and lower part of the dome.
It's a simplified and optimized version of the Dome Tilt Compensation with a 90 degrees tilt. Faster and easier to use.

These last two options might need some redesign.


If you use Daniel's original shader, you notice the absence of the Flip and Offset options. They are there, just hidden as the code does not implement them yet.

The Flip implementation should be a no brainer, but the Offset is something I have to think about, as the 3D effect could be affected.

Rob

• ▶ Reply

Permalink Reply by Roberto Ziche on January 21, 2011 at 1:01pm

Hi Antoine,

 

If I apply no maps, the center of the image will be distorted, as the cameras will rotate while looking at the small center area. As a minimum, a simple map should be applied for the center, and can be a procedural map, like a gradient, that progressively zeroes the camera separation when approaching the center. That will eliminate 3D for that spot, but avoid a very visible artifacts. The image below uses this method.

 

The best approach remains, in my opinion, the combination of head turn multiplier and camera separation map I illustrated above, at least for horizontal or slightly tilted domes.

 

The camera separation multiplier is there just to control the amount of 3D effect, not a conversion factor. The base value for the camera separation can be the eye distance or a larger value then controlled by the map if the effect needs to be enhanced or diminished from "normal".
The distance hes to match the scene units, so if I'm working in millimeters, I would enter 65 there, but also the dome radius need to be adjusted.

A set of default maps can be provided, but a serious production should consider adjusting them on a shot by shot basis. As an extreme example, if the action starts on one area of the dome and crosses to another area, the maps could be animated to keep the best 3D possible effect following the action.
That means that head turn, tilt, and eye separation are constantly adjusted for the predicted viewer head movement.

On anaglyph images, red and blue images will swap accordingly to the position of the object relative to the convergence point (dome radius). That's teh same as it woudl work on any other steroscopy camera setup on a 3d application.

I'm currently doing some short animations and test images that I can test on a real dome. That will finally help me tweak this thing :)
Here's an anaglyph of a frame (reduced).

• ▶ Reply

Permalink Reply by Antoine Durr on January 21, 2011 at 2:15pm

Regarding camera separati

Roberto Ziche said:

If I apply no maps, the center of the image will be distorted, as the cameras will rotate while looking at the small center area. As a minimum, a simple map should be applied for the center, and can be a procedural map, like a gradient, that progressively zeroes the camera separation when approaching the center. That will eliminate 3D for that spot, but avoid a very visible artifacts. The image below uses this method.

 

The best approach remains, in my opinion, the combination of head turn multiplier and camera separation map I illustrated above, at least for horizontal or slightly tilted domes.

 

The camera separation multiplier is there just to control the amount of 3D effect, not a conversion factor. The base value for the camera separation can be the eye distance or a larger value then controlled by the map if the effect needs to be enhanced or diminished from "normal".
The distance hes to match the scene units, so if I'm working in millimeters, I would enter 65 there, but also the dome radius need to be adjusted.

From a UI standpoint, you have two controls that impact the same result.  Why use one over the other?  That usually just confuses the users, especially if you can just put an expression into the field, e.g. 65*1.25.  

 

A set of default maps can be provided, but a serious production should consider adjusting them on a shot by shot basis. As an extreme example, if the action starts on one area of the dome and crosses to another area, the maps could be animated to keep the best 3D possible effect following the action.
That means that head turn, tilt, and eye separation are constantly adjusted for the predicted viewer head movement.

I don't think you can always predict where people will look.  They may find something interesting completely away from your center of action, or may still be looking at some interesting object even though now we're all supposed to look somewhere else.  And good planetarium shows have lots of that, which only adds to the immersive experience.

On anaglyph images, red and blue images will swap accordingly to the position of the object relative to the convergence point (dome radius). That's teh same as it woudl work on any other steroscopy camera setup on a 3d application.

I'm currently doing some short animations and test images that I can test on a real dome. That will finally help me tweak this thing :)
Here's an anaglyph of a frame (reduced).

 

• ▶ Reply

Permalink Reply by Roberto Ziche on January 22, 2011 at 10:30pm

Hi Antoine,

 

The multiplier makes sense only when used witha texture map. Changing the value in the UI with no map is just for testing purpose.

 

Unfortunatley the UI is limited to what Max/mental ray allow me to do . I'm using a simple float value mappable to a texture. That's the easiest way to implement it as it's 100% transparent to the code, and mental ray handles all the stuff for me.

The drawback, is that the float value input field is visible in the UI, and I don't have a way to hide it.

 

If I implement it as a map, the UI would show just a big button for the map assignment, but my code would become a lot more complex.

 

About the second question. Viewers can look anywhere on the dome, and 90% of the time they can and they will see proper 3D. Only some areas need corrections, and the show producers shoudl be aware of those areas.

 

I had the opprtunity today to finally test some images and animations on a real dome, and everything was working as I expected.

I had areas with no 3D effect and they blended with no problem with the areas in full 3D. I'm confident that the system works.

 

I'm now going to be working of a few 30 seconds demo animations for different dome configurations.

• ▶ Reply

Permalink Reply by Antoine Durr on January 24, 2011 at 3:35pm

Hey Roberto,

  I was wondering, what is happening with the stereo offset direction SE and SW of center?  Left vs. right follows the lattitude around most of the dome.  Is that the effect of the separation map or the turn map?

 

• ▶ Reply

Permalink Reply by Antoine Durr on January 25, 2011 at 5:29pm

Have you done any tests with an extremely wide interocular?

• ▶ Reply

Permalink Reply by Roberto Ziche on January 26, 2011 at 12:23pm

That's the separation map. It's spreading too far. The maps I posted in the first post are just two tests and need tuning.

I have to look for a better technique to create them, as photoshop doesn't let me control the gradient areas as I want.

Maybe I can use Illustrator, or even using a different projection (Cylindrical?) and then convert to polar.

 

I run a couple of test saturday using a 5in and 10in eyes separation. Despite being both hyperstereo, the 5in still looked not deep enough. I believe that's becasue I rendered for a dome witha a bigger diameter than the one I tested the images on.

 

Next time I will prepare some ad-hoc images for that dome.

 

• ▶ Reply

Permalink Reply by Michael J. Narlock on March 5, 2011 at 10:59am

Roberto,

 

Do you have a x64 version of this plugin that will work with max2011?  

 

I currently use two fisheye renderers...vraydomecam and Ott's domeafl (though for some reason I can't get his domeafl_WxH to work...comes up as "not found" shader).

 

At any rate, I'd love to test out your plugin on our systems.  Currently the fisheye renderers out there aren't "one stop shopping"...Mental Ray doesn't do afterburn and vray doesn't work well with vue xstream.

• ▶ Reply

• ‹ Previous
• 1
• 2
• 3
• …
• 13
• Next ›
• Page