From the thread 'Concept car' in p.b.i. you can see that many
people are interested in POV-Ray Quiz :) The one suggested
by Ken is more for POV-Ray developers rather than POV-Ray
users which I think is majority in POV-Ray community.

So here is a call for three different POV-Ray Quizes:
Quiz for POV-Ray Beginners
Quiz for POV-Ray Intermediate Users
Quiz for POV-Ray Advanced Users

Each quiz should have the questions and three or more possible
answers with just one correct answer. The answers can be
represented as images as well.

Here is just an example:

Quiz for POV-Ray Beginners
1. 'orthograhic' keyword belongs to:
    a. light_source
    b. camera.
    c. radiosity

Quiz for POV-Ray Intermediate Users
2.  Where should you put 'orthographic' keyword:
    a. right after 'camera' declaration
    b. after camera coordinates
    c. no matter

Quiz for POV-Ray Advanced Users
3.When you use 'orthographic' camera the object can disappear from view
if:
    a. object is too far from the look_at point of the camera
    b. object is too close to the look_at oint of the camera.
    c. both a and b

Send you questions and answers to this thread.

Gena.

Post a reply to this message

Gena wrote:
> 
> From the thread 'Concept car' in p.b.i. you can see that many
> people are interested in POV-Ray Quiz :) The one suggested
> by Ken is more for POV-Ray developers rather than POV-Ray
> users which I think is majority in POV-Ray community.
> 
> [...]

I agree that the hardcore Pover test is quite focussed on
programmer-characters among the POV-Ray users but i also think a multiple
choice quiz is not adequate for POV-Ray.  POV-Ray is not a multiple choice
program after all - there are no dialogs with checkboxes for adjusting
settings.

There are a lot of things that can't be asked in form of a multiple choice
question without making things really easy and if you are able to answer a
lot of those questions you are not necessarily very competent in using
POV-Ray.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

On Mon, 02 Jun 2003 10:47:31 -0700, Gena <obu### [at] mailcom> wrote:
> Send you questions and answers to this thread.

4. Where you can enter the matrix?
  a. in camera modifiers because this effect changes view of movie
  b. in object modifiers because it should change designed reality
  c. in texture modifiers for those who like distorted pigments
  d. in search field of your help engine with loaded POV manual
  e. all above
  f. none above

;-)

ABX

Post a reply to this message

I guess it's for advanced users :) So please define category
next time.

Gena.

ABX wrote:

> On Mon, 02 Jun 2003 10:47:31 -0700, Gena <obu### [at] mailcom> wrote:
> > Send you questions and answers to this thread.
>
> 4. Where you can enter the matrix?
>   a. in camera modifiers because this effect changes view of movie
>   b. in object modifiers because it should change designed reality
>   c. in texture modifiers for those who like distorted pigments
>   d. in search field of your help engine with loaded POV manual
>   e. all above
>   f. none above
>
> ;-)
>
> ABX

Post a reply to this message

Christoph Hormann wrote:

> I agree that the hardcore Pover test is quite focussed on
> programmer-characters among the POV-Ray users but i also think a multiple
> choice quiz is not adequate for POV-Ray.  POV-Ray is not a multiple choice
> program after all - there are no dialogs with checkboxes for adjusting
> settings.

I think that the answer to any question which really has the answer
can be represnted as a choice from multiple answers. Give me any
question which cannot have a choice of answers :)

> There are a lot of things that can't be asked in form of a multiple choice
> question without making things really easy and if you are able to answer a
> lot of those questions you are not necessarily very competent in using
> POV-Ray.

I usually use quizes just to define holes in my knowledge. It also helps
and stimulates to learn the subject.

Gena.

Post a reply to this message

ABX wrote:

> 4. Where you can enter the matrix?

I would rather like to know, where I can get out of the Matrix! :)

/Ib

Post a reply to this message

Ib Rasmussen wrote:

> I would rather like to know, where I can get out of the Matrix! :)

Just '...don't let machine do what you can do yourself...'
Not sure if that's correct quotation from first 'Matrix' :)

Gena.

