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