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