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

>   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

Philippe Debar wrote:

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

Yes, but one thing you get is that any standard XML editor (and more are
arriving each day) can do all that editing and homework for you. You'd then end
up typing less, and would be able to view your scene as a tree, move things
around, colapse and expand, etc.

I had just thrown things out quickly as an example. There'd be a little more
different if this were real XML. Here's a more extreme example. but remember it
is all handled by editors.

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

And the editor imported what you typed and then did your preferred tab
formatting on it, of course. :-)


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

Oh! Okay, alright, I see now.  Well, that was why I was wondering about it.
Within POV alone (script, not hard-coded) I had to adjust for the textures
quite a bit because of overlap.  The image averaging never seems to suffer
from that due to the way it gets handled.

Bob

Goran Begicevic <gor### [at] tidaxse> wrote in message
news:3846369C.F8C1433A@tidax.se...
>
> 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

Ken <tyl### [at] pacbellnet> wrote in message
news:38464170.FA093F22@pacbell.net...
>
>   I get scared whenever someone mentions changing the scripting language
> in POV-Ray.

  Scarier is that fact that Jon A. C. has a voice on the POV-Team and I saw
his last message in reply to Phillipe D. just now.
  Fact is I have to use at least the last two major versions, namely 3.02
and 3.1, just to keep my head above water when dealing with all the scene
files I have here.  There's that ever-present danger of losing today's
compatibility for yesterdays files.
  Mostly though I'd agree vehemently about the nonprogrammer status.  I
dropped Basic when it changed to QBasic and many of my files couldn't seem
to be adapted.   Along with the fact I wasn't willing to keep subroutining
in more various ways.  I'm not entirely made of programmer stuff you know.
  The capabilities which open up with the additions of better scripting in
POV-Ray is no doubt a good thing for the right people but if it were to lose
the ease of use for average people, like Ken says, there would certainly be
a gaping crevice between the two factions.  Something which is very
difficult to comprehend clearly since the raytracing medium is so varied,
from art to scientific modeling.  To make for a less debatable subject it
might be brought up about there being potential for user friendly (gee,
that's an old saying) plug-ins and extensions to the program in which the
programming aspect remains avid as all the while a user interface keeps to a
standard of useable features.

Bob

Post a reply to this message

On Thu, 2 Dec 1999 11:50:49 -0600, omniVERSE wrote:

>Ken <tyl### [at] pacbellnet> wrote in message
>news:38464170.FA093F22@pacbell.net...
>>
>>   I get scared whenever someone mentions changing the scripting language
>> in POV-Ray.
>
>  Scarier is that fact that Jon A. C. has a voice on the POV-Team [...]

That's news to me, as I'm sure it is to the other POV-Team members.  The 
official Team roster was just posted in povray.general within the past
few days.  You might want to go reread it.

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

Whew! (nothing personal Jon)
Terribly sorry to confuse others by implying Jon Cruz to be on the POV-Team.
Sincere apologies to all.  I had read both those messages just yesterday and
somehow Jon got stuck in my mind as being listed there.  Strange really
because he isn't even one of the repliers to either of those.  Maybe I've
been psyched out, or paranoia is a worse thing than I previously thought.

Bob

Ron Parker <ron### [at] povrayorg> wrote in message
news:3846b3e9@news.povray.org...
> On Thu, 2 Dec 1999 11:50:49 -0600, omniVERSE wrote:
>
> >Ken <tyl### [at] pacbellnet> wrote in message
> >news:38464170.FA093F22@pacbell.net...
> >>
> >>   I get scared whenever someone mentions changing the scripting
language
> >> in POV-Ray.
> >
> >  Scarier is that fact that Jon A. C. has a voice on the POV-Team [...]
>
> That's news to me, as I'm sure it is to the other POV-Team members.  The
> official Team roster was just posted in povray.general within the past
> few days.  You might want to go reread it.
>
> --
> These are my opinions.  I do NOT speak for the POV-Team.
> The superpatch: http://www2.fwi.com/~parkerr/superpatch/
> My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

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

OK, so what does a for loop look like in this
imaginary XML povscript?  

I guess that we can simply plug-in the appropriate
editors for different groups in the XML file?
Plug-in the sphere editor, bezier editor, spline,
etc...

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

Whew you??? Whew me!

I just saw your first post and started scanning those recent announcements to
see if I had forgotten someone talking to me.   =-O   (me with my hair standing
up)



omniVERSE wrote:

> Whew! (nothing personal Jon)
> Terribly sorry to confuse others by implying Jon Cruz to be on the POV-Team.
> Sincere apologies to all.  I had read both those messages just yesterday and
> somehow Jon got stuck in my mind as being listed there.  Strange really
> because he isn't even one of the repliers to either of those.  Maybe I've
> been psyched out, or paranoia is a worse thing than I previously thought.
>
> Bob
>
> Ron Parker <ron### [at] povrayorg> wrote in message
> news:3846b3e9@news.povray.org...
> > On Thu, 2 Dec 1999 11:50:49 -0600, omniVERSE wrote:
> >
> > >Ken <tyl### [at] pacbellnet> wrote in message
> > >news:38464170.FA093F22@pacbell.net...
> > >>
> > >>   I get scared whenever someone mentions changing the scripting
> language
> > >> in POV-Ray.
> > >
> > >  Scarier is that fact that Jon A. C. has a voice on the POV-Team [...]
> >
> > That's news to me, as I'm sure it is to the other POV-Team members.  The
> > official Team roster was just posted in povray.general within the past
> > few days.  You might want to go reread it.
> >
> > --
> > These are my opinions.  I do NOT speak for the POV-Team.
> > The superpatch: http://www2.fwi.com/~parkerr/superpatch/
> > My other stuff: http://www2.fwi.com/~parkerr/traces.html

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

Nigel Stewart wrote:

> > <sphere radius=1>
> >   <pigment>
> >     <color rgb='#ff00ff'>
> >   </pigment>
> >   <rotate x=0 y=10 z=0>
> > </sphere>
>
> OK, so what does a for loop look like in this
> imaginary XML povscript?
>
> I guess that we can simply plug-in the appropriate
> editors for different groups in the XML file?
> Plug-in the sphere editor, bezier editor, spline,
> etc...
>
> --
> Nigel Stewart (nig### [at] nigelscom)
> Research Student, Software Developer, Tokyo Dweller
> "The Australian Government wants to read your email."

<loop counter=foo initial=1 final=5 step =1>

 <sphere radius=1>
   <center x=0 y=0 z=0/>
   <pigment>
     <color rgb='#ff00ff'/>
   </pigment>
   <rotate x=0 y=10 z=0/>
   <translate>
     <y>foo + 1 * 5</y>
   </translate>
 </sphere>

</loop>


Arrggggghhh! no! stop stop stop!!!
My head is exploding!

;-)

I think this little exercise is getting out of hand.

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

Philippe Debar wrote in message <38468602@news.povray.org>...
>Jon A. Cruz wrote:
>> <sphere radius=1>
>>   <pigment>
>>     <color rgb='#ff00ff'>
>>   </pigment>
>>   <rotate x=0 y=10 z=0>
>> </sphere>
>
>BTW, wasn't some early POVscript (or DKB) that looked like that? Or am I
>completely mistaken once again?
>


DKBTrace had a similar syntax.

OBJECT
 SPHERE
  <0 2 0> 1
 END_SPHERE
 TEXTURE
  COLOUR RED 1 GREEN 1 BLUE 1
  PHONG 1
  DIFFUSE 0.1
  REFLECTION 0.9
  METALLIC
 END_TEXTURE
END_OBJECT

Mark

Post a reply to this message

Ken wrote in message <38464170.FA093F22@pacbell.net>...
>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.

POV script should be changed to a language based on LISP :-)

