I like the talk of this becoming a potential feature, even if way off into a
future version or patch.  Something to consider would be how texture is
applied to such objects, or all of the scene in the case of camera movement.
The multiplications cause a lot of overlapping texture to occur and that has
to be adjusted for.  I think some of the image averaging procedures account
for this from what I remember was said before.  Within POV-Ray itself
however there would need to be similar adjustment since each still image is
in fact a series of images of a sort.
Don't want to put a damper on the subject, just wanted to be sure that this
also was thought about. And I guess this is where I came in, the talk of
collecting color info for the object(s).
Btw, I know nothing of programming in here.  I had only done my own "in-pov"
tests of motion blur and found the need to either csg difference or tone the
texture color down while a object moves.
I'll let you all continue now and leave you with it  ; )

Bob

Goran Begicevic <gor### [at] tidaxse> wrote in message
news:38401830.B80A56D8@tidax.se...
> > Sounds like you'd still have the problem caused by shadows, reflections
and
> > refraction.
>
>
> Hmmm...i don't think i will. Could you please point out why? I cannot
> think of any problem here.
>
>
> Let's do a mind-experiment. Ray is being shot from camera. Ray
> intersects cube in the scene. Vector is calculated from
> intersection-point to light_source and checked to all object in scene to
> see if intersection-point is obscured by anything (in shadow).
>
> Now, if there is a motion-blur object between our cube and light_source
> we should use same approach as if our blur-object is intersected by
> camera-ray. Object is jittered in time domain, some value between fully
> obscured and fully lighted is obtained , and that value is used to
> determine color of that pixel.
>
> Correct me if i'm wrong.
>
>
>
> Cheers, Goran

Post a reply to this message

Goran Begicevic <gor### [at] tidaxse> wrote:
: be to use bezier curves for this. It would rule-out hand-writing scenes
: with motion blur, but who cares. It's time to say goodbye to it anyway

  Nonsense. You will never be able to achieve the same functionality that
a scripting language gives you with a graphical modeller. There will always
be very handy things that are quite easy to write but completely impossible
to achieve with a modeller (unless the modeller supports a scripting
language by itself, of course).
  The good thing about a scripting language is that you can program (almost)
anything you will which is not directly supported by povray. For example look
at Chris Colefax's include files. The things they do are not directly
supported by povray (there are no keywords for them), but they are perfectly
possible and quite easy to make.
  Now, you can never achieve this kind of flexibility with a modeller.
  Most advanced modellers have their own scripting language for this reason.
  And besides, certain things are just easier to try by hand.

: 3. While rendering , every time that ray intersects this motion-blur
: bounding box, object should be jittered across it's motion path in
: time-domain and re-tested with same ray. This would give us oversampled
: Monte-Carlo approximation of it's blurred trail. It will also work
: satisfactory with shadows, reflections and such.

  It will look very grainy. Like current media or focal blur with a small
confidence (like the default one).
  You can get a very good idea of how slow it will be by putting a plane
at the focal_point, differencing a hole in it and putting some object behind
it and then rendering with focal blur with a high enough confidence
(like 0.999).

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

> : be to use bezier curves for this. It would rule-out hand-writing scenes
> : with motion blur, but who cares. It's time to say goodbye to it anyway
> 
>   Nonsense. You will never be able to achieve the same functionality that
> a scripting language gives you with a graphical modeller.

I think there is room for compromise.  I think it's fair to say that 
some kind of hybrid would be the ideal.  I don't see why I should 
deal with a text editor to change the color of an object - I should
be able to click my way through the heirachy.  But, I wouldn't
accept this at the price of loosing POV script!

--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer, Tokyo Dweller
"The Australian Government wants to read your email."

Post a reply to this message

Nigel Stewart wrote:

> > : be to use bezier curves for this. It would rule-out hand-writing scenes
> > : with motion blur, but who cares. It's time to say goodbye to it anyway
> >
> >   Nonsense. You will never be able to achieve the same functionality that
> > a scripting language gives you with a graphical modeller.
>
> I think there is room for compromise.  I think it's fair to say that
> some kind of hybrid would be the ideal.  I don't see why I should
> deal with a text editor to change the color of an object - I should
> be able to click my way through the heirachy.  But, I wouldn't
> accept this at the price of loosing POV script!
>

XML...   XML...   XML...   XML...

--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.

Post a reply to this message

> Btw, I know nothing of programming in here.  I had only done my own "in-pov"
> tests of motion blur and found the need to either csg difference or tone the
> texture color down while a object moves.
> I'll let you all continue now and leave you with it  ; )

This won't matter. If averaging multiple images, colors will be weighted
as well. Imagine photographic film exposed multiple of times with object
slightly moved. You would need to adjust exposure-time for every
exposure.

