Will #persistent make it from Ueberpov to 3.8? Extremely usefull feature.

ingo

Post a reply to this message

ingo <ing### [at] tagpovrayorg> wrote:
> Will #persistent make it from Ueberpov to 3.8? Extremely usefull feature.
>
> ingo

second

Post a reply to this message

Am 27.12.2018 um 22:54 schrieb ingo:
> Will #persistent make it from Ueberpov to 3.8? Extremely usefull feature.

Not yet - the implementation in UberPOV is too hackish, with persistent 
variables not only carrying over between frames of an animation, but 
also between independent renders in the same session (on Windows).

Post a reply to this message

in news:5c25f0ef$1@news.povray.org clipka wrote:

> [...] with
> persistent variables not only carrying over between frames of an
> animation, but also between independent renders in the same session
> (on Windows). 
> 

Ouch. That's not what we want.

Thanks Clipka,

ingo

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 27.12.2018 um 22:54 schrieb ingo:
> > Will #persistent make it from Ueberpov to 3.8? Extremely usefull feature.
>
> Not yet -

shucks

> the implementation in UberPOV is too hackish, with persistent
> variables not only carrying over between frames of an animation, but
> also between independent renders in the same session (on Windows).

ok for linux tho (which is where i use it)?  if not so much, just restart povray
between projects?

Post a reply to this message

Am 28.12.2018 um 13:00 schrieb green:

>> the implementation in UberPOV is too hackish, with persistent
>> variables not only carrying over between frames of an animation, but
>> also between independent renders in the same session (on Windows).
> 
> ok for linux tho (which is where i use it)?  if not so much, just restart povray
> between projects?

No, the proper route is to clean up POV-Ray's internal architecture even 
more, and then implement it in a fashion that works regardless of the 
platform.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 28.12.2018 um 13:00 schrieb green:
>
> >> the implementation in UberPOV is too hackish, with persistent
> >> variables not only carrying over between frames of an animation, but
> >> also between independent renders in the same session (on Windows).
> >
> > ok for linux tho (which is where i use it)?  if not so much, just restart povray
> > between projects?
>
> No, the proper route is to clean up POV-Ray's internal architecture even
> more, and then implement it in a fashion that works regardless of the
> platform.

Yes, for "long-term proper".

For short-term accessibility, perhaps a #reset_defaults to begin a scene with,
that be deprecated / ignored one the long-term permanent proper fix is in.

Post a reply to this message

in news:web.5c27863e874d1a8e765e06870@news.povray.org Bald Eagle wrote:

> For short-term

Meh. With #write a lot can be done already, below's the resulting file 
of ~170 lines of macro. I'd opt for doing #persistent right. That doesnt 
take a way that it is an important feature that I've missed often and 
for me would be high on the list.

#declare Self=dictionary{
  ["LogLevel"]:0,
  ["Default"]:dictionary{
    ["Tolerance"]:0.010,
    ["MaxIter"]:100
  },
  ["ProcessType"]:dictionary{
    ["BaseEnd"]:0,
    ["BaseSubbase"]:1,
    ["SubbaseSubbase"]:2,
    ["SubbaseEnd"]:3,
    ["ClosedLoop"]:4
  },
  ["Index"]:array{"Base1"},
  ["Proc"]:array[1]{"Base1"},
  ["Base1"]:dictionary{
    ["Type"]:"BaseEnd",
    ["Joint"]:array[7]{<0,0,0> ,<0,0.25,0> ,<0,0.5,0> ,<0,0.75,0> ,
<0.111803,0.973607,0> ,<-0.277081,1.28788,0> ,<-0.0783398,1.74669,0> },
    ["_Lengths"]:array[6]{0.25,0.25,0.25,0.25,0.5,0.5},
    ["_Length"]:2.000000,
    ["_O"]:<0,0,0> ,
    ["_N"]:7,
    ["_M"]:6,
    ["Effector"]:6,
    ["Target"]:<-0.0786086,1.74607,0> ,
    ["Constraints"]:dictionary{
      ["3"]:dictionary{
        ["Objn"]:"C",
        ["Objs"]:C,
        ["Axis"]:<0,1,0> ,
        ["TTs"]:<0,1,0> ,
      },
    },
  },
}

Post a reply to this message

ingo <ing### [at] tagpovrayorg> wrote:
> in news:web.5c27863e874d1a8e765e06870@news.povray.org Bald Eagle wrote:
>
> > For short-term
>
> Meh. With #write a lot can be done already, below's the resulting file
> of ~170 lines of macro. I'd opt for doing #persistent right. That doesnt
> take a way that it is an important feature that I've missed often and
> for me would be high on the list.
>

i can't say i can connect the code with the topic.
  #write might be more useful in this context if it wrote to a ram disk.

i believe my question to lipka was off-target.  linux generally spawns povray
for each batch of frames, so persistent objects should be lost after a job.  it
is hard to see how name conflicts would arise without contrived examples.
  for windows it is different.  i've already bumped my nose hard against it.  i
use a construct such as this to work around it;

#declare klock=clock; // or whatever time you are interested in
#if( klock=0)         // or whatever time you are interested in
    #ifdef( thatthing)
        #undef thatthing
    #end
#end
#ifndef(thatthing)
    #persistent thatthing=
    ...
#end

i think this type of thing should be sufficient.

i have not exercised due diligence in determining how much time uberpov saves
for long-parsing frames, but the small amount of experimentation i have done
suggests ten or twenty percent.  which is an enormous amount when making frames
for days or weeks or months.  so i will keep on using uberpov for animations
unless 3.8 has something i /have/ to have.

Post a reply to this message