 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
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.
[*] <https://wiki.povray.org/content/Reference:Scene_Parsing_Options#Constant>
regards, jr.
jr@swift:2:now$ c### [at] tst pov
#version 3.8;
global_settings {assumed_gamma 1}
box {0,1}
#if (!defined(Seed))
#declare seed_ = mod((now-int(now))*1e16,1e9);
#else
#declare seed_ = Seed;
#end
#debug concat("seed_ = ",str(seed_,0,0),".\n")
jr@swift:3:now$ povray tst.pov +w32 +h32 -d -f -gr -gs
Persistence of Vision(tm) Ray Tracer Version 3.8.0-alpha.9945627.unofficial
...
==== [Parsing...] ==========================================================
seed_ = 242007125.
==== [Rendering...] ========================================================
Rendered 1024 of 1024 pixels (100%)
POV-Ray finished
jr@swift:4:now$ povray tst.pov +w32 +h32 -d -f -gr -gs declare=Seed=242007125
...
==== [Parsing...] ==========================================================
seed_ = 242007000.
==== [Rendering...] ========================================================
Rendered 1024 of 1024 pixels (100%)
POV-Ray finished
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
