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

Colin Doncaster <col### [at] bentanimationcom> wrote:
: Jittering the ray
: (or sample) is what gives you the blurred reflections and refractions, soft
: shadows, DOF etc..

  I think that this is an incomplete statement.
  If you send _one_ sample for one pixel and jitter this sample (ie. change
it randomly) you will certainly not get blurred nor soft anything. You will
just add noise to the image.
  To get a blur you have to send _many_ samples for that one pixel and
average the results.
  Jittering can be used here, but it's not mandatory. For example, with
area light sources you can use jittering or not. If you don't use it, you
can get color banding at the shadows if the light sources inside the area
light are too far away from each other. On the other hand, if you use
jittering (and not enough light sources) you will get noisy shadows.
You can see the uglyness of noise with the media of the official povray.
  AFAIK radiosity and photon mapping do not use jittering for this reason.

-- 
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

Colin Doncaster <col### [at] bentanimationcom> wrote...
> 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.

This would be best, but not very possible with POV.  If it was just limited
to transformations, it might be possible to interpolate (since
transformations are linear).  However, it is possible to use more than just
transformations, which would be very difficult to interpolate.

-Nathan

Post a reply to this message