 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmail com> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> 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.
>
Well, my 8 core/16 thread machine is pretty fast as-is, but...
My 40-mesh blur example, at 800X600 and no AA (and no 'vignetting' or
'distortion'), took a total of 2min 15sec (!)-- of which about 16 sec was the
parse time. Pretty amazing. (I did turn off the radiosity that was in one of the
meshcam includes though.) I guess most of the parse time is spent constructing
the single mesh; it's done in SDL in 'meshcam_macros.inc', not internally. By
saving the mesh on the first go-round, subsequent renders will be even faster--
which makes it easier to experiment with the motion-blur, since the mesh itself
doesn't change.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Josh English <Jos### [at] joshuarenglishcom> wrote:
>
> 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.
>
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.)
In the attached image, the center-row renders are the same as in the overlapped
stereogram. If you can cross your eyes, you'll see the nice 3-D effect. My color
anaglyph example had to be made in a separate app though. I hope the 3-D effect
is apparent, as my red-cyan glasses are actually a very dense and
non-standard(?) red/GREEN. I had to fudge the colors somewhat, as well as image
brightness etc.
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.
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'.
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 :-)
3) In the 'meshcam_persp_demo' file: When 'aa_samples=0', only one camera mesh
is created. When it's set to 1, TWO meshes are actually made-- but they exactly
overlap and behave like one mesh. In the equations at
#declare c_look_at_tmp=...
it appears that the 2nd mesh should be 'jittered' in its position, but isn't.
I've tried to follow the math there, but I don't yet see why the 2nd one is not
being moved. (If aa_samples=2, the 3rd mesh IS jittered.) HOWEVER, when using
aa_samples=1, the 2nd mesh can be easily exploited to create a stereogram, which
is the method I used.
Anyway, I hope the attached image is self-explanatory.
More to come (!)
Post a reply to this message
Attachments:
Download 'meshcam_stereo_demo_diagram_kw_5_2023.jpg' (187 KB)
Preview of image 'meshcam_stereo_demo_diagram_kw_5_2023.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/19/2023 3:14 PM, Kenneth 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.
It depends on where you center the transformation. If you rotate the
meshes around the look_at point you get focal blur.
I suspect based on my Towers scene moving the meshes based on the camera
location you get less blurring in the distance. It makes sense because
the angles created by two triangles in a mesh to a distance object is
much smaller than the angle on a closer object.
Josh
Post a reply to this message
Attachments:
Download 'meshcam07c.png' (203 KB)
Preview of image 'meshcam07c.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
Josh English <Jos### [at] joshuarenglishcom> wrote:
> On 5/19/2023 5:21 PM, Kenneth wrote:
> ...
> >
> > More to come (!)
> >
>
> I'm looking forward to it. You're faster than I am.
+1.
(this thread is "shaping up nicely" :-))
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Josh English <Jos### [at] joshuarenglishcom> wrote:
>
> Oddly enough, you can give the [camera] 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.
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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
