Op 27-6-2022 om 17:56 schreef And:
> First release.

Thanks And!

Test version, so I shall not (yet) comment on the visual aspects and so on.

However, one very important thing is the way decimals are written to the 
example include files. My system uses 'dots' (example: 3.9432) instead 
of 'commas' (example: 3,9432) like is done by your app. I guess that 
some countries/systems do so standard, but not all. My system uses 
'dots'. If this is an issue for better international use, could you make 
this an initial choice to make by the user? Or is there another way to 
change this easily?

-- 
Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 27-6-2022 om 17:56 schreef And:
> > First release.
>
> Thanks And!
>
> Test version, so I shall not (yet) comment on the visual aspects and so on.
>

Thanks for understanding.


> However, one very important thing is the way decimals are written to the
> example include files. My system uses 'dots' (example: 3.9432) instead
> of 'commas' (example: 3,9432) like is done by your app. I guess that
> some countries/systems do so standard, but not all.

I use 'meter' as the length unit, so that output result is caused by my habit.
The dots are decimal points.
I want to ask a question, a number contain commas can be read as 'one' number
correct by POV-Ray?
Can 3,9432 be a number?

> If this is an issue for better international use, could you make
> this an initial choice to make by the user? Or is there another way to
> change this easily?
>
> --
> Thomas

Currently You might need use 'scale' to the pigment to convert it to your
customary unit. I will add a list(menu) to select unit on the "Basic
Profile"(first page) in the future version. But I need time to research this.

Post a reply to this message

Excuse me, I upload the same version but compress to the .zip

Post a reply to this message

Attachments:
Download 'wooddesignprogram alpha ver20220627.zip' (987 KB)

"And" <49341109@ntnu.edu.tw> wrote:

> > However, one very important thing is the way decimals are written to the
> > example include files. My system uses 'dots' (example: 3.9432) instead
> > of 'commas' (example: 3,9432) like is done by your app. I guess that
> > some countries/systems do so standard, but not all.
>
> I use 'meter' as the length unit, so that output result is caused by my habit.
> The dots are decimal points.

Units don't appear to be the issue.   The representation of decimal fractions is
what Thomas is concerned about.

> I want to ask a question, a number contain commas can be read as 'one' number
> correct by POV-Ray?
> Can 3,9432 be a number?

Nope.  That would be a string.  AFAIK, all versions of POV-Ray use only numerals
and the "+,-, and ." glyphs to represent numerical values.  Formatting those
values using str and probably a macro would be necessary to show the usual
commas between every step of 10^3.


> > If this is an issue for better international use, could you make
> > this an initial choice to make by the user? Or is there another way to
> > change this easily?
> >
> > --
> > Thomas
>
> Currently You might need use 'scale' to the pigment to convert it to your
> customary unit. I will add a list(menu) to select unit on the "Basic
> Profile"(first page) in the future version. But I need time to research this.

I think he means "Is there a way to specify whether to use "," or "." for the
data's output format.

Post a reply to this message

Op 04/07/2022 om 20:53 schreef Bald Eagle:
> "And" <49341109@ntnu.edu.tw> wrote:
> 
>>> However, one very important thing is the way decimals are written to the
>>> example include files. My system uses 'dots' (example: 3.9432) instead
>>> of 'commas' (example: 3,9432) like is done by your app. I guess that
>>> some countries/systems do so standard, but not all.
>>
>> I use 'meter' as the length unit, so that output result is caused by my habit.
>> The dots are decimal points.
> 
> Units don't appear to be the issue.   The representation of decimal fractions is
> what Thomas is concerned about.
> 
Exactly. The issue here is whether the 'comma' represents a 'Thousands 
separator' (example: 3,943,200.00) or - and I guess this is what is 
intended here - the 'decimal dot' (example: 3943200,00). Neither can be 
used by POV-Ray.

>> I want to ask a question, a number contain commas can be read as 'one' number
>> correct by POV-Ray?
>> Can 3,9432 be a number?
> 
> Nope.  That would be a string.  AFAIK, all versions of POV-Ray use only numerals
> and the "+,-, and ." glyphs to represent numerical values.  Formatting those
> values using str and probably a macro would be necessary to show the usual
> commas between every step of 10^3.
> 
> 
>>> If this is an issue for better international use, could you make
>>> this an initial choice to make by the user? Or is there another way to
>>> change this easily?
>>>
>>> --
>>> Thomas
>>
>> Currently You might need use 'scale' to the pigment to convert it to your
>> customary unit. I will add a list(menu) to select unit on the "Basic
>> Profile"(first page) in the future version. But I need time to research this.
> 
> I think he means "Is there a way to specify whether to use "," or "." for the
> data's output format.
> 

