I've taken what I've managed to learn about mesh cameras and applied it 
to my desert towers scene.

Josh

Post a reply to this message

Attachments:
Download 'drunk_towers.png' (1634 KB)

Preview of image 'drunk_towers.png'

Il 08/05/2023 07:46, Josh English ha scritto:
> I've taken what I've managed to learn about mesh cameras and applied it 
> to my desert towers scene.
> 
> Josh

Nice image! Should it be understood as a shaken landscape or as a 
stereogram to be seen with three eyes? ;-)

Paolo

Post a reply to this message

On 5/14/2023 1:32 PM, Paolo Gibellini wrote:
> Il 08/05/2023 07:46, Josh English ha scritto:
>> I've taken what I've managed to learn about mesh cameras and applied 
>> it to my desert towers scene.
>>
>> Josh
> 
> Nice image! Should it be understood as a shaken landscape or as a 
> stereogram to be seen with three eyes? ;-)
> 
> Paolo

Once I animate it, drunk.

Josh

Post a reply to this message

Paolo Gibellini <p.g### [at] gmailcom> wrote:
> Il 08/05/2023 07:46, Josh English ha scritto:
> > I've taken what I've managed to learn about mesh cameras and applied it
> > to my desert towers scene.
> >
> > Josh
>
> Nice image! Should it be understood as a shaken landscape or as a
> stereogram to be seen with three eyes? ;-)
>

I was curious to know the same thing, ha!

It does kind of look like a '3-eyed' stereogram-- in that the image separations
are 'different' for the tower object than for the farther-away background, which
is a clue.

Josh's image inspired me to dig into the mesh-camera code, to see if I could
change some things to create the same kind of effect (but with only two
'eyes')... and then to try and find some way to apply red/cyan filters to the
overlapped images, to make an anaglyph. But that 2nd idea is not as simple as I
thought.

I'm still experimenting...

Post a reply to this message

On 5/16/2023 12:41 AM, Kenneth wrote:
> Paolo Gibellini <p.g### [at] gmailcom> wrote:
>> Il 08/05/2023 07:46, Josh English ha scritto:
>>> I've taken what I've managed to learn about mesh cameras and applied it
>>> to my desert towers scene.
>>>
>>> Josh
>>
>> Nice image! Should it be understood as a shaken landscape or as a
>> stereogram to be seen with three eyes? ;-)
>>
> 
> I was curious to know the same thing, ha!
> 
> It does kind of look like a '3-eyed' stereogram-- in that the image separations
> are 'different' for the tower object than for the farther-away background, which
> is a clue.
> 
> Josh's image inspired me to dig into the mesh-camera code, to see if I could
> change some things to create the same kind of effect (but with only two
> 'eyes')... and then to try and find some way to apply red/cyan filters to the
> overlapped images, to make an anaglyph. But that 2nd idea is not as simple as I
> thought.
> 
> I'm still experimenting...
> 
> 
> 
I've been trying to build up a tutorial on some special effects. I've 
managed a somewhat decent motion blur and focal blur, and a "portal" 
effect where one part of the image is in a different space than the rest.

For the anaglyph, remember you can also include the mesh AS AN OBJECT in 
the scene itself. Jaime's Vignette code does this. The mesh_camera 
doesn't sit on the mesh, but starts the rays just offset from the mesh. 
So you may be able to include them and tint them ... oh, yeah. I see the 
problem. You can't group real world objects with individual rays in the 
definition. Maybe build the scene in two sets, and two copies of the 
mesh with the tinted overlays for each set (or, at that point, large 
semi transparent spheres around each set would do it).

Just a thought.

Josh

Josh

Post a reply to this message

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

> >
> I've been trying to build up a tutorial on some special effects. I've
> managed a somewhat decent motion blur and focal blur, and a "portal"
> effect where one part of the image is in a different space than the rest.
>

The more I play with the meshcam demo scenes, the more fascinating it all gets!

I'm still working on the stereo red/cyan anaglyph idea (and its problems, ha),
but meanwhile, here are some of my own motion-blur experiments. I used the
'meshcam_persp_demo' file, with aa_samples=40.

In that code-- in the mesh-camera's #while loop-- I simply changed
            #declare c_look_at_tmp=...
 to
            #declare c_look_at_tmp=c_look_at;

 then following that:
            mesh{camera_mesh
            translate .008*i_samples*x // (or any x,y,z combination!)
            // and/or...
            rotate .8*i_samples*z
            meshcam_placement(c_location,c_look_at_tmp)
                }