Post a reply to this message

"Gena" <obu### [at] mailcom> wrote:
> Ib Rasmussen wrote:
>
> > I would rather like to know, where I can get out of the Matrix! :)
>
> Just '...don't let machine do what you can do yourself...'
> Not sure if that's correct quotation from first 'Matrix' :)
>
> Gena.

Are you referring to "Never send a human to do a machine's job." by Agent
Smith?

Regards,
Daniel.

Post a reply to this message

Christoph Hormann wrote:
> I agree that the hardcore Pover test is quite focussed on
> programmer-characters among the POV-Ray users but i also think a multiple
> choice quiz is not adequate for POV-Ray.  POV-Ray is not a multiple choice
> program after all - there are no dialogs with checkboxes for adjusting
> settings.

For the advanced user, the quiz will consist of things like
'write a computer-vs-computer chess game in POV-SDL which
renders each move' or 'with such-and-such settings and the
following scene, what would the approximate number of rays
shot (scientific notation, 2 significant figures), WITHOUT
running it through POV yourself'...he heh he

-- 
Tim Cook
http://home.bellsouth.net/p/PWP-empyrean

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------

Post a reply to this message

Daniel Ngu wrote:

> Are you referring to "Never send a human to do a machine's job." by Agent
> Smith?

You are right. It has absolutely different meaning :)

Gena.

Post a reply to this message

translate x*2 is the same as:

a. translate 2
b. translate 2*x
c. translate <2, 0, 0>
d. translate <2, 1, 1>
e. translate <4/2, 0, 0>
f.  b, c and e

Post a reply to this message

Parsing time will be shorter if you use:

a. separate trasnformation operations - scale, rotate and translate
b. one transformation block - transform{scale x*n rotate y*m translate z*k}

c. matrix

Post a reply to this message

Gena <obu### [at] mailcom> wrote:
> Parsing time will be shorter if you use:

> a. separate trasnformation operations - scale, rotate and translate
> b. one transformation block - transform{scale x*n rotate y*m translate z*k}
> c. matrix

  Have you actually measured which of those is fastest?

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

In article <3EDD4217.83B3A431@mail.com>, Gena <obu### [at] mailcom> wrote:

> Parsing time will be shorter if you use:
> 
> a. separate trasnformation operations - scale, rotate and translate
> b. one transformation block - transform{scale x*n rotate y*m translate z*k}
> c. matrix

The answers are vaguely worded, so it is unclear what exactly they mean, 
and the topic...there won't be enough of a difference to matter.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

> Well, I don't want to post answers here :) I only measured difference between a
> and b.
> For b and c I rely on documentation - 6.3.4 Transform Identifiers (see bottom
> part).

In case of c) it would be more correct to say:
c. separate matrix for scale, rotate and translate.

Because I think one combined transformation matrix should have the same
performance as 'transform'. Please correct me if I'm wrong :)

Gena.

Post a reply to this message

Christopher James Huff wrote:

> The answers are vaguely worded, so it is unclear what exactly they mean,

Feel free to correct, add and modify everything :)

> and the topic...there won't be enough of a difference to matter.

Do you mean that just one category will be enough?

Gena.

Post a reply to this message

Gena Obukhov <obu### [at] mailcom> wrote:
>> and the topic...there won't be enough of a difference to matter.

> Do you mean that just one category will be enough?

  I think that he meant that the difference in parsing time between the
given transformation syntaxes are so minimal that in practice it isn't
a big deal. (And as we know, the difference in rendering time, which is
usually the most important issue, is non-existent.)

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Warp wrote:

>   I think that he meant that the difference in parsing time between the
> given transformation syntaxes are so minimal that in practice it isn't
> a big deal. (And as we know, the difference in rendering time, which is
> usually the most important issue, is non-existent.)

I posted some sources to p.b.s.-f. newsgroup (transform test). Try to
render that scene with two different macros: 'tomtree.inc' and 'tomtreet.inc'
The only difference between these two macros is 'transform'. The scene which
uses macro with 'transform' (tomtreet.inc) renders 6-7 times faster.

