Its about time persistent variables showed up in either the official of
non-official versions of POV-ray

Post a reply to this message

On Wed, 17 Nov 1999 12:53:52 +0800, Pabs <pab### [at] hotmailcom> wrote:

>Its about time persistent variables showed up in either the official of
>non-official versions of POV-ray
>

So write a patch.

-- 
NOT speaking for the POV-Team.  Definitely not.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

Pabs <pab### [at] hotmailcom> wrote:
: Its about time persistent variables showed up in either the official of
: non-official versions of POV-ray

  It's easy. Write something like this at the beginning of the scene:

#if(clock=0)
  // set initial values to the persistent variables
#else
  #fopen iFile "variables.dat" read
  // read values for persistent variables from iFile
  #fclose iFile
#end

  At the end of the scene:

#fopen oFile "variables.dat" write
// write values of persistent values to oFile separated with commas
#fclose oFile

  I have used this method in my 'robots' irtc animation with success.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

That I'm starting;
Heres what I got so far for usage
1 #persist varnam [= rval]
mark varnam as persistent
[set varnam to rval]
good for dynamic systems animation - some people have been calling for

2 #unpersist varnam [= rval]
mark varnam as non-persistent
[set varnam to rval]

3 persists(varnam)
 returns true if persistent
check a variable

4 #declare varnam = rval
changes varnam if it is not persistent

5 #declarepersist varnam = rval
same as
#declare varnam = rval
#persist varnam
good for those objects/textures that don't change between renders
extension of using #if and the above

6 #declareunpersist varnam = rval
same as
#declare varnam = rval
#unpersist varnam
extension of using #if and the above

UI
a dialog box indicating persistent variables and providing for their
management-
refresh, destroy, etc

Any ideas, critisisms, comments to pab### [at] hotmailcom after 25-26 Nov (can't
access the news server) - thanks

PS once I/others have written the code could it be included in Superpatch??
please :-) :-| :-(
PS Love that isosurface. Can it be over a larger area rather than unit cube?

Ron Parker wrote:

> On Wed, 17 Nov 1999 12:53:52 +0800, Pabs <pab### [at] hotmailcom> wrote:
>
> >Its about time persistent variables showed up in either the official of
> >non-official versions of POV-ray
> >
>
> So write a patch.
>
> --
> NOT speaking for the POV-Team.  Definitely not.
> The superpatch: http://www2.fwi.com/~parkerr/superpatch/
> My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

In article <383A2DCD.648D3DD9@wantree.com.au>, mnewton
<mne### [at] wantreecomau> wrote:

I think maybe a better solution would be to make variables have more
distinct types, like vector, float, etc. You could then add persistant,
constant, etc.
#declare varA = persistant const vector < 0, 1, 3>;

#redefine varA = vector varA;

#declare varB = varA.x;

Maybe the type modifiers should be enclosed in [],(), or something to
separate them from the rest of the declaration, but I don't think that
would be necessary. The parser would attempt to automatically determine
the types, but they should be used for clarity.
This has the advantage that it uses fewer keywords, and makes it
clearer what the code does.


Another possible syntax, which fits in with object {}, texture {}, etc.
being their own type:
#declare varA = vector {< 0, 1, 3> persistant on const on};

#redeclare varA = vector {varA persistant off const off};

#declare varB = float {varA.x};
The persistant and const flags would default to off, and just the
keywords would turn them on.

Also, I think all variable declarations should end in a semicolon, this
makes things like layered texture declarations more obvious and is more
consistant. Also, you could have something like:
#declare MySpheres =
sphere {blahblah}
sphere {blahblah}
sphere {blahblah};

be interpreted as:
#declare MySpheres =
union {
    sphere {blahblah}
    sphere {blahblah}
    sphere {blahblah};
};


Also, I think the #local keyword is explained a bit ambiguously, is a
local variable local to the #keyword...#end block containing it, or
only to the containing file or #macro? The latter should be the case,
because this wouldn't work otherwise:
#local k=0;
#while(k<10)
    #local k=k+1;//if this is local to the loop, it won't affect the
counter.
#end

> PS Love that isosurface. Can it be over a larger area rather than unit cube?

The isosurface can be bounded by whatever shape you want, although I
have never tried an infinite object like a plane. Those may not work
correctly, I don't know.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

On Tue, 23 Nov 1999 07:42:57 -0500, Chris Huff wrote:
>> PS Love that isosurface. Can it be over a larger area rather than unit cube?
>
>The isosurface can be bounded by whatever shape you want, although I
>have never tried an infinite object like a plane. Those may not work
>correctly, I don't know.

Actually, only boxes and spheres are supported, as mentioned (sort of) in
the docs.  Some functions, like the round box, require a box.

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

In article <383a95ff@news.povray.org>, Ron Parker
<ron### [at] povrayorg> wrote:

> Actually, only boxes and spheres are supported, as mentioned (sort of) in
> the docs.  Some functions, like the round box, require a box.

Hrm, I was sure I had used a cylinder before...oh well.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Wouldn't it be easier to do it with #macros that use file-io?

  On the other hand, it would only work with floats and vectors (and arrays
of them with array-specific macros). But is there need for other types of
identifiers to be persistent?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <383aa335@news.povray.org>, Nieminen Juha
<war### [at] punarastascstutfi> wrote:

>   Wouldn't it be easier to do it with #macros that use file-io?
> 
>   On the other hand, it would only work with floats and vectors (and arrays
> of them with array-specific macros). But is there need for other types of
> identifiers to be persistent?

The patch would be easier to use, once it is written. :-)
There are a lot of times it would be useful to make an object
persistant, say you have a tree that doesn't change through the
animation, but takes 20 minutes to parse. You would be saving 20
minutes per frame after the first frame. Also, particle simulations
would benefit a lot from persistant variables.
Also, it might be difficult to manage a persistant array using file I/O.
And besides that, I think the syntax for declaring variables could be
improved. No reason to drop the old syntax, just provide for the new
one.
The patch shouldn't be too difficult to do, except for the persistant
variables part(which I don't know how to do). I propose something like
this:
#declare MyFloat = float {FLOAT_EXP VARIABLE_FLAGS};
#declare MyVector = vector {VECTOR_EXP VARIABLE_FLAGS};
and so on, with object, texture, and others. Maybe a restricted sort of
pointer, too?(with protection against modifying memory it shouldn't)

where VARIABLE_FLAGS are:
const on/off           Whether or not the variable can be modified, an
attempt to modify it produces an error.
persistant on/off      Whether the value is carried to the next frame
or not.
Any suggestions?

Also, maybe #declare and #local should be required only when creating a
new identifier, so you could use:
#declare k=float{0};
#while(k<5)
    k=k+1;         //short form
    k=float{k+1};  //long form, ideally, both would be allowed
#end
This is just a minor thing I have been thinking about, but it would
make a lot of code easier to read. A variable should not be modified if
it is used in the #if() or #while() expression, though.(if it was, a ==
operator would be required, and some old scenes would break)

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

There have been suggestion about adding support for "static" objects in
povray. These static objects would be parsed only for the first frame but
not for the rest.
  Identifiers could also be declared as static, making the persistent. A
constant identifier could also be a good idea.

#static Position = <1,2,3>; // like #local, but persistent
#const Radius = 5; // same as #static, but makes it also unchangeable
#static Object =
  union
  { ...
  }

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message