As far as I understand this issue, the use of 'thousands separators' is 
only a visually attractive(?) trick, while calculations on those numbers 
ignore them (obviously). My advice would be to drop them altogether, 
especially for input to POV-Ray.

-- 
Thomas

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "And" <49341109@ntnu.edu.tw> wrote:
>
> > > However, one very important thing is the way decimals are written to the
> > > example include files. My system uses 'dots' (example: 3.9432) instead
> > > of 'commas' (example: 3,9432) like is done by your app. I guess that
> > > some countries/systems do so standard, but not all.
> >
> > I use 'meter' as the length unit, so that output result is caused by my habit.
> > The dots are decimal points.
>
> Units don't appear to be the issue.   The representation of decimal fractions is
> what Thomas is concerned about.
>

Labeling titles and units on diagram is important I know. I will label them.


> > I want to ask a question, a number contain commas can be read as 'one' number
> > correct by POV-Ray?
> > Can 3,9432 be a number?
>
> Nope.  That would be a string.  AFAIK, all versions of POV-Ray use only numerals
> and the "+,-, and ." glyphs to represent numerical values.  Formatting those
> values using str and probably a macro would be necessary to show the usual
> commas between every step of 10^3.
>
>
> > > If this is an issue for better international use, could you make
> > > this an initial choice to make by the user? Or is there another way to
> > > change this easily?
> > >
> > > --
> > > Thomas
> >
>
> I think he means "Is there a way to specify whether to use "," or "." for the
> data's output format.


I'm not clear this time. POV-Ray cannot use a number contains commas as you
said, why I need add commas between every step of 10^3. I attach a picture, this
picture is what I saw on my output data. Is the same format on your output data?

Post a reply to this message

Attachments:
Download 'radial_speed_output.png' (96 KB)

Preview of image 'radial_speed_output.png'

Thomas de Groot <tho### [at] degrootorg> wrote:
> Exactly. The issue here is whether the 'comma' represents a 'Thousands
> separator' (example: 3,943,200.00) or - and I guess this is what is
> intended here - the 'decimal dot' (example: 3943200,00). Neither can be
> used by POV-Ray.
>

>
> As far as I understand this issue, the use of 'thousands separators' is
> only a visually attractive(?) trick, while calculations on those numbers
> ignore them (obviously). My advice would be to drop them altogether,
> especially for input to POV-Ray.
>
> --
> Thomas

What the length unit does you use? Because my outputting number is usually small
with this program(while meter is the length unit).

Post a reply to this message

Op 5-7-2022 om 09:53 schreef And:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> Exactly. The issue here is whether the 'comma' represents a 'Thousands
>> separator' (example: 3,943,200.00) or - and I guess this is what is
>> intended here - the 'decimal dot' (example: 3943200,00). Neither can be
>> used by POV-Ray.
>>
> 
>>
>> As far as I understand this issue, the use of 'thousands separators' is
>> only a visually attractive(?) trick, while calculations on those numbers
>> ignore them (obviously). My advice would be to drop them altogether,
>> especially for input to POV-Ray.
>>
>> --
>> Thomas
> 
> What the length unit does you use? Because my outputting number is usually small
> with this program(while meter is the length unit).
> 
The length units I use are from the metric system; whether they are mm, 
cm, m, or km, is of no importance and only relevant within a given scene 
of course.

Where things go wrong, starts with the exported ****_radial_speed.inc 
file where

#local r_pos = array[7][4] {
{ 0,00, 0,053815, 0,10493, 0,161445 },
{ 0,161445, 0,217235, 0,273236, 0,336914 },
{ 0,336914, 0,397284, 0,47667, 0,533589 },
{ 0,533589, 0,571795, 0,600867, 0,622288 },
{ 0,622288, 0,662945, 0,675592, 0,719823 },
{ 0,719823, 0,749311, 0,79926, 0,843443 },
{ 0,843443, 0,891902, 0,946315, 0,99775 },
}