Gena.

Post a reply to this message

On Wed, 04 Jun 2003 18:56:49 -0700, Gena Obukhov <obu### [at] mailcom> wrote:

>> Well, I don't want to post answers here :) I only measured difference between a
>> and b.
>> For b and c I rely on documentation - 6.3.4 Transform Identifiers (see bottom
>> part).
>
>In case of c) it would be more correct to say:
>c. separate matrix for scale, rotate and translate.
>
> Because I think one combined transformation matrix should have the same
> performance as 'transform'. Please correct me if I'm wrong :)

Simple transformation written directly in modifiers, as

  scale 2
  translate x

means 4 tokens to be parsed, while enclosed by transform

  transform{
    scale 2
    translate x
  }

means 7 tokens to be parsed, while written as matrix

  matrix <2,0,0,0,2,0,0,0,2,1,0,0>

means 26 tokens to be parsed. So all together difference might be not that
simple as it may look. They are rather other benefits from using one method or
another.

ABX

Post a reply to this message

In article <3ede847e@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>> a. separate trasnformation operations - scale, rotate and translate
>> b. one transformation block - transform{scale x*n rotate y*m translate z*k}
>> c. matrix
>
>   Have you actually measured which of those is fastest?

Does it matter? ;-)  If you want, I can make any of these the fastest! ;-)

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Gena Obukhov <obu### [at] mailcom> wrote:
> The scene which
> uses macro with 'transform' (tomtreet.inc) renders 6-7 times faster.

  You don't mean it parses 6-7 times faster?

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Warp wrote:

> Gena Obukhov <obu### [at] mailcom> wrote:
> > The scene which
> > uses macro with 'transform' (tomtreet.inc) renders 6-7 times faster.
>
>   You don't mean it parses 6-7 times faster?

Yes, it looks like parsing time is almost the same :) So, where is the
advantage of 'transform' - parsing or rendering time? According
to doc it's parsing time (6.3.4 Transform Identifiers). According to this
test it's rendering time. I'm confused :(

Gena.

Post a reply to this message

On 5 Jun 2003 10:21:53 -0400, Warp <war### [at] tagpovrayorg> wrote:
> > The scene which
> > uses macro with 'transform' (tomtreet.inc) renders 6-7 times faster.
>
> You don't mean it parses 6-7 times faster?

When you apply transform to CGS each scale, translate, rotate etc. cause
separate calculation of transformation matrix and applying it to all children of
this object. So if you have union of 100 objects, and you rotate and then scale
this union it cause 202 calls to Transform_Object (for each child + parent). If
you enclose scale and rotate within transform{} it is first parsed into one
matrix within Parse_Objects_Mods and 101 calls to Transform_Object is executed. 
The difference is not small and increases with number of transformations.

ABX

Post a reply to this message

Gena Obukhov <obu### [at] mailcom> wrote:
> According to this test it's rendering time. I'm confused :(

  Internally only one type of transformation matrix is used. Every
transformation you write with the POV-Ray SDL is stored in this internal
transformation matris, regardless of their syntax or amount.

  There's one additional thing, though:
  A transformation matrix is not always applied to an object. If the object
does not need any transformation matrix, then none is used in it. This
naturally speeds up rendering because the ray doesn't need to be multiplied
by the matrix when rendering.
  There are some primitives which have an optimization built into them:
For example, if you translate or rotate a sphere, only its center point
will be modified, but no transformation matrix will be assigned to it.
Similarly if you scale the sphere uniformly, only its radius will be modified.
(If the sphere has a texture, the a transformation must be applied to the
texture itself, though.) Only if you scale the sphere non-uniformly, a
transformation matrix will be applied to it.

  Now, this may explain the difference in rendering speed. If the tree
consists solely of primitives which have these built-in optimizations
(such as spheres, boxes, cylinders and cones, AFAIK) and you only use
transformations which are optimizable away (such as translates), POV-Ray
will not generate any transformation matrix for the whole tree structure.
  However, if you use a transformation not included in the optimizations
(such as the 'transform' block seems to be the case), matrices will be
applied to all objects in the tree, thus causing a penalty in render time.

  To test that this theory is correct, try your test with non-uniform
scaling (such as "scale <1,1.5,1.2>") in additions to the translates.
If the theory is correct, the render time should be identical no matter
what transformation syntax you use.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

Warp wrote:
> However, if you use a transformation not included
> in the optimizations (such as the 'transform' block
> seems to be the case), matrices will be applied to
> all objects in the tree, thus causing a penalty in
> render time.

Couldn't it be tested for a transform block if it could be optimized to
a rotation, a translation and a uniform scaling? Shouldn't it be enough
to test if the transformation matrix is an orthogonal one? And if it is,
isn't it always possible to do the desired optimization?

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com (updated Oct 19)
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

Rune <run### [at] runevisioncom> wrote:
> Couldn't it be tested for a transform block if it could be optimized to
> a rotation, a translation and a uniform scaling? Shouldn't it be enough
> to test if the transformation matrix is an orthogonal one? And if it is,
> isn't it always possible to do the desired optimization?

  I suppose so, and I suppose that no-one bothered when implementing the
transform block code... :)

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

Warp wrote:
> I suppose so, and I suppose that no-one bothered
> when implementing the transform block code... :)

