Andrew Woodfin wrote:

> ...pixel objects according to original
> pixel color and contrast, and allows for animation to blow the picture
> to smithereens.
> Andrew Woodfin

 I spent quite a bit of time last tonight trying to figure out what
this guy could possible have been thinking whan he added a clock
modifier to every single objects translation statement, Not just
for one direction but for all three three at one time. How was I
to guess that it was the long awaited "Blow it to Smithereens"
option ? I had thought that maybe there was a bug in the std.out
directive until I found that brief mention of the feature above.

  While I agree that it is a novel idea I suggest a command line
option for it's inclusion. Edited out through search and relplace
yielded a file size reduction of 70k for a 640x480 image -> sphere
conversion I tried last night. A similar file output size and memory
enhancement for the cylinder output option could be implemented
as well. Currently if you specify the single color option the
program is writing a seperate texture statement for each cylinder
in the file.
  This adds little to no flexibility to the scene file, but the
overhead is high for formatting the scene file in this way. It
would be better to wrap all of the cylinders in a simple union and
and treat them with one global texture statement. When applied on
a object by object basis as is the method now, the program must
calculate the seperate texture, scale it, rotate it, translate it,
and then adds a memory pointer for the texture on each and every
object in the scene. This adds another 80k in physical file size
and nearly doubles the memory requirements for the scene file.

  Suggestions for other possible modifications or changes in
user definable options are:

1.) user declare object spacing - center line to center line.
    Currently the program allows for % of pixels sampled and
    the object size is based loosely on this. Even where the
    provision for the objects size has been made it does not
    help dictate object placement. If too small an object size
    is used, the spacing between them becomes to great, and the
    pattern is effected in a negative way.

2.) Option to apply the original image as an image map overay
    to the ojects generated as opposed to individualy pigmented
    objects. I am not suggesting removal of the current process
    but I feel there are times where it would be nice to have
    the alternative available. Since the program already knows
    the boundries of the entire object it is easier for it
    to scale and translate an image map into place than it is
    for the user to try to calculate themselves.

3.) Related to the last would be an option to have the program
    wrap all object in a union, normalize it's position in
    relation to the origin, and then scale it down to a unit
    sized object. It is difficult to know how large and where
    it is exactly right now and attempts to move and scale it
    results in time consuming operations to position and scale
    it elsewhere in the scene.

4.) A general observation you may act upon or ignore at your own
    discretion. Programs that produce a large number of objects
    for Pov, and this part I still don't understand, will invariably
    use formatting of the Pov script that comsumes a very large
    chunk of real estate. For example you have in your translate
    statements:

    <2.24  +clock*1.402,  10.2  +clock*3.3,  -3.32  +clock*12.343>

    That is a lot of file space for something that could be handled
    differently and produce the same functionality. If for example
    you declared an abreviation for the clock at the top of the file
    you could loose up to 12 characters per line.
    Example:

    #declare T = clock;

    <2.24  +T*1.402,  10.2  +T*3.3,  -3.32  +T*12.343>

    If yuu removed the double spaces after each comma, and before
    the + sign that is an additional 10 character spaces removed
    from the file. Example:

    <2.24+T*1.402,10.2+T*3.3,-3.32 +T*12.343>

    While these changes seem petty on a line by line basis they
    add up in a big hurry when your object numbers in excess of
    a couple of thousand. I also know that it really grates on
    the nerves of programmer types to vary from the very rigid
    language structures they use in the code but lets face it,
    nobody is going to go through a 1 meg file generated by
    your program and try to read it on a line by line basis.
    All they are likely ever to see is the first twenty and last
    twenty lines and rest are obscurred for eternity. I did a
    little creative editing on one of the files I tested last
    night to see exacstly how far I could reduce the file size
    without changing the functionality of the content.


   Initial file size                         1,144,240
   Removed spaces between comma seperators   1,068,741 -> - 75,499
   Removed word color from the entire file   1,100,261 ->  -63,480
   Finished removing every uneeded space       833,861 -> -171,400

   Total savings in file size after edit =     310,379

     As you can see that works out to a file size savings of nearly
    one third of the original. With a few other replacement tricks
    I probably could have got that down to about 700k but I feel
    I have illustrated my point well enough with my examples.
    That is an impressive amount and the consequences of files with
    that much dead space simply imply the amount of hard drive space
    each one consumes. Pov doesn't really care one way or another but
    I do.


  Anyway I thought I would take the time to offer my observations
 and suggestions and I hope you find them useful to you.

Thank you,

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message