I am trying to understand the mesh camera and picking apart the demo 
scenes but I'm just not getting something.

I thought the mesh involved had to have on triangle per pixel, and 
that's easy enough. The normal vector of the triangle determines the 
direction of the ray for that pixel. Does the position of the mesh also 
determine the location of the ray?

A second question: is the first triangle in the mesh the upper left 
corner of the image or bottom left corner?

A third question: does the ray start at the first vector in each triangle?

I set up a simple scene with a vertical cylinder, but through the mesh 
camera it shows up horizontally. So I'm wondering if the second triangle 
in the mesh has to follow the column or the row.

Any help from those of you who are way smarter than me?

Thanks

Uncle Josh

Post a reply to this message

On 30/04/2023 12:30, Josh English wrote:
> I am trying to understand the mesh camera and picking apart the demo scenes but I'm
just not getting something.

It's a long time since I wrote the mesh camera code, so please excuse me if my memory
is rusty, but I'll try to answer.

The following applies to distribution methods 0, 1 and 2:

> The normal vector of the triangle determines the direction of the ray for that
pixel.

Yes, with the consideration that if the camera Z direction is less than 0, the normal
is reversed.

> Does the position of the mesh also determine the location of the ray?

Yes, with the caveat that the Z location of the camera is then used to offset the
ray's origin along its direction.

> A second question: is the first triangle in the mesh the upper left corner of the
image or bottom left corner?

Upper left. The face index is mapped as y * width + x, where y, width and x are all
first mapped to unsigned int.

> A third question: does the ray start at the first vector in each triangle?

No, it's shot from the triangle's centroid.

About mesh selection:

Distribution 0 is single or multiple rays per pixel, with each additional ray going to
the next mesh in the sequence in which they were declared.

Distribution 1 is 1:1 distribution across summed meshes, potentially with multiple
rays per pixel. The faces of all the supplied meshes are logically summed together as
if they were one single mesh. If shooting multiple rays per pixel, the face index is
determined as (width * height * ray_number) + pixel_number.

Distribution 2 is multiple logical cameras, placed side-by-size horizontally, with
mesh #0 being the left-most camera, and mesh #n is the right-most. Rays per pixel is
ignored.

I won't cover distribution 3 here as it's quite different from the above.

I also suggest that, if you haven't already done so, you take a look at Jaime's mesh
camera page at http://www.ignorancia.org/index.php/technical/mesh-camera/. He's also
posted some other examples here in the groups, e.g.
http://news.povray.org/povray.binaries.images/thread/%3C500fb7e5%40news.povray.org%3E/

-- Chris

Post a reply to this message

On 4/30/2023 5:08 AM, Chris Cason wrote:
> On 30/04/2023 12:30, Josh English wrote:
>> I am trying to understand the mesh camera and picking apart the demo 
>> scenes but I'm just not getting something.

> 
> I also suggest that, if you haven't already done so, you take a look at 
> Jaime's mesh camera page at 
> http://www.ignorancia.org/index.php/technical/mesh-camera/. He's also 
> posted some other examples here in the groups, e.g. 
>
http://news.povray.org/povray.binaries.images/thread/%3C500fb7e5%40news.povray.org%3E/
> 
> -- Chris

Thank you.

I was going through Jaime's demo files and just not understanding the 
logic. I still don't but I think my problem may be in my mesh 
generation. I am looping through each row, then each column, and 
creating a triangle, but I was not creating an equilateral triangle and 
I thought that was the problem. I updated my code to match Jaime's but 
the problem remains.

My loops:

// frame for the mesh
#declare UL = <(-image_width/image_height)/2, 2, -4>;
#declare LR = <(image_width/image_height)/2, 1, -4>;

#declare u_vect = <LR.x, UL.y, LR.z> - UL;
#declare v_vect = <UL.x, LR.y, LR.z> - UL;

#declare tr_base_1=<        0,2/3,0>*0.1;
#declare tr_base_2=< 1/2, -1/3,0>*0.1;
#declare tr_base_3=<-1/2, -1/3,0>*0.1;
#declare camera_mesh =
mesh {
   #for(V,0,image_height,1)
     #for(U,0,image_width,1)
       #declare here = (UL+u_vect*(U/image_width)+v_vect*(V/image_height));
       triangle {
         here + tr_base_1, here + tr_base_2, here + tr_base_3
       }
     #end // for U
   #end // for V
} // mesh

The first attachment shows the basic scene, where I've built the mesh 
and what it's looking at. The second attachment shows the results of 
using the mesh with distribution 0. The cylinder is diagonal and repeated.

The mesh camera code itself is
camera {
   mesh_camera { 1 0
     mesh { camera_mesh }
   }
   location <0,0,-.1>
   direction z
   }

I have no idea what's going on with this code.

Josh

Post a reply to this message

Attachments:
Download 'mech_cam_blocking.png' (196 KB) Download 'mesh_cam_wtf.png' (18 KB)