Well, it only makes for a render speed difference of 6-7 times anyway...
;)

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com (updated Oct 19)
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

For pure yellow background you can use:

a. #include "colors.inc"
    background {Yellow}

b. #include "colors.inc"
    background {color Yellow}

c. #include "colors.inc"
    background {color rgb Yellow}

d. #include "colors.inc"
    background {Red + Green}

e. background {<1, 1, 0>}

f. all above

Post a reply to this message

On Thu, 05 Jun 2003 15:58:29 +0200, "Thorsten Froehlich"
<tho### [at] trfde> wrote:

>Does it matter? ;-)  If you want, I can make any of these the fastest! ;-)

Without handicapping the other two?


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

On Thu, 05 Jun 2003 16:35:08 +0200, ABX <abx### [at] abxartpl> wrote:

>When you apply transform to CGS each scale, translate, rotate etc. cause
>separate calculation of transformation matrix and applying it to all children of
>this object. 

Are you sure about that? IIRC the logic behind CGS is that when a ray
is traced, it is first reverse-transformed by the CSG transformation,
and then for each child that has a transform, it is
reverse-transformed by the child transformation. Or am I wrong?


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

On Tue, 10 Jun 2003 15:48:47 +0300, Peter Popov <pet### [at] vipbg> wrote:
> > When you apply transform to CGS each scale, translate, rotate etc. cause
> > separate calculation of transformation matrix and applying it to all children of
> > this object. 
>
> Are you sure about that? IIRC the logic behind CGS is that when a ray
> is traced, it is first reverse-transformed by the CSG transformation,
> and then for each child that has a transform, it is
> reverse-transformed by the child transformation. Or am I wrong?

Well, I did not debuged it but ...

  void Parse_Object_Mods (OBJECT *Object)
  {
    ...
    CASE (TRANSLATE_TOKEN)
      Parse_Vector (Local_Vector);
      Compute_Translation_Transform(&Local_Trans, Local_Vector);
      Translate_Object (Object, Local_Vector, &Local_Trans);
    END_CASE
    ...
  }

and ...

  void Translate_Object (OBJECT *Object, VECTOR Vector, TRANSFORM *Trans)
  {
    ...
    Translate(Object, Vector, Trans);
  }

and ...

  #define Translate(x,y,z) ((*((x)->Methods->Translate_Method)) (x,y,z))

and ...

  static void Translate_CSG (OBJECT *Object, VECTOR Vector, TRANSFORM *Trans)
  {
    OBJECT *Sib;
    for (Sib = ((CSG *) Object)->Children; Sib != NULL; Sib = Sib->Sibling)
    {
      Translate_Object(Sib, Vector, Trans);
    }
    Recompute_BBox(&Object->BBox, Trans);
  }

and intersection tests for CSG seems not contain transforming of ray.

ABX

Post a reply to this message