On 5/19/2023 5:21 PM, Kenneth wrote:

> 
> SO... I've been concentrating on the 'meshcam_persp.demo' scene, and came up
> with a way to easily generate a two-'camera' stereo view, at least as the
> *basics* of a 3D anaglyph. It's the same set-up as the motion-blur code, but
> using  only two 'eyes'. The camera's initial position doesn't actually change;
> it's the camera's mesh that is displaced, which has the same effect. Honestly,
> I was not *sure* that this trick produced a true 3-D effect, so I had to prove
> it to myself with a different test set-up.
> 
> (It would seem that the 'meshcam_stereo_demo' scene would be the logical choice
> for my experiments, but I have not yet been able to *overlap* the two images
> there instead of being side-by-side. My math attempts have been woefully crude
> and unsuccessful.)

I think that demo is designed for things like Google Cardboard.


> So far, my attempts to color each of the two views as red/cyan, *within* the
> meshcam scene, have all failed. I've tried using the instantiated meshes as
> objects...or semi-transparent spheres... or even tiny thin cylinders and discs--
> but they interfere with each other in an odd way when used in pairs, and ruin
> the effect. For a *single* camera view (only one mesh), an instantiated/colored
> mesh works very well-- but not with two views that overlap. As you alluded to,
> the mesh-as-CAMERA and the mesh-as-INSTANTIATED-into-the-scene behave completely
> differently. That's difficult to visualize and explain though.

Oddly enough, you can give the mesh a pigment:

camera {
   mesh_camera { 2 0
     mesh { spherical_mesh pigment { blue 1 transmit 0.1 }
       transform { Position_on_Camera(Camera_Location, Camera_Look_At, 
Camera_Sky) }
     }
     mesh { perspective_mesh pigment { red 1 transmit 0.1 }

     }
   }

and the thing renders without color. I would expect this to raise a 
parsing error but it just ignores it. It's a shame, because this could 
really help with these sorts of effects.
> 
> Here are some interesting little facts that I've learned along the way:
> 1) The camera mesh is curved-- like a section of a sphere surface-- and is not
> actually at the given 'c_location'; that's the CENTER of the 'sphere'. And the
> spherical diameter depends on the given 'c_angle'.

Yes. It's a proper pinhole, not like the standard perspective camera.
> 
> 2) When the camera-mesh is first constructed in 'meshcam_macros.inc', it is
> apparently made facing +z, and centered on the origin (that is, the 'center of
> the sphere' is at the origin, I think). Then it's later re-positioned and
> re-oriented by the meshcam_placement macro-- like this in the
> 'meshcam_persp_demo' file:
>                    camera{
>                            mesh_camera{ aa_samples+1    0
>                            mesh{camera_mesh
>                            meshcam_placement(c_location,c_look_at)
>                                        }
> 
> So, prior to meshcam_placement, the mesh can be moved around (translated) in an
> understandable x,y,z way, if you choose to :-)

Fun, ain't it? This is the easiest way to do it, in my opinion. There's 
less math. At least, there's easier ways to sequester the math in a macro.

> 
> More to come (!)
> 

I'm looking forward to it. You're faster than I am.

Josh

Post a reply to this message