Mark

Post a reply to this message

Jon A. Cruz wrote:
> Yes, but one thing you get is that any standard XML editor (and more are
> arriving each day) can do all that editing and homework for you. You'd
then end
> up typing less, and would be able to view your scene as a tree, move
things
> around, colapse and expand, etc.
>
> And the editor imported what you typed and then did your preferred tab
> formatting on it, of course. :-)

This is way better. I didn't get this editor idea. The tree view is really
seducing. But I still am more confortable with keeping povscript the way it
is and to use(don't look at me, I am no programer) a pov2xml translator or -
even better IMHO - to have a povscript treeview editor (I said I am no
programer - heck, I can't even _spell_ "programmer" correctly).


Povingly


Philippe

Post a reply to this message

Mark Wagner wrote:
> DKBTrace had a similar syntax.
>
> OBJECT
>  SPHERE
>   <0 2 0> 1
>  END_SPHERE
>  TEXTURE
>   COLOUR RED 1 GREEN 1 BLUE 1
>   PHONG 1
>   DIFFUSE 0.1
>   REFLECTION 0.9
>   METALLIC
>  END_TEXTURE
> END_OBJECT


So, I was not so mistaken (it is the keyword / end_keyword syntax that gave
me that impression).

Thank you Mark.


Philippe

Post a reply to this message

On Fri, 3 Dec 1999 01:23:34 -0500, Mark Wagner wrote:
>
>Ken wrote in message <38464170.FA093F22@pacbell.net>...
>>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.
>
>POV script should be changed to a language based on LISP :-)

I'm with him.  That'd make the parser *really* easy to write. :)

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

> I think this little exercise is getting out of hand.

	I must admit, I was surprised to see the reaction
	to our quiet little conversation...  You'd think
	that the current scripting is the be all and
	end-all of scripting.  I can understand people
	getting worried about "elitist programmer types"
	wanting to impose new paradigms - but all we're 
	doing is talking about it.  The POV team are
	conservative about making changes - this ensures
	that users will not get bulldozed....

	A basic criteria for me would be that the parser
	is modularised, so that the "old" parser and the
	"new" parser would still both work.  I personally
	don't want to tell people to do things "my" way,
	I just think that POV script is TOO MUCH like C
	programming, and a bit too unstructured.  That is
	my opinion as an experienced C and C++ programmer.
	I'd like POV data to be a bit more "open" in terms
	of exchange with other applications.  (Even
	between different versions of POV... :-)

	So, although I'm kindof impressed with the
	reaction, please lets keep some perspective.

	We're not talking about turning POV into a modeller.
	We're saying that the scene files can be strutured
	so that GUI based editing is more feasible. 

	Now, Jon, lets rename our thread to 
	"Re: Porting POV to Java" so that we can get some 
	peace.. :-)


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