Ron Parker wrote:

> On Thu, 25 Nov 1999 12:36:16 -0800, "Jon A. Cruz"
> <jon### [at] geocitiescom> wrote:
>
> >Hmmm. Ya got my brain working more.
> >
> >I imagine that one could hook in some image analysis to help. Just render
> >two frames spaced normally. Then do a diff and locate the rectangle areas in
> >the images that changed from one to the next. Then re-render sub-frames with
> >only these sections specified. This should catch reflections, etc. also.
>
> Unfortunately, it doesn't work.  If the "before" and "after" positions
> of the object don't intersect in screen-space, you might neglect to
> rerender the space in between for each subframe.  The object also
> might not just move within the rectangle bounded by its beginning and
> ending positions.

Ahhh. and this is where the problem gets interesting.

Getting the proper algorithm for calculating the rectangles to render would
probably be a very satisfying challenge.

However, it's quite likely that as long as a fairly decent target frame rate
(15fps+ ?) is used, and objects aren't moving too fast, then it would be far
less likely to miss object movement. And the program running the frame renders
can do some simple motion vector tracking and extrapolation.

Then of course there's allways the fallback of flagging unusual cases for human
intervention. And there's always the option of giving it some hints (manual or
.pov extracted).

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

Motivated by previous post on this group, i did some thinking on how top
implement motion-blur in POV-Ray most efficiently. I came to following
conclusions:

To be able to render motion blur, POV must do following things:

1. Have decent way of scripting motion-paths for object, it's
acceleration/deacceleration and rotations. Smoothest way should probably
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
(well, that's my opinion on that issue, don't flame  me for it, let's
concentrate on motion-blur)

2. POV-Ray should first be able to accuratly calculate bounding box that
surrounds blurred object at all positions on it's path. 

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.

Altough this jitter-samling technique is time-consuming, it would be a
good way of doing motion-blur for small objects in a scene that is
stationary.

Of course, there will be a threshold when it's less time-consuming to
render multiple images and average them togheter instead, but that would
only apply to images with lot's of moving object or moving camera.

Please give me some useful input, like if this is feasible way to go
before i start experimenting.


Cheers, Goran

Post a reply to this message

Goran Begicevic wrote:

> Motivated by previous post on this group, i did some thinking on how top
> implement motion-blur in POV-Ray most efficiently. I came to following
> conclusions:
>
> To be able to render motion blur, POV must do following things:
>
> 1. Have decent way of scripting motion-paths for object, it's
> acceleration/deacceleration and rotations. Smoothest way should probably
> 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
> (well, that's my opinion on that issue, don't flame  me for it, let's
> concentrate on motion-blur)
>
> 2. POV-Ray should first be able to accuratly calculate bounding box that
> surrounds blurred object at all positions on it's path.
>
> 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.
>
> Altough this jitter-samling technique is time-consuming, it would be a
> good way of doing motion-blur for small objects in a scene that is
> stationary.
>
> Of course, there will be a threshold when it's less time-consuming to
> render multiple images and average them togheter instead, but that would
> only apply to images with lot's of moving object or moving camera.
>
> Please give me some useful input, like if this is feasible way to go
> before i start experimenting.
>
> Cheers, Goran

Sounds like you'd still have the problem caused by shadows, reflections and
refraction.

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

> 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

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