I've been trying to animate various scenes for a couple of weeks now,
but i have been unsuccessful in writing the script for multiple
renderings of a scene.  Therefore I have rendered many animations
entirely by hand.  Can anyone give me a step by step walk through of
writing script for multiple renderings of a scene?  As my knowledge on
this topic seems to be virtually nil, as complete a walk through as
possible would be much appreciated.

thanks

Post a reply to this message

"Kristofer J. Westphal" wrote:
> 
> I've been trying to animate various scenes for a couple of weeks now,
> but i have been unsuccessful in writing the script for multiple
> renderings of a scene.  Therefore I have rendered many animations
> entirely by hand.  Can anyone give me a step by step walk through of
> writing script for multiple renderings of a scene?  As my knowledge on
> this topic seems to be virtually nil, as complete a walk through as
> possible would be much appreciated.
> 
> thanks

See my introduction to animations and the continuation of the animation
process tutorial by Steve at:

http://www.puzzlecraft.com/cm/ClockMod.html

-- 
Ken Tyler
  
mailto://tylereng@pacbell.net
http://home.pacbell.net/tylereng/links.htm

Post a reply to this message

A little comment about the tutorial:
  I hate to whine again about indentation, but you have to notice that the
tutorial is written for all the people who want to read it. It's not only
for yourself (here "you" means the author of the tutorial; I'm not completely
sure who is it).
  Since a tutorial should be extremely easy to understand, all the example
codes should be it too. For example this:

sphere{<0,0,0>,1 pigment{gradient x
color_map{[0 rgb<1,0,0>][1 rgb 1]}}
finish{ambient .4 diffuse .1 reflection .1 specular 1 roughness .001}
rotate 360*y*clock}

is a little confusing. Why so much obfuscation? I think that the purpose of
the tutorial is not to make the reader to try to decipher the example code.
You could make the codes a lot easier to understand, like:

sphere
{  <0,0,0>,1
   pigment
   {  gradient x
      color_map
      {  [0 rgb<1,0,0>]
         [1 rgb 1]
      }
   }
   finish { ambient .4 diffuse .1 reflection .1 specular 1 roughness .001 }

   rotate 360*y*clock
}

  It takes more space, but it's a lot easier to understand. You can easyly
see that the rotate command really applies to the sphere (and not to the
pigment, for example).

  I think this is not the place for an indentation war. As I said, I think
that the tutorial is intended for anyone and it should be as easy to
understand as possible.

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

In the tutorial Ken mentioned (Advanced POV Animation for Beginners) -

1. That's the only unformatted code in the tutorial.

2. In 15 minutes it will be replaced.

My oversight - I left out the <pre> tags.


steve



Nieminen Mika wrote:

>   A little comment about the tutorial:
>   I hate to whine again about indentation, but you have to notice that the
> tutorial is written for all the people who want to read it. It's not only
> for yourself (here "you" means the author of the tutorial; I'm not completely
> sure who is it).
>   Since a tutorial should be extremely easy to understand, all the example
> codes should be it too. For example this:
>
> sphere{<0,0,0>,1 pigment{gradient x
> color_map{[0 rgb<1,0,0>][1 rgb 1]}}
> finish{ambient .4 diffuse .1 reflection .1 specular 1 roughness .001}
> rotate 360*y*clock}
>
> is a little confusing. Why so much obfuscation? I think that the purpose of
> the tutorial is not to make the reader to try to decipher the example code.
> You could make the codes a lot easier to understand, like:
>
> sphere
> {  <0,0,0>,1
>    pigment
>    {  gradient x
>       color_map
>       {  [0 rgb<1,0,0>]
>          [1 rgb 1]
>       }
>    }
>    finish { ambient .4 diffuse .1 reflection .1 specular 1 roughness .001 }
>
>    rotate 360*y*clock
> }
>
>   It takes more space, but it's a lot easier to understand. You can easyly
> see that the rotate command really applies to the sphere (and not to the
> pigment, for example).
>
>   I think this is not the place for an indentation war. As I said, I think
> that the tutorial is intended for anyone and it should be as easy to
> understand as possible.
>
> --
> 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

Steve <ste### [at] puzzlecraftcom> wrote:
: 2. In 15 minutes it will be replaced.

  I think now it's overindented :)

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

Nieminen Mika wrote:
> 
> Steve <ste### [at] puzzlecraftcom> wrote:
> : 2. In 15 minutes it will be replaced.
> 
>   I think now it's overindented :)

Would you rather he replaced it with the original format ? There is no
pleasing some people sheeeeeeeesh !

-- 
Ken Tyler
  
mailto://tylereng@pacbell.net
http://home.pacbell.net/tylereng/links.htm

Post a reply to this message

Ken <tyl### [at] pacbellnet> wrote:
: Would you rather he replaced it with the original format ? There is no
: pleasing some people sheeeeeeeesh !

  Exaggeration is seldom the answer...

  It's like me asking for some water and you bringing me a tanker. :)

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

I recently picked up that style from Bjarne Stroustrup, although he uses a
mixed bag of styles in his book C++ Programming Language, 3rd ed.

It features isolating and vertically aligning the matched pairs of braces.
It's simply faster for me to audit the braces (and their contents) with this
layout.

The style is certainly not conducive to reducing book publishing costs.

Discussions on coding style are presented in any number of programming books
but there is no consensus that I can detect.

Looks like Stroustrup hasn't made up his mind which style to use, either. If
he does I'll probably copy him.

steve


Nieminen Mika wrote:

> Steve <ste### [at] puzzlecraftcom> wrote:
> : 2. In 15 minutes it will be replaced.
>
>   I think now it's overindented :)
>
> --
> 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

Pov doesn't care if it's indented so why should I ?

Steve wrote:
> 
> I recently picked up that style from Bjarne Stroustrup, although he uses a
> mixed bag of styles in his book C++ Programming Language, 3rd ed.
> 
> It features isolating and vertically aligning the matched pairs of braces.
> It's simply faster for me to audit the braces (and their contents) with this
> layout.
> 
> The style is certainly not conducive to reducing book publishing costs.
> 
> Discussions on coding style are presented in any number of programming books
> but there is no consensus that I can detect.
> 
> Looks like Stroustrup hasn't made up his mind which style to use, either. If
> he does I'll probably copy him.
> 
> steve
> 
> Nieminen Mika wrote:
> 
> > Steve <ste### [at] puzzlecraftcom> wrote:
> > : 2. In 15 minutes it will be replaced.
> >
> >   I think now it's overindented :)
> >
> > --
> > main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> > ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

-- 
Ken Tyler
  
mailto://tylereng@pacbell.net
http://home.pacbell.net/tylereng/links.htm

Post a reply to this message

Ken <tyl### [at] pacbellnet> wrote:
: Pov doesn't care if it's indented so why should I ?

  Pov doesn't, but people reading your code do.

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