>   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

I just replied to a reply you made to me in which you showed a example image
of motion blur.  Never mind the questions there then, I think I see now that
you have coded it into a custom POV source.  Guessing so anyhow.

Bob

Post a reply to this message

Nigel Stewart wrote:

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

Yes. Given a valid DTD for some POV-Ray flavor of XMl, then any good
generic XML editor could do that. All attributes for a given tag, and
valid contexts for tags are known, so the editors can do exactly that.
Well, almost. To do the color and such you might need a specialy editor,
or just custom attributes for an editor.

But, it would know that you can add a pigment to that sphere, and that
you can't add a box, etc.

<sphere radius=1>
  <pigment>
    <color rgb='#ff00ff'>
  </pigment>
  <rotate x=0 y=10 z=0>
</sphere>

Or there could be all sorts of different ways to do it.

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

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

Sorry , i didn't see your post! This newsgroup isn't the quickest around
, you know ;)

It's same technique that is to be used internaly in POV, but implemented
(just for test) in script.
With other words, object is jittered on it's motion path, and images are
rendered multiple times to be averaged later.

Now, that introduces lot's of redundant calculations and should be done
on ray-basis and not on image-basis.

Anyway, those images were averaged and i didn't notice any colour
difference beacuse of that. 


Cheers.

Post a reply to this message

Off-topic but i just needed to say this.

I think POV-scripting language should stay the same. 
Actually , i started writing POV scenes before i learned to programme in
C. It was around 1992. When i started learning C, i was amazed to see
how similar it's syntax was to POV scripting language and it helped me a
lot.



"Jon A. Cruz" wrote:
> 
> Nigel Stewart wrote:
> 
> > > 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
> 
> Yes. Given a valid DTD for some POV-Ray flavor of XMl, then any good
> generic XML editor could do that. All attributes for a given tag, and
> valid contexts for tags are known, so the editors can do exactly that.
> Well, almost. To do the color and such you might need a specialy editor,
> or just custom attributes for an editor.
> 
> But, it would know that you can add a pigment to that sphere, and that
> you can't add a box, etc.
> 
> <sphere radius=1>
>   <pigment>
>     <color rgb='#ff00ff'>
>   </pigment>
>   <rotate x=0 y=10 z=0>
> </sphere>
> 
> Or there could be all sorts of different ways to do it.
> 
> --
> "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

Goran Begicevic wrote:
> 
> Off-topic but i just needed to say this.
> 
> I think POV-scripting language should stay the same.
> Actually , i started writing POV scenes before i learned to programme in
> C. It was around 1992. When i started learning C, i was amazed to see
> how similar it's syntax was to POV scripting language and it helped me a
> lot.

  I get scared whenever someone mentions changing the scripting language
in POV-Ray. I have no programming language skills at all but have become
reasonably proficient with the POV-Ray scene description language because
it is so simple. I like the way that it uses descriptive keywords that
are intuitive enough that you don't have to be a programmer to use the
program. Every once in a while an over zealous person with a programming
background pops up and suggests that the language should become more C
oriented or should include object oriented programming or a host of other
scenarios. Truth is, if the POV-Team changed the basic language in POV-Ray,
they would likely lose a large amount of it's present user base. Many of
the people that use it do so because it does not take a programmers back-
ground to understand and use the program.

-- 
Ken Tyler -  1200+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Jon A. Cruz wrote:
> <sphere radius=1>
>   <pigment>
>     <color rgb='#ff00ff'>
>   </pigment>
>   <rotate x=0 y=10 z=0>
> </sphere>

I prefer

sphere{x,1 texture{pigment{color rgb <1,0,1>}} rotate 10*y}

It is shorter (60 characters instead of 92, and you left out the centre) and
I find it much more readable. Part of this readability is from the one-line
formatting, but I wouldn't like  the one-line:

<sphere centerx=1 centery=0 centerz=0 radius=1> <pigment> <color
rgb='#ff00ff'> </pigment> <rotate x=0 y=10 z=0> </sphere>

(I took the liberty to add a centre for the sphere in a syntax analogue to
what you propose.) I think I couldn't stand the inflation. more word to make
typos, less info on screen (hence harder to read the script flow),. And
think about backward compatibility... :-(


> Or there could be all sorts of different ways to do it.


If you really want this povml, you can still write a povml2pov (and back)
translator, so you can test the idea (and maybe win us over).


I must confess the povml idea is somehow seductive (dark side of
POVscritpt? - no the Dark Side should be easier and quicker). I had much
work to unroot it from my mind (some times ago).


BTW, wasn't some early POVscript (or DKB) that looked like that? Or am I
completely mistaken once again?


Philippe

Post a reply to this message