#local year_pos = array[7][4] {
{ 0,00, 2,60, 5,20, 7,80 },
{ 7,80, 10,366667, 12,933333, 15,50 },
{ 15,50, 17,933333, 20,366667, 22,80 },
{ 22,80, 24,433333, 26,066667, 27,70 },
{ 27,70, 30,80, 33,90, 37,00 },
{ 37,00, 39,066667, 41,133333, 43,20 },
{ 43,20, 45,466667, 47,733333, 50,00 },
}

and all other exported include files where something like this is 
written. POV-Ray does not like it. :-)

It would be OK if this were:

#local r_pos = array[7][4] {
{ 0.00, 0.053815, 0.10493, 0.161445 },
{ 0.161445, 0.217235, 0.273236, 0.336914 },
{ 0.336914, 0.397284, 0.47667, 0.533589 },
{ 0.533589, 0.571795, 0.600867, 0.622288 },
{ 0.622288, 0.662945, 0.675592, 0.719823 },
{ 0.719823, 0.749311, 0.79926, 0.843443 },
{ 0.843443, 0.891902, 0.946315, 0.99775 },
}

#local year_pos = array[7][4] {
{ 0.00, 2.60, 5.20, 7.80 },
{ 7.80, 10.366667, 12.933333, 15.50 },
{ 15.50, 17.933333, 20.366667, 22.80 },
{ 22.80, 24.433333, 26.066667, 27.70 },
{ 27.70, 30.80, 33.90, 37.00 },
{ 37.00, 39.066667, 41.133333, 43.20 },
{ 43.20, 45.466667, 47.733333, 50.00 },
}

which, I suppose, is what you intend.

-- 
Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> The length units I use are from the metric system; whether they are mm,
> cm, m, or km, is of no importance and only relevant within a given scene
> of course.
>
> Where things go wrong, starts with the exported ****_radial_speed.inc
> file where
>
> #local r_pos = array[7][4] {
> { 0,00, 0,053815, 0,10493, 0,161445 },
> { 0,161445, 0,217235, 0,273236, 0,336914 },
> { 0,336914, 0,397284, 0,47667, 0,533589 },
> { 0,533589, 0,571795, 0,600867, 0,622288 },
> { 0,622288, 0,662945, 0,675592, 0,719823 },
> { 0,719823, 0,749311, 0,79926, 0,843443 },
> { 0,843443, 0,891902, 0,946315, 0,99775 },
> }
>
> #local year_pos = array[7][4] {
> { 0,00, 2,60, 5,20, 7,80 },
> { 7,80, 10,366667, 12,933333, 15,50 },
> { 15,50, 17,933333, 20,366667, 22,80 },
> { 22,80, 24,433333, 26,066667, 27,70 },
> { 27,70, 30,80, 33,90, 37,00 },
> { 37,00, 39,066667, 41,133333, 43,20 },
> { 43,20, 45,466667, 47,733333, 50,00 },
> }
>
> and all other exported include files where something like this is
> written. POV-Ray does not like it. :-)
>
> It would be OK if this were:
>
> #local r_pos = array[7][4] {
> { 0.00, 0.053815, 0.10493, 0.161445 },
> { 0.161445, 0.217235, 0.273236, 0.336914 },
> { 0.336914, 0.397284, 0.47667, 0.533589 },
> { 0.533589, 0.571795, 0.600867, 0.622288 },
> { 0.622288, 0.662945, 0.675592, 0.719823 },
> { 0.719823, 0.749311, 0.79926, 0.843443 },
> { 0.843443, 0.891902, 0.946315, 0.99775 },
> }
>
> #local year_pos = array[7][4] {
> { 0.00, 2.60, 5.20, 7.80 },
> { 7.80, 10.366667, 12.933333, 15.50 },
> { 15.50, 17.933333, 20.366667, 22.80 },
> { 22.80, 24.433333, 26.066667, 27.70 },
> { 27.70, 30.80, 33.90, 37.00 },
> { 37.00, 39.066667, 41.133333, 43.20 },
> { 43.20, 45.466667, 47.733333, 50.00 },
> }
>
> which, I suppose, is what you intend.
>
> --
> Thomas


Oh, this is important. I just fix it(but need you testing). Thank you.

No any other change. except in demo scene, I rotate<0,0,0> instead of
rotate<0,0,90> the wood-block.

Post a reply to this message

Attachments:
Download 'wooddesignprogram alpha ver20220705.rar.dat' (966 KB)

compress to .zip

Post a reply to this message

Attachments:
Download 'wooddesignprogram alpha ver20220705.zip' (980 KB)