I am playing around with MegaPov, currently the motion blur feature.
It's seems like a pretty decent patch for motion blur, camera motion
blur can be simulated by moving all the objects over time in the
opposite direction the camera is moving.  I have two questions - first
of all, is there a way to jitter the motion blur ray?  Right now if you
specify 5 samples, you get a stepped look to the blur which, with
jittering, I think would be removed or at least lessen the artifact.
Second, is it possible to blur deforming geometry?  If in the motion
blur block I specify and if, and say, if this is the first pass of the
motion blur object use this mesh, if second step use this mesh and
repeat it for each sample step, I should, in theory, be able to blur
deforming geometry - right?

    Thanks, C.

BTW - any good tutorials available for creating procedural surfaces?  Oh
yeah - is displacement available? And another thing :) is a 4.0 version
being developed.  thanks.

--
Colin Doncaster
Bent Animation Inc.
"I can't make a cow, I can only make sausage." - Tim Schafer

Post a reply to this message

In article <385D166D.CE6C6CE8@bentanimation.com>, Colin Doncaster 
<col### [at] bentanimationcom> wrote:

>   I am playing around with MegaPov, currently the motion blur feature.
> It's seems like a pretty decent patch for motion blur, camera motion
> blur can be simulated by moving all the objects over time in the
> opposite direction the camera is moving.  I have two questions - first
> of all, is there a way to jitter the motion blur ray?  Right now if you
> specify 5 samples, you get a stepped look to the blur which, with
> jittering, I think would be removed or at least lessen the artifact.

It is possible, if you use a counter to control the blur manually. It is 
also possible without the counter variable if you take the delta 
value-the "exposure time"-into account, although I haven't taken the 
time to figure that one out yet.

#declare motBlurSamps = 5;
#declare expTime = 1;
global_settings {
   assumed_gamma 1.8
   motion_blur motBlurSamps, expTime
}

#declare rStrm=seed(156153);
#declare CLK=clock;//this is outside any motion_blur block
                   //so it isn't affected by the blur.
                   //Use this variable in place of clock
                   //where blur is controlled manually

//"conventional" motion blur, with the clock variable
motion_blur {
   sphere {< 0, 0, 0>, 0.5
      texture {BallTex}
      translate x*clock
      translate y*1.25
   }
}

//manually controlled motion blur, makes things like jitter
//and directional blur possible
#declare C=0;
motion_blur {
   sphere {< 0, 0, 0>, 0.5
      texture {BallTex}
      translate x*(C/(motBlurSamps-1))*rand(rStrm)
      translate x*CLK
      translate -x*0.5
   }
   #declare C=C+1;
}

I posted some source in povray.text.scene-files which you might find 
useful.


> Second, is it possible to blur deforming geometry?  If in the motion
> blur block I specify and if, and say, if this is the first pass of the
> motion blur object use this mesh, if second step use this mesh and
> repeat it for each sample step, I should, in theory, be able to blur
> deforming geometry - right?

Yes, it is possible. Anything that changes within the motion_blur block 
will be blurred, with the exceptions of light_sources and the camera.



> BTW - any good tutorials available for creating procedural surfaces?

If you mean the isosurface, I am working on one, and there is one online 
here: http://members.aol.com/stbenge/


> Oh yeah - is displacement available?

A form of displacement can be done with the isosurface patch.


> And another thing :) is a 4.0 version
> being developed.  thanks.

POV-Ray 3.5 version is being developed, which will incorporate many of 
the patches that have been created. POV-Ray 4.0 will be a rewrite of 
POV-Ray in C++.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

I think that jittering will make it look grainy and so even worse.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Hmm, I beleive jittering the motion blur sample is the actual defacto way
of handling motion blur so a minimal sample amount is needed, at least in a
distributed raytracer.  (is POV a distributed ray tracer?)  Jittering the ray
(or sample) is what gives you the blurred reflections and refractions, soft
shadows, DOF etc.. ( 262 and 265 in Andvanced Animation and Rendering
Techniques - Mark and Alan Watt).

    C.

Nieminen Juha wrote:

>   I think that jittering will make it look grainy and so even worse.
>
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

--
Colin Doncaster
Bent Animation Inc.
"I can't make a cow, I can only make sausage." - Tim Schafer

Post a reply to this message

Colin Doncaster <col### [at] bentanimationcom> wrote...
> I have two questions - first
> of all, is there a way to jitter the motion blur ray?  Right now if you
> specify 5 samples, you get a stepped look to the blur which, with
> jittering, I think would be removed or at least lessen the artifact.

