On 2021-07-26 7:46 AM (-4), jr wrote:
> 
> it appears that when I use a "Constant"[*] on the command-line, its value gets
> rounded to six digits, see below.  for the alpha, and the current beta.  (and
> 'povr')  have not tried from an ini file.

This has been the case since 3.7.0.  POV-Ray 3.6 would read at least 9
digits, but was unreliable beyond 8 digits.

I brought this up during the release candidate phase of 3.7, but nothing
was done.  The fact that it was changed from unreliable greater
precision to reliable lower precision suggests that the change was
deliberate, but I'd need confirmation from the developers.

https://news.povray.org/povray.beta-test/thread/%3Cweb.5019e866aa48f60685de7b680%40news.povray.org%3E/

Post a reply to this message

Am 26.07.2021 um 17:37 schrieb Cousin Ricky:

>> it appears that when I use a "Constant"[*] on the command-line, its value gets
>> rounded to six digits, see below.  for the alpha, and the current beta.  (and
>> 'povr')  have not tried from an ini file.
> 
> This has been the case since 3.7.0.  POV-Ray 3.6 would read at least 9
> digits, but was unreliable beyond 8 digits.
> 
> I brought this up during the release candidate phase of 3.7, but nothing
> was done.  The fact that it was changed from unreliable greater
> precision to reliable lower precision suggests that the change was
> deliberate, but I'd need confirmation from the developers.
> 
>
https://news.povray.org/povray.beta-test/thread/%3Cweb.5019e866aa48f60685de7b680%40news.povray.org%3E/

Yeeeeah... digging through the code right now, and that's some very 
asinine code I'm looking at right there. Whoever made that change back 
in 2005 must have had their head screwed on backwards that day.

And I mean, VERY asinine.

I'll get that sorted out before the next beta, provided one of you folks 
submits an issue report on GitHub to remind me.

Post a reply to this message

On 7/26/21 3:23 PM, clipka wrote:
> Am 26.07.2021 um 17:37 schrieb Cousin Ricky:
> 
>>> it appears that when I use a "Constant"[*] on the command-line, its 
>>> value gets



>>

>> digits, but was unreliable beyond 8 digits.
>>
>> I brought this up during the release candidate phase of 3.7, but nothing

>> precision to reliable lower precision suggests that the change was
>> deliberate, but I'd need confirmation from the developers.
>>
>>
https://news.povray.org/povray.beta-test/thread/%3Cweb.5019e866aa48f60685de7b680%40news.povray.org%3E/

>>
> 
...
> 
> I'll get that sorted out before the next beta, provided one of you folks 
> submits an issue report on GitHub to remind me.

See: https://github.com/POV-Ray/povray/issues/428

For those, like me, not realizing we can declare strings on the command 
line due:

https://wiki.povray.org/content/Reference:Scene_Parsing_Options,

it might be worth reading about the issue on github. Even in existing 
v3.7/v3.8 code strings can be defined in a useful - if not completely 
clean - manner.

Bill P.

Post a reply to this message

On a related note:

- Multiple `Declare=...` settings in an INI file will not work as 
expected. Only one value will come through.

- Using `Declare='Foo="..."'` cannot be used to declare an empty string. 
Trying to do so will give a string containing `"` (a single instance of 
the double quote character).

Post a reply to this message

On 7/29/21 7:05 AM, clipka wrote:
> On a related note:
> 
> - Multiple `Declare=...` settings in an INI file will not work as 
> expected. Only one value will come through.
> 
> - Using `Declare='Foo="..."'` cannot be used to declare an empty string. 
> Trying to do so will give a string containing `"` (a single instance of 
> the double quote character).

Good catch. I just did see notices for your new issues. I did some 
testing with multiple and mixed declares on the command line and those 
worked OK, but only simple single declares for ini testing - I don't use 
ini files myself except when working to debug a scene from someone else.

Bill P.

Post a reply to this message

Am 29.07.2021 um 13:50 schrieb William F Pokorny:
> On 7/29/21 7:05 AM, clipka wrote:
>> On a related note:
>>
>> - Multiple `Declare=...` settings in an INI file will not work as 
>> expected. Only one value will come through.
>>
>> - Using `Declare='Foo="..."'` cannot be used to declare an empty 
>> string. Trying to do so will give a string containing `"` (a single 
>> instance of the double quote character).
> 
> Good catch. I just did see notices for your new issues. I did some 
> testing with multiple and mixed declares on the command line and those 
> worked OK, but only simple single declares for ini testing - I don't use 
> ini files myself except when working to debug a scene from someone else.

Multiple declares on the command line should also be non-functional, 
with only the last setting "surviving".

I didn't actually test them in an INI file, but on the faux command line 
on the Windows interface.

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 29.07.2021 um 13:50 schrieb William F Pokorny:
> > On 7/29/21 7:05 AM, clipka wrote:
> >> On a related note:
> >>
> >> - Multiple `Declare=...` settings in an INI file will not work as
> >> expected. Only one value will come through.
> >>
> >> - Using `Declare='Foo="..."'` cannot be used to declare an empty
> >> string. Trying to do so will give a string containing `"` (a single
> >> instance of the double quote character).
> >
> > Good catch. I just did see notices for your new issues. I did some
> > testing with multiple and mixed declares on the command line and those
> > worked OK, but only simple single declares for ini testing - I don't use
> > ini files myself except when working to debug a scene from someone else.
>
> Multiple declares on the command line should also be non-functional,
> with only the last setting "surviving".
>
> I didn't actually test them in an INI file, but on the faux command line
> on the Windows interface.

all seems to work fine under Linux, see below.  did same test with beta.1, same
results.


regards, jr.




jr@swift:1:wfp$ c### [at] xyzpov

#version 3.8;