Take a peek at:
http://www.student.hig.se/~kp97gbc/computer_graphics/pool_800x600.html
There is one off my studies of POV motion blur using makro-jittered
objects.

It works, believe me ;)

Post a reply to this message

Nigel Stewart <nig### [at] nigelscom> wrote:
: I don't see why I should 
: deal with a text editor to change the color of an object - I should
: be able to click my way through the heirachy.

  Then use moray.
  Povray is not a modeller, it's a renderer. A portable one. Modellers are
seldom very portable.

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

>   Nonsense. You will never be able to achieve the same functionality that

Hey, i don't say that we should ditch whole scripting language. I just
mean that motion-paths should be given in script by giving POV control
points for bezier-curves. 

We have lots of examples for this in POV-Ray scripting language. As far
as i know, there is very few people that hand-code smooth-triangles or
bezier-surfaces in script. 

So motion blur paths should (of course), be inplemented on script, but
should only be acurately modelled by 2:nd hand utilites.



> : 3. While rendering , every time that ray intersects this motion-blur
> : bounding box, object should be jittered across it's motion path in
> : time-domain and re-tested with same ray. This would give us oversampled
> : Monte-Carlo approximation of it's blurred trail. It will also work
> : satisfactory with shadows, reflections and such.
> 
>   It will look very grainy. Like current media or focal blur with a small
> confidence (like the default one).
>   You can get a very good idea of how slow it will be by putting a plane
> at the focal_point, differencing a hole in it and putting some object behind
> it and then rendering with focal blur with a high enough confidence
> (like 0.999).

Well, this is not a good comparision. Focal blur shoots plenty of
redundant rays. Rays shot against motion-jittered objects would only
affect space surounded by it's bounding box. The smaller the object is ,
the faster it will go.

As far as i know, and judging to all computer graphic pappers i have
read up to date, this is easyest way to implement motion blur. At least
in complexity/visual appearence terms.

Fancy post-processing "look-alike" won't cut it in most of cases where
real-looking scenes are required.

Only better solution that springs to my mind is to construct algorithm
that is calculating integral over time-space for given object and in
such way determine visibility in certain point at certain time. This
would be really be a grandious project, not to mention different
algorithms for different types of objects. And even if we could do this,
it would probably involve heaps of numeric calculations anyway, so it's
probably better to shoot for Monte-Carlo approach anyway.


Cheers, Goran





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

Goran Begicevic <gor### [at] tidaxse> wrote:
: We have lots of examples for this in POV-Ray scripting language. As far
: as i know, there is very few people that hand-code smooth-triangles or
: bezier-surfaces in script. 

  I have done both :)

: So motion blur paths should (of course), be inplemented on script, but
: should only be acurately modelled by 2:nd hand utilites.

  It's perfectly possible to use splines in scripts. Of course if you want
an exact path, it's a lot of trial-and-error modelling...
  However, I didn't say that graphical modellers aren't handy. They are.

: Well, this is not a good comparision. Focal blur shoots plenty of
: redundant rays. Rays shot against motion-jittered objects would only
: affect space surounded by it's bounding box. The smaller the object is ,
: the faster it will go.

  That's why I suggested you to put the plane at the distance of the
focal point.
  Another possibility could also be that the blurred object is the only
object in the scene. I think that adjusting confidence and variance you
can control how many rays are shot when the first ray doesn't hit anything.

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

> XML...   XML...   XML...   XML...

Heh.  I'm with you on that one Jon.
As I understand XML (not very well)
it is data-oriented.  How do we keep
the sanity of XML while allowing 
functionality?  And, is XML really
oriented to manual editing?

The kind of thing that I'm thinking
is that if I click inside a sphere { ..}
block, I should be able to change 
properties graphically, with context
help linked back to the documentation.

Nigel

--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer, Tokyo Dweller
"The Australian Government wants to read your email."

Post a reply to this message

Goran Begicevic <gor### [at] tidaxse> wrote in message
news:3844D637.9B4EB21D@tidax.se...
> This won't matter. If averaging multiple images, colors will be weighted
> as well. Imagine photographic film exposed multiple of times with object
> slightly moved. You would need to adjust exposure-time for every
> exposure.
>
> Take a peek at:
> http://www.student.hig.se/~kp97gbc/computer_graphics/pool_800x600.html
> There is one off my studies of POV motion blur using makro-jittered
> objects.
>
> It works, believe me ;)

Indeed it does!  Was this "frame averaging" in POV-Ray? Such as multiple
image_map layers.   Or was this a technique done on the objects themselves?
Sorry, I didn't understand the "makro-jittered objects" statement.

Bob

Post a reply to this message