Preview of image 'mech_cam_blocking.png'

Preview of image 'mesh_cam_wtf.png'

hi,

Josh English <Jos### [at] joshuarenglishcom> wrote:
> ...
> I have no idea what's going on with this code.

while I would not be able to tell, at any rate, a ready-to-run copy'n'paste code
to "try things" would have been nice/helpful.


regards, jr.

Post a reply to this message

On 5/1/2023 5:43 AM, jr wrote:
> hi,
> 
> Josh English <Jos### [at] joshuarenglishcom> wrote:
>> ...
>> I have no idea what's going on with this code.
> 
> while I would not be able to tell, at any rate, a ready-to-run copy'n'paste code
> to "try things" would have been nice/helpful.
> 
> 
> regards, jr.
> 

True. Unfortunately my code is so hodge-podge I am always reluctant to 
post it because a) I suck at documentation, and b) you guys shouldn't 
have to perform archeology for me.

I gave up and stole one of Jaime's macros then hacked it to do what I 
wanted.

I've attached the code that's misbehaving.

Post a reply to this message

Attachments:
Download 'mesh_explorer.png' (30 KB)

Preview of image 'mesh_explorer.png'

On 5/1/2023 12:32 PM, Josh English wrote:
> On 5/1/2023 5:43 AM, jr wrote:
>> hi,
>>
>> Josh English <Jos### [at] joshuarenglishcom> wrote:
>>> ...
>>> I have no idea what's going on with this code.
>>
>> while I would not be able to tell, at any rate, a ready-to-run 
>> copy'n'paste code
>> to "try things" would have been nice/helpful.
>>
>>
>> regards, jr.
>>
> 
> True. Unfortunately my code is so hodge-podge I am always reluctant to 
> post it because a) I suck at documentation, and b) you guys shouldn't 
> have to perform archeology for me.
> 
> I gave up and stole one of Jaime's macros then hacked it to do what I 
> wanted.
> 
> I've attached the code that's misbehaving.
  Oh ffs.

Post a reply to this message

Attachments:
Download 'mesh_explorer.pov.txt' (5 KB)

hi,

Josh English <Jos### [at] joshuarenglishcom> wrote:
> ...
> >> code to "try things" would have been nice/helpful.
> > True. Unfortunately my code is so hodge-podge I am always reluctant ...

know that feeling :-)  also think though that when one runs into a problem,
writing some code just to replicate the problem in the simplest scene possible,
can often provide (new) insight.


> > I've attached the code that's misbehaving.
>   Oh ffs.

</grin>

thanks.  will follow this thread with interest, as mesh cam is a big puzzle to
me.

regards, jr.

Post a reply to this message

On 5/2/2023 4:24 AM, jr wrote:
> hi,
> 
> Josh English <Jos### [at] joshuarenglishcom> wrote:
>> ...
>>>> code to "try things" would have been nice/helpful.
>>> True. Unfortunately my code is so hodge-podge I am always reluctant ...
> 
> know that feeling :-)  also think though that when one runs into a problem,
> writing some code just to replicate the problem in the simplest scene possible,
> can often provide (new) insight.
> 
> 
>>> I've attached the code that's misbehaving.
>>    Oh ffs.
> 
> </grin>
> 
> thanks.  will follow this thread with interest, as mesh cam is a big puzzle to
> me.
> 
> regards, jr.
> 

I found the mistake that is causing the skewed image. I forgot the end 
condition on a FOR loop will can the end value of the loop, so I was 
calculating one extra pixel per row, which the mesh camera dutifully 
pushed to the next row, so my original code was generating more 
triangles than needed.

Live and learn.

Well ... live.

Josh

Post a reply to this message

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

> I found the mistake that is causing the skewed image. I forgot the end
> condition on a FOR loop will can the end value of the loop, so I was
> calculating one extra pixel per row, which the mesh camera dutifully
> pushed to the next row, so my original code was generating more
> triangles than needed.

Ah - that explains it.

Of course, now that you've discovered that, you could actually (ab)use that to
do things like a TV-interference effect.  Also wondering what happens if you
double the columns and halve the rows.  Triple, quadruple...


Perhaps at some point when you get everything mostly worked out to your liking,
you can post a working scene file.  It would be nice to make some explanatory
diagrams to complement the extant documentation, and maybe make a version that
makes use of a Bezier patch as the camera control surface.  :)

Nice job hunting down the cause.

- BW

Post a reply to this message

On 5/5/2023 3:24 AM, Bald Eagle wrote:
> It would be nice to make some explanatory
> diagrams to complement the extant documentation, and maybe make a version that
> makes use of a Bezier patch as the camera control surface.

I'm thinking about how to explain some of my discoveries to expand on 
Jaime's work.

But bezier patches? That's a cruel challenge. I don't know how to 
convert a patch to a mesh in the first place. That's why I used them: to 
let POV-Ray do the hard work.

Josh

Post a reply to this message