Not really.  Remember that this works by actually creating multiple objects
at PARSE time, and NOT by modifying the object at RENDER time.  This
technique does not use distributed ray-tracing to achieve the effect.  You
could jitter the time that was used for creation of the object (see Chris
Huff's reply) but I don't think it would do what you want.

> Second, is it possible to blur deforming geometry?  If in the motion
> blur block I specify and if, and say, if this is the first pass of the
> motion blur object use this mesh, if second step use this mesh and
> repeat it for each sample step, I should, in theory, be able to blur
> deforming geometry - right?

Yes, you could do this.

-Nathan

Post a reply to this message

Colin Doncaster <col### [at] bentanimationcom> wrote...
>     Hmm, I beleive jittering the motion blur sample is the actual defacto
way
> of handling motion blur so a minimal sample amount is needed, at least in
a
> distributed raytracer.  (is POV a distributed ray tracer?)  Jittering the
ray
> (or sample) is what gives you the blurred reflections and refractions,
soft
> shadows, DOF etc.. ( 262 and 265 in Andvanced Animation and Rendering
> Techniques - Mark and Alan Watt).

Is POV a distributed ray tracer?  Yes and No.

Technically, no.  But area lights use distributed techniques.  And then
someone added focal blur.  And now MegaPov has blurred reflections (and
blurred transparancy if anyone ever gets around to writing the code).
Unfortunately, focal blur and blurred reflections do not work together (by
sharing samples) automatically (although if you use focal blur, you could
then get by with one sample for blurred reflections and probably nobody
would notice).

Anyway, at its core, POV was not designed for animation, so all objects in a
scene are static.  Therefore, it would be quite difficult to jitter an
object in the time domain during rendering.

-Nathan

Post a reply to this message

In article <385d53d6@news.povray.org>, "Nathan Kopp" <Nat### [at] Koppcom> 
wrote:

> (and
> blurred transparancy if anyone ever gets around to writing the code)

I have written a patch which does blurred transparency, it is based on 
the blurred reflection patch. The syntax is a bit strange, it was 
designed as part of my transparency patch, but could easily be modified 
back to work with a more standard syntax.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Nathan Kopp wrote:

> Technically, no.  But area lights use distributed techniques.  And then
> someone added focal blur.

    Couldn't the focal blur code be altered to also take samples at different
points in time?  There would be need to store the scene similar to the current
motion blur but the sampling would be integrated with DOF.  Or have I
misunderstood how it works?

> Anyway, at its core, POV was not designed for animation, so all objects in a
> scene are static.  Therefore, it would be quite difficult to jitter an
> object in the time domain during rendering.

    It's more the ray that gets jittered, similar to DOF, than the actual
object.  You'd just need to hold the different sample points in memory similar
to the current implementation.  Wouldn't you?

    C.

--
Colin Doncaster
Bent Animation Inc.
"I can't make a cow, I can only make sausage." - Tim Schafer

Post a reply to this message

Colin Doncaster <col### [at] bentanimationcom> wrote...
>     It's more the ray that gets jittered, similar to DOF, than the actual
> object.  You'd just need to hold the different sample points in memory
similar
> to the current implementation.  Wouldn't you?

But how exactly would you jitter the ray.  As I understand it, jittering a
ray in the time domain does not change the geometry of the ray itself, but
rather just means that you choose a time for that ray.  Then, the
intersection function for each object includes a 'time' parameter, which
temporarily adjusts the object accordingly, so that you end up with the
intersection for that point in time.  This would require that objects be
able to store expressions based on the clock variable (or at least splines
based on clock) for various attributes, which would then be evaluated a
render-time.  Currently all expressions, including those based on the clock
variable, are evaluated at parse time, producing a static scene.  No
movement information is stored in the objects.

My motion blur patch still uses static objects.  It just provides the
ability to produce a bunch of static objects and make them all
semi-transparent through a special supersampling scheme.

-Nathan

Post a reply to this message

Nathan Kopp wrote:

> But how exactly would you jitter the ray.  As I understand it, jittering a
> ray in the time domain does not change the geometry of the ray itself, but
> rather just means that you choose a time for that ray.  Then, the
> intersection function for each object includes a 'time' parameter, which
> temporarily adjusts the object accordingly, so that you end up with the
> intersection for that point in time.

    Well, you're implementation gives you the means to store 5 different
version of the object for each frame right, objects in povray must be stored in
some structure that if made into an array per object would allow you to store
more than one copy of the variable (I know that povray supports arrays of
objects anyway, this may be part of the method).  Then, depending on the time
that gets jittered you use some threshold to sample the correct element in the
array.  This could also be extended to compare the differences between the
elements that encompass the sample and building a vector (there is more to it
that just a vector, but for now I guess we can assume an all encompassing
general vector) that is the difference between the two and move the original
based on this vector.  It's a lot more work of course.

    Again - you probably know a lot more about the povray code than I, I am
just splurging goo off the top of my head and hopeing some of it might land in
someones lap.  :)

    Later, C.

--
Colin Doncaster
Bent Animation Inc.
"I can't make a cow, I can only make sausage." - Tim Schafer

Post a reply to this message