"Jonathan Bush" <djb### [at] gmxcom> wrote:

> I have a question about the error message Yesbird encountered. It says "possible
> parse error" but I don't find any difference in the 3.8 user manual in its
> description of a text object. I also do not see the error message say that the
> render halted. Was the render halted? If not, why not let it run and see what
> happens?

See here:

https://news.povray.org/povray.general/message/%3C60cb7ab5%241%40news.povray.org%3E/#%3C60cb7ab5%241%40news.povray.org%
3E

Post a reply to this message

OK I found the bug; apparently the color of text objects must be specified.
I modified L01text.inc and upgraded the #version directive to 3.8 in
L01game.pov.

If you still have the frames from your first run, you could move the first 420
of them into the /frames4K/animated/ folder here. They are all the same pure
text screen. Then run the command

povray +SF421 L01game.pov

to save yourself a few minutes.

Post a reply to this message

Attachments:
Download 'l01game.tar.gz' (732 KB)

hi,

> > I had a very quick look at the archive, and fwiw, the naming is .. strange.  >
> That's the convention I have been following. Every distinct povray project I do
> has its own folder which contains a povray.ini file. I just always edit
> povray.ini when I want to change resolution or framerate. Is this wrong? Wrong,
> I am concerned about. Strange, not so much.

conventions, yes, I too have "bad habits" </grin>.  but it works (for you), so
wrong isn't the word, it's more like "additional cognitive hurdle".

those "habits" can lead to "wrong" though, from your 'povray.ini':
; Aspect ratio is expected to be 9:16
Height=2160
Width=3840

correct, for you, as the height is listed first.  however, anyone else reading
this would expect the ratio / aspect to be 16:9, ie the "width:height" thing is
fixed, preferences notwithstanding ;-).


> I have a question about the error message Yesbird encountered. ...
>
> OK I found the bug; apparently the color of text objects must be specified.
> I modified L01text.inc and upgraded the #version directive to 3.8 in
> L01game.pov.

should not be the cause.  POV-Ray supplies a default texture when there's none.
<https://wiki.povray.org/content/Reference:Default_Directive>

I tried and ran your code to 1K frames, using 3.8.0-alpha.9945627, with
"all_file = on", and nothing.  no errors, no warnings.  hth.


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> hi,

Hi back.

>
> > I have a question about the error message Yesbird encountered. ...
> >
> > OK I found the bug; apparently the color of text objects must be specified.
> > I modified L01text.inc and upgraded the #version directive to 3.8 in
> > L01game.pov.
>
> should not be the cause.  POV-Ray supplies a default texture when there's none.
> <https://wiki.povray.org/content/Reference:Default_Directive>
>
> I tried and ran your code to 1K frames, using 3.8.0-alpha.9945627, with
> "all_file = on", and nothing.  no errors, no warnings.  hth.
>
>
> regards, jr.

No FRAMES? Please tell me you generated some frames. :-)

I ran my earlier code under 3.8 beta, and there were no errors but all the text
objects were white.

Post a reply to this message

"Jonathan Bush" <djb### [at] gmxcom> wrote:

> I ran my earlier code under 3.8 beta, and there were no errors but all the text
> objects were white.

In version 3.8 there has been a Change to the pigment default setting. The
default setting is now rgb <1,1,1> as opposed to the rgb <0,0,0> value used in
previous versions. Requires #version 3.8; or equivalent INI setting or
command-line option. See also: Version Directive.

https://wiki.povray.org/content/Reference:Pigment

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Jonathan Bush" <djb### [at] gmxcom> wrote:
>
> > I ran my earlier code under 3.8 beta, and there were no errors but all the text
> > objects were white.
>
> In version 3.8 there has been a Change to the pigment default setting. The
> default setting is now rgb <1,1,1> as opposed to the rgb <0,0,0> value used in
> previous versions. Requires #version 3.8; or equivalent INI setting or
> command-line option. See also: Version Directive.
>
> https://wiki.povray.org/content/Reference:Pigment

OK thank you.

BTW I neglected to update the version in my povray.ini file, so here is just
that file, to replace the one in the POVray folder.

Post a reply to this message

I may have made some unwarranted assumptions here.

I am grateful to Yesbird and everyone else for their help. What I am asking for
would not only take a lot of processing time, but a huge chunk of memory. Every
frame from 421 to 10681 is close to 8 MB, in lossless png format. I estimate the
total might be about 80 GB. I haven't even asked about how I would download
that. Maybe you have access to some cloud hosting service.

None of this is free for Yesbird. If this works out, I may ask for help with
more videos in the future. Maybe we could talk about this? My email is
twixtfanatic atsymbol gmail period com

Thanks again for providing this amazing resource.

Post a reply to this message

On 09/06/2024 14:42, Jonathan Bush wrote:
> I am grateful to Yesbird and everyone else for their help.
...
> Thanks again for providing this amazing resource.

Sorry for the late answer - had no time even to look at newsgroups.
I really want to assist you, but I need to solve some non-IT problems.
Please give me one-two days and I will email you.

Happy POVing :)
--
YB.

Post a reply to this message

I have little experience with animations, but I noticed a merge in your 
code where a union would have been sufficient. So I rendered frames 
7001-7100 with your original code in 83 minutes (1920*1080, 14 work 
threads, i9### [at] 36GHz). After exchanging 4 merge statements (2 in 
L01tiles.inc, 1 in L01box.inc and 1 in Zillionstrapboard.inc) by unions 
the same frames took 15 minutes 33 seconds to render.

I had expected a faster calculation, but a factor of more than five 
really surprised me.

Best regards
Michael

Post a reply to this message

On 6/11/24 10:01, MichaelJF wrote:
> I had expected a faster calculation, but a factor of more than five 
> really surprised me.

Reminds me I have a "todo" item to look at removing some merge bounding 
related code I ran across one day which looks like it dump the objects 
in a merge into the infinite / not bounded bucket once the bounding box 
gets above a certain size.

It triggered at a size that was not that big - and I couldn't figure out 
why it would ever be a good idea(*). If you have bounding for the merge 
of objects, why wouldn't one always use it? How can it be, effectively, 
worse than tossing all the objects into the infinite bucket?

Anyhow, someday I'll dig more into it.

Bill P.

(*) - Maybe there was some pre-auto bounding reason for it? Or it might 
be there is some detail about how the bounding works I don't yet 
understand... :-)

Post a reply to this message