"Kenneth" <kdw### [at] gmailcom> wrote:

> Yep. In my own tests, I tried the same coloring attempt in meshcam_macros.inc,
> at the end of the  #macro meshcam_pinhole(...) mesh-generator code.
> But no result :-(  (I even tried adding an interior_texture, AND an
> inside_vector). It was all ignored. I guess the mesh-as-CAMERA in the source
> code is a different animal than a mesh OBJECT.

If I read the documentation correctly, there is a normal direction, and an
offset.  If you keep the normal direction the same, but change the offset so
that the camera ray origin is behind the mesh instead of in front of it, does
that achieve the desired result?
I seem to recall something about being able to see the mesh used as the camera.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
> > Yep. In my own tests, I tried the same coloring attempt in meshcam_macros.inc,
> > at the end of the  #macro meshcam_pinhole(...) mesh-generator code.
> > But no result :-(  (I even tried adding an interior_texture, AND an
> > inside_vector). It was all ignored. I guess the mesh-as-CAMERA in the source
> > code is a different animal than a mesh OBJECT.
>
> If I read the documentation correctly, there is a normal direction, and an
> offset.  If you keep the normal direction the same, but change the offset so
> that the camera ray origin is behind the mesh instead of in front of it, does
> that achieve the desired result?
> I seem to recall something about being able to see the mesh used as the camera.

Honestly, some of that documentation I don't understand at all. :-[  In the
meshcam_persp_demo file-- in the camera{mesh_camera{ ... block, there *is* a
location <0,0,-.01> (not to be confused with the camera's c_location). I've
tried changing that z value various ways; and a few times, I had an 'Aha!'
moment-- only to find that it messed up something else that I was trying. Some
of the features seem to be interconnected(?) But I haven't run through ALL the
permutations of things yet. *sigh*

I'm *still* trying to get a stereogram with the red/cyan filtering-- but it
appears that the (internal) mesh CAMERA interferes in some strange way with
*any* colored objects placed in the appropriate locations, when TWO views are
used. It's very odd. I'm putting together another collage of renders to
illustrate this...

Post a reply to this message

On 5/20/2023 7:08 AM, Bald Eagle wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> 
>> Yep. In my own tests, I tried the same coloring attempt in meshcam_macros.inc,
>> at the end of the  #macro meshcam_pinhole(...) mesh-generator code.
>> But no result :-(  (I even tried adding an interior_texture, AND an
>> inside_vector). It was all ignored. I guess the mesh-as-CAMERA in the source
>> code is a different animal than a mesh OBJECT.
> 
> If I read the documentation correctly, there is a normal direction, and an
> offset.  If you keep the normal direction the same, but change the offset so
> that the camera ray origin is behind the mesh instead of in front of it, does
> that achieve the desired result?
> I seem to recall something about being able to see the mesh used as the camera.
> 

You can include the mesh in the file, and since the mesh_camera rays are 
offset, the mesh will be seen. The demonstration has a vignette feature 
that demonstrates this in action.

I made a few changes to the perspective code demo:

// common test subjects and scenario
#declare Room = union {
#include "demo_common.inc"
}

...

// create the camera with the generated or loaded mesh
camera{
   mesh_camera{ 2 0  // distribution 1 will do the job too in this case, 
as all the meshes are the same
     mesh{camera_mesh
       meshcam_placement(c_location,c_look_at)
     }
     mesh{camera_mesh meshcam_placement(c_location, c_look_at) translate 
28.5*x }
   }
   location <0,0,-.01> // look at the face slighty off along the normal
}

...

object { Room clipped_by { sphere { 0, 14 } } }
object { Room clipped_by { sphere { 0, 14 } } translate 28*x }
sphere { <0,0,0> 6 pigment { red 1 transmit 0.5} }
sphere { <28,0,0> 6 pigment { blue 1 green 1 transmit 0.5 } }

And this created a proof of concept below (completely wrong angles, 
because I have no idea how to make one, and I don't know what it takes 
to get a POV-Ray scene to even make one colorized version.

Post a reply to this message

Attachments:
Download 'meshcam_anaglyph_demo.png' (230 KB)

Preview of image 'meshcam_anaglyph_demo.png'

On 5/20/2023 10:02 AM, Kenneth wrote:
> Honestly, some of that documentation I don't understand at all. 😅  In the
> meshcam_persp_demo file-- in the camera{mesh_camera{ ... block, there*is*  a
> location <0,0,-.01> (not to be confused with the camera's c_location). I've
> tried changing that z value various ways; and a few times, I had an 'Aha!'
> moment-- only to find that it messed up something else that I was trying. Some
> of the features seem to be interconnected(?) But I haven't run through ALL the
> permutations of things yet.*sigh*

The camera location is the offset from the individual triangles. If you 
had a positive z value you'd shoot the rays the opposite way from the 
mesh, reversing the triangle normals and probably not getting anything 
exciting. I've experimented with sliding the location around the XY 
plane but it doesn't seem to have any cool effects like slanting the 
image or anything.

Post a reply to this message

Josh English <Jos### [at] joshuarenglishcom> wrote:

> And this created a proof of concept below (completely wrong angles,
> because I have no idea how to make one, and I don't know what it takes
> to get a POV-Ray scene to even make one colorized version.

Paul Bourke has an impressive collection of detailed POV-Ray articles, an I
recall stumbling over his stereogram article several times over the years.


http://paulbourke.net/stereographics/vpac/povray.html

- BE

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Josh English <Jos### [at] joshuarenglishcom> wrote:
>
> > And this created a proof of concept below (completely wrong angles,
> > because I have no idea how to make one, and I don't know what it takes
> > to get a POV-Ray scene to even make one colorized version.
>
> Paul Bourke has an impressive collection of detailed POV-Ray articles, an I
> recall stumbling over his stereogram article several times over the years.
>
>
> http://paulbourke.net/stereographics/vpac/povray.html
>

That's a very interesting method and description; I had not seen it before.
Thanks. From a quick glance, I can't yet tell if his method creates a complete
stereogram in only *one* render (like using the meshcam), or if it requires two
renders. I'll have to come back to it to absorb it in detail.

Meanwhile, I'm still doing some hard thinking about my red/cyan trials...

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> Meanwhile, I'm still doing some hard thinking about my red/cyan trials...
>

SO...after *MANY* experiments and failed attempts, here is my first successful
meshcam color anaglyph-- rendered in a single pass with the 'meshcam_persp_demo'
file, only slightly modified. It was a hard learning curve, ha.

I added a few objects to the scene (and in 'demo_common.inc') just to test
various things.

I was pleasantly surprised at the good color separation between the two camera
views, with very little 'ghosting' or cross-talk. Of course, that depends on the
colors matching those of the anaglyph glasses.

The first thing you might notice is that all of the objects pop *out* of the
screen, not into it; I have not yet worked out the proper code changes to fix
that (without messing up something else.) Just getting to this point was a
workout.

I had to abandon the idea of using colored instantiated meshes or spheres to
create the two-color stereo effect; they caused too many odd and un-fixable
problems. Instead, I used very small colored cylinders, placed *just so*, in
combination with changed values in the code's  'location' vector  (location
<0,0,-1.4>). The mesh camera's two views essentially look 'through' the
cylinders. At least, I think so! For this test, I used rgbf <1,0,0,1> and
likewise green (or blue/cyan). There may be better combinations of filter +
transmit colors.

Several of the code's values and settings interact with each other, so it has
been difficult to 'tease out' the best combination. So far, changing the camera
angle (c_angle) and the render resolution both work OK with my set-up, without
having to make other changes. I even made a short anaglyph animation, moving the
camera around.

Prior to this successful demo, I tried all sorts of crazy and unworkable
schemes. Some are worth posting about later, because they show some interesting
behavior of the meshcam and its meshes.

--to be continued!--

Post a reply to this message

Attachments:
Download 'meshcam_anaglyph_1_kw.jpg' (212 KB)

Preview of image 'meshcam_anaglyph_1_kw.jpg'

Well done, sir!

-- 
Thomas

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
> SO...after *MANY* experiments and failed attempts, here is my first successful
> meshcam color anaglyph-- rendered in a single pass with the 'meshcam_persp_demo'
> file, only slightly modified.
>
> The first thing you might notice is that all of the objects pop *out* of the
> screen, not into it...

I solved the 3-D depth problem of the objects appearing solely in front of the
'screen plane', and I'm generally happy with the single-render effect--
although the method I used is not ideal. (The only post-processing I did was to
add the text.)

Essentially, there is a basic horizontal translation of the 2nd camera mesh to
*get* the 3-D, then I rotated that mesh horizontally (about it's 'spherical
center point') to correct the in/out depth effect. But rotating the camera mesh
introduces subtle 'lens distortion' when that view is combined with the 1st
camera mesh; it's most pronounced near the diagonal edges of the frame, as
slight vertical color offsets . The mesh-camera's 'angle' setting (c_angle)
affects the amount of this distortion; I used 65 for this view, which is rather
wide-angle. With, say, 45, there is less offset.

Ideally, the objects in the two colored views should appear to have only strict
horizontal displacement; without the needed rotation, that IS so. To correct the
3-D depth appearance, I tried other strict translations instead-- but they
caused depth-REVERSAL problems (or wiped out the 3-D altogether.)

I think I understand why the rotated mesh causes the slight offset, but I don't
know how to correct for it.  It looks kind of like lens 'barrel distortion', but
not quite. So I tried invoking that feature in the demo scene, in a 'reverse'
way, but it affects BOTH meshes (since a single created mesh is used for both
views.) Of course, it's possible that there are other code changes or tricks
that might work instead of a simple rotation, but no luck so far.

As was suggested earlier, the *best* way to get such a stereogram would be to
use two separate mesh CAMERAS, rather than two meshes in a single camera. I
tried that-- but multiple 'camera' statements in a scene are not allowed, with
the usual error message, "More than one camera in scene, ignoring previous
camera(s)".

Meanwhile, I continue to learn new things!

Post a reply to this message

Attachments:
Download 'meshcam_anaglyph_2_kw.jpg' (194 KB)

Preview of image 'meshcam_anaglyph_2_kw.jpg'

26/05/2023 18:53, Kenneth wrote:
> I solved the 3-D depth problem of the objects appearing solely in front of the
> 'screen plane', and I'm generally happy with the single-render effect--
> although the method I used is not ideal. (The only post-processing I did was to
> add the text.)
> 
  A very nice result!

Paolo

Post a reply to this message