>Are you a developer or a user of the logistics program?
>The Pov code need to be changed so that it defines a macro with
>different variables.
>I am not a programmer but I have been using programs that export Pov
>code, for about 15 years. It is a problem with machine written code. :-(

I am an user. Do you have any source on how to use/write macros in pov ray?

> > Question 1: How should the file (scene?) look like when it contains a object
> > that is repeated 30.000 times at different locations to minimize parsing time.
>
> As for the object itself, that looks about as good as it gets: The
> object description actually references a "template" presumably defined
> earlier (named M_0 in this case), with the matrix<...> statement
> specifying the location and orientation of the respective copy by means
> of a coordinate transformation matrix.
>
> The "#declare cube=pigment ..." statement should be present only once
> (for each distinct filename, that is); if that is indeed the case, then
> there's not much more to optimize there either. If the statement is
> repeated all around the place, then it's an indication that the author
> of the generating software /tried/ to optimize the generated .pov file
> but made some stupid blunder along the way. (As a matter of fact, the
> very purpose of the "#declare" statement is to define templates for
> various things to be referenced later, in this case some texture
> property. You'll also find some "#declare M_0=..." somewhere, hopefully
> in just one single place.)


The complete part that I postet repeats 30.000 times. Including the #declare...
line.

In addition to this at the beginning of the document I can find the more general
definition you mentioned.

#declare cube=pigment { image_map { png "povincludes/cube.png"} }
#declare M_0=
  mesh2 {
    #include "povincludes/M0c27c969_b190_4ad2_9fb3_0f1f068dc56b_VV.inc"
    #include "povincludes/M0c27c969_b190_4ad2_9fb3_0f1f068dc56b_NV.inc"
    #include "povincludes/M0c27c969_b190_4ad2_9fb3_0f1f068dc56b_UV.inc"
    texture_list { 1,
      texture { cube finish { ambient 1 diffuse 1 reflection 0 } }
    }
    #include "povincludes/M0c27c969_b190_4ad2_9fb3_0f1f068dc56b_FI.inc"
    uv_mapping
  }
object { M_0
  matrix <
  -9.091367E-06,  -3.256779E-05,  0.9999999,
  -3.532349E-06,  1,  3.256775E-05,
  -0.9999999,  -3.532056E-06,  -9.091482E-06,
  -12.64854,  10.48967,  -33.32481>
}

I edited the pov file in a text editor and removed the extra 30.000 declare
lines. Unfortunately that did not reduce the parsing time.

Furthermore I tried the following:
- Changed the png file to a 1x1 px file. Parsing now only takes 40 seconds.
- Changed the png file to a 1x1 px file AND removed the 30.000 declare lines.
parsing now takes about 15 seconds.

So we found the spot where we have to apply the tweaking.

Something I can do by myself: Use smaller PNG file (even they are not really big
actually).

The big question is: How can we (or better said the developer) optimize the
loading of png files. Only removing the declare line has not changed a lot.

Post a reply to this message