This works because the camera mesh, as first constructed in
'meshcam_macros.inc', is apparently made facing +z and is centered on the origin
(well, it's a bit more complicated than that.) So any translations or rotations
here come *before* the mesh(es) are re-positioned and re-oriented by the
'meshcam_placement(...)' macro. Simple! But it took me quite awhile to
understand how the mesh camera and its mesh work together, in the various
includes.

BTW, only one triangle mesh is actually constructed; all of the others used in
the meshcam camera are just copies.

---------------
I'll follow up with some more notes and images of my stereogram tests and
instantiated meshes...

Post a reply to this message

Attachments:
Download 'meshcam_motion_blur_tests_kenw.jpg' (66 KB)

Preview of image 'meshcam_motion_blur_tests_kenw.jpg'

"Kenneth" <kdw### [at] gmailcom> wrote:
> Josh English <Jos### [at] joshuarenglishcom> wrote:
>
> > >
> > I've been trying to build up a tutorial on some special effects. I've
> > managed a somewhat decent motion blur and focal blur, and a "portal"
> > effect where one part of the image is in a different space than the rest.
> >
>
> The more I play with the meshcam demo scenes, the more fascinating it all gets!
>
> I'm still working on the stereo red/cyan anaglyph idea (and its problems, ha),
> but meanwhile, here are some of my own motion-blur experiments. I used the
> 'meshcam_persp_demo' file, with aa_samples=40.
>
> In that code-- in the mesh-camera's #while loop-- I simply changed
>             #declare c_look_at_tmp=...
>  to
>             #declare c_look_at_tmp=c_look_at;
>
>  then following that:
>             mesh{camera_mesh
>             translate .008*i_samples*x // (or any x,y,z combination!)
>             // and/or...
>             rotate .8*i_samples*z
>             meshcam_placement(c_location,c_look_at_tmp)
>                 }
>
> This works because the camera mesh, as first constructed in
> 'meshcam_macros.inc', is apparently made facing +z and is centered on the origin
> (well, it's a bit more complicated than that.) So any translations or rotations
> here come *before* the mesh(es) are re-positioned and re-oriented by the
> 'meshcam_placement(...)' macro. Simple! But it took me quite awhile to
> understand how the mesh camera and its mesh work together, in the various
> includes.
>
> BTW, only one triangle mesh is actually constructed; all of the others used in
> the meshcam camera are just copies.
>
> ---------------
> I'll follow up with some more notes and images of my stereogram tests and
> instantiated meshes...

Wow...that is very cool. Great as a motion blur.

Post a reply to this message

On 5/19/2023 8:43 AM, Kenneth wrote:

> The more I play with the meshcam demo scenes, the more fascinating it all gets!
> 
> I'm still working on the stereo red/cyan anaglyph idea (and its problems, ha),
> but meanwhile, here are some of my own motion-blur experiments. I used the
> 'meshcam_persp_demo' file, with aa_samples=40.
> 
> In that code-- in the mesh-camera's #while loop-- I simply changed
>              #declare c_look_at_tmp=...
>   to
>              #declare c_look_at_tmp=c_look_at;
> 
>   then following that:
>              mesh{camera_mesh
>              translate .008*i_samples*x // (or any x,y,z combination!)
>              // and/or...
>              rotate .8*i_samples*z
>              meshcam_placement(c_location,c_look_at_tmp)
>                  }
> 
> This works because the camera mesh, as first constructed in
> 'meshcam_macros.inc', is apparently made facing +z and is centered on the origin
> (well, it's a bit more complicated than that.) So any translations or rotations
> here come *before* the mesh(es) are re-positioned and re-oriented by the
> 'meshcam_placement(...)' macro. Simple! But it took me quite awhile to
> understand how the mesh camera and its mesh work together, in the various
> includes.
> 
> BTW, only one triangle mesh is actually constructed; all of the others used in
> the meshcam camera are just copies.
> 
> ---------------
> I'll follow up with some more notes and images of my stereogram tests and
> instantiated meshes...
> 

The placement macro JVP has is pretty good, but it fails to adjust for a 
sky vector. I've spent a couple of weeks getting that to work.

These look really good. I'm amazed at how fast it processes multiple 
rays for each pixel. At least, it seems to me to be pretty fast.

Josh

Post a reply to this message

> [Kenneth wrote:]
> meanwhile, here are some of my own motion-blur experiments. I used the
> 'meshcam_persp_demo' file, with aa_samples=40.

> [Mike Miller wrote:]
> Wow...that is very cool. Great as a motion blur.

Thanks. It's a lot of fun to play around with. I also *think* that the blur
effect is distance-based-- that is, objects nearer the mesh camera are blurred
more than distant objects. I haven't tried a different scene to confirm that,
although it seems to follow from the fact that the camera's 40 meshes are
essentially just translated sideways a little bit. Like having 40 'eyes', but
spread out over a small 'interocular distance' in total. So distant objects
should have much less blur, just as they would have much less 3-D depth in a
human stereo view.

> [Josh wrote:]
>
> These look really good. I'm amazed at how fast it processes multiple
> rays for each pixel. At least, it seems to me to be pretty fast.
>
Same here. The rendering speed might be due to there being only one 'created'
mesh, which is then used multiple times. I think a triangle mesh is kept in
memory (cached?), so that multiple copies take almost no extra time to process.

BTW, if you have free time, try the blur code on your castle scene. I would be
curious to know if the castle gets blurred more than your distant background.

Post a reply to this message

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

> Thanks. It's a lot of fun to play around with. I also *think* that the blur
> effect is distance-based-- that is, objects nearer the mesh camera are blurred
> more than distant objects. I haven't tried a different scene to confirm that,
> although it seems to follow from the fact that the camera's 40 meshes are
> essentially just translated sideways a little bit. Like having 40 'eyes', but
> spread out over a small 'interocular distance' in total. So distant objects
> should have much less blur, just as they would have much less 3-D depth in a
> human stereo view.

Presumably you could render a top-down view, and project very long normal
vectors from each of the triangle centroids out into the scene to get a diagram
of what's going on...

> > [Josh wrote:]
> >
> > These look really good. I'm amazed at how fast it processes multiple
> > rays for each pixel. At least, it seems to me to be pretty fast.
> >
> Same here. The rendering speed might be due to there being only one 'created'
> mesh, which is then used multiple times. I think a triangle mesh is kept in
> memory (cached?), so that multiple copies take almost no extra time to process.

The way I understand it, is that the triangles in the mesh are all stored as the
original mesh object, and all other instantiations are just that mesh with a
matrix transform applied.


How long do these renders take?  I tried a 1024x768 with some code jr has worked
out, and it was taking so long, that I canceled the render and did a tiny one -
which still seemed quite slow.


- BE

Post a reply to this message