hi,

as per the subject, I have tried to .. brow-beat CC to consider some of the nice
'povr' features you added, when the opportunity arose talking about the
broken-on-Linux RTR feature.

so, regarding RTR, I want to find out what (pretty much) exactly was the
difference to the Windows version (and 'povr').  my guess was/is, essentially a
pointer not pointing to the correct buffer, as everything appears to work except
the preview window.

have several more questions, but would (probably) prefer to ask those in
private.


regards, jr.

Post a reply to this message

On 2/26/23 06:59, jr wrote:
> hi,
> 
> as per the subject, I have tried to .. brow-beat CC to consider some of the nice
> 'povr' features you added, when the opportunity arose talking about the
> broken-on-Linux RTR feature.
> 
> so, regarding RTR, I want to find out what (pretty much) exactly was the
> difference to the Windows version (and 'povr').  my guess was/is, essentially a
> pointer not pointing to the correct buffer, as everything appears to work except
> the preview window.

IIRC. The only thing you need to do to activate the existing rtr feature 
with 'unix' compiles in v3.8+ branches is to define a variable called 
RTR_HACK.

There were a couple of issues / bugs as I recall which are fixed in the 
povr source. First was that RTR_HACK didn't wrap all the rtr related 
code - why it appears to be there, but broken with unix compiles. There 
was too a bug where AA worked only for the first frame or two of an rtr 
animation - true no matter the Operating System. Might be some other 
stuff, but nothing popping into my head.

There is too a POV_RTR_DEBUG define - but I don't 'think' it currently 
used. It might be in certain sets of code.

The povr fork has gone on to add additional features as you know. All 
should be wrapped with RTR_HACK as in:

#ifdef RTR_HACK
...
#endif

> 
> have several more questions, but would (probably) prefer to ask those in
> private.
> 

I'll email you from my gmail account. I hardly use it these days, but it 
is the account where I've tried to keep most POV-Ray email.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 2/26/23 06:59, jr wrote:
>
> There were a couple of issues / bugs as I recall which are fixed in the
> povr source. First was that RTR_HACK didn't wrap all the rtr related
> code - why it appears to be there, but broken with unix compiles. There
> was too a bug where AA worked only for the first frame or two of an rtr
> animation - true no matter the Operating System. Might be some other
> stuff, but nothing popping into my head.
>

[Windows 10, and using v3.8.0 beta 1, already compiled]:
Just tested +kla +rtr, and AA does work with it. It has been awhile since I used
the real-time animation feature-- probably on an older Win 7 machine a couple of
years ago.

The only trouble I'm currently having is getting the animation to stop! On my
newer and faster machine, hitting the GUI's 'stop' button sometimes works,
sometimes doesn't. It depends on how fast the animation is running. Shutting
down POV-ray is then the only way to end the process (AFTER hitting the stop
button repeatedly)-- otherwise, it would probably run until the year 10,191 :-O

Here's something subtle that I also just noticed: In this 'runaway' condition,
and after stabbing at the 'stop' button with no result, the animation will
sometimes suddenly speed up even faster(!). My machine's processor fan also
quiets down-- as if there is suddenly no more CPU-processing taking place. It's
like the animation is now simply playing back from a memory cache(?).

Post a reply to this message

On 3/1/23 23:12, Kenneth wrote:
> Just tested +kla +rtr, and AA does work with it. It has been awhile since I used
> the real-time animation feature-- probably on an older Win 7 machine a couple of
> years ago.
Hmm. I'm pretty sure AA modes 1 & 2 stop working completely after frame 
2 or 3. It's running, but it doesn't do anything after a while because 
the internal box sizes shrink on every recursion and never get reset.

> 
> The only trouble I'm currently having is getting the animation to stop!

Yes, this seems to be a problem more so on windows than unix/linux but 
it happens there too sometimes. There is I believe a github issue open 
on the problem. Little bells... I 'think' more often with SDL1.2 than 
SDL2.0/X11 an on unix/linux the preview window needs to be in 'focus' / 
active.

With the povr branch I broke out the cylic control as it's own thing and 
the default is to run through the cameras only once. Also means +kla / 
clockless_animation now means 'clockless animation' and not 'cylic 
clockless animation'.

