"clipka" <nomail@nomail> wrote:
> "Grobi" <and### [at] boesmanncom> wrote:
> > Is there a way to keep the parsed information to use with e.g. another
> > resolution render ?
>
> Not yet.
>
> However, if you precompute anything, you might want to #write data to a file
> (maybe "ready to rock" as an #include file)



Wait, did you say yet??  Ooohh, I like the sound of that!

Actually... I was thinking about that the other day, and I thought it might be
neat to introduce a keyword 'static', which would specify that an object need
not be reparsed for animations.  Working with larger sized meshes, image_map
textures, and high resolution heightfields (greater than 10 mb) pretty much
convinced me that such a thing would be very nice.
I fondly imagine code like the following:

// code:
static height_field{
    png "MASSIVE.PNG" // 25 mb image on older, low speed IDE drive
    smooth            //  shared over a WAN connected to by dial-up.
}

// rest of scene is parsed normally for each frame

I was even thinking about how a declaration could be static and not reparsed,
but the object could still be moved:

// code:

static height_field{
    png "MASSIVE1.PNG"
    smooth
    translate <0,0,clock>
// since it is NOT reparsed, hf doesn't move as clock changes.
// instead, it simply sits where it was translated by the initial
// value of clock, when it was first parsed
}


#declare myHF =
static height_field{
    png "MASSIVE2.PNG"
    smooth
}

object{ myHF  translate <0,0,clock> }
// while myHF is not reparsed, this particular instance of myHF
// does move as clock changes, since the instantiation is parsed normally.

Of course, this got me thinking about the whole thing with images, and how they
can be used as an image_map or height_field or some other thing, and how maybe
it would be neat to have a non-object, non-rendering primitive in the form of
an image{}.
Like:

#declare myImage = image{ png "terrain.png" }

//then, later:
height_field
{
  myImage  // no need to re-read myImage
  smooth   // since it was read when it was declared
    pigment{
        image_map{ myImage }
        // could have also used it for image_pattern, etc
    }
}

// then, even later:
#declare myImage = static image{ png "myTexture.png" }


Then, I started thinking about how maybe this 'static' thing is something that
could be better implemented differently, like changing the way included files
or macros are handled (so as to prevent unnecessary file re-reading).  After
thinking that, I remembered that if you only read a file once, one could no
longer write complicated self-modifying scenes that use 3 or fewer files as
easily (not that I would condone such activities), so I stopped thinking about
these things at that point.

Anyway, as much as I like using the keyword 'static' for this, it occurs to me
that it is probably better used for (eventually) declaring permanent-yet-local
identifiers, and using it to mean two different things in two different
contexts is probably not the best idea.


  -Reactor

Post a reply to this message