global_settings {assumed_gamma 1}
box {0,1}

#declare s_ = datetime(now);

#debug concat("datetime v3.8 default: '",s_,"'.\n")

#if (defined(A))
  #debug concat("A = ",str(A,0,0),".\n")
#end

#if (defined(B))
  #debug concat("B = ",str(B,0,0),".\n")
#end

#if (defined(C))
  #debug concat("C = ",str(C,0,0),".\n")
#end


jr@swift:2:wfp$ c### [at] xyzini

width = 32
height = 32

display = off
render_console = off
statistic_console = off
output_to_file = off

input_file_name = xyz.pov

declare = A=4
declare = B=5
declare = C=6


jr@swift:3:wfp$ povparse xyz.pov declare=A=1 declare=B=2 declare=C=3
Persistence of Vision(tm) Ray Tracer Version 3.8.0-alpha.9945627.unofficial
  ...
==== [Parsing...] ==========================================================
datetime v3.8 default: '2021-07-29 13:15:35Z'.
A = 1.
B = 2.
C = 3.
==== [Rendering...] ========================================================
Rendered 1024 of 1024 pixels (100%)
POV-Ray finished


jr@swift:4:wfp$ povparse xyz
  ...
==== [Parsing...] ==========================================================
datetime v3.8 default: '2021-07-29 13:15:43Z'.
A = 4.
B = 5.
C = 6.
==== [Rendering...] ========================================================
Rendered 1024 of 1024 pixels (100%)
POV-Ray finished

Post a reply to this message

On 7/29/21 9:22 AM, jr wrote:
...
>> Multiple declares on the command line should also be non-functional,
>> with only the last setting "surviving".
>>
>> I didn't actually test them in an INI file, but on the faux command line
>> on the Windows interface.
> all seems to work fine under Linux, see below.  did same test with beta.1, same
> results.
...

I had the thought on getting up this morning perhaps what Christoph was 
seeing for multiple declares not working (windows?) was also tangled in 
me 'not really' running the recent v3.8 beta 1. Perhaps v3.8 beta 1 has 
such issues. Running just now it does't - for float declarations.

My results (Ununtu 20.04) match jr's for all the v3.8 versions I tried 
including povr. Multiple declares of floats work.

What doesn't work is an ini file containing declares to strings:

declare=D1=1.0123456789012348
declare=S1=\"Heard\"
declare=D2=2.0123456789012345
declare=S2=\"a\"
declare=D3=3.0123456789012342
declare=S3=\"bump\"

I tried a good many quoting variations. In both p380b1 and my most 
recent povr I get:

Expected 'string expression', float function 'float identifier' found 
instead

'after' parsing the ini file and where I hit the SDL line:

#debug concat("S1 = ",S1," \n")

---
I'd make a bet, the above ini specific failing explains our current 
documentation for cmd/ini declares supporting only floats!

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

The ini parsing is somehow different than the command line parsing :-(.

Hmmm. I guess povray doesn't die during the actual ini parsing of the 
string, maybe it just marks the type incorrectly as a float.

Bill P.

Post a reply to this message

On 8/1/21 7:02 AM, William F Pokorny wrote:
...
> 
> The ini parsing is somehow different than the command line parsing :-(.
> 
> Hmmm. I guess povray doesn't die during the actual ini parsing of the 
> string, maybe it just marks the type incorrectly as a float.
> 
...

OK. After a day banging around in code and wrapper scripts. On my Ubuntu 
20.04 system and I expect most unix/linux/osx, you can declare multiple 
strings and constants on the command line and in ini files - no matter 
the recent >v3.6 branch. Constants (excepting, for now, the upcoming 
povr branch) support only single float precision or a little less.

--- The ini files need to look like:

declare=D1=1.0123456789012348
declare='S1="Heard.a"'
declare=D2=2.0123456789012345
declare='S2="bump and"'
declare=D3=3.0123456789012342
declare='S3=" jumped=up = 2 times "'

--- The command line. Note extra quotes where spaces in string. The back 
slash escaped newline characters are not strictly needed and used for 
clarity.

p380b1 +mv3.8 +iFloatAndStrings.inc \
       declare=D1=1.0123456789012348 \
       declare=\'S1=\"Heard.a\"\' \
       declare=D2=2.0123456789012345 \
       declare=\'S2=\""bump and"\"\' \
       declare=D3=3.0123456789012342 \
       declare=\'S3=\""jumped up = 2 times"\"\'

--- The simplifications and complications

The povr branch - for some fix in the past I've not run down - allows 
simpler and more conventional command line quoting:

povr +mv3.8 +iFloatAndStrings.inc \
     declare=D1=1.0123456789012348 \
     declare=S1=\"Heard.a\" \
     declare=D2=2.0123456789012345 \
     declare=S2=\""bump and"\" \
     declare=D3=3.0123456789012342 \
     declare=S3=\""jumped up = two times"\"

There are wrapper script complications which had me chasing my backside 
for the better part of yesterday when you have strings with spaces. You 
must set the IFS (Internal Field Separator) environment variable in such 
scripts to newline characters.

With shell / 'sh' povray wrapper scripts this is done by adding two 
lines ahead of the use of the $@ argument passing / pass-through. Note, 
there is below, an invisible newline character between the single quotes.

IFS='
'

In bash / 'bash' povray wrapper scripts you need to add a similar 
setting with a single line ahead of the $@ use:

IFS=$'\n'

Expect other shell languages would need adjustments too and there are 
probably alternate methods to preserver the spaces. I'm a hack at shell 
wrapper scripts.

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 8/1/21 7:02 AM, William F Pokorny wrote:
> ...
> --- The ini files need to look like:
> ...
> declare='S1="Heard.a"'

_thanks_.


regards, jr.

Post a reply to this message