// Use +kc (Cyclic_Animation=true) for cylic / continuous renders
// looping through cameras.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 3/1/23 23:12, Kenneth wrote:
> >
> > Just tested +kla +rtr, and AA does work with it.

> Hmm. I'm pretty sure AA modes 1 & 2 stop working completely after frame
> 2 or 3. It's running, but it doesn't do anything after a while because
> the internal box sizes shrink on every recursion and never get reset.

I had to double-check this, to prove it to myself ;-)  It does seem to be
working OK.

I let my animation cycle for several minutes(!), with a '20-camera animation'.
The attached images are screenshots of 'camera 19', then blown up 200%.
> >
> > The only trouble I'm currently having is getting the animation to stop!
>
> I 'think' more often with SDL1.2 than
> SDL2.0/X11 an on unix/linux the preview window needs to be in 'focus' /
> active.

That appears to help with the Windows version too, if the animation isn't
playing *super*-fast. Thanks.

Post a reply to this message

Attachments:
Download 'aa_with_kla_rtr.jpg' (162 KB)

Preview of image 'aa_with_kla_rtr.jpg'

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> I let my animation cycle for several minutes(!), with a '20-camera animation'.
> The attached images are screenshots of 'camera 19', then blown up 200%.

Forgot to mention that the "CL" lettering in the images is not being
anti-aliased, by mistake; the reason is that I had set its texture{diffuse...}
value to 20, not 1...and anti-aliasing begins to fail with super-bright objects
>> 1.0

Post a reply to this message

On 3/3/23 03:38, Kenneth wrote:
>> Hmm. I'm pretty sure AA modes 1 & 2 stop working completely after frame
>> 2 or 3. It's running, but it doesn't do anything after a while because
>> the internal box sizes shrink on every recursion and never get reset.
> I had to double-check this, to prove it to myself 😉  It does seem to be
> working OK.
> 
> I let my animation cycle for several minutes(!), with a '20-camera animation'.
> The attached images are screenshots of 'camera 19', then blown up 200%.

OK. Thanks!

I'll put it on the list to again review in povr. I'd first noticed it 
with povr's, again truly random jitter with and big jitter values (>1). 
Maybe I did something which caused the problem while banging on code! Or 
maybe the windows version is for some reason different - in official 
POV-Ray code, RTR doesn't work on unix/linux machines.

Hmm, I got the compiles set now to turn off the duplicate vector zeroing 
on allocation. Maybe the duplicate zeroing was covering some other 
behavior as I've found quite a few times already. To test such thoughts 
is why there is the povr configure option:

--enable-vector-zeroing enable old, nearly always unneeded vector zeroing.

Bill P.

Post a reply to this message

On 3/3/23 05:57, William F Pokorny wrote:
> OK. Thanks!
> 
> I'll put it on the list to again review in povr. I'd first noticed it 
> with povr's, again truly random jitter with and big jitter values (>1). 
> Maybe I did something which caused the problem while banging on code! Or 
> maybe the windows version is for some reason different - in official 
> POV-Ray code, RTR doesn't work on unix/linux machines.

Alright. I both didn't remember well and I never completely understood 
what was happening... This is only a povr big jitter +j(>1.0) issue.

First jitter must be on. This is me not remembering - and, IIRC, it is 
on by default with recent POV-Ray releases, but not in povr.

Plus! The user value must be larger than 1.0 for the issue to show 
itself - which can only happen with my povr branch. The official release 
jitter can only be on or off. Somewhere the jitter value is getting 
reset/restored to 1.0 after each RTR frame - though in a quick look I 
don't see where!

I too continue to get AA in all my RTR frames, but povr's big jitter 
goes to a value of 1.0 after the first frame.

Thank you, Kenneth, for straightening me out! :-) I've added some notes 
to the source to jog my memory down the road...

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 3/3/23 05:57, William F Pokorny wrote:
>
> First jitter must be on. This is me not remembering - and, IIRC, it is
> on by default with recent POV-Ray releases, but not in povr.
>
Yes, in the Windows version the AA jitter is on by default.
>
> Thank you, Kenneth, for straightening me out! :-) I've added some notes
> to the source to jog my memory down the road...
>
I'm glad that it helped!

Post a reply to this message