povray.text.scene-files message digest

[jr] Re: Shell from Metashape [25 days 5 hours and 3 minutes ago]

Fri, 20 Mar 2026 15:55:00 GMT

hi,

yesbird wrote:
> This is a scene with shell geometry and set of materials for those who
> want to render it better:
> https://drive.google.com/file/d/1Fh8nRaxaCYb1R-4NdrkrCETzzPKPMvZF/view?usp=sharing

thanks, 81M "data" </grin>.  lovely object.


regards, jr.

[yesbird] Shell from Metashape [26 days 19 hours and 47 minutes ago]

Thu, 19 Mar 2026 01:11:39 GMT

This is a scene with shell geometry and set of materials for those who
want to render it better:
https://drive.google.com/file/d/1Fh8nRaxaCYb1R-4NdrkrCETzzPKPMvZF/view?usp=sharing 

--
YB

[yesbird] Re: Star catalogue [27 days 3 hours and 42 minutes ago]

Wed, 18 Mar 2026 17:16:19 GMT

On 17/03/2026 21:36, Leroy wrote:
> Second Try! I tried to post these a few days ago and it didn't take!?
> Making spaceships take time, here's one I make a while back base on futurama.
> Because every needs a spaceship!

Nice !
I like it, especially his sinusoidal manner to move, would like to have
the same.
--
YB

[jr] Re: Star catalogue [28 days and 3 minutes ago]

Tue, 17 Mar 2026 20:55:00 GMT

hi,

"Leroy" <whe### [at] gmailcom> wrote:
> "Maetes" <nomail@nomail> wrote:
> > That's the damn reason why I don't have time to build damn spaceships.
> > :)
> > Ma
> Second Try! I tried to post these a few days ago and it didn't take!?
> Making spaceships take time, here's one I make a while back base on futurama.

time well spent, thanks.  Fry used to call ideas "headaches with pictures"..


> Because every needs a spaceship!

yes, see attached ;-)


regards, jr.

[Leroy] Re: Star catalogue [28 days 2 hours and 18 minutes ago]

Tue, 17 Mar 2026 18:40:00 GMT

"Maetes" <nomail@nomail> wrote:
>
> That's the damn reason why I don't have time to build damn spaceships.
>
> :)
>
> Ma

Second Try! I tried to post these a few days ago and it didn't take!?
Making spaceships take time, here's one I make a while back base on futurama.
Because every needs a spaceship!

[Leroy] Re: Star catalogue [33 days 19 hours and 28 minutes ago]

Thu, 12 Mar 2026 01:30:00 GMT

"Maetes" <nomail@nomail> wrote:
> If anyone wants to try their hand at creating a real starry sky with simulated
> stars, I've trimmed the HYG star catalogue (120,000 entries) a bit and turned it
> into a Povray array.
>
> Documented more thoroughly than I would like, took way too long, as always.
>
> A macro collection that makes use of it is in the works.
>
> See:
> https://www.maetes.com/en/download/hyg-lite-star-catalogue
>
> That's the damn reason why I don't have time to build damn spaceships.
>
> :)
>
> Ma

I made a ship a long time ago for a Futurama like game. And the last line of
your post made think...
I'm to lazy to download your stuff and create a sky so I just use the picture
here.
Here it is the ship!

[yesbird] Re: Star catalogue [62 days 22 hours and 38 minutes ago]

Tue, 10 Feb 2026 22:19:50 GMT

On 04/02/2026 13:06, Maetes wrote:
> I'm pretty sure you can't wait that long, but I also dealt with constellations,
> lines and borders in December. Corresponding 3 or more database tables as well
> as a Povray macro collection are in the works. However, I need time for the
> completion, I have just started something else. Will probably not be finished
> until March, or even later.
>

You are right about the time - I don't like to waste it, so
working hard on the planetarium, which now is https://viewspace.online/.

One guy on this forum solved all my problems with data sources
in one shot message:
https://www.cloudynights.com/forums/topic/992636-data-sources-for-virtual-planetarium/

Also his site is full of useful code and interesting ideas, so
I am glad that registered there.
--
YB

[Maetes] Re: Star catalogue [69 days 10 hours and 48 minutes ago]

Wed, 4 Feb 2026 10:10:00 GMT

yesbird wrote:
> Thanks for the suggestion, this man provides more details about
> this subject: https://pbarbier.com/constellations/boundaries.html
> Probably I need to dive deeper into astronomy and need a good book for
> beginners. School lessons are not enough and were too many years ago ...

I'm pretty sure you can't wait that long, but I also dealt with constellations,
lines and borders in December. Corresponding 3 or more database tables as well
as a Povray macro collection are in the works. However, I need time for the
completion, I have just started something else. Will probably not be finished
until March, or even later.

ma

[Maetes] Re: Star catalogue [69 days 10 hours and 53 minutes ago]

Wed, 4 Feb 2026 10:05:00 GMT

yesbird wrote:
> Sorry for the inconvenience, it was my fault - I forgot
> to comment out debug info and all 13979 records of NGC were printed to
> browser's page. Now it works fine - no more crashes, I promise :).

Shame on you. I've absolutely never made such mistakes...


> I have also registered in this serious astronomic community:
> https://www.cloudynights.com/

Interesting site, I didn't know yet, maybe I'll sign up too.


> Here is large-scale prototype for what I am doing:
> http://aladin.cds.unistra.fr/AladinLite/

I also found Aladdin yesterday, but I didn't want to spoil your fun :)


"jr" <cre### [at] gmailcom> wrote:
> in which case, likely, the default setting in the global 'povray.conf' will
> "trip you up".  you have to set "[Shellout Security]" to 'allowed'.

Thanks for that, this little piece of information can potentially save a lot of
searching.

ma

[yesbird] Re: Star catalogue [69 days 17 hours ago]

Wed, 4 Feb 2026 03:58:40 GMT

On 01/02/2026 12:42, yesbird wrote:
> Thank you for sharing this data. Really, I am looking for good
> data source for my present Virtual planetary project:
> https://yesbird.online/planetarium/
> 

Here is large-scale prototype for what I am doing:
http://aladin.cds.unistra.fr/AladinLite/

I am plan to make something similar, but less scientific,
more user friendly, with better GUI, higher quality images
and VR support.
--
YB

[yesbird] Re: Star catalogue [69 days 17 hours and 20 minutes ago]

Wed, 4 Feb 2026 03:37:47 GMT

On 03/02/2026 22:29, Maetes wrote:
> Maybe use bound_20 (top-left in the select-box).
> Thats the epoch, bounds_18 means 1875.
> 
> They are slightly different.
> https://en.wikipedia.org/wiki/Epoch_(astronomy)#Epochs_and_periods_of_validity
> 
Thanks for the suggestion, this man provides more details about
this subject: https://pbarbier.com/constellations/boundaries.html

Probably I need to dive deeper into astronomy and need a good book for
beginners. School lessons are not enough and were too many years ago ...
--
YB

[Maetes] Re: Star catalogue [70 days 1 hour and 28 minutes ago]

Tue, 3 Feb 2026 19:30:00 GMT

yesbird wrote:
> And I found it:
>
http://vizier.cds.unistra.fr/viz-bin/VizieR-3?-source=VI/49/bound_18&-out.max=50&-out.form=HTML%20Table&-out.add=_r&-
out.add=_RAJ,_DEJ&-sort=_r&-oc.form=sexa
>
> --
> YB

Congrats!
Maybe use bound_20 (top-left in the select-box).
Thats the epoch, bounds_18 means 1875.

They are slightly different.
https://en.wikipedia.org/wiki/Epoch_(astronomy)#Epochs_and_periods_of_validity

Ma

[yesbird] Re: Star catalogue [70 days 3 hours and 39 minutes ago]

Tue, 3 Feb 2026 17:18:49 GMT

On 03/02/2026 18:15, yesbird wrote:
> On 03/02/2026 14:52, Maetes wrote:
>>
>> As I said, I haven't looked for it yet, but if I find something, I'll 
>> let you
>> know. I also made a PHP script with which I can create Povray arrays from
>> databases, if helpful. But it takes time, sorry.
>>
> 
> The most desired thing for me now is coordinates of constellation
> bounds, as I would like to store them as vectors to control separately -
> one by one, but not sure if such a thing exists anywhere.

And I found it:
http://vizier.cds.unistra.fr/viz-bin/VizieR-3?-source=VI/49/bound_18&-out.max=50&-out.form=HTML%20Table&-out.add=_r&-out.add=_RAJ,_DEJ&-sort=_r&-oc.form=sexa

-- 
YB

[yesbird] Re: Star catalogue [70 days 5 hours and 43 minutes ago]

Tue, 3 Feb 2026 15:15:06 GMT

On 03/02/2026 14:52, Maetes wrote:
> 
> As I said, I haven't looked for it yet, but if I find something, I'll let you
> know. I also made a PHP script with which I can create Povray arrays from
> databases, if helpful. But it takes time, sorry.
> 

The most desired thing for me now is coordinates of constellation
bounds, as I would like to store them as vectors to control separately -
one by one, but not sure if such a thing exists anywhere.
-- 
YB

[yesbird] Re: Star catalogue [70 days 6 hours and 21 minutes ago]

Tue, 3 Feb 2026 14:36:55 GMT

On 03/02/2026 15:18, Maetes wrote:
> 
> Now I was curious myself and went on a short search.
> ...

Thanks, very well, I will examine it later, as now I am too busy with
coding. I have also registered in this serious astronomic community:
https://www.cloudynights.com/
and hope for their support.
--
YB

[yesbird] Re: Star catalogue [70 days 6 hours and 32 minutes ago]

Tue, 3 Feb 2026 14:26:21 GMT

On 03/02/2026 12:17, Mr wrote:
> This works insanely great on my phone :-) ! (as usual I had to open it there
> because your site is blocked from my corporate proxy :-/ )
> 

Glad to hear it, as I am now taking care about mobile platform(s) too.
In general, it will support desktops, mobiles and VR headsets.

But nothing to see there yet and it's only a template, which I am
turning into a real application very fast. Hope till Saturday it becomes
much more interesting :).
-- 
YB

[yesbird] Re: Star catalogue [70 days 6 hours and 39 minutes ago]

Tue, 3 Feb 2026 14:19:38 GMT

On 03/02/2026 14:52, Maetes wrote:
> 
> The keyword for coordinates and data is:
> NGC Catalogue.
> https://en.wikipedia.org/wiki/New_General_Catalogue

Thanks a lot, I have already taken and tested it, works fine with
AlaSQL, which I am using as a DB engine.

> 
> Images could be a problem, as I am not aware of any valid source that provides
> such data in a uniform format. Maybe it comes down to the fact that you have to
> search for them manually.
> But I can also be wrong, maybe there is something like that in the meantime. If
> I find something, I'll tell you.

Thanks again, I will start an intensive search after completing
application. Filling DB with the content will be an endless
procedure :).

> Chromium on a Raspberry Pi.
> I clicked somewhere and a Box opened with the text "Object" few million times,
> so my Pi was busy to show all text.
> And in dont want to risk it again, don't like crashes.

Sorry for the inconvenience, it was my fault - I forgot
to comment out debug info and all 13979 records of NGC were printed to
browser's page. Now it works fine - no more crashes, I promise :).
-- 
YB

[jr] Re: Star catalogue [70 days 7 hours and 8 minutes ago]

Tue, 3 Feb 2026 13:50:00 GMT

hi,

"Maetes" <nomail@nomail> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > ...
> > <wiki.povray.org/content/Reference:Shell_Command_Options>
>
> I also have a similar workaround.
> A PHP script that converts an SQL database into an array.
> But it is a detour that is limited in flexibility.

my guess is that you will be able to use that code with (comparatively) little
adaptation.

> Nevertheless the reference to the shell commands is interesting, I didn't know
> them before.

in which case, likely, the default setting in the global 'povray.conf' will
"trip you up".  you have to set "[Shellout Security]" to 'allowed'.

> I'll take a look, maybe I can use my PHP script a little better
> with it.

:-).

regards, jr.

[Maetes] Re: Star catalogue [70 days 7 hours and 53 minutes ago]

Tue, 3 Feb 2026 13:05:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> one should be able to do this using an ini file, ie have a script executing a
> scene or frame specific query and write the result(s) to a POV-Ray-style CSV
> file, which would be available in the scene/frame for reading.
>
> <wiki.povray.org/content/Reference:Shell_Command_Options>

I also have a similar workaround.
A PHP script that converts an SQL database into an array.
But it is a detour that is limited in flexibility.

Nevertheless the reference to the shell commands is interesting, I didn't know
them before. I'll take a look, maybe I can use my PHP script a little better
with it.

Thanks,
m

[jr] Re: Star catalogue [70 days 8 hours and 23 minutes ago]

Tue, 3 Feb 2026 12:35:00 GMT

hi,

"Maetes" <nomail@nomail> wrote:
> ...
> If Povray could execute SQL queries - even if only simple selects - that would
> be really really nice.

one should be able to do this using an ini file, ie have a script executing a
scene or frame specific query and write the result(s) to a POV-Ray-style CSV
file, which would be available in the scene/frame for reading.

<wiki.povray.org/content/Reference:Shell_Command_Options>

regards, jr.

[Maetes] Re: Star catalogue [70 days 8 hours and 38 minutes ago]

Tue, 3 Feb 2026 12:20:00 GMT

Please ignore the last answer, I thought the forum had deleted the first block.
-----------


Now I was curious myself and went on a short search.

Maybe this is the original one:
https://heasarc.gsfc.nasa.gov/W3Browse/all/ngc2000.html

The data can be found here (ngc2000.dat):
https://cdsarc.cds.unistra.fr/ftp/cats/VII/118/


A newer version maybe is this here, but I havent found a download-file:
http://www.klima-luft.de/steinicke/ngcic/rev2000/Explan.htm

This one could be a competitor of yours:
https://cosmos-book.github.io/catalogue/NGC/index.html


ma

[Maetes] Re: Star catalogue [70 days 8 hours and 58 minutes ago]

Tue, 3 Feb 2026 12:00:00 GMT

yesbird wrote:
> Pictures of good quality with complete objects info, including
> coordinates. This will be a gallery with a pointer to the object's
> location on the sky sphere. Now I rely mostly on NASA/Hubble materials,
> but other sources also can help. This will be a long-term project ...

The keyword for coordinates and data is:
NGC Catalogue.
https://en.wikipedia.org/wiki/New_General_Catalogue

As I said, I haven't looked for it yet, but if I find something, I'll let you
know. I also made a PHP script with which I can create Povray arrays from
databases, if helpful. But it takes time, sorry.

ma

[Maetes] Re: Star catalogue [70 days 8 hours and 58 minutes ago]

Tue, 3 Feb 2026 12:00:00 GMT

"Mr" <m******r******at_hotmail_dot_fr> wrote:
> I think such a thing would be awesome delivered with POV-Ray out of the box!

If Povray could execute SQL queries - even if only simple selects - that would
be really really nice.

It's on my (unpublished) wish list.


Ma

[Maetes] Re: Star catalogue [70 days 9 hours and 3 minutes ago]

Tue, 3 Feb 2026 11:55:00 GMT

yesbird wrote:

> Pictures of good quality with complete objects info, including
> coordinates. This will be a gallery with a pointer to the object's
> location on the sky sphere. Now I rely mostly on NASA/Hubble materials,
> but other sources also can help. This will be a long-term project ...

The keyword for coordinates and data is:
NGC Catalogue.
https://en.wikipedia.org/wiki/New_General_Catalogue

As I said, I haven't looked for it yet, but if I find something, I'll let you
know. I also made a PHP script with which I can create Povray arrays from
databases, if helpful. But it takes time, sorry.

Images could be a problem, as I am not aware of any valid source that provides
such data in a uniform format. Maybe it comes down to the fact that you have to
search for them manually.
But I can also be wrong, maybe there is something like that in the meantime. If
I find something, I'll tell you.

> Possible, as it's in a very early state of development.
> What browser do you have (including a platform) and could you
> please send me console content (F12) ?
> --
> YB

Chromium on a Raspberry Pi.
I clicked somewhere and a Box opened with the text "Object" few million times,
so my Pi was busy to show all text.
And in dont want to risk it again, don't like crashes.

ma

[Mr] Re: Star catalogue [70 days 11 hours and 38 minutes ago]

Tue, 3 Feb 2026 09:20:00 GMT

"Maetes" <nomail@nomail> wrote:
> If anyone wants to try their hand at creating a real starry sky with simulated
> stars, I've trimmed the HYG star catalogue (120,000 entries) a bit and turned it
> into a Povray array.
>
> Documented more thoroughly than I would like, took way too long, as always.
>
> A macro collection that makes use of it is in the works.
>
> See:
> https://www.maetes.com/en/download/hyg-lite-star-catalogue
>
> That's the damn reason why I don't have time to build damn spaceships.
>
> :)
>
> Ma

I think such a thing would be awesome delivered with POV-Ray out of the box!

[Mr] Re: Star catalogue [70 days 11 hours and 38 minutes ago]

Tue, 3 Feb 2026 09:20:00 GMT

yesbird wrote:
> On 08/12/2025 02:45, Maetes wrote:
> > If anyone wants to try their hand at creating a real starry sky with simulated
> > stars, I've trimmed the HYG star catalogue (120,000 entries) a bit and turned it
> > into a Povray array. ...
>
> Hi, Maetes.
>
> Thank you for sharing this data. Really, I am looking for good
> data source for my present Virtual planetary project:
> https://yesbird.online/planetarium/
>
> I am expected that it should be informative and compact enough,
> also includes deep sky objects like nebulas and galaxies, but
> assume that it will be not for professional use, but mostly addressed
> to schoolchildren and students just for fun.
>
> Could you suggest such a data source ?
> --
> YB

This works insanely great on my phone :-) ! (as usual I had to open it there
because your site is blocked from my corporate proxy :-/ )

[yesbird] Re: Star catalogue [70 days 15 hours and 58 minutes ago]

Tue, 3 Feb 2026 04:59:52 GMT

On 02/02/2026 20:19, Bald Eagle wrote:
> "Maetes" <nomail@nomail> wrote:
> 
> I did 655,000 minor planets as part of my solar system model:
> 
> https://news.povray.org/web.592d5e424e850994c437ac910%40news.povray.org
>

Thanks, Bill, very interesting source, I've saved it to bookmarks.
Maybe I will use it later, after filling the database with larger
objects :).
--
YB

[yesbird] Re: Star catalogue [70 days 16 hours and 2 minutes ago]

Tue, 3 Feb 2026 04:56:36 GMT

On 02/02/2026 17:14, Maetes wrote:
> Maybe.
> What are you looking for exactly?
> Position-Data?
> Pictures of the objects?

Pictures of good quality with complete objects info, including
coordinates. This will be a gallery with a pointer to the object's
location on the sky sphere. Now I rely mostly on NASA/Hubble materials,
but other sources also can help. This will be a long-term project ...

> Your Planetarium crashed my browser!

Possible, as it's in a very early state of development.
What browser do you have (including a platform) and could you
please send me console content (F12) ?
-- 
YB

[Bald Eagle] Re: Star catalogue [71 days 3 hours and 38 minutes ago]

Mon, 2 Feb 2026 17:20:00 GMT

"Maetes" <nomail@nomail> wrote:

I did 655,000 minor planets as part of my solar system model:

https://news.povray.org/web.592d5e424e850994c437ac910%40news.povray.org

- BE

[Maetes] Re: Star catalogue [71 days 6 hours and 43 minutes ago]

Mon, 2 Feb 2026 14:15:00 GMT

yesbird wrote:
> Thank you for sharing this data. Really, I am looking for good
> data source for my present Virtual planetary project:
> https://yesbird.online/planetarium/
>
> Could you suggest such a data source ?
> --
> YB

Maybe.
What are you looking for exactly?
Position-Data?
Pictures of the objects?

However, I haven't cared about deep sky objects so far, rather stars, exoplanets
and stuff like that. Describe in more detail what you would like to have, then I
can take a look for you during my search for my own data sources. I found so
much crap and didn't find it what I need, I'm slowly developing some practice.

Your Planetarium crashed my browser!

:)

Ma

[yesbird] Re: Star catalogue [72 days 11 hours and 16 minutes ago]

Sun, 1 Feb 2026 09:42:45 GMT

On 08/12/2025 02:45, Maetes wrote:
> If anyone wants to try their hand at creating a real starry sky with simulated
> stars, I've trimmed the HYG star catalogue (120,000 entries) a bit and turned it
> into a Povray array. ...

Hi, Maetes.

Thank you for sharing this data. Really, I am looking for good
data source for my present Virtual planetary project:
https://yesbird.online/planetarium/

I am expected that it should be informative and compact enough,
also includes deep sky objects like nebulas and galaxies, but
assume that it will be not for professional use, but mostly addressed
to schoolchildren and students just for fun.

Could you suggest such a data source ?
--
YB

[Maetes] Re: Lunar Crater Catalogue - LCC V1.0 [74 days 5 hours and 28 minutes ago]

Fri, 30 Jan 2026 15:30:00 GMT

Another example-image

[Maetes] Lunar Crater Catalogue - LCC V1.0 [74 days 5 hours and 33 minutes ago]

Fri, 30 Jan 2026 15:25:00 GMT

On my website I have deposited a database with more or less all lunar craters
and other features bigger than 1 kilometer.

It can be downloaded as an SQL import file and in the form of a long Povray
array inside a text file. Both contain almost 9000 entries.

https://www.maetes.com/en/blog/lunar-crater-catalogue-lcc-version-1

Greetings,
M

[jr] Re: Roman numerals [110 days 6 hours and 3 minutes ago]

Thu, 25 Dec 2025 14:55:00 GMT

hi,

kurtz le pirate <kur### [at] freefr> wrote:
On 21/12/2025 13:32, jr wrote:
> > ...
> > agree, unrealistic (I only wanted to get a(n approximate) "feel").
>
> for 20000 converts :
>   * Elapsed time = 0.0202 ms for my macro
>   * Elapsed time = 0.0162 ms for yours
>
> you're the winner.
> ;)

</LOLz>  truly, "I've won" because I feel that thanks to your inputs my macro
got better as a result.  cheers.


regards, jr.

[jr] Re: Roman numerals [110 days 6 hours and 3 minutes ago]

Thu, 25 Dec 2025 14:55:00 GMT

hi.

oh man, beautiful.  thank you, very much.


regards, jr.

[kurtz le pirate] Re: Roman numerals [110 days 12 hours and 32 minutes ago]

Thu, 25 Dec 2025 08:26:34 GMT

On 24/12/2025 22:08, Bald Eagle wrote:
> 
> 
EXCELLENT




-- 
kurtz le pirate
compagnie de la banquise

[Bald Eagle] Re: Roman numerals [110 days 23 hours and 48 minutes ago]

Wed, 24 Dec 2025 21:10:00 GMT

[kurtz le pirate] Re: Roman numerals [112 days 3 hours and 59 minutes ago]

Tue, 23 Dec 2025 16:59:29 GMT

On 21/12/2025 13:32, jr wrote:
> hi,
> 
> kurtz le pirate <kur### [at] freefr> wrote:
>> ...
>> 20K is a lot, and double loops can be detrimental. You're right.
> 
> agree, unrealistic (I only wanted to get a(n approximate) "feel").
> 

for 20000 converts :
  * Elapsed time = 0.0202 ms for my macro
  * Elapsed time = 0.0162 ms for yours

you're the winner.


;)

-- 
kurtz le pirate
compagnie de la banquise

[jr] Re: Roman numerals [114 days 8 hours and 23 minutes ago]

Sun, 21 Dec 2025 12:35:00 GMT

hi,

kurtz le pirate <kur### [at] freefr> wrote:
> ...
> 20K is a lot, and double loops can be detrimental. You're right.

agree, unrealistic (I only wanted to get a(n approximate) "feel").

> In fact, a long time ago, I was developing applications with FileMaker
> and I had the same need. I just found my function and converted it to
> POV SDL. Juste for fun ;)

and that last is key.  last night I remembered that POV-Ray permits nested macro
declarations/definitions, and (fwiw) attach a text file with the code as adapted
"over breakfast" :-).  cheers.

regards, jr.

[kurtz le pirate] Re: Roman numerals [114 days 10 hours and 11 minutes ago]

Sun, 21 Dec 2025 10:47:15 GMT

On 20/12/2025 23:53, jr wrote:
> hi,
> 
> kurtz le pirate <kur### [at] freefr> wrote:
>> ...
>> what do you think of this version?
>> ...
> 
> several things.  </grin>  first, it was fun to compare (thanks) and find the old
> "swings and roundabouts" adage confirmed.
> 
> it is pretty neat, the all-in-one macro.  pretty compact too.  (too small to
> merit an include file </facetious-grin>)  not having a "mathematical brain" I
> found your code "amazing" but not as "obvious" as the method/algorithm provided
> by Wikipedia.  also, it comes at a cost.  when running each macro ~20k times (5
> loops over 1-3999 range) the nested loops are a little more "expensive".


20K is a lot, and double loops can be detrimental. You're right.


In fact, a long time ago, I was developing applications with FileMaker 
and I had the same need. I just found my function and converted it to 
POV SDL. Juste for fun ;)




-- 
kurtz le pirate
compagnie de la banquise

[jr] Re: Roman numerals [114 days 22 hours and 3 minutes ago]

Sat, 20 Dec 2025 22:55:00 GMT

hi,

kurtz le pirate <kur### [at] freefr> wrote:
> ...
> what do you think of this version?
> ...

several things.  </grin>  first, it was fun to compare (thanks) and find the old
"swings and roundabouts" adage confirmed.

it is pretty neat, the all-in-one macro.  pretty compact too.  (too small to
merit an include file </facetious-grin>)  not having a "mathematical brain" I
found your code "amazing" but not as "obvious" as the method/algorithm provided
by Wikipedia.  also, it comes at a cost.  when running each macro ~20k times (5
loops over 1-3999 range) the nested loops are a little more "expensive".

regards, jr.

[Alain Martel] Re: Roman numerals [115 days 3 hours and 27 minutes ago]

Sat, 20 Dec 2025 17:31:06 GMT

Le 2025-12-20 Ã  11:47, kurtz le pirate a Ã©critÂ :
> On 20/12/2025 13:27, jr wrote:
>> hi,
>>
>> kurtz le pirate <kur### [at] freefr> wrote:
>>> On 20/12/2025 00:16, jr wrote:
>>>> I wrote/"needed" a macro ('LatinYear()') ...
>>
>>> Good work, a little too complicated, but good work.
>>
>> thank you, very much.Â  you're right, of course.Â  attached an
update, less
>> "cruft" :-).Â  also I got rid of the '#for', and the macro can now be 
>> used with
>> version 3.7 too (tested with v3.7.0.8).
>>
>>
>> enjoy, jr.
> 
> what do you think of this version?
> 
> 
> // --- macro start
> #macro ToRoman(DecimalToConvert)
>  Â #local Nb = 13;
>  Â #local values = array[Nb] {1000,900,500,400,100,90,50,40,10,9,5,4,1};
>  Â #local symbols = array[Nb] 
> {"M","CM","D","CD","C","XC","L","XL","X","IX","V","IV","I"};
>  Â #local roman = "";
>  Â #local num = DecimalToConvert;
>  Â #local i = 0;
>  Â #while ( i<Nb & num>0 )
>  Â  #while( values[i] <= num )
>  Â Â  #local num = num - values[i];
>  Â Â  #local roman = concat(roman,symbols[i]);
>  Â  #end
>  Â  #local i = i + 1;
>  Â #end
>  Â roman
> #end
> // --- macro end
> 
> 
> #declare D = 10191; // beginning of the Dune Story
> #declare R = ToRoman(D);
> #debug concat(str(D,0,0)," -> ",R,"\n")
> 
> 
> 
> 
> ...of course, valid only for positive years.
Just use the absolute value of the year and add Â«BCEÂ» for the
negative 
years.
-2027 â†’ MMXXVII BCE

Now, need a font supporting macron for years 1 000 000 to 999 999 999. 
And double macron for years 1 000 000 000 to 999 999 999 999.

[kurtz le pirate] Re: Roman numerals [115 days 4 hours and 11 minutes ago]

Sat, 20 Dec 2025 16:47:22 GMT

On 20/12/2025 13:27, jr wrote:
> hi,
> 
> kurtz le pirate <kur### [at] freefr> wrote:
>> On 20/12/2025 00:16, jr wrote:
>>> I wrote/"needed" a macro ('LatinYear()') ...
> 
>> Good work, a little too complicated, but good work.
> 
> thank you, very much.  you're right, of course.  attached an update, less
> "cruft" :-).  also I got rid of the '#for', and the macro can now be used with
> version 3.7 too (tested with v3.7.0.8).
> 
> 
> enjoy, jr.

what do you think of this version?


// --- macro start
#macro ToRoman(DecimalToConvert)
  #local Nb = 13;
  #local values = array[Nb] {1000,900,500,400,100,90,50,40,10,9,5,4,1};
  #local symbols = array[Nb] 
{"M","CM","D","CD","C","XC","L","XL","X","IX","V","IV","I"};
  #local roman = "";
  #local num = DecimalToConvert;
  #local i = 0;
  #while ( i<Nb & num>0 )
   #while( values[i] <= num )
    #local num = num - values[i];
    #local roman = concat(roman,symbols[i]);
   #end
   #local i = i + 1;
  #end
  roman
#end
// --- macro end


#declare D = 10191; // beginning of the Dune Story
#declare R = ToRoman(D);
#debug concat(str(D,0,0)," -> ",R,"\n")




...of course, valid only for positive years.



-- 
kurtz le pirate
compagnie de la banquise

[tTh] Re: Helpers - Macro-Collection for many applicat... [115 days 4 hours and 35 minutes ago]

Sat, 20 Dec 2025 16:22:46 GMT

On 1/12/25 04:46, Cousin Ricky wrote:

>   - An end to scope leakage.  #local scope does not stay local, which
>     means that if you write a library, you have to read the minds of
>     every other POVer on earth.

    This is also one of my wishs for this xmas :)

-- 
**                                                            **
*                      tTh des Bourtoulots                     *
*                  http://maison.tth.netlib.re/                *
**                                                            **

[Bald Eagle] Re: Roman numerals [115 days 6 hours and 33 minutes ago]

Sat, 20 Dec 2025 14:25:00 GMT

This is quite synchronicitous - I was just musing about doing Roman Numerals the
other day.

Chalked it up to "add to to do list", and "surely someone else has done this
before".  And promptly got interrupted with something else to do.


Not sure if this helps any - read the last sentence:

https://wiki.povray.org/content/Documentation_Talk:Reference_Section_2.3

- BE

[jr] Re: Roman numerals [115 days 8 hours and 28 minutes ago]

Sat, 20 Dec 2025 12:30:00 GMT

hi,

kurtz le pirate <kur### [at] freefr> wrote:
> On 20/12/2025 00:16, jr wrote:
> > I wrote/"needed" a macro ('LatinYear()') ...

> Good work, a little too complicated, but good work.

thank you, very much.  you're right, of course.  attached an update, less
"cruft" :-).  also I got rid of the '#for', and the macro can now be used with
version 3.7 too (tested with v3.7.0.8).

enjoy, jr.

[kurtz le pirate] Re: Roman numerals [115 days 10 hours and 35 minutes ago]

Sat, 20 Dec 2025 10:23:25 GMT

On 20/12/2025 00:16, jr wrote:
> hi,
> 
> I wrote/"needed" a macro ('LatinYear()') to convert years to their Roman
> numerals representation, posting it .. just in case.  the macro takes the year
> and returns a string, for instance:
> 
> #version 3.8;
> global_settings {assumed_gamma 1}
> 
> #include "latinum.inc"
> 
> #debug concat("2000  ",LatinYear(2000),".\n")
> #debug concat("1984  ",LatinYear(1984),".\n")
> #debug concat("2026  ",LatinYear(2026),".\n")
> 
> 
> enjoy, jr.

Hi,

Good work, a little too complicated, but good work.





-- 
kurtz le pirate
compagnie de la banquise

[jr] Roman numerals [115 days 21 hours and 38 minutes ago]

Fri, 19 Dec 2025 23:20:00 GMT

hi,

I wrote/"needed" a macro ('LatinYear()') to convert years to their Roman
numerals representation, posting it .. just in case.  the macro takes the year
and returns a string, for instance:

#version 3.8;
global_settings {assumed_gamma 1}

#include "latinum.inc"

#debug concat("2000  ",LatinYear(2000),".\n")
#debug concat("1984  ",LatinYear(1984),".\n")
#debug concat("2026  ",LatinYear(2026),".\n")


enjoy, jr.

[Maetes] Star catalogue [127 days 21 hours and 8 minutes ago]

Sun, 7 Dec 2025 23:50:00 GMT

If anyone wants to try their hand at creating a real starry sky with simulated
stars, I've trimmed the HYG star catalogue (120,000 entries) a bit and turned it
into a Povray array.

Documented more thoroughly than I would like, took way too long, as always.

A macro collection that makes use of it is in the works.

See:
https://www.maetes.com/en/download/hyg-lite-star-catalogue

That's the damn reason why I don't have time to build damn spaceships.

:)

Ma

[Maetes] Re: Milky Way [164 days 8 hours and 38 minutes ago]

Sat, 1 Nov 2025 12:20:00 GMT

"Leroy" <whe### [at] gmailcom> wrote:
>
> Great Job! I loaded the 8k and 32k images separately . The 32k images crashed
> IrfanView. The 8k images looks great!

Thanks.

My Gwenview and 2 other picture-browser crashes also, even if you open a folder
with this big files, not the big file directly.

Nevertheless, povray use the files at least till the RAM is full without
crashing.

So far, I haven't found a way to make a good looking Milky Way without maps.

ma

[Leroy] Re: Milky Way [165 days 1 hour and 13 minutes ago]

Fri, 31 Oct 2025 19:45:00 GMT

"Maetes" <nomail@nomail> wrote:
> I finally finished a Povray package and published it on my website.
> It places a photorealistic image of the Milky Way on the Sky-Sphere of Povray.
>
> https://www.maetes.com/en/povray-os/ma_milkyway
>
> The package is ready-to-use and contains all maps up to 16k resolution.
> These and 32k maps can be downloaded separately in the download section.
>
> https://www.maetes.com/en/download/
>
> Have fun with it,
> Ma

Great Job! I loaded the 8k and 32k images separately . The 32k images crashed
IrfanView. The 8k images looks great!

Having  fun!

[yesbird] Re: Milky Way [165 days 2 hours and 9 minutes ago]

Fri, 31 Oct 2025 18:48:46 GMT

On 31/10/2025 19:19, yesbird wrote:
> On 31/10/2025 15:03, Maetes wrote:
>> I finally finished a Povray package and published it on my website.
>> It places a photorealistic image of the Milky Way on the Sky-Sphere of 
>> Povray.
>> ...
> 
> Really interesting - it looks like the seed of the future
> planetarium project ...

Here is a quick sketch of possible scene implementation:
https://yesbird.online/gallery/?m=deep_space&e=env_space2&r=true

Press <Esc> or <Space> to get back to gallery home.
Use VR headset for best experience.
--
YB

[yesbird] Re: Milky Way [165 days 4 hours and 39 minutes ago]

Fri, 31 Oct 2025 16:19:31 GMT

On 31/10/2025 15:03, Maetes wrote:
> I finally finished a Povray package and published it on my website.
> It places a photorealistic image of the Milky Way on the Sky-Sphere of Povray.
> ...

Really interesting - it looks like the seed of the future
planetarium project ...

If you will be able to render stereo-pair in spherical projection
(VR360) for VR headset, I will include it in my gallery:
https://yesbird.online/gallery/

This is how to do that with different versions of POV-Ray:
-- HgPovray38 --
https://wiki.povray.org/content/User:Le_Forgeron/HgPovray38

-- Official POV-Ray 3.8 beta --
https://wiki.povray.org/content/Reference:Camera#User_defined_projection
https://www.clodo.it/blog/omnidirectional-stereo-ods-with-pov-ray/
https://paulbourke.net/stereoscopy/pov_odsp/

If you have a limited hardware resources, just make a scene setup and
share it here - I will do rendering on my fast 128-cores server.
--
YB

[yesbird] Re: Model- and Script-Collections [165 days 4 hours and 55 minutes ago]

Fri, 31 Oct 2025 16:03:11 GMT

On 30/10/2025 23:16, Maetes wrote:
> I have created a new page on my website, where I have listed the collections of
> objects and scripts I know. The list is still very short, but I will continue to
> maintain and expand it when I find new sources.

Good start - I need such sources too for my new VR gallery:
https://yesbird.online/gallery/

Will follow you quest ...
-- 
YB

[Maetes] Milky Way [165 days 8 hours and 53 minutes ago]

Fri, 31 Oct 2025 12:05:00 GMT

I finally finished a Povray package and published it on my website.
It places a photorealistic image of the Milky Way on the Sky-Sphere of Povray.

https://www.maetes.com/en/povray-os/ma_milkyway

The package is ready-to-use and contains all maps up to 16k resolution.
These and 32k maps can be downloaded separately in the download section.

https://www.maetes.com/en/download/

Have fun with it,
Ma

[Maetes] Model- and Script-Collections [166 days and 38 minutes ago]

Thu, 30 Oct 2025 20:20:00 GMT

I have created a new page on my website, where I have listed the collections of
objects and scripts I know. The list is still very short, but I will continue to
maintain and expand it when I find new sources.


https://www.maetes.com/en/povray/model-and-scriptcollections


I know a few more, but I want to test them first before they will be part of the
listing.

If you know websites with good, at least partially working code, just let me
know, feel free to post the links here in the forum.


maetes

[yesbird] Jewelry rendering - best practice ? [180 days 17 hours and 36 minutes ago]

Thu, 16 Oct 2025 03:22:40 GMT

This is the result of conversion and rendering in a studio environment
with materials from Mike Miller. Any suggestions about quality
improvement of similar models (jewelry) are highly appreciated.
--
YB

[Dave Blandston] Re: Compute Visibility Distance for Flat Earth T... [207 days 1 hour and 28 minutes ago]

Fri, 19 Sep 2025 19:30:00 GMT

I forgot to mention this but if anyone wants to experiment with this there are a
few variables to set. They're clearly documented and positioned near the
beginning of the file.

[Dave Blandston] Compute Visibility Distance for Flat Earth Test [207 days 3 hours and 13 minutes ago]

Fri, 19 Sep 2025 17:45:00 GMT

This is a simple program to compute how far an observer must travel from a
visible object (such as a bright light at night) before the object is obscured
by the curvature of the Earth. The program allows one to select the amount of
desired curvature required (called "Earth bump" in the program - this is
illustrated when the program is run). An example output image is posted in the
povray.binaries.images section.

Kind regards,
Dave Blandston

[Mr] Re: Airport - Teaser [217 days 11 hours and 48 minutes ago]

Tue, 9 Sep 2025 09:10:00 GMT

"Maetes" <nomail@nomail> wrote:
> "Mr" <m******r******at_hotmail_dot_fr> wrote:
> > Hi !
> > I would start by lowering the diffuse on many of the object's textures ...
>
>
> You're certainly right, but I haven't bothered with textures yet.
> Just named them properly and outsourced them.
>
> My order:
> - overall design of all elements
> - add new models (aircrafts and stuff)
> - teach aircrafts flying + create a movie (most funny part)
> - ...
> - ...
> - textures and design
>
> ma

I love the fuel truck cylindrical tank's specular and got carried away! don't
mind me, keep having fun! :-)

[Maetes] Re: Airport - Teaser [219 days 10 hours and 13 minutes ago]

Sun, 7 Sep 2025 10:45:00 GMT

"Mr" <m******r******at_hotmail_dot_fr> wrote:
> Hi !
> I would start by lowering the diffuse on many of the object's textures ...


You're certainly right, but I haven't bothered with textures yet.
Just named them properly and outsourced them.

My order:
- overall design of all elements
- add new models (aircrafts and stuff)
- teach aircrafts flying + create a movie (most funny part)
- ...
- ...
- textures and design

ma

[Maetes] Re: Airport - Teaser [219 days 10 hours and 18 minutes ago]

Sun, 7 Sep 2025 10:40:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> It might be a few days, but I can dig in the archive and see what I have.
> IIRC, it was a plane, a copter, a rocket launch pad, some buildings ....
> I don't recall that I ever got around to doing the boats and dock, etc.

Thanks, I can use everything well.
But don't stress you, I'm still busy for at least another week.

M

[Mr] Re: Airport - Teaser [224 days 6 hours and 58 minutes ago]

Tue, 2 Sep 2025 14:00:00 GMT

"Maetes" <nomail@nomail> wrote:
> At the moment I'm aiap (as insane as possible) constructing an airport.
> A lot of own work, but also open source models from the Internet, such as
> Lohmueller-Plane and Heli.
>
> The source code will be published at some point (autumn? winter?), but it's
> still too early for that, everything is heavily under construction and buggy.
>
> I have enough ideas (beer garden, tower, hangar, traffic lights, surveillance
> cameras,...).
>
> But I could use models for aircraft and accessories.
> If any of you have models and want to share them, even if they are old and don't
> run right away, that would be nice.
>
> The same applies to ready-to-use textures, I'm not the best at that either.
>
> Ciao,
> Martin

Hi !
I would start by lowering the diffuse on many of the object's textures, starting
from the asphalt which looks like it has no room to interact with radiosity, sun
or sky light. it should be extremely low, then most of it's reflectivity should
be from a still veeery low intensity specular/phong, but with high
size/roughness. (the pillars of the platform would also benefit from lower
diffuse)

[Bald Eagle] Re: Airport - Teaser [224 days 8 hours and 3 minutes ago]

Tue, 2 Sep 2025 12:55:00 GMT

"Maetes" <nomail@nomail> wrote:

Very nice.

A while back I began doing a similar project, to model Fearing Island from the
Tom Swift Jr. series of books.

It might be a few days, but I can dig in the archive and see what I have.

IIRC, it was a plane, a copter, a rocket launch pad, some buildings ....
I don't recall that I ever got around to doing the boats and dock, etc.

- BE

[Maetes] Airport - Teaser [224 days 8 hours and 43 minutes ago]

Tue, 2 Sep 2025 12:15:00 GMT

At the moment I'm aiap (as insane as possible) constructing an airport.
A lot of own work, but also open source models from the Internet, such as
Lohmueller-Plane and Heli.

The source code will be published at some point (autumn? winter?), but it's
still too early for that, everything is heavily under construction and buggy.

I have enough ideas (beer garden, tower, hangar, traffic lights, surveillance
cameras,...).

But I could use models for aircraft and accessories.
If any of you have models and want to share them, even if they are old and don't
run right away, that would be nice.

The same applies to ready-to-use textures, I'm not the best at that either.

Ciao,
Martin

[Josh English] Wave Function Collapse 0.1 [286 days 21 hours and 43 minutes ago]

Tue, 1 Jul 2025 23:14:47 GMT

Here is the minimal viable product of a wave function collapse algorithm 
implemented in POV-Ray's SDL.

There are more enhancements and fine-tuning I want to make, so please be 
kind about the code, I know it could be better.

I could also, you know, DOCUMENT the thing. The wfc001.pov file has some 
helpful comments walking through usage. The include file does not have 
as many helpful comments explaining the problem solving.

Uncle Josh

[jr] chain link puzzle solver [367 days 10 hours and 13 minutes ago]

Sat, 12 Apr 2025 10:45:00 GMT

hi,

attached is the first version of a "Chain Link" puzzle solver (attempt :-)),
inspired by Kurtz le Pirate's posting an image etc of his Sudoku solver.  here
in the UK the "i" newspaper publishes these puzzles (daily), hence the 'icls'
prefix of the code.

the archive includes a pov/inc/ini "combo" and a zip with a small number of
example puzzles. installation is simply putting the code in one directory, the
puzzle files in another, then fixing a path (line 17) in the pov file, and the
output_file_name in the ini.  also included, for Linux users, a few lines of
BASH to automate running the solver.

there are Debug and Verbose options for text output, and a 'Solve' option which
can be overridden to render just the puzzle as published -- for printing out and
manual solving :-).

the code is fairly well commented but comes w/out documentation, and requires a
3.8 version to run.  the include files used are all available from
<wiki.povray.org/content/User:Jr>.

this version implements only one simple "strategy" and, consequently, does not
solve every puzzle.  a second strategy which takes the chain layout into account
is planned, but the prerequisite "divine inspiration" has not yet struck.

comments / discussion / participation welcome.

enjoy, jr.

[jr] Re: Helpers - Macro-Collection for many applicat... [456 days 4 hours and 28 minutes ago]

Mon, 13 Jan 2025 16:30:00 GMT

hi,

antoine <map### [at] orangefr> wrote:
> Le 12/01/2025 à 17:37, Bald Eagle a écrit :
> > Cousin Ricky <ric### [at] yahoocom> wrote:
> >> But as jr alluded to, the parser is the biggest monster to be slain in
> >> this software.  It's a recursive descent algorithm and very inflexible.
> > As this applies to most anything in life:
> > Hope is not a plan.

that's quotable :-)


> > No one is coming to save you/us.
> > Skills are more valuable than things.
> > As I have brought up in the past, it would probably be a good idea to look
> > outside of the tiny little corner of the internet that we frequent, and try to
> > find someone amongst the many academic and commercial computer science people
> > that use POV-Ray for some purpose, and ask if they can have a student write out
> > the basic framework of a modern (LR-style?) parser to get things firmly started
> > in the proper direction.
> > In the absence of that, what are your thoughts on beginning to write out THE NEW
> > parser amongst ourselves?  I have seen that someone has already begun doing such
> > a thing, and perhaps we can all build on whatever contributions people can
> > offer.
> > WFP is already writing yuqk.
> > jr and I have Stroustrup's tome.
> > Plenty of people are capable of writing some level of code - be it in SDL or
> > some other language.
> > Even if we simply start sketching out the framework, others can come in and fill
> > in the blanks.
> > I mean, even if the code doesn't actually DO anything and it's just blocks of
> > comments describing what should be done at each step - we can still write what
> > amounts to an operational flowchart, where we can just output a summary of what
> > the code WOULD do if there was functional code in the framework.

after some thought, I've decided to start a new thread in
..pov4.discussion.general, subject "SDL2".  over the years there have been a
number of "feature requests", this may be the time to start having them in one
place.

every post to the thread should discuss exactly _one_ new feature / whatever
aspect of SDL programming, with bits of pseudo code to illustrate, as suggested
above.

and yes, a kindhearted academic who'd provide .. support, would be "the ideal".
fingers crossed, it's a big world :-)


> Hello,
> (I apologize in advance for the possible bad english)
> I remember some years ago, Christoph Lipka was evocating/evoking the
> Json script language as a replacement of POVRay's Scene description
> language. Maybe the POVRay project should go in this direction.
> Regards,
> Antoine.

personally, I'd prefer a SDL2 which compiles.  but I would love to have a SDL2
which can read/import objects (say mesh) and or data from .json files.  re "Json
script language", you mean JavaScript ?


regards, jr.

[Bald Eagle] Re: Helpers - Macro-Collection for many applicat... [456 days 5 hours and 8 minutes ago]

Mon, 13 Jan 2025 15:50:00 GMT

antoine <map### [at] orangefr> wrote:

> Hello,
> (I apologize in advance for the possible bad english)

No worries.  Some of the people who speak the worst English are the ones born in
English-speaking countries.  ;)

> I remember some years ago, Christoph Lipka was evocating/evoking the
> Json script language as a replacement of POVRay's Scene description
> language.

("advocating"?)

https://news.povray.org/povray.pov4.discussion.general/thread/%3C566c3270%40news.povray.org%3E/

I was involved in a very large-scale project, and the way it was organized, was
that those who wanted their "camp" to be considered would submit a "cover
letter" explaining their position, and supported by a "spreadsheet" covering all
of the pros and cons, deficiencies and benefits of their way of going about
things.
People signed up to be part of the team, with the understanding that when a
critical mass was achieved (the development team), they would then do what was
necessary to become an active developer.

In order to "best" determine the will of the active user base / developers, the
Condorcet method was used to select which "camp" would drive the development.
https://en.wikipedia.org/wiki/Minimax_Condorcet_method

I think it would be productive and educational if a list of programming
styles/paradigms was made, with representative specific languages, and then
people with specialized knowledge of each of those languages would fill in the
details, and explain how things are the same, different, beneficial,
detrimental, etc.  Then we could have something to read over and really KNOW
what we want for a "new SDL", and there would historical documentation for the
users to understand WHY - which seems to fill up a lot of recurring newsgroup
threads.

Then we could move on to organizing the complexities of the hierarchies of CSG,
pigments, textures, normals, finishes, uv_mapping, cutaway_textures, etc.

Specifically highlighting good programming practices, and exposing the pitfalls
of certain ways of doing things that lead to ambiguity, unintended results,
scope leakage, etc. (with specific coding examples and results) would minimize
covering the same ground repeatedly, and focus efforts on continual progress,
rather than getting bogged down in rehashing old issues with new contributors.

Once again, I'll point out that a lot of folks here that have been around a long
time, simply don't have the time, energy, focus, round-tuits, programming
experience, writing parsers and lexers, etc to take on something like re-writing
all of SDL from scratch and getting something functioning at the end of it.

So soliciting outside expertise in these areas seems to be less of a suggestion
and more of a critical need.

- BW

[antoine] Re: Helpers - Macro-Collection for many applicat... [457 days 3 hours and 29 minutes ago]

Sun, 12 Jan 2025 17:29:09 GMT

Le 12/01/2025 Ã  17:37, Bald Eagle a Ã©critÂ :
> Cousin Ricky <ric### [at] yahoocom> wrote:
> 
>> But as jr alluded to, the parser is the biggest monster to be slain in
>> this software.  It's a recursive descent algorithm and very inflexible.
> 
> As this applies to most anything in life:
> Hope is not a plan.
> No one is coming to save you/us.
> Skills are more valuable than things.
> 
> As I have brought up in the past, it would probably be a good idea to look
> outside of the tiny little corner of the internet that we frequent, and try to
> find someone amongst the many academic and commercial computer science people
> that use POV-Ray for some purpose, and ask if they can have a student write out
> the basic framework of a modern (LR-style?) parser to get things firmly started
> in the proper direction.
> 
> In the absence of that, what are your thoughts on beginning to write out THE NEW
> parser amongst ourselves?  I have seen that someone has already begun doing such
> a thing, and perhaps we can all build on whatever contributions people can
> offer.
> 
> WFP is already writing yuqk.
> jr and I have Stroustrup's tome.
> Plenty of people are capable of writing some level of code - be it in SDL or
> some other language.
> 
> Even if we simply start sketching out the framework, others can come in and fill
> in the blanks.
> 
> I mean, even if the code doesn't actually DO anything and it's just blocks of
> comments describing what should be done at each step - we can still write what
> amounts to an operational flowchart, where we can just output a summary of what
> the code WOULD do if there was functional code in the framework.
> 
> - BW
> 
Hello,
(I apologize in advance for the possible bad english)
I remember some years ago, Christoph Lipka was evocating/evoking the 
Json script language as a replacement of POVRay's Scene description 
language. Maybe the POVRay project should go in this direction.
Regards,
Antoine.

[Bald Eagle] Re: Helpers - Macro-Collection for many applicat... [457 days 4 hours and 18 minutes ago]

Sun, 12 Jan 2025 16:40:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:

> But as jr alluded to, the parser is the biggest monster to be slain in
> this software.  It's a recursive descent algorithm and very inflexible.

As this applies to most anything in life:
Hope is not a plan.
No one is coming to save you/us.
Skills are more valuable than things.

As I have brought up in the past, it would probably be a good idea to look
outside of the tiny little corner of the internet that we frequent, and try to
find someone amongst the many academic and commercial computer science people
that use POV-Ray for some purpose, and ask if they can have a student write out
the basic framework of a modern (LR-style?) parser to get things firmly started
in the proper direction.

In the absence of that, what are your thoughts on beginning to write out THE NEW
parser amongst ourselves?  I have seen that someone has already begun doing such
a thing, and perhaps we can all build on whatever contributions people can
offer.

WFP is already writing yuqk.
jr and I have Stroustrup's tome.
Plenty of people are capable of writing some level of code - be it in SDL or
some other language.

Even if we simply start sketching out the framework, others can come in and fill
in the blanks.

I mean, even if the code doesn't actually DO anything and it's just blocks of
comments describing what should be done at each step - we can still write what
amounts to an operational flowchart, where we can just output a summary of what
the code WOULD do if there was functional code in the framework.

- BW

[Cousin Ricky] Re: Helpers - Macro-Collection for many applicat... [457 days 17 hours and 12 minutes ago]

Sun, 12 Jan 2025 03:46:38 GMT

On 2025-01-02 13:55 (-4), Maetes wrote:
> 
> Unfortunately, I can't find any item of my personal wish list (except for
> optional parameters) in the revision list of version 3.8.
> These are:
> - spherical heightfields
> - Type-Identification
> - new functions to handle strings/arrays
> - Object-Oriented Programming (Classes)

On my own wish list:
 - An end to scope leakage.  #local scope does not stay local, which
   means that if you write a library, you have to read the minds of
   every other POVer on earth.
 - A call stack postmortem, so you can determine where the parse error
   *really* occurred.

But as jr alluded to, the parser is the biggest monster to be slain in
this software.  It's a recursive descent algorithm and very inflexible.

[jr] Re: Helpers - Macro-Collection for many applicat... [463 days 8 hours and 33 minutes ago]

Mon, 6 Jan 2025 12:25:00 GMT

hi,

"Maetes" <nomail@nomail> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > can you give some examples of what you (most) miss, please ?
> Most of the functions handwritten in my helper package. ...

ok.

> What annoyed me a lot:
> You have no chance of figuring out what type a variable is. You have to know
> what it is and cant convert them automatically.
> On the other hand, povray is not a real programming language but focuses on the
> render output.

so.. :-)  by now (as of 3.7 I think, perhaps earlier) the Scene Description
Language (SDL) is "Turing complete".  but it evolved to that stage, and both
developers and users obsess about "backward compatibility", therefore SDL, the
current parser, is most unlikely to evolve further to offer us worthwhile
"introspection" tools (like WFP started introducing in his branch).

> I am happy about what it can do and that I was able to extend it for myself.
> So I don't want to complain.

is all we do ;-)  (also gets easier with age.  more time to practice :-))

> I have a wish list, but I don't expect anyone to implement it in their free
> time. And my programming skills do not allow me to get involved in the project
> at the moment. So I have to live with what I have, and that's a lot of fun.

+1.

>> jr and I are looking into that.  But at the moment we're both sort of tied up
>> with too much non-POV-Ray real life drudgery.  :(

> Yes yes, I know.
> Could do it around the clock, but have other things to do, unfortunately.

you live in the same world we do, so you do know that it is all about ..
pedalling faster, to keep standing still.  </shrug>  but I think the majority of
"us" would spend more time "povving", if RL allowed.

regards, jr.

[Maetes] Re: Helpers - Macro-Collection for many applicat... [463 days 9 hours and 58 minutes ago]

Mon, 6 Jan 2025 11:00:00 GMT

"Mr" <m******r******at_hotmail_dot_fr> wrote:
> "Maetes" <nomail@nomail> wrote:
> >
> > Or I will try the "B-Thing".
>
> Please do ! Our POV-Ray addon needs feedback :
> https://extensions.blender.org/add-ons/povable/

You won't believe it, but coincidentally I tested this just before Christmas!
(or a similar Extension)

My goal was to get some models of NASA spacecraft from Blender to Povray  -
without any B-Thing knowledge!

It worked, more or less, but looks like all Textures were gone.

I canceld further tests, because B was too complicated for me, after > 4 hours I
had enough.

Maybe I will give it another try. Somewhen.

IS THERE A SEPARATE THREAD FOR THIS EXTENSION?

Martin

[Maetes] Re: Helpers - Macro-Collection for many applicat... [463 days 10 hours and 13 minutes ago]

Mon, 6 Jan 2025 10:45:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
> > - new functions to handle strings/arrays
>
> can you give some examples of what you (most) miss, please ?

Most of the functions handwritten in my helper package. Searching in strings,
filtering, sorting arrays, etc.
PHP has dozens of functions for this. I wrote most of the ones I needed, but it
was a hell of work. And I'm still amazed that Povray interprets them so quickly,
thought that would slow everything down.

What annoyed me a lot:
You have no chance of figuring out what type a variable is. You have to know
what it is and cant convert them automatically.

On the other hand, povray is not a real programming language but focuses on the
render output.
I am happy about what it can do and that I was able to extend it for myself.
So I don't want to complain.

I have a wish list, but I don't expect anyone to implement it in their free
time. And my programming skills do not allow me to get involved in the project
at the moment. So I have to live with what I have, and that's a lot of fun.

Ma

[Maetes] Re: Helpers - Macro-Collection for many applicat... [463 days 10 hours and 23 minutes ago]

Mon, 6 Jan 2025 10:35:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Spherical heightfields:
>
> "shapes.inc includes shapes_old.inc and contains many macros for working with
> objects, and for creating special objects, such as bevelled text, spherical
> height fields, and rounded shapes."
> https://wiki.povray.org/content/Reference:Shapes.inc
> So it ought to be in the drop-down insert menu.
>
https://news.povray.org/povray.binaries.images/thread/%3C5f16dc29%40news.povray.org%3E/
>
https://news.povray.org/povray.binaries.images/thread/%3C38a2dc5b%40news.povray.org%3E/

Hmmm ... I will check it, first try looks promising.
But there are some strage "features" in the picture.
Later, in a separate thread.

> Welcome to the club.  It's not big, and you're in it.  ;)
>
> > Or I push my C++ skills and find out if I can work on the development of
> > Povray-Sourcode.
>
> jr and I are looking into that.  But at the moment we're both sort of tied up
> with too much non-POV-Ray real life drudgery.  :(

Yes yes, I know.
Could do it around the clock, but have other things to do, unfortunately.

> > Or I will try the "B-Thing".
> :O  Hush.

:)
I deliberately didn't dare to write the bad word.


ma

[Mr] Re: Helpers - Macro-Collection for many applicat... [464 days 11 hours and 53 minutes ago]

Sun, 5 Jan 2025 09:05:00 GMT

"Maetes" <nomail@nomail> wrote:

>
> Or I will try the "B-Thing".
>
> Ma

Please do ! Our POV-Ray addon needs feedback :
https://extensions.blender.org/add-ons/povable/


You may also be interested in the work of when refactorings tend to occur)

He tried to demonstrate how to implement some object oriented features to POV:
https://news.povray.org/povray.programming/thread/%3Cweb.621b65ab50be6c547283012224d82e4%40news.povray.org%3E/

[jr] Re: Helpers - Macro-Collection for many applicat... [467 days 1 hour and 13 minutes ago]

Thu, 2 Jan 2025 19:45:00 GMT

hi,

to add to Bald Eagle's reply.

> - new functions to handle strings/arrays

can you give some examples of what you (most) miss, please ?


> - Object-Oriented Programming (Classes)

Bruno Cabasson had "a go":
<https://news.povray.org/povray.binaries.scene-files/thread/%3Cweb.621f42cb592fe9587283012224d82e4%40news.povray.org%3E
/>

but SDL would need to be "divorced" from its current parser before classes
("proper", as I imagine you mean), etc could be part of the language.


regards, jr.

[Bald Eagle] Re: Helpers - Macro-Collection for many applicat... [467 days 2 hours and 43 minutes ago]

Thu, 2 Jan 2025 18:15:00 GMT

"Maetes" <nomail@nomail> wrote:

> Unfortunately, I can't find any item of my personal wish list (except for
> optional parameters) in the revision list of version 3.8.
> These are:
> - spherical heightfields
> - Type-Identification
> - new functions to handle strings/arrays
> - Object-Oriented Programming (Classes)

Spherical heightfields:

"shapes.inc includes shapes_old.inc and contains many macros for working with
objects, and for creating special objects, such as bevelled text, spherical
height fields, and rounded shapes."
https://wiki.povray.org/content/Reference:Shapes.inc
So it ought to be in the drop-down insert menu.

https://news.povray.org/povray.binaries.images/thread/%3C5f16dc29%40news.povray.org%3E/

https://news.povray.org/povray.binaries.images/thread/%3C38a2dc5b%40news.povray.org%3E/

> Whether 3.7 or 3.8 makes little difference to me.

3.8 does have some little fixes and things, so I've been running that since it
got released as the beta.

> So I have to wait for Povray 4.0 (year 2030?) and write macros, macros, macros
> ......

Welcome to the club.  It's not big, and you're in it.  ;)

> Or I push my C++ skills and find out if I can work on the development of
> Povray-Sourcode. I've already started but failed (to view/understand/compile the
> source).

jr and I are looking into that.  But at the moment we're both sort of tied up
with too much non-POV-Ray real life drudgery.  :(

> Or I will try the "B-Thing".

:O  Hush.

- BW

[Maetes] Re: Helpers - Macro-Collection for many applicat... [467 days 2 hours and 58 minutes ago]

Thu, 2 Jan 2025 18:00:00 GMT

"jr" <cre### [at] gmailcom> wrote:
>
> ah, shame.  if "Linux knowledge" weren't an issue (you'd need to compile/install
> from source), the 'yuqk' branch might "tick your boxes"; there's (SDL) support
> for querying type of variable, for instance.

I don't waste time to check other or Beta-Versions of Povray.
I waste time to write complex macros from scratch :)
(soooo many hours, shame on ME)

> (and we're all _waiting_ for .. the gods to pull out their thumbs and make 3.8
> official)

Unfortunately, I can't find any item of my personal wish list (except for
optional parameters) in the revision list of version 3.8.
These are:
- spherical heightfields
- Type-Identification
- new functions to handle strings/arrays
- Object-Oriented Programming (Classes)

https://wiki.povray.org/content/Documentation:Tutorial_Section_1#Version_3.8

Whether 3.7 or 3.8 makes little difference to me.
So I have to wait for Povray 4.0 (year 2030?) and write macros, macros, macros
......

Or I push my C++ skills and find out if I can work on the development of
Povray-Sourcode. I've already started but failed (to view/understand/compile the
source).
Next life, maybe.

Or I will try the "B-Thing".

Ma

[jr] Re: Helpers - Macro-Collection for many applicat... [467 days 5 hours and 23 minutes ago]

Thu, 2 Jan 2025 15:35:00 GMT

hi,

"Maetes" <nomail@nomail> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > may also be a fun way to keep the older ones running.
> You love this small box or you ignore it.

:-)  the (late) Mrs Thatcher liked to say "there is no alternative".

> > you'd get to use the new 'optional' keyword for macro arguments
> it's not just about optional parameters, but also about the lack of
> type-identification.
> And as long as version 3.8 is not part of the official Debian repository, I will
> use and write for version 3.7.
> Installing the package manually requires more Linux knowledge, I also avoid that
> if possible.

ah, shame.  if "Linux knowledge" weren't an issue (you'd need to compile/install
from source), the 'yuqk' branch might "tick your boxes"; there's (SDL) support
for querying type of variable, for instance.  the latest is here:
<https://news.povray.org/povray.binaries.programming/thread/%3C675ff7f7%40news.povray.org%3E/>

(and we're all _waiting_ for .. the gods to pull out their thumbs and make 3.8
official)

> I hope my scripts are useful nevertheless.

still "investigating" ;-)

regards, jr.

[Maetes] Re: Helpers - Macro-Collection for many applicat... [467 days 12 hours and 18 minutes ago]

Thu, 2 Jan 2025 08:40:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> fast ?  <https://www.southampton.ac.uk/~sjc/raspberrypi/pi_pictures.htm>
> may also be a fun way to keep the older ones running.

You love this small box or you ignore it.

"jr" <cre### [at] gmailcom> wrote:
> would it not be a good idea to update your 'ma_helpers.inc' to version 3.8 ?
> you'd get to use the new 'optional' keyword for macro arguments

it's not just about optional parameters, but also about the lack of
type-identification.
And as long as version 3.8 is not part of the official Debian repository, I will
use and write for version 3.7.
Installing the package manually requires more Linux knowledge, I also avoid that
if possible.

Debian-Version in the current Release: 3.7.0.10
https://packages.debian.org/bookworm/povray
In the next Release: 3.7.0.10
https://packages.debian.org/trixie/povray

I hope my scripts are useful nevertheless.

Martin

[jr] Re: Helpers - Macro-Collection for many applicat... [468 days 12 hours and 13 minutes ago]

Wed, 1 Jan 2025 08:45:00 GMT

hi,

also :-)

"Maetes" <nomail@nomail> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > fwiw, 'MA_String2Array()' "jumped out" at me as I had need of something similar,
> Then you know ...

while "nosing around" the .inc file more, this comment caught my eye:

  MA_Terminal_T*
  Sends Text and/or variables to the terminal-window. Nice to have during
development of programming-tasks.
  Unfortunately povray doesnt know something about ...
  - optional parameters

would it not be a good idea to update your 'ma_helpers.inc' to version 3.8 ?
you'd get to use the new 'optional' keyword for macro arguments:
<https://wiki.povray.org/content/Reference:User_Defined_Macros#Optional_Parameters>

regards, jr.

[jr] Re: Helpers - Macro-Collection for many applicat... [470 days and 13 minutes ago]

Mon, 30 Dec 2024 20:45:00 GMT

hi,

> Phh ... this is my world:

"strange .. strange .. strange" :-)  I'd have thought being a Linux user, you'd
know all the "creation myths" of the unices including BSDs.

I never got round to playing with Pis, alas.  (along with countless other things
:-))


> 2nd Pi 5 ordered few week ago (for povray-jobs only), have three Pi 4, many
> older ones ...
> So I can tell you, the Pi 5 renders pure povray-scripts 2.87 times faster than
> the Pi 4.

fast ?  <https://www.southampton.ac.uk/~sjc/raspberrypi/pi_pictures.htm>

may also be a fun way to keep the older ones running.


> Then you know how painfull it is, to write the string and array macros from
> scratch, that are part of every other programming language.

yes.  writing SDL macros _is_ character-building ;-).


regards, jr.

[Maetes] Re: Helpers - Macro-Collection for many applicat... [470 days and 58 minutes ago]

Mon, 30 Dec 2024 20:00:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> fwiw, 'MA_String2Array()' "jumped out" at me as I had need of something similar,
> <https://news.povray.org/web.64b08576d08f3556b49d80446cde94f1%40news.povray.org>

Damn, I posted this thread in the wrong group.
If anyone can fix this, please feel free.

m

[Maetes] Re: Helpers - Macro-Collection for many applicat... [470 days 1 hour and 23 minutes ago]

Mon, 30 Dec 2024 19:35:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> you failed to doff your cap, wipe your feet ?!  </grin>

Sorry, I will work on my behavior. Promised.

> yes, there's more to the world than (just) MS Windows :-).

Phh ... this is my world:
https://www.raspberrypi.com/products/raspberry-pi-5/

2nd Pi 5 ordered few week ago (for povray-jobs only), have three Pi 4, many
older ones ...
So I can tell you, the Pi 5 renders pure povray-scripts 2.87 times faster than
the Pi 4.

> fwiw, 'MA_String2Array()' "jumped out" at me as I had need of something similar,
> <https://news.povray.org/web.64b08576d08f3556b49d80446cde94f1%40news.povray.org>

Then you know how painfull it is, to write the string and array macros from
scratch, that are part of every other programming language.
But I needed them!

Ma

[jr] Re: Helpers - Macro-Collection for many applicat... [470 days 1 hour and 53 minutes ago]

Mon, 30 Dec 2024 19:05:00 GMT

hi,

"Maetes" <nomail@nomail> wrote:
> Strange ... strange ... STRANGE.
> I thought 7-zip had already established itself as one of the standards.
> I think about to switch back to ZIP.

you're correct, it's well established.  your file was the first .7z I had a
problem with; no worries, may have been a "glitch".

> Maybe the lady likes to test this file:

thank you, appreciated.

> What I've done this time ... :)
> And not even in this thread!

you failed to doff your cap, wipe your feet ?!  </grin>

> First thing I had to do was to duckduckgo what BSD means at all.

yes, there's more to the world than (just) MS Windows :-).

fwiw, 'MA_String2Array()' "jumped out" at me as I had need of something similar,
though simpler.
<https://news.povray.org/web.64b08576d08f3556b49d80446cde94f1%40news.povray.org>

regards, jr.

[Maetes] Re: Helpers - Macro-Collection for many applicat... [470 days 2 hours and 28 minutes ago]

Mon, 30 Dec 2024 18:30:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:

> Doth thou so presume to address a Noble in so rude, so crass, so vulgar a
> manner, _commoner_?
>

What I've done this time ... :)
And not even in this thread!

Ladies or whatever you are, I check whether I can also store the files as
text-file that can be displayed directly in the Browser.

Mr. Martin Seydler

[Bald Eagle] Re: Helpers - Macro-Collection for many applicat... [470 days 2 hours and 53 minutes ago]

Mon, 30 Dec 2024 18:05:00 GMT

"Maetes" <nomail@nomail> wrote:

> Maybe the lady likes to test this file:

"Maybe _HER LADYSHIP_ likes to test this file:"

<eyroll>
Doth thou so presume to address a Noble in so rude, so crass, so vulgar a
manner, _commoner_?

;)

- BW

[Maetes] Re: Helpers - Macro-Collection for many applicat... [470 days 3 hours and 8 minutes ago]

Mon, 30 Dec 2024 17:50:00 GMT

Strange ... strange ... STRANGE.
I thought 7-zip had already established itself as one of the standards.
I think about to switch back to ZIP.

Maybe the lady likes to test this file:

https://www.maetes.com/downloads/ma_helpers.zip

Not mentioned on the website at the moment, for your eyes only :)
First thing I had to do was to duckduckgo what BSD means at all.

Martin

[jr] Re: Helpers - Macro-Collection for many applicat... [470 days 5 hours and 28 minutes ago]

Mon, 30 Dec 2024 15:30:00 GMT

hi,

"Maetes" <nomail@nomail> wrote:
> Hi Everyone.

(I preferred "ladies" </grin>)


> Since I work a lot with animations and elaborate scenarios, I have written many
> macros in recent years, some of which expand the Povray possibilities
> considerably.
> They can be used to search in strings, search, sort and crop arrays, and much
> more. Maybe helpful for you too?

might be, can't tell unfortunately ;-).  the downloaded .7z cannot be listed
with (BSD) 'tar' on my machine(s), nor extracted.


regards, jr.

[Maetes] Helpers - Macro-Collection for many applications [470 days 13 hours and 28 minutes ago]

Mon, 30 Dec 2024 07:30:00 GMT

Hi Everyone.

Since I work a lot with animations and elaborate scenarios, I have written many
macros in recent years, some of which expand the Povray possibilities
considerably.

They can be used to search in strings, search, sort and crop arrays, and much
more. Maybe helpful for you too?

Download and documentation:
https://www.maetes.com/en/povray-os/ma_helpers

Have fun,
Martin

[Jörg "Yadgar" Bleimann] Ten random RSCOP scenes mediately generated by C... [620 days 18 hours and 56 minutes ago]

Fri, 2 Aug 2024 02:02:44 GMT

Hi(gh)!

Once more also the scripts generated by ChatGPT...

...generally it can be said that ChatGPT produces much higher POV code 
quality than Poe - with the latter, more often than not I had to correct 
the code manually, quite often due to use of non-existing keywords such 
as "checkerboard" instead of "checker"!

See you in Khyberspace!

Yadgar
-- 
VBI BENE, IBI BACTRIA!

[Jörg "Yadgar" Bleimann] Ten random RSOCP scenes mediately generated by P... [627 days and 17 minutes ago]

Fri, 26 Jul 2024 20:41:15 GMT

Hi(gh)!

As announced on povray.binaries.images, here the ten RSOCP scripts 
generated by Poe 3.1!

In one case, I had to fix some bugs manually - Poe used "checkerboard" 
instead of "checker" and placed the normal statement inside the finish 
statement...

See you in Khyberspace!

Yadgar

-- 
VBI BENE, IBI BACTRIA!

[ingo] Re: "bst.inc" A Binary Search Tree [646 days 14 hours and 23 minutes ago]

Sun, 7 Jul 2024 06:35:00 GMT

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

Thanks, added it to the collection.

> Bald Eagle pointed me to this very good (imo) resource:
> <http://staff.ustc.edu.cn/~csli/graduate/algorithms/book6/chap14.htm>

[jr] Re: "bst.inc" A Binary Search Tree [647 days 8 hours and 33 minutes ago]

Sat, 6 Jul 2024 12:25:00 GMT

hi,

"ingo" <nomail@nomail> wrote:
> ...
> When deleting I first followed some Python et al. examples, but these high level
> and OOP languages obfuscate what really has to be done. ...

Bald Eagle pointed me to this very good (imo) resource:
<http://staff.ustc.edu.cn/~csli/graduate/algorithms/book6/chap14.htm>


regards, jr.

[ingo] Re: "bst.inc" A Binary Search Tree [649 days 15 hours and 28 minutes ago]

Thu, 4 Jul 2024 05:30:00 GMT

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

Thanks.

I already had quite some problems with deleting a node in this one.

When deleting I first followed some Python et al. examples, but these high level
and OOP languages obfuscate what really has to be done. Copy data to a node and
then search won't work as you have the same value twice. So copy, delete, paste.
That took some time to figure out where it went wrong.

One thing that didn't work was keeping count of the amount of entries,
especially after deleting a value. So now I just search for an empty one when
inserting.

It is and will stay a slow moving project,

ingo

> cool.  had a v similar project on the go, and "faltered" when it came to RB tree
> deletion of nodes; could not get the parser "to agree" on the code variations I
> tried :-).  bon chance.
>
>
> regards, jr.

[jr] Re: "bst.inc" A Binary Search Tree [649 days 18 hours and 13 minutes ago]

Thu, 4 Jul 2024 02:45:00 GMT

"ingo" <nomail@nomail> wrote:
> "ingo" <nomail@nomail> wrote:
>
> A completely new version. Options still to be added over time: a macro to
> balance a tree, macro's to rotate parts of a tree to get proper Red Black trees.
>
> ---%<------%<------%<---

cool.  had a v similar project on the go, and "faltered" when it came to RB tree
deletion of nodes; could not get the parser "to agree" on the code variations I
tried :-).  bon chance.

regards, jr.

[ingo] Re: "bst.inc" A Binary Search Tree [650 days 8 hours and 43 minutes ago]

Wed, 3 Jul 2024 12:15:00 GMT

"ingo" <nomail@nomail> wrote:

A completely new version. Options still to be added over time: a macro to
balance a tree, macro's to rotate parts of a tree to get proper Red Black trees.

---%<------%<------%<---

/*
POV-Ray include file: bst.inc

A POV-Ray include file for a Binary Seach Tree (BST).

Author : Ingo Janssen
Date   : 2024-03-16
Version: 0.6
History: 2024-07-03 Complete update and breaking rewrite to fix numerous bugs.
         Changed the structure of the tree array to accommodate numbers,
         strings and vectors


The resulting BST is an array of nodes where each node is an array of array for
the nodes value and the node's children.

BinarySearchTree[N]{

    node[2]{values[1]{value}, children[2]{left, right}},
    ...
    node{{value},{left, right}},
    node{{value},{left, right}},
    ...
}

By overriding some declared values and macros the node value can be numbers,
strings or vectors. The indices are integers. Overriding values has to be done
before the include file is used. Mixing multiple trees of multiple types in a
scene will get messy, unless everything is nicely sequential.
To see the demos at the end of this file, run this bst.inc file as is.

*/

//cmd: -d -p  -f +wt0
#version 3.7;
#ifndef( BST_Inc_Temp)
#declare BST_Inc_Temp = version;


/*: _Sentinel & _ValSentinel

These are the default values in the arrays. One can override _ValSentinel in the
scene file.
For string values use: #declare _ValSentinel = "";
For vectors values use: #declare _ValSentinel = <-999999, -999999, -999999>;
When using strings or vectors, one also has to override IsEqual(), Comp() and
DebugNode() macros.
Mixing multiple trees of multiple types in a scene will get messy, unless
everyting is nicely sequential.

If _Sentinel collides with the scene data it can also be overriden, it has to be
an integer.
*/
#declare _Sentinel = -999999;
#declare _ValSentinel = -999999;


#macro IsEqualNum(A,B)
/*: IsEqualNum(A,B)

Checks whether numbers A and B are identical/equal.

Result: true or false
*/
  #local Return = false;
  #if(A = B)
    #local Return = true;
  #end
  Return
#end


#macro IsEqualStr(A,B)
/*: IsEqualSrr(A,B)

Checks whether strings A and B are identical/equal.

Result: true or false
*/
  #local Return = false;
  #if(A = B)
    #local Return = true;
  #end
  Return
#end

#macro IsEqualVec(A,B)
/*: IsEqualVec(A,B)

Checks whether vectors A and B are identical/equal.
This works for all vectors and colours are they are promoted to 5d.

Result: true or false
*/
  #local Return = false;
  #local vA = <0,0,0,0,0> + A;
  #local vB = <0,0,0,0,0> + B;
  #if(vA.x = vB.x & vA.y = vB.y & vA.z = vB.z & vA.filter = vB.filter & vA.t =
vB.t)
    #local Return = true;
  #end
  Return
#end


#macro IsEqual(A,B)
/*: IsEqual(A,B)

Checks whether vectors A and B are identical/equal.
The macro inside of IsEqual defines what 'types' are compared, the default is
numeric.
For a different comparison override the macro in your scene file and use
IsEqualVec,
isEqualStr inside it, or one of your own making.

Result: true or false
*/
  IsEqualNum(A,B)
#end


#macro NumComp(A, B)
/*: NumComp(A, B)
A macro to compare two numeric values.

When A<B the result = -1,
when equal: 0 and when
A>B the result is 1.
*/
  #local Return = 0;
  #if (A < B)
    #local Return = -1;
  #elseif(A > B)
    #local Return = 1;
  #end
  Return
#end


#macro StrComp(A, B)
/*: StrComp(A, B)
A macro to compare two strings.

When A<B the result = -1,
when equal: 0
and when A>B the result is 1.
*/
  #local Return = 0;
  #if (A < B)
    #local Return = -1;
  #elseif(A > B)
    #local Return = 1;
  #end
  Return
#end


#macro VecComp(A, B)
/*: VecLenComp(A, B)
A macro to compare the length of two vectors.

When the vector are identical: 0
When A=<B the result = -1,
and when A>B the result is 1.
*/
  #if(IsEqualVec(A,B))
    #local Return = 0;
  #else
    #local vA = vlength(<0,0,0> + A);
    #local vB = vlength(<0,0,0> + B);
    #if (vA <= vB)
      #local Return = -1;
    #elseif(vA > vB)
      #local Return = 1;
    #end
  #end
  Return
#end


#macro VecGrayComp(A, B)
/*: VecGrayComp(A, B)
A macro to compare the gray value of two colours.

When A<B the result = -1,
when equal: 0
and when A>B the result is 1.
*/
  #local gA = A.gray;
  #local gB = B.gray;
  #local Return = 0;
  #if (gA < gB)
    #local Return = -1;
  #elseif(gA > gB)
    #local Return = 1;
  #end
  Return
#end


#macro Comp(A, B)
/*: Comp(A,B)

A macro to compare two values.
When A<B the result = -1,
when equal: 0
and when A>B the result is 1.

The macro inside of Comp defines what 'types' are compared, the default is
numeric.
For a different comparison override the macro in your scene file and use
VecLenComp
inside it for example, or one of your own.
*/
  NumComp(A,B)
#end


// Node enum
#declare _nodeValues = 0;
#declare _nodeChildren = 1;

#declare _nodeVal = 0;

#declare _nodeLeft = 0;
#declare _nodeRight = 1;


#macro bstGetNode(BST, NodeIdx)
/*: bstGetNode(BST, NodeIdx)

Gets the node at the NodeIdx index from the BST search tree.
It returns a node array:

node = array[2]{
  array[1]{SomeValue},
  array[2]{IndexLeftSide, IndexRightChild}
};

*/
  BST[NodeIdx]
#end


/*: NodeVal(Node), NodeLeft(Node), NodeRight(Node)

These macros get the value, left child index (int) and right child index (int)
from
a node as extracted by bstGetNode(BST, NodeIdx). The _ValSentinel, or_Sentinel
value
will be returned if undefined.
*/
#macro NodeVal(Node)   Node[_nodeValues][_nodeVal] #end
#macro NodeLeft(Node)  Node[_nodeChildren][_nodeLeft] #end
#macro NodeRight(Node) Node[_nodeChildren][_nodeRight] #end


/*: bstNodeVal(Node), bstNodeLeft(Node), bstNodeRight(Node)

These macros get the value, left child index (int) and right child index (int)
from
a node in the BST search tree. The _ValSentinel, or_Sentinel value
will be returned if undefined
*/
#macro bstNodeVal(BST, NodeIdx)   BST[NodeIdx][_nodeValues][_nodeVal] #end
#macro bstNodeLeft(BST, NodeIdx)  BST[NodeIdx][_nodeChildren][_nodeLeft] #end
#macro bstNodeRight(BST, NodeIdx) BST[NodeIdx][_nodeChildren][_nodeRight] #end


/* for internal use to set data in the tree */
#macro _bstNodeSet(BST, NodeIdx, Node)      #local BST[NodeIdx] = Node; #end
#macro _bstNodeSetVal(BST, NodeIdx, Val)    #local
BST[NodeIdx][_nodeValues][_nodeVal] = Val; #end
#macro _bstNodeSetLeft(BST, NodeIdx, lIdx)  #local
BST[NodeIdx][_nodeChildren][_nodeLeft] = lIdx; #end
#macro _bstNodeSetRight(BST, NodeIdx, rIdx) #local
BST[NodeIdx][_nodeChildren][_nodeRight] = rIdx; #end


/*:  _nodeDefined(Node), _nodeDefinedVal(Node), _nodeDefinedLeft(Node),
_nodeDefinedRight(Node)

These macro's check whether the node or its parts are defined. They return
'true' or 'false'.

Use:
#local IsNode = DefineNode(bstGetNode(BST, NodeIdx))
or
#local NodeHasValue = DefinedNodeVal(YourBST[NodeIdx])
*/
#macro _nodeDefined(Node)
  #local Return = true;
  #if(//Node[_nodeValues][_nodeVal] = _ValSentinel &
      IsEqual(Node[_nodeValues][_nodeVal], _ValSentinel) &
      Node[_nodeChildren][_nodeLeft] = _Sentinel &
      Node[_nodeChildren][_nodeRight] = _Sentinel
  )
    #local Return = false;
  #end
  Return
#end


#macro _nodeDefinedVal(Node)
  #local Return = true;
  #if (IsEqual(Node[_nodeValues][_nodeVal], _ValSentinel) )
    #local Return = false;
  #end
  Return
#end


#macro _nodeDefinedLeft(Node)
  #local Return = true;
  #if (Node[_nodeChildren][_nodeLeft] = _Sentinel )
    #local Return = false;
  #end
  Return
#end


#macro _nodeDefinedRight(Node)
  #local Return = true;
  #if (Node[_nodeChildren][_nodeRight] = _Sentinel )
    #local Return = false;
  #end
  Return
#end


#macro NodeInit()
/*: NodeInit()

Initializes an 'empty' node with sentinels.
*/
  array[2]{
    array[1]{_ValSentinel},
    array[2]{_Sentinel, _Sentinel}
  }
#end


#macro BSTinit(MaxNodes)
/*: BSTinit(MaxNodes)

Creates an array for a Binary Search Tree.

Parameters:
  MaxNodes (int): maximum number of nodes the tree can contain.

Result:
  Returns an array of node arrays
  array[MaxNodes]{node, node, ...};

  array{array{array{value}, array{indices}}}

*/
  #local BST = array[MaxNodes];
  #for(NodeIdx, 0, MaxNodes-1)
    _bstNodeSet(BST, NodeIdx, NodeInit())
  #end
  BST
#end


/*: NodeDebugNum(Node), NodeDebugStr(Node),
   NodeDebugVec2(Node), NodeDebugVec3(Node)

Helper macros for formatting the output of various types of nodes
to the debugging stream. They can be used directly or are used through the
NodeDebug() or BSTDebug() macro.
*/
#macro NodeDebugNum(Node)
  #debug concat("[Value : ", str(NodeVal(Node), 14, -1))
  #debug ",  "
  #debug concat("Left : ", str(NodeLeft(Node), 7, 0))
  #debug ",  "
  #debug concat("Right : ", str(NodeRight(Node), 7, 0))
  #debug "]"
#end

#macro NodeDebugStr(Node)
  #debug concat("[Value : ", NodeVal(Node))
  #debug ",  "
  #debug concat("Left : ", str(NodeLeft(Node), 7, 0))
  #debug ",  "
  #debug concat("Right : ", str(NodeRight(Node), 7, 0))
  #debug "]"
#end

#macro NodeDebugVec2(Node)
  #debug concat("[Value : <", vstr(2,NodeVal(Node),", ", 14, -1))
  #debug ">,  "
  #debug concat("Left : ", str(NodeLeft(Node), 7, 0))
  #debug ",  "
  #debug concat("Right : ", str(NodeRight(Node), 7, 0))
  #debug "]"
#end

#macro NodeDebugVec3(Node)
  #debug concat("[Value : <", vstr(3,NodeVal(Node),", ", 14, -1))
  #debug ">,  "
  #debug concat("Left : ", str(NodeLeft(Node), 7, 0))
  #debug ",  "
  #debug concat("Right : ", str(NodeRight(Node), 7, 0))
  #debug "]"
#end


#macro NodeDebug(Node)
/*: NodeDebug(Node)

writes the nodes content to the debug stream.
By default it writes numerical nodes. For string or vector
nodes override NodeDbug in the scenefile. For example:
#macro NodeDebug(Node)
  NodeDebugVec3(Node)
#end

*/
  NodeDebugNum(Node)
#end


#macro BSTDebug(BST)
/*: BSTDebug(BST)

Writes the content of the BST to the debug stream. It depends on NodeDebug for
proper formatting.
*/
  #for(I, 0, dimension_size(BST, 1) - 1)
    #local Node = bstGetNode(BST, I);
    NodeDebug(Node)
    #debug concat("  NodeIdx : ", str(I, 3, 0), "\n")
  #end
  #debug"\n"
#end


#macro SearchEmptyNode(BST)
/*: SearchEmptyNode(BST)

Searches through the array of nodes for the first 'free' position to put a node.

output (int): a node index or the _Sentinel if the tree is full.
*/

  #local EmptyNode = false;
  #local NI = 0;
  #while (EmptyNode = false & NI < dimension_size(BST,1))
    #local Node = BST[NI];
    #local EmptyNode = !_nodeDefined(Node);
    #local NI = NI + 1;
  #end
  #if (EmptyNode = false)
    #local NI = _Sentinel;
  #end
  NI - 1
#end


#macro BSTheight(BST, NodeIdx)
/*: BSTheight(BST, NodeIdx)

Returns the height, the number of vertices from the root to the deepest node,
of the tree starting from the node NodeIdx.
*/
  #if(NodeIdx = _Sentinel)
    #local Return = -1;
  #else
    #local LeftHeight  = BSTheight(BST, bstNodeLeft(BST, NodeIdx));
    #local RightHeight = BSTheight(BST, bstNodeRight(BST, NodeIdx));
    #if(LeftHeight > RightHeight)
      #local Return = LeftHeight + 1;
    #else
      #local Return = RightHeight +1;
    #end
  #end
  Return
#end


#macro BSTinsert(BST, Value)
/*: BSTInsert(BST, Value)

Insert data in a free node in the BST and sets the 'pointer' (child index) to
itself in its parent.
*/
//#debug concat("Insert value: ", str(Value,0,0),"\n")
  #local FreeNode = SearchEmptyNode(BST);
  #if(FreeNode != _Sentinel)
    #local NodeIdx = 0;
    #local NodeAdded = false;
    #while(NodeAdded = false)
      //#debug concat("NodeIdx : ",str(NodeIdx,0,0),"\n")
      #if(!_nodeDefinedVal(BST[NodeIdx]))
        #local Case = 2;
      #else
      #local Case = Comp(Value, bstNodeVal(BST, NodeIdx));
      #end
      #switch(Case)
        #case(-1)

          #if(!_nodeDefinedLeft(BST[NodeIdx]))
            // Found an empty left child, insert the value here
            _bstNodeSetLeft(BST, NodeIdx, FreeNode)

[ remainder of message truncated in this digest view due to length ]

[ingo] Re: "bst.inc" A Binary Search Tree [676 days 15 hours and 13 minutes ago]

Fri, 7 Jun 2024 05:45:00 GMT

There's a bug in it :( Will take some time to fix. After deletions valid data
can be over written.

"ingo" <nomail@nomail> wrote:
> Run the file as is for some demo output.
>
> ingo
>
> ---%<------%<------%<---
> /*
> POV-Ray include file: bst.inc
>

[ingo] "mergesort.inc" sort data in arrays [677 days 3 hours and 53 minutes ago]

Thu, 6 Jun 2024 17:05:00 GMT

An include file for the relative spiffy merge sort. Run the file as is for some,
boring, demo output.


ingo


---%<------%<------%<---
/*
 POV-Ray 3.7 Scene File " mergesort.inc"
 author:  Ingo Janssen
 date:    2024-05-26

 Merge sort in two versions, one that returns a sorted array,
 one that results in a sorted index to the original array.
*/

#version 3.7;
//#global_settings{ assumed_gamma 1.0 }
//#default{ finish{ ambient 0.1 diffuse 0.9 }}


#macro MergeSort(ValArr)
  #local Len = dimension_size(ValArr, 1);
  #if (Len <= 1)
    #local Result = ValArr;
  #else
    #local Mid = div(Len, 2);

    #local Left = array[Mid]
    #local I = 0;
    #for(J, 0, Mid - 1)
      #local Left[I] = ValArr[J];
      #local I = I + 1;
    #end

    #local Right = array[Len - Mid]
    #local I = 0;
      #for(J, Mid, Len - 1)
      #local Right[I] = ValArr[J];
      #local I = I + 1;
    #end

    #local Left = MergeSort(Left);
    #local Right = MergeSort(Right);
    #local Result = array[Len];


    #local I = 0;
    #local J = 0;
    #local K = 0;

    #while (I < dimension_size(Left, 1) & J < dimension_size(Right, 1))
      #if (Left[I] < Right[J])
        #local Result[K] = Left[I];
        #local I = I + 1;
      #else
        #local Result[K] = Right[J];
        #local J = J + 1;
      #end
      #local K = K + 1;
    #end

    #local M = I;
    #while (M < dimension_size(Left, 1))
      #local Result[K] = Left[M];
      #local M = M + 1;
      #local K = K + 1;
    #end
    #local M = J;
    #while (M < dimension_size(Right, 1))
      #local Result[K] = Right[M];
      #local M = M + 1;
      #local K = K + 1;
    #end
  #end
  Result
#end


#macro MergeSortByIdx(ValArr, IdxArr)
  /*: MergeSortByIdx(ValArr, IdxArr)
  MergeSortByIdx results in an index array that points to the ValArr in an
ordered way.



  */
  #local Len = dimension_size(IdxArr, 1);
  #if (Len <= 1)
    #local Result = IdxArr;
  #else
    #local Mid = div(Len, 2);

    #local Left = array[Mid]
    #local I = 0;
    #for(J, 0, Mid - 1)
      #local Left[I] = IdxArr[J];
      #local I = I + 1;
    #end

    #local Right = array[Len - Mid]
    #local I = 0;
      #for(J, Mid, Len - 1)
      #local Right[I] = IdxArr[J];
      #local I = I + 1;
    #end

    #local Left = MergeSortByIdx(ValArr, Left);
    #local Right = MergeSortByIdx(ValArr, Right);
    #local Result = array[Len];


    #local I = 0;
    #local J = 0;
    #local K = 0;

    #while (I < dimension_size(Left, 1) & J < dimension_size(Right, 1))
      #if (ValArr[Left[I]] < ValArr[Right[J]])
        #local Result[K] = Left[I];
        #local I = I + 1;
      #else
        #local Result[K] = Right[J];
        #local J = J + 1;
      #end
      #local K = K + 1;
    #end

    #local M = I;
    #while (M < dimension_size(Left, 1))
        #local Result[K] = Left[M];
        #local M = M + 1;
        #local K = K + 1;
    #end

    #local M = J;
    #while (M < dimension_size(Right, 1))
        #local Result[K] = Right[M];
        #local M = M + 1;
        #local K = K + 1;
    #end
  #end
  Result
#end


#if(input_file_name="mergesort.inc")

  #declare StrVals = array[16] {"4", "3", "2", "2", "2", "4", "5", "1", "9",
"7", "7", "5", "6", "1", "8", "9"};
  #declare Vals =    array[16] {4, 3, 2, 2, 2, 4, 5, 1, 9, 7,  7,  5,  6,  1,
8,  9};
  #declare ValsIdx = array[16] {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13,
14, 15};

  #declare OddStrVals = array[15] {"4", "3", "2", "2", "2", "4", "5", "1", "9",
"7", "7", "5", "6", "1", "8"};
  #declare OddVals =    array[15] {4, 3, 2, 2, 2, 4, 5, 1, 9, 7,  7,  5,  6,  1,
 8};
  #declare OddValsIdx = array[15] {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13,
14};

  #declare SortedVals = MergeSort(StrVals);
  #for(I,0, dimension_size(StrVals,1)-1)
    #debug concat(SortedVals[I],", ")
  #end
  #debug "\n"

  #declare SortedVals = MergeSort(Vals);
  #for(I,0, dimension_size(Vals,1)-1)
    #debug concat(str(SortedVals[I],0,0),", ")
  #end
  #debug "\n"

  #declare IdxSortedVals = MergeSortByIdx(Vals, ValsIdx);
  #for(I, 0, dimension_size(ValsIdx, 1) - 1)
      #debug concat(str(Vals[IdxSortedVals[I]], 0, 0), ", ")
  #end
  #debug "\n"


  #declare OddSortedVals = MergeSort(OddStrVals);
  #for(I,0, dimension_size(OddStrVals,1)-1)
    #debug concat(OddSortedVals[I],", ")
  #end
  #debug "\n"


  #declare OddSortedVals = MergeSort(OddVals);
  #for(I,0, dimension_size(OddVals,1)-1)
    #debug concat(str(OddSortedVals[I],0,0),", ")
  #end
  #debug "\n"

  #declare OddIdxSortedVals = MergeSortByIdx(OddVals, OddValsIdx);
  #for(I, 0, dimension_size(OddValsIdx, 1) - 1)
      #debug concat(str(OddVals[OddIdxSortedVals[I]], 0, 0), ", ")
  #end
  #debug "\n"

#end

---%<------%<------%<---

[ingo] "bst.inc" A Binary Search Tree [677 days 3 hours and 58 minutes ago]

Thu, 6 Jun 2024 17:00:00 GMT

Run the file as is for some demo output.

ingo

---%<------%<------%<---
/*
POV-Ray include file: bst.inc

Author : Ingo Janssen
Date   : 2024-03-16
Version: 0.5

A POV-Ray include file for a Binary Seach Tree (BST)
*/

#version 3.7;

#declare _Sentinel = -999999;

// Enums for BST struct
#declare _bstNodeVal = 0;
#declare _bstLeft    = 1;
#declare _bstRight   = 2;
#declare _bstSize    = 3;

#macro BSTDebug(BST)
  #for(I, 0, dimension_size(BST[_bstNodeVal], 1) - 1)
    #debug concat("Value : ",str(BSTree[_bstNodeVal][I], 14, -1), ",  ")
    #debug concat("Left  : ",str(BSTree[_bstLeft][I], 7, 0), ",  ")
    #debug concat("Right : ",str(BSTree[_bstRight][I], 7, 0), "\n")
  #end
  #debug"\n"
#end

#macro BSTInit(MaxNodes)
  /*InitBST(MaxNodes)
  Creates a "struct" for a Binar Search Tree.

  Parameters:
    MaxNodes (int): maximum nuber of nodes the tree can contain.

  Result:
    Returns an array of arrays
    array{
      array[MaxNodes]; // Value array
      array[MaxNodes]; // Left pointer array
      array[MaxNodes]; // Right pointer arra
      array[1];        // BST size, is updated during inserts
    };

  */
  #local BST = array[4];
  #local BST[_bstNodeVal] = array[MaxNodes]; // Value array
  #local BST[_bstLeft]    = array[MaxNodes]; // Left pointer array
  #local BST[_bstRight]   = array[MaxNodes]; // Right pointer array
  #local BST[_bstSize]    = array[1];

  #local BST[_bstSize][0] = 0;
  #for(I, 0, MaxNodes-1)
    #local BST[_bstNodeVal][I] = _Sentinel;
    #local BST[_bstLeft][I]    = _Sentinel;
    #local BST[_bstRight][I]   = _Sentinel;
  #end
  BST
#end


#macro BSTInsert(BST, Value)
  /*: BSTInsert(BST, Value)
  Insert data in the BST.
  */
  //#debug concat("\nBSTsize: ",str(BST[_bstSize][0],0,0), "\n\n")
  #if(BST[_bstSize][0] < dimension_size(BST[_bstNodeVal], 1))
    #local Node = 0;
    #local NodeAdded = false;
    #while(NodeAdded = false)
      #if(BST[_bstNodeVal][Node] = _Sentinel)

        // Found an empty node, insert the value here
        #local BST[_bstNodeVal][Node] = Value;
        #local BST[_bstSize][0] = BST[_bstSize][0] + 1;
        #local NodeAdded = true;

      #else

        #if(Value < BST[_bstNodeVal][Node])
          #if(BST[_bstLeft][Node] = _Sentinel)
            // Found an empty left child, insert the value here
            #local BST[_bstLeft][Node] = BST[_bstSize][0];
            #local BST[_bstNodeVal][BST[_bstSize][0]] = Value;
            #local BST[_bstSize][0] = BST[_bstSize][0] + 1;
            #local NodeAdded = true;
          #else
            // Traverse the left subtree
            #local Node = BST[_bstLeft][Node];
          #end

        #else

           #if(Value > BST[_bstNodeVal][Node])
            #if(BST[_bstRight][Node] = _Sentinel)
              // Found an empty right child, insert the value here
              #local BST[_bstRight][Node] = BST[_bstSize][0];
              #local BST[_bstNodeVal][BST[_bstSize][0]] = Value;
              #local BST[_bstSize][0] = BST[_bstSize][0] + 1;
              #local NodeAdded = true;
            #else
              // Traverse the right subtree
              #local Node = BST[_bstRight][Node];
            #end
          #else
            // Value already exists in the tree, do nothing
            #local NodeAdded = true;
          #end
        #end

      #end
    #end
  #else
    #error "Binary search tree is full"
  #end
#end


#macro BSTSearch(BST, Value)
  /*: BSTSearch(BST, Value)
  Finds the index the given value is at.
  Returns -1 if the value is not found in the BST.
  */
  #local Node = 0;
  #while(Node != _Sentinel)
    #if(Value < BST[_bstNodeVal][Node])
      #local Node = BST[_bstLeft][Node];
    #else
      #if(Value > BST[_bstNodeVal][Node])
        #local Node = BST[_bstRight][Node];
      #else
        // Value found in the tree
        #break
      #end
    #end
  #end
  Node
#end


#macro BSTMinVal(BST, Node)
  /*: BSTMinVal(BST, Node)

  Returns the minimum value in the tree, starting from Node.
  */
  #while(BST[_bstLeft][Node] != _Sentinel)
    #local Node = BST[_bstLeft][Node];
  #end
  BST[_bstNodeVal][Node]
#end

#macro BSTMinIdx(BST, Node)
  /*: BSTMinIdx(BST, Node)

  Returns the index of the minimum value in the tree, starting from Node.
  */
  #while(BST[_bstLeft][Node] != _Sentinel)
    #local Node = BST[_bstLeft][Node];
  #end
  Node
#end


#macro BSTiot(BST, Node)
  /*: BSTiot(BST, Node)

  BST In Order Traversal : Left - Root - Right pattern traversal of the tree,
  starting from Node

  Returns an array with values.
  */
  #macro _BSTIOTraverse(BST, Node, Traversed, I)
    #if(Node != _Sentinel)
      // Visit the left subtree
      _BSTIOTraverse(BST, BST[_bstLeft][Node], Traversed, I)
      // Visit the current node
      //#debug concat("Node : ", str(Node,0,0)," Value :
",str(BST[_bstNodeVal][Node], 0, 0), "\n")
      #local Traversed[I] = BST[_bstNodeVal][Node];
      #local I = I + 1;
      // Visit the right subtree
      _BSTIOTraverse(BST, BST[_bstRight][Node], Traversed, I)
    #end
  #end
  #local I = 0;
  #local Traversed = array[dimension_size(BST[_bstNodeVal],1)];
  _BSTIOTraverse(BST, Node, Traversed, I)
  Traversed
#end


#macro BSTpre(BST, Node)
  /*: BSTpre(BST, Node)
  BST Pre Order Traversal: Root - Left - Right pattern traversal of the tree,
  starting from Node

  Returns an array with values.
  */
  #macro _BSTpreTraverse(BST, Node, Traversed, I)
    #if(Node != _Sentinel)
      //#debug concat("Node : ", str(Node,0,0)," Value :
",str(BST[_bstNodeVal][Node], 0, 0), "\n")
      #local Traversed[I] = BST[_bstNodeVal][Node];
      #local I = I + 1;
      _BSTpreTraverse(BST, BST[_bstLeft][Node] , Traversed, I)
      _BSTpreTraverse(BST, BST[_bstRight][Node], Traversed, I)
    #end
  #end
  #local I = 0;
  #local Traversed = array[dimension_size(BST[_bstNodeVal],1)];
  _BSTpreTraverse(BST, Node, Traversed, I)
  Traversed
#end


#macro BSTpro(BST, Node)
  /*: BSTpost(BST, Node)
  BST Post Order Traversal: Left - Right - Root patern traversal of the tree,
  starting from Node.

  Returns an array with values.
  */
  #macro _BSTpostTraverse(BST, Node, Traversed, I)
    #if(Node != _Sentinel)
      _BSTpostTraverse(BST, BST[_bstLeft][Node] , Traversed, I)
      _BSTpostTraverse(BST, BST[_bstRight][Node], Traversed, I)
      //#debug concat("Node : ", str(Node,0,0)," Value :
",str(BST[_bstNodeVal][Node], 0, 0), "\n")
    #end
  #end
  #local I = 0;
  #local Traversed = array[dimension_size(BST[_bstNodeVal],1)];
  _BSTpostTraverse(BST, Node, Traversed, I)
  Traversed
#end


#macro BSTDelete(BST, Value)
  /*: BSTDelete(BST, Value)

  Deletes the given value from the BST.
  */

  #local Root = 0;
  #local NodeToDelete = BSTSearch(BST, Value);

  #if (NodeToDelete != _Sentinel)
    // Node found, proceed with deletion
    #local ParentOfNodeToDelete = _Sentinel;

    // Find the parent of the node to be deleted
    #while (Root != NodeToDelete)
      #if (Value < BST[_bstNodeVal][Root])
        #local ParentOfNodeToDelete = Root;
        #local Root = BST[_bstLeft][Root];
      #else
        #local ParentOfNodeToDelete = Root;
        #local Root = BST[_bstRight][Root];
      #end
    #end

    // Handle the case of a leaf node
    #if (BST[_bstLeft][NodeToDelete] = _Sentinel & BST[_bstRight][NodeToDelete]
= _Sentinel)
      #if (ParentOfNodeToDelete = _Sentinel)
        // Node to be deleted is the root node
        #local BST[_bstNodeVal][0] = _Sentinel;
        #local BST[_bstLeft][0] = _Sentinel;
        #local BST[_bstRight][0] = _Sentinel;
      #else
        #if (BST[_bstNodeVal][ParentOfNodeToDelete] > Value)
          #local BST[_bstLeft][ParentOfNodeToDelete] = _Sentinel;
        #else
          #local BST[_bstRight][ParentOfNodeToDelete] = _Sentinel;
        #end
      #end
    #end

    // Handle the case of a node with one child
    #if (BST[_bstLeft][NodeToDelete] != _Sentinel & BST[_bstRight][NodeToDelete]
= _Sentinel)
      #if (ParentOfNodeToDelete = _Sentinel)
        // Node to be deleted is the root node
        #local BST[_bstNodeVal][0] =
BST[_bstNodeVal][BST[_bstLeft][NodeToDelete]];
        #local BST[_bstLeft][0] = BST[_bstLeft][BST[_bstLeft][NodeToDelete]];
        #local BST[_bstRight][0] = BST[_bstRight][BST[_bstLeft][NodeToDelete]];
      #else
        #if (BST[_bstNodeVal][ParentOfNodeToDelete] > Value)
          #local BST[_bstLeft][ParentOfNodeToDelete] =
BST[_bstLeft][NodeToDelete];
        #else
          #local BST[_bstRight][ParentOfNodeToDelete] =
BST[_bstLeft][NodeToDelete];
        #end
      #end
    #elseif (BST[_bstLeft][NodeToDelete] = _Sentinel &
BST[_bstRight][NodeToDelete] != _Sentinel)
      #if (ParentOfNodeToDelete = _Sentinel)
        // Node to be deleted is the root node
        #local BST[_bstNodeVal][0] =
BST[_bstNodeVal][BST[_bstRight][NodeToDelete]];
        #local BST[_bstLeft][0] = BST[_bstLeft][BST[_bstRight][NodeToDelete]];
        #local BST[_bstRight][0] = BST[_bstRight][BST[_bstRight][NodeToDelete]];
      #else
        #if (BST[_bstNodeVal][ParentOfNodeToDelete] > Value)
          #local BST[_bstLeft][ParentOfNodeToDelete] =
BST[_bstRight][NodeToDelete];
        #else
          #local BST[_bstRight][ParentOfNodeToDelete] =
BST[_bstRight][NodeToDelete];
        #end
      #end
    #end

    // Handle the case of a node with two children
    #if (BST[_bstLeft][NodeToDelete] != _Sentinel & BST[_bstRight][NodeToDelete]
!= _Sentinel)
      // Find the in-order successor (smallest value in the right subtree)
      #local InOrderSuccessor = BSTMinIdx(BST, BST[_bstRight][NodeToDelete]);

      // Copy the value of the in-order successor to the node to be deleted
      #local BST[_bstNodeVal][NodeToDelete] =
BST[_bstNodeVal][InOrderSuccessor];

      // Delete the in-order successor node
      BSTDelete(BST, BST[_bstNodeVal][InOrderSuccessor]);
    #end

    // Decrement the size of the BST
    #local BST[_bstSize][0] = BST[_bstSize][0] - 1;

  #else
    // Node not found, do nothing
  #end
#end



//=====

#if(input_file_name="bst.inc")

#declare MAX_NODES = 15; // Maximum number of nodes in the tree
                         // for demo sake a bigger array then used is defined
#declare BSTree = BSTInit(MAX_NODES);

#declare ValArr = array[13]{3.33,432,90,pi,6,8,-1,34,9,0,13,12,23};
#for(I, 0, dimension_size(ValArr,1) - 1)
  BSTInsert(BSTree, ValArr[I])
  #debug concat("I : ", str(I, 1, 1), "\n")
  BSTDebug(BSTree)
#end
#debug "\n"


#declare SearchVal = 90;
#declare IsNode = BSTSearch(BSTree, SearchVal);
#debug concat("Searched value ",str(SearchVal,7,-1) ," is at index ",
str(IsNode, 0, 0),"\n\n")


#debug concat("The MinVal is ", str(BSTMinVal(BSTree, 5),7,-1)," and is at index
", str(BSTMinIdx(BSTree, 5),0,0),"\n\n")


#declare InOrderVals = BSTiot(BSTree, 0);
#debug "BSTiot : "
#for(I, 0, dimension_size(InOrderVals,1) - 1)
  #if(defined(InOrderVals[I]))  // because one can define a bigger array than is
actually used.
    #debug concat(str(InOrderVals[I],7,-1), ", ")
  #end
#end
#debug "\n\n"


#declare PreOrderVals = BSTpre(BSTree, 0);
#debug "BSTpre : "
#for(I, 0, dimension_size(PreOrderVals,1) - 1)
  #if(defined(PreOrderVals[I]))
    #debug concat(str(PreOrderVals[I],7,-1), ", ")
  #end
#end
#debug "\n\n"


#declare PostOrderVals = BSTpre(BSTree, 0);
#debug "BSTpost: "
#for(I, 0, dimension_size(PostOrderVals,1) - 1)
  #if(defined(PostOrderVals[I]))
    #debug concat(str(PostOrderVals[I],7,-1), ", ")
  #end
#end
#debug "\n\n"


BSTDelete(BSTree, 12)
#declare InOrderVals = BSTiot(BSTree, 0);
#debug "BSTiot : "
#for(I, 0, dimension_size(InOrderVals,1) - 1)
  #if(defined(InOrderVals[I]))  // because one can define a bigger array than is
actually used.
    #debug concat(str(InOrderVals[I],7,-1), ", ")
  #end
#end
#debug "\n\n"

BSTDebug(BSTree)


#debug "\n"
#end // if inc..
---%<------%<------%<---

[yesbird] Re: view_materials.zip [730 days 23 hours and 58 minutes ago]

Sat, 13 Apr 2024 20:59:54 GMT

On 01/06/2023 06:56, Mike Miller wrote:
> - Material library and material sample viewer. Includes a simple utility that
> reads a material list and generates a formatted POV scene for the viewer.
> Info.txt has additional information for creating and using.
> - I'm sure something like this has been done. I wrote this to help organize a
> growing material count and for building, comparing, and tweaking.
> Mike.

While playing with them I found that in file 'samples_default.pov'
there is duplicated index '603' which masks beautiful 'M_ground_sky' )).
-----------------------------------------------------
#declare mat_array [603][0] = "M_ground_sky" ;
#declare mat_array [603][1] = M_ground_sky ;

#declare mat_array [603][0] = "M_ground_sky_chrome" ;
#declare mat_array [603][1] = M_ground_sky_chrome ;
-----------------------------------------------------
--
YB

[yesbird] Re: view_materials.zip [731 days 1 hour and 45 minutes ago]

Sat, 13 Apr 2024 19:13:42 GMT

On 01/06/2023 06:56, Mike Miller wrote:
> - Material library and material sample viewer. Includes a simple utility that
> reads a material list and generates a formatted POV scene for the viewer.
> Info.txt has additional information for creating and using.
> - I'm sure something like this has been done. I wrote this to help organize a
> growing material count and for building, comparing, and tweaking.
> Mike.

Hi, Mike.
Thank you very much for sharing this viewer ! This is exactly what I
was looking for and tried to implement somehow, but your variant is much
more complete and useful.
Now I've included it in my laboratory sketchbook:
https://povlab.online/?scene=materials/samples_default.pov

Maybe I will break it into a few parts for better performance...
--
YB

[yesbird] Re: view_materials.zip [731 days 1 hour and 49 minutes ago]

Sat, 13 Apr 2024 19:08:52 GMT

On 01/06/2023 06:56, Mike Miller wrote:
> - Material library and material sample viewer. Includes a simple utility that
> reads a material list and generates a formatted POV scene for the viewer.
> Info.txt has additional information for creating and using.
> - I'm sure something like this has been done. I wrote this to help organize a
> growing material count and for building, comparing, and tweaking.
> Mike.

Hi, Mike !
Thank you very much for sharing this viewer - this is exactly what I
was looking for and tried to implement somehow, but your variant is much
more complete and useful.
Now I've included it in my sketchbook:
https://povlab.online/?scene=materials/samples_default.pov

Maybe I will break it into a few parts for better performance...
--
YB

[yesbird] Re: view_materials.zip [731 days 1 hour and 52 minutes ago]

Sat, 13 Apr 2024 19:06:20 GMT

On 01/06/2023 06:56, Mike Miller wrote:
> - Material library and material sample viewer. Includes a simple utility that
> reads a material list and generates a formatted POV scene for the viewer.
> Info.txt has additional information for creating and using.
> - I'm sure something like this has been done. I wrote this to help organize a
> growing material count and for building, comparing, and tweaking.
> Mike.

Hi, Mike !
Thank you very much for sharing this viewer - this is exactly what I
was looking for and tried to implement somehow, but your variant is much
more complete and useful.
Now I've included it in my sketchbook:
https://povlab.online/?scene=materials/samples_default.pov

Maybe I will break it into a few parts for better performance...
--
YB

[yesbird] Re: view_materials.zip [731 days 1 hour and 53 minutes ago]

Sat, 13 Apr 2024 19:05:41 GMT

On 01/06/2023 06:56, Mike Miller wrote:
> - Material library and material sample viewer. Includes a simple utility that
> reads a material list and generates a formatted POV scene for the viewer.
> Info.txt has additional information for creating and using.
> - I'm sure something like this has been done. I wrote this to help organize a
> growing material count and for building, comparing, and tweaking.
> Mike.

Hi, Mike !
Thank you very much for sharing this viewer - this is exactly what I
was looking for and tried to implement somehow, but your variant is much
more complete and useful.
Now I've included it in my sketchbook:
https://povlab.online/?scene=materials/samples_default.pov

Maybe I will break it into a few parts for better performance...
--
YB

[yesbird] Re: view_materials.zip [731 days 1 hour and 55 minutes ago]

Sat, 13 Apr 2024 19:03:18 GMT

On 01/06/2023 06:56, Mike Miller wrote:
> - Material library and material sample viewer. Includes a simple utility that
> reads a material list and generates a formatted POV scene for the viewer.
> Info.txt has additional information for creating and using.
> - I'm sure something like this has been done. I wrote this to help organize a
> growing material count and for building, comparing, and tweaking.
> Mike.

Hi, Mike.
Thank you very much for sharing this viewer ! This is exactly what I
was looking for and tried to implement somehow, but your variant is much
more complete and useful.
Now I've included it in my sketchbook:
https://povlab.online/?scene=materials/samples_default.pov

Maybe I will break it into a few parts for better performance...
--
YB

[Kenneth] Re: Source code for "Towards Tek's Isosurface Ci... [823 days 1 hour and 58 minutes ago]

Fri, 12 Jan 2024 19:00:00 GMT

Alain Martel <kua### [at] videotronca> wrote:
> Le 2024-01-08 à 14:21, Kenneth a écrit :
> >
> > I added a missing line to your camera--
> >               right x*image_width/image_height
> >
> If you use version 3.8, that line is not needed as the right vector
> default is x*image_width/image_height

Ah yes, I see that now.

However, Tor Olav's scene file has #version 3.7 in the header. If I run it as-is
in v3.8 beta 1, at (for example)  +w200  +h700, the render is distorted. If I
change his scene to #version 3.8, the render looks normal. That's what confused
me. So, by using #version 3.7 in the scene, it 'back-tracks' to the previous
behavior-- requiring the camera's   right x*image_width/image_height  to be
explicitly stated.

[Alain Martel] Re: Source code for "Towards Tek's Isosurface Ci... [825 days and 37 minutes ago]

Wed, 10 Jan 2024 20:20:50 GMT

Le 2024-01-08 Ã  14:21, Kenneth a Ã©critÂ :
> Thanks for posting this, especially the interesting code for the window
> textures!
> 
> I added a missing line to your camera--
>               right x*image_width/image_height
> 
If you use version 3.8, that line is not needed as the right vector 
default is x*image_width/image_height

[Kenneth] Re: Source code for "Towards Tek's Isosurface Ci... [827 days 1 hour and 33 minutes ago]

Mon, 8 Jan 2024 19:25:00 GMT

Thanks for posting this, especially the interesting code for the window
textures!

I added a missing line to your camera--
             right x*image_width/image_height

Without it, the render will look distorted unless it is run at a 'default' 4X3
ratio.

I noticed that your window textures show a slight 'discontinuity', which I'm
sure you noticed too.  Today, I came across yet another interesting post, by Sam
Benge in 2008. In it, he and TEK discuss crackle patterns and function code
relating to TEK's crackle-city and its windows. (This was prior to TEK's later
image post of his completed city, with the nicely-applied windows he eventually
came up with.) The code there looks like a modification of your own windows
function. I don't yet understand how it really works, but I thought it would be
of interest to you. Unfortunately, TEK never posted his finished and modified(?)
window code, as far as I can tell. :-(

https://news.povray.org/povray.binaries.images/thread/%3C488e5300%40news.povray.org%3E/?mtop=280940

[Tor Olav Kristensen] Source code for "Towards Tek's Isosurface City" [827 days 20 hours and 28 minutes ago]

Mon, 8 Jan 2024 00:30:00 GMT

The attached scene file contains the source code for my "Towards Tek's
Isosurface City" image.

Relevant threads:

From: Tor Olav Kristensen
Subject: Towards Tek's Isosurface City
Date: 2023-12-27 22:50:00
http://news.povray.org/povray.binaries.images/thread/%3Cweb.658cef0e2f5f1a9e2ba5690489db30a9%40news.povray.org%3E/

From: Tek
Subject: Isosurface City revistied (WIP-maybe)
Date: 2008-03-25 19:24:01
https://news.povray.org/povray.binaries.images/thread/%3C47e997a1%40news.povray.org%3E/

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[jr] Re: Filed() macro for CSV data file handling [830 days 7 hours and 18 minutes ago]

Fri, 5 Jan 2024 13:40:00 GMT

hi,

'filed.inc' has been updated with a new '.Verbatim' key, inspired by the recent
"animation display window does not reset" thread.  example use below.

<https://drive.google.com/file/d/10pGH0yi_-8aBTQvTwQPB4AdfRl9JsTGg/view?usp=sharing>


enjoy, jr.

-----<snip>-----
#version 3.8;

global_settings {assumed_gamma 1}
box {0,1}

#declare fild_workingDir = "/tmp/";

#include "filed.inc"

#declare D = dictionary {
  .File     : "bash1.sh",
  .Access   : "write",
  .Fields   : array [1] {"S"},
  .Data     : array [3] {
                "echo \\\"new feature\\\" '.Verbatim' key,",
                "echo *thanks* JB :').'\necho $(date)",
                "ls --hide=systemd* ; echo"
              },
  .Strict   : false,
  .Verbatim : true,
  .Verbose  : true
};

Filed(D)

[Paolo Gibellini] X-mas snail shell [848 days 20 hours and 9 minutes ago]

Mon, 18 Dec 2023 00:48:55 GMT

Source of example in p.general.

Paolo

[Samuel B ] Re: Ridged Multifractal Planet [880 days 19 hours and 18 minutes ago]

Thu, 16 Nov 2023 01:40:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 24-10-2023 om 12:22 schreef Khelito:
> > That's nice !
> > I saw a lot of things I did't understand at first
> >
> > I did not know about f_ridged_mf
> >
> > I kinda wish you added oceans. But then you may need to use iso surfaces, no ?
> >
> > Or just a clipping in low f_ridged_mf value ?
> >
>
> Edit the texture map... and presto! :-)
>
> --
> Thomas

Looks pretty good, Thomas! If we keep pumping plant food into our atmosphere,
maybe we'll have one as green as it someday ;)

Sam

[Samuel B ] Re: Ridged Multifractal Planet [880 days 19 hours and 18 minutes ago]

Thu, 16 Nov 2023 01:40:00 GMT

"Khelito" <nomail@nomail> wrote:
> That's nice !
> I saw a lot of things I did't understand at first
>
> I did not know about f_ridged_mf
>
> I kinda wish you added oceans. But then you may need to use iso surfaces, no ?
>
> Or just a clipping in low f_ridged_mf value ?

Thanks, Khelito. No need for isosurfaces, as a lot can be done with surface
stuff as Thomas demonstrated.

Sam

[Mike Miller] POV scene file - 6 simple plants [885 days 16 hours and 53 minutes ago]

Sat, 11 Nov 2023 04:05:01 GMT

POV scene file with 6 plants. Plants use billboards of smooth triangles. Stems
are cubic spline sweeps. Very simple - renders fast. Working of some flowers
that use this same setup. The grass patch uses a random rotation seed and a mix
of 3 blade type. Can be easily tweaked for different variations and heights.
Miller

[Mike Miller] radiosity_material_study.zip [886 days 23 hours and 58 minutes ago]

Thu, 9 Nov 2023 21:00:01 GMT

radiosity / material study scene file. A simple room interior with many
variables to test radiosity lighting using a combination of emissive materials
and area lighting. There's a mix a standard and image mapped materials to test
with the lights. I'll post an image of some renderings using this file. I used a
photo for reference to model the space and may try to model in the furniture to
get a complete scene.
Miller

[William F Pokorny] Re: Pursuit curve (was Rainy Sunday afternoon) [890 days 5 hours and 22 minutes ago]

Mon, 6 Nov 2023 15:36:29 GMT

On 11/4/23 04:19, kurtz le pirate wrote:
> ok. if one day you need something, don't hesitate ðŸ˜‰

Thank you for the offer! :-)

Bill P.

[kurtz le pirate] Re: Pursuit curve (was Rainy Sunday afternoon) [892 days 12 hours and 38 minutes ago]

Sat, 4 Nov 2023 08:19:56 GMT

On 03/11/2023 12:59, William F Pokorny wrote:
> On 11/2/23 11:40, kurtz le pirate wrote:
>> I can code other colors conversion method found on
>> <https://www.rapidtables.com/convert/color/index.html>
>> Tell me if it's worth it...
> 
> Thanks for the offer, but my up front answer is hold off for now - 
> unless doing it for your own interests.
> 
> I'm unsure of the overall worth without diving into what is there. My 
> todo list is effectively infinite - and the extended include file work 
> will likely not see much attention for a while.
> 
> That said. When we do get to a color manipulation include, we'd want to 
> look in more detail at the code we have long had versus any new. What we 
> have I believe works. However, the immediately attractive aspect of your 
> hsb2rgb() code is it's cleaner than CHSV2RGB(). No pointless conversions 
> of individual parameters into a vector only to peel the vector apart 
> again inside the CHSV2RGB() macro for a start.
> 
> Are the other conversion methods on that site also cleaner than what 
> we've long had coded? Some like the hex color inputs would be useful 
> just to have, but the end code there should probably be a parser inbuilt 
> - maybe some extension of the 'srgb*' specification methods?
> 
> Bill P.
> 
> 

ok. if one day you need something, don't hesitate ;)



-- 
Kurtz le pirate
Compagnie de la Banquise

[William F Pokorny] Re: Pursuit curve (was Rainy Sunday afternoon) [893 days 8 hours and 59 minutes ago]

Fri, 3 Nov 2023 11:59:03 GMT

On 11/2/23 11:40, kurtz le pirate wrote:
> I can code other colors conversion method found on
> <https://www.rapidtables.com/convert/color/index.html>
> Tell me if it's worth it...

Thanks for the offer, but my up front answer is hold off for now - 
unless doing it for your own interests.

I'm unsure of the overall worth without diving into what is there. My 
todo list is effectively infinite - and the extended include file work 
will likely not see much attention for a while.

That said. When we do get to a color manipulation include, we'd want to 
look in more detail at the code we have long had versus any new. What we 
have I believe works. However, the immediately attractive aspect of your 
hsb2rgb() code is it's cleaner than CHSV2RGB(). No pointless conversions 
of individual parameters into a vector only to peel the vector apart 
again inside the CHSV2RGB() macro for a start.

Are the other conversion methods on that site also cleaner than what 
we've long had coded? Some like the hex color inputs would be useful 
just to have, but the end code there should probably be a parser inbuilt 
- maybe some extension of the 'srgb*' specification methods?

Bill P.

[kurtz le pirate] Re: Pursuit curve (was Rainy Sunday afternoon) [894 days 5 hours and 18 minutes ago]

Thu, 2 Nov 2023 15:40:09 GMT

On 02/11/2023 12:33, William F Pokorny wrote:
> On 11/2/23 02:40, kurtz le pirate wrote:
>> Last remark. To reduce the hue between 0 and 360, I use my "mod2"
>> function, which ALWAYS returns a positive value.
>>
>> #declare mod2 = function (x,y) { select(mod(x,y),mod(x,y)+y,mod(x,y)) }
>>
>> Too many troubles with the standard mod() function ...
> 
> Thanks! I've made your updates and done a couple, hsb2rgb vs CHSV2RGB, 
> image compares. I too see the results matching perfectly.
> 
> Your mod2 function is a good candidate to make an inbuilt parser 
> function. I've already implemented an inbuilt function in my fork called 
> f_npmod which matches the internal pattern mechanism's version of:
> 
> [0, n] = {x | 0 <= x <= n}  (n == 1 always inside the pattern mechanism)
> 
> rather than mod's usual:
> 
> [0, n) = {x | 0 <= x < n}
> 
> and there is perhaps a place for a fourth form I suppose which would 
> functionally be a combination of both mod2 and f_npmod.
> 
> The color manipulation macros like hsb2rgb() - traditionally in 
> colors.inc - I see as better existing in an include called 
> color_manipulations.inc (or similar) apart from any general color 
> definitions.
> 
> The color_manipulations.inc then being a part of a separately maintained 
> 'extended includes' package for my yuqk fork. Who knows though, if I'll 
> ever get around to maintaining and shipping such a package.
> 
> Still, I've been capturing SDL code I think would be good as part of 
> such a package though - and your implementation of hsb2rgb saved aside 
> for that eventual purpose.
> 
> Bill P.
> 

Yes, a "color_manipulations.inc" is a very good idea.
You can use my code as you like.

I can code other colors conversion method found on
<https://www.rapidtables.com/convert/color/index.html>
Tell me if it's worth it...




-- 
Kurtz le pirate
Compagnie de la Banquise

[William F Pokorny] Re: Pursuit curve (was Rainy Sunday afternoon) [894 days 9 hours and 25 minutes ago]

Thu, 2 Nov 2023 11:33:09 GMT

On 11/2/23 02:40, kurtz le pirate wrote:
> Last remark. To reduce the hue between 0 and 360, I use my "mod2"
> function, which ALWAYS returns a positive value.
> 
> #declare mod2 = function (x,y) { select(mod(x,y),mod(x,y)+y,mod(x,y)) }
> 
> Too many troubles with the standard mod() function ...

Thanks! I've made your updates and done a couple, hsb2rgb vs CHSV2RGB, 
image compares. I too see the results matching perfectly.

Your mod2 function is a good candidate to make an inbuilt parser 
function. I've already implemented an inbuilt function in my fork called 
f_npmod which matches the internal pattern mechanism's version of:

[0, n] = {x | 0 <= x <= n}  (n == 1 always inside the pattern mechanism)

rather than mod's usual:

[0, n) = {x | 0 <= x < n}

and there is perhaps a place for a fourth form I suppose which would 
functionally be a combination of both mod2 and f_npmod.

The color manipulation macros like hsb2rgb() - traditionally in 
colors.inc - I see as better existing in an include called 
color_manipulations.inc (or similar) apart from any general color 
definitions.

The color_manipulations.inc then being a part of a separately maintained 
'extended includes' package for my yuqk fork. Who knows though, if I'll 
ever get around to maintaining and shipping such a package.

Still, I've been capturing SDL code I think would be good as part of 
such a package though - and your implementation of hsb2rgb saved aside 
for that eventual purpose.

Bill P.

[kurtz le pirate] Re: Pursuit curve (was Rainy Sunday afternoon) [894 days 14 hours and 17 minutes ago]

Thu, 2 Nov 2023 06:40:51 GMT

On 01/11/2023 12:08, William F Pokorny wrote:
> On 10/31/23 06:07, kurtz le pirate wrote:
>> The code is here.
> 
> Thank you!
> 
> FWIW. Because my yuqk fork playpen doesn't ship with a color.inc file, I 
> first tried using the macro you included, hsb2rgb(), over CHSV2RGB(). I 
> had to change the bottom part some for it to run.
> 
> ...
>           #elseif ( _Hue>=300 & _Hue<=360) // Was ( ... _Hue<360) ?
>                  #local RED = C;
>                  #local GREEN = 0;
>                  #local BLUE = X; // 'x' is a vector ?
>          #else
>                  #debug concat("_Hue is ",str(_Hue,9,3),"\n")
>                  #error "_Hue out of range in convertion ! "
>          #end
> 
>          <(RED+m), (GREEN+m), (BLUE+m), 0, _Transmit>
> #end
> 
> I ended up grabbing the older color.inc macros and using those because 
> the colors looked better - like what you had posted - than did the 
> hsb2rgb() results.
> 
> I'm not going to dig into why the difference at the moment as I have 
> many other fires burning low. I need to return to those before I forget 
> too much! :-)
> 
> Bill P.
> 


Thank Bill you for your very pertinent comments !


First of all, this "hsb2rgb()" macro was not supposed to be in the code.
It's not used because i'm using the "CHSV2RGB()" in the Draw() macro.


Then, there's my mistake "x" vs "X". I'm ashamed. Apologies.


In fact, the value of "_hue" must simply be reduced to the interval
[0..360[.

So at the beginning of the macro I added :
	#local HUE = mod2(_Hue,360);

and it's this variable that's used in everything else.


I made a little code that draws colored squares with both methods and
compared them in Photoshop. There's no difference in color.


And now the most important point. There's an error in the code. A big
error. (Yes, one more). The formula used for calculating X is wrong :
	#local X = C - (1 - abs(mod(HUE/60,2) - 1));

The good one is :
	#local X = C * (1 - abs(mod(HUE/60,2) - 1));

X = C **multiply by** ...



Last remark. To reduce the hue between 0 and 360, I use my "mod2"
function, which ALWAYS returns a positive value.

#declare mod2 = function (x,y) { select(mod(x,y),mod(x,y)+y,mod(x,y)) }

Too many troubles with the standard mod() function ...





;)


-- 
Kurtz le pirate
Compagnie de la Banquise

[kurtz le pirate] Re: Pursuit curve (was Rainy Sunday afternoon) [895 days 3 hours and 49 minutes ago]

Wed, 1 Nov 2023 17:09:00 GMT

On 01/11/2023 12:08, William F Pokorny wrote:
> On 10/31/23 06:07, kurtz le pirate wrote:
>> The code is here.
> 
> Thank you!
> 
> FWIW. Because my yuqk fork playpen doesn't ship with a color.inc file, I 
> first tried using the macro you included, hsb2rgb(), over CHSV2RGB(). I 
> had to change the bottom part some for it to run.
> 
> ...
>           #elseif ( _Hue>=300 & _Hue<=360) // Was ( ... _Hue<360) ?
>                  #local RED = C;
>                  #local GREEN = 0;
>                  #local BLUE = X; // 'x' is a vector ?
>          #else
>                  #debug concat("_Hue is ",str(_Hue,9,3),"\n")
>                  #error "_Hue out of range in convertion ! "
>          #end
> 
>          <(RED+m), (GREEN+m), (BLUE+m), 0, _Transmit>
> #end
> 
> I ended up grabbing the older color.inc macros and using those because 
> the colors looked better - like what you had posted - than did the 
> hsb2rgb() results.
> 
> I'm not going to dig into why the difference at the moment as I have 
> many other fires burning low. I need to return to those before I forget 
> too much! :-)
> 
> Bill P.
> 

Thank Bill you for your very pertinent comments !

First of all, this "hsb2rgb()" macro was not supposed to be in the code.
It's not used because i'm using the "CHSV2RGB()" in the Draw() macro.

Then, there's my mistake "x" vs "X". I'm ashamed. Apologies.

Now for another point. The correction "less than or equal to 360"
instead of "strictly lower to 360". I don't agree with that.

Let's say the hue is equal to 390Â°. With your modification, everything
above 360 becomes red, whereas 390 (which equals 360 + 30) should be
orange.

Do you agree ?

In fact, the value of "_hue" must simply be reduced to the interval
[0..360[.

So at the beginning of the macro I added :
	#local HUE = mod2(_Hue,360);

and it's this variable that's used in everything else.

I made a little code that draws colored squares with both methods and
compared them in Photoshop. There's no difference in color.

And now the most important point. There's an error in the code. A big
error. (Yes, one more). The formula used for calculating X is wrong :
	#local X = C - (1 - abs(mod(HUE/60,2) - 1));

The good one is :
	#local X = C * (1 - abs(mod(HUE/60,2) - 1));

X = C **multiply by** ...

Last remark. To reduce the hue between 0 and 360, I use my "mod2"
function, which ALWAYS returns a positive value.

#declare mod2 = function (x,y) { select(mod(x,y),mod(x,y)+y,mod(x,y)) }

Too many troubles with the standard mod() function ...

;)

-- 
Kurtz le pirate
Compagnie de la Banquise

[William F Pokorny] Re: Pursuit curve (was Rainy Sunday afternoon) [895 days 9 hours and 50 minutes ago]

Wed, 1 Nov 2023 11:08:08 GMT

On 10/31/23 06:07, kurtz le pirate wrote:
> The code is here.

Thank you!

FWIW. Because my yuqk fork playpen doesn't ship with a color.inc file, I 
first tried using the macro you included, hsb2rgb(), over CHSV2RGB(). I 
had to change the bottom part some for it to run.

...
          #elseif ( _Hue>=300 & _Hue<=360) // Was ( ... _Hue<360) ?
                 #local RED = C;
                 #local GREEN = 0;
                 #local BLUE = X; // 'x' is a vector ?
         #else
                 #debug concat("_Hue is ",str(_Hue,9,3),"\n")
                 #error "_Hue out of range in convertion ! "
         #end

         <(RED+m), (GREEN+m), (BLUE+m), 0, _Transmit>
#end

I ended up grabbing the older color.inc macros and using those because 
the colors looked better - like what you had posted - than did the 
hsb2rgb() results.

I'm not going to dig into why the difference at the moment as I have 
many other fires burning low. I need to return to those before I forget 
too much! :-)

Bill P.

[Alain Martel] Re: Pursuit curve (was Rainy Sunday afternoon) [896 days 8 hours and 53 minutes ago]

Tue, 31 Oct 2023 12:05:11 GMT

Le 2023-10-31 Ã  06:07, kurtz le pirate a Ã©critÂ :
> 
> 
> 
> The code is here.
> 
> 
Thank you

[kurtz le pirate] Pursuit curve (was Rainy Sunday afternoon) [896 days 10 hours and 51 minutes ago]

Tue, 31 Oct 2023 10:07:12 GMT

The code is here.


-- 
Kurtz le pirate
Compagnie de la Banquise

[Thomas de Groot] Re: Ridged Multifractal Planet [903 days 6 hours and 19 minutes ago]

Tue, 24 Oct 2023 14:39:39 GMT

Op 24-10-2023 om 12:22 schreef Khelito:
> That's nice !
> I saw a lot of things I did't understand at first
> 
> I did not know about f_ridged_mf
> 
> I kinda wish you added oceans. But then you may need to use iso surfaces, no ?
> 
> Or just a clipping in low f_ridged_mf value ?
> 

Edit the texture map... and presto! :-)

-- 
Thomas

[Khelito] Re: Ridged Multifractal Planet [903 days 10 hours and 33 minutes ago]

Tue, 24 Oct 2023 10:25:00 GMT

That's nice !
I saw a lot of things I did't understand at first

I did not know about f_ridged_mf

I kinda wish you added oceans. But then you may need to use iso surfaces, no ?

Or just a clipping in low f_ridged_mf value ?

[Samuel B ] Ridged Multifractal Planet [920 days and 58 minutes ago]

Sat, 7 Oct 2023 20:00:00 GMT

/*
 RidgedMFPlanetB.pov

 2023 Sam Benge

 Inspired by:

https://old.reddit.com/r/proceduralgeneration/comments/16y8rnz/the_wonderful_worlds_of_procedural_generation_100/

 Recommended command line options:
  +fn +f +a0.03 +am2 +r2 +w1920 +h1080

 Note: for some reason the cloud layer enhances the planet's surface normal, so
the
 planet's surface normal amount will need to be doubled when not rendering the
clouds.
*/

#version 3.7;

global_settings{ assumed_gamma 1.0 }

#default{ finish{ambient 0} }

#include "functions.inc"

camera{
 orthographic
 right x*1.77 up y
 //right x up y
 location <0, 0, -10>
 look_at <.15, .8, 0>
 angle 10
}

// sunlight
light_source{
 <1, .7, .5>*1e5, 2 * <2, 1.95, 1.9>
 #if(1)
  #declare ALRes = 2;
  #declare ALSize = .1 * 1e5;
  area_light x*ALSize, z*ALSize, ALRes, ALRes
  jitter
  adaptive 1
  area_illumination
 #end
}

// planet
#if(1)

 sphere{
  0, 1

  // first multifractal
  #local FRidged1 =
   function{
    pattern{
     function{
      f_ridged_mf(
       x, y, z,
       0.61, // H
       2.2, // Lacunarity
       15,  // Octaves
       0.42, // Offset
       90.0, // Gain
       2
      )
      }
      warp{turbulence .15 lambda 3}
     }
   }

  // second multifractal
  #local FRidged2 =
   function{
    pattern{
     function{
      f_ridged_mf(
       x, y, z,
       0.54, // H
       1.42, // Lacunarity
       15,  // Octaves
       0.3, // Offset
       100, // Gain
       2
      )
      }
      warp{turbulence .25 lambda 3 octaves 7}
      translate z*20
     }
   }

  // combine multifractals
  #local FRidged =
   function{
    min(
     FRidged1(x, y, z)
     + .02,

     #local Scale = 1;
     .03 + 1.44 * FRidged2(x*Scale, y*Scale, z*Scale)
    )
   }

  // planet texture
  texture{

   pigment{
     function{FRidged(x, y, z)}
     color_map{
      [0 rgb .025]
      [1 rgb <.8, .7, .5>]
     }
    }

    normal{
     function{FRidged(x, y, z)}
     .075/2
     accuracy .001/3
    }

    finish{diffuse 1}

    // adjustment
    scale .75
    translate 25*x

  }

  hollow
 }

#end // /planet

// clouds
#if(1)

 #local CloudHeight = 0.002;

 sphere{
  0, 1+CloudHeight

  // for cloud detail
  #local FGranite = function{pattern{granite scale .1}}

  // main clouds shape
  #local FRidged3 =
   function{
    pattern{
     function{
      max(
       0,
       min(
        1,
        f_ridged_mf(
         x, y, z,
         0.53, // H
         1.72, // Lacunarity
         15,  // Octaves
         -.16, // Offset
         15.0, // Gain
         2
        )
        - .3
       )
      )
      }
      scale 3
      warp{turbulence .5 lambda 1.5}
      scale 1
     }
   }

  // combine cloud shape with sine details
  #local FClouds =
   function{
    max(
     0,
     min(
      1,
      2 * FRidged3(x, y, z)
      - .5
      + .125*FGranite(x, y, z)
      + .25*FGranite(x*3, y*3, z*3)
     )
    )
   }

  // clouds texture
  texture{

   pigment{
     //function{FRidged3(x, y, z)}
     function{FClouds(x, y, z)}
     poly_wave 2
     color_map{
      [.2 rgbt 1]
      [1 rgb 1 transmit .65]
     }
    }

    normal{
     function{FRidged3(x, y, z)}
     .02
     accuracy .0025
    }

    finish{diffuse .6 brilliance .5}

    // adjustment
    translate 9*z
    scale .35
  }

  hollow
 }

#end // /clouds

// atmosphere
#if(1)

 #local SkyRGB     = <.2, .5, 1>;
 #local SkyThickness  = .007;
 #local SkyScattering = 30000;
 #local SkyAbsorption = 120000;

 sphere{
  0, 1+SkyThickness
  pigment{rgbt 1}
  interior{
   media{
    scattering{5, SkyRGB*SkyScattering}
    absorption SkyRGB*SkyAbsorption
    intervals 1
    samples 1, 1
    jitter .2
    density{
     spherical
     poly_wave 2
     scale 1+SkyThickness
    }
   }
  }
  hollow
 }

#end // /atmosphere

[jr] Re: robot_fish.zip [975 days 5 hours and 53 minutes ago]

Sun, 13 Aug 2023 15:05:00 GMT

hi,

"Mike Miller" <mil### [at] gmailcom> wrote:
> ...
> Below is the PB code. I also attached the .PB file
> good luck,
> Mike

thank you / cheers.


regards, jr.

[Mike Miller] Re: robot_fish.zip [975 days 22 hours and 13 minutes ago]

Sat, 12 Aug 2023 22:45:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Mike Miller" <mil### [at] gmailcom> wrote:
> > I'm using this file to model a robotic fish that will be
> > added to some sci-fi themed renderings.
>
> 250 years ago, some maniac made "robot" fish for an animated swan to eat.
>
> Truly incredible.
>
>
https://www.itv.com/news/tyne-tees/2021-10-06/conservation-experts-study-the-bowes-museums-18th-century-silver-swan

Wow..had not seen that. very cool!

[Bald Eagle] Re: robot_fish.zip [976 days 1 hour and 33 minutes ago]

Sat, 12 Aug 2023 19:25:00 GMT

"Mike Miller" <mil### [at] gmailcom> wrote:
> I'm using this file to model a robotic fish that will be
> added to some sci-fi themed renderings.

250 years ago, some maniac made "robot" fish for an animated swan to eat.

Truly incredible.

https://www.itv.com/news/tyne-tees/2021-10-06/conservation-experts-study-the-bowes-museums-18th-century-silver-swan

[Mike Miller] Re: robot_fish.zip [976 days 4 hours and 3 minutes ago]

Sat, 12 Aug 2023 16:55:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "Mike Miller" <mil### [at] gmailcom> wrote:
> > Scene file and .x3d to POV converter. ... x3d_blender_points.exe ...
>
> thanks, any chance of a different format (or source) ?  have no Microsoft OS.
>
>
> regards, jr.

I'm using PureBasic for this. ...I'm leaning on free programs.. haha
I did see Unix & Mac OS versions available. I'm using 64bit Windows 11.

I have another compile that parses most of the other Blender types (blobs,
cubes, cylinders, torus, etc.) if you can compile to your OS.

Below is the PB code. I also attached the .PB file
good luck,
Mike

; Read .x3d
; m.miller 3.20.23
; 8.8 revised to handle multiple POV types from the same pointData
; removed all other blender types

StandardFile$ = "C:\file.x3d"   ;
Pattern$ = "x3d (*.x3d)|*.x3d"
Pattern = 0  ; use the first of the three possible patterns
x3d_File$ = OpenFileRequester("open x3d file", StandardFile$, Pattern$, Pattern)
Path$ = GetPathPart(x3d_File$)
fileName$ = GetFilePart(x3d_File$)
fileName$ = Mid(fileName$, 1, Len(fileName$) -4)
exportFile$ = Path$ + fileName$ + ".inc"

objectCount = 0
pointDataCount = 0

arraySize = 5000
Dim aName$ (arraySize)
Dim aPosX$ (arraySize)
Dim aPosY$ (arraySize)
Dim aPosZ$ (arraySize)
Dim aPos_POV$ (arraySize)
Dim aScaleX$ (arraySize)
Dim aScaleY$ (arraySize)
Dim aScaleZ$ (arraySize)
Dim aScale_POV$ (arraySize)
Dim aRotX$ (arraySize)
Dim aRotY$ (arraySize)
Dim aRotZ$ (arraySize)
Dim aRot_POV$ (arraySize)

If x3d_File$
  File = ReadFile(#PB_Any, x3d_File$)
  While Eof(File) = 0
    search_1$ =   "Transform DEF="
    search_2$ =   "ifs"
    search_3$ =   "_TRANSFORM"
    quote$ =      Chr(34)      ; "
    space$ =      Chr(32)      ; space
    equal$ =      Chr(61)      ; =
    lineStr$ = ReadString(File, #PB_Ascii)
    p =   FindString(lineStr$, search_1$, 1)
    p2 =  FindString(lineStr$, search_2$, 1)
    p3 =  FindString(lineStr$, equal$, 1)
    ; find transform def without IndexedFaceSet
    If p > 0 And p2 = 0
      ;found object
      objectCount +1
      l = Len(lineStr$) - p
      s$ = Mid(lineStr$, p, l)
      ; find first quote
      q =  FindString(s$, quote$, 1)
      ; find _TRANSFORM
      t =  FindString(s$, "_TRANSFORM", 1)
      name$ = Mid(s$, q+1, (Len(s$) - q+1)-11)
      ; ----- find types
      If Mid(name$, 0, 9) = "pointData"
        pointDataCount+1
      EndIf


--------------------------------------------------------------------------------------
      ;  read TRANSLATION (position)
      ;
--------------------------------------------------------------------------------------
      temp$ = ReadString(File, #PB_Ascii)
      ; find first quote mark
      p =  FindString(temp$, quote$, 1)
      ; trim from quote mark
      trans$ = Mid(temp$,p+1,l)
      ; remove end quote mark
      trans$ = Mid(trans$, 0, Len(trans$) - 1)
      ; find first space
      p1 =  FindString(trans$, space$, 1)
      ; x data
      x$ = Mid(trans$, 0, p1)
      x$ = Left(x$, FindString(x$,".")+3)
      ; ---flip X   ?? .x3d exported as Z-forward Y-up outputs -X
      pN = FindString(x$, "-", 1)
      If ( pN > 0 )
        x$ = Right(x$, Len(x$) - 1)
      Else
        x$ = "-" + x$
      EndIf
      ; re-trim
      temp$ = Mid(trans$,p1+1)
      ;find second space
      p2 =  FindString(temp$, space$, 1)
      ; y data
      y$ = Mid(temp$, 0, p2)
      y$ = Left(y$, FindString(y$,".")+3)
      ; z data
      z$ = Mid(temp$, p2+1)
      z$ = Left(z$, FindString(z$,".")+3)
      aName$(objectCount) = name$
      aPosX$(objectCount) = x$
      aPosY$(objectCount) = y$
      aPosZ$(objectCount) = z$
      aPos_POV$(objectCount) = "<" + x$ + ", " +  y$ + ", "  + z$ + "> "

      ; ---------------------------------------------------------------
      ;  read SCALE
      ; ---------------------------------------------------------------
      temp$ = ReadString(File, #PB_Ascii)
      ; find first quote mark
      p =  FindString(temp$, quote$, 1)
      ; trim from quote mark
      trans$ = Mid(temp$,p+1,l)
      ; remove end quote mark
      trans$ = Mid(trans$, 0, Len(trans$) - 1)
      ; find first space
      p1 =  FindString(trans$, space$, 1)
      ; x data
      x$ = Mid(trans$, 0, p1)
      x$ = Left(x$, FindString(x$,".")+3)
      ; re-trim
      temp$ = Mid(trans$,p1+1)
      ;find second space
      p2 =  FindString(temp$, space$, 1)
      ; y data
      y$ = Mid(temp$, 0, p2)
      y$ = Left(y$, FindString(y$,".")+3)
      ; z data
      z$ = Mid(temp$, p2+1)
      z$ = Left(z$, FindString(z$,".")+3)
      aScaleX$(objectCount) = x$
      aScaleY$(objectCount) = y$
      aScaleZ$(objectCount) = z$
      aScale_POV$(objectCount) = "<" + x$ + ", " +  z$ + ", "  + y$ + "> "

      ; ---------------------------------------------------------------
      ;  read ROTATION
     ; ---------------------------------------------------------------
      temp$ = ReadString(File, #PB_Ascii)
      ; find first quote mark
      p =  FindString(temp$, quote$, 1)
      ; trim from quote mark
      trans$ = Mid(temp$,p+1,l)

      ; remove end quote mark
      trans$ = Mid(trans$, 0, Len(trans$) - 1)

      ; find first space
      p1 =  FindString(trans$, space$, 1)

      ; x data
      x$ = Mid(trans$, 0, p1)
      x$ = Left(x$, FindString(x$,".")+3)

      ; re-trim
      temp$ = Mid(trans$,p1+1)

      ;find second space
      p2 =  FindString(temp$, space$, 1)

      ; y data
      y$ = Mid(temp$, 0, p2)
      y$ = Left(y$, FindString(y$,".")+3)

      ; z data
      z$ = Mid(temp$, p2+1)
      z$ = Left(z$, FindString(z$,".")+3)


      aRotX$(objectCount) = x$
      aRotY$(objectCount) = y$
      aRotZ$(objectCount) = z$

      aRot_POV$(objectCount) = "<" + x$ + ", " +  y$ + ", "  + z$ + "> "

    EndIf
 Wend
 CloseFile(File)

; ---------------------------------------------------------------
;      write header
; ---------------------------------------------------------------
 ; Create temp file name.
Path$ = GetPathPart(x3d_File$)
fileName$ = GetFilePart(x3d_File$)
fileName$ = Mid(fileName$, 1, Len(fileName$) -4)
exportFile$ = Path$ + fileName$ + ".inc"
File = CreateFile(#PB_Any, exportFile$)
Debug exportFile$
Debug ".x3d convert to POV object types"
Debug "pointData Count: "   +  pointDataCount
; write header
tab$ = "     "
s0$ = "//   pointData from " + fileName$ + ".x3d"
s1$ = "//   m.miller 8.8.2023" + Chr(13)
s2$ = "//   note: lathe requires positive x for all points"
s3$ = "//         prisms are plotted on z plane and extrude in y"
s4$ = "" + Chr(13)
WriteStringN(File, s0$, #PB_Ascii)
WriteStringN(File, s1$, #PB_Ascii)
WriteStringN(File, s2$, #PB_Ascii)
WriteStringN(File, s3$, #PB_Ascii)
WriteStringN(File, s4$, #PB_Ascii)
WriteStringN(File, s4$, #PB_Ascii)


; ---------------------------------------------------------------
;      write ARRAY
; ---------------------------------------------------------------
If pointDataCount > 0
  n=0
  WriteStringN(File,"//--- pointArray " , #PB_Ascii)
  WriteStringN(File,"#declare pointDataCount = " + pointDataCount + " ;" ,
#PB_Ascii)
  WriteStringN(File,"#declare pointArray = array mixed [pointDataCount][2]" + "
;",  #PB_Ascii)
  For i = 1 To objectCount
    If Mid(aName$(i), 0, 9) = "pointData"
      s0$ = "#declare pointArray[" + n + "][0] = " + aPos_POV$(i) + " ;"
      s1$ = "#declare pointArray[" + n + "][1] = " + aScaleX$(i)  + " ;"
      WriteStringN(File, s0$, #PB_Ascii)
      WriteStringN(File, s1$, #PB_Ascii)
      n+1
    EndIf
  Next
  WriteStringN(File, "", #PB_Ascii)
EndIf

; ---------------------------------------------------------------
;      write PRISM Z
; ---------------------------------------------------------------
If pointDataCount > 0
  n=0
  c=pointDataCount+1
  s0$ = "//--- prism Z"
  s1$ = "#declare " + fileName$ +"_prism_z ="
  s2$ = "prism {"
  s3$ = "    linear_spline"
  WriteStringN(File,Chr(13), #PB_Ascii)
  WriteStringN(File, s0$, #PB_Ascii)
  WriteStringN(File, s1$, #PB_Ascii)
  WriteStringN(File, s2$, #PB_Ascii)
  WriteStringN(File, s3$, #PB_Ascii)
  s$ = "    0, 1, " + c + ","
  WriteStringN(File,s$ , #PB_Ascii)
  For i = 1 To objectCount
    If Mid(aName$(i), 0, 9) = "pointData"
      s$ = "    <" + aPosX$(i) + "," +  aPosZ$(i) + ">,"
      If i = objectCount
        s$ = "    <" + aPosX$(i) + "," +  aPosZ$(i) + ">"
      EndIf
       WriteStringN(File, s$, #PB_Ascii)
       n+1
     EndIf
   Next
   s$ = "    <" + aPosX$(1) + "," +  aPosZ$(1) + ">"
   s1$ = "}"
   WriteStringN(File, s$, #PB_Ascii)
   WriteStringN(File, s1$, #PB_Ascii)
   WriteStringN(File, "", #PB_Ascii)
EndIf

; ---------------------------------------------------------------
;      write PRISM Y
; ---------------------------------------------------------------
If pointDataCount > 0
  n=0
  c=pointDataCount+1
  s0$ = "//--- prism Y"
  s1$ = "#declare " + fileName$ +"_prism_y ="
  s2$ = "prism {"
  s3$ = "    linear_spline"
  WriteStringN(File,Chr(13), #PB_Ascii)
  WriteStringN(File, s0$, #PB_Ascii)
  WriteStringN(File, s1$, #PB_Ascii)
  WriteStringN(File, s2$, #PB_Ascii)
  WriteStringN(File, s3$, #PB_Ascii)
  s$ = "    0, 1, " + c + ","
  WriteStringN(File,s$ , #PB_Ascii)
  For i = 1 To objectCount
    If Mid(aName$(i), 0, 9) = "pointData"

      s$ = "    <" + aPosX$(i) + "," +  aPosY$(i) + ">,"
      If i = objectCount
        s$ = "    <" + aPosX$(i) + "," +  aPosY$(i) + ">"
      EndIf
       WriteStringN(File, s$, #PB_Ascii)
       n+1
     EndIf
   Next
   s$ = "    <" + aPosX$(1) + "," +  aPosY$(1) + ">"
   s1$ = "}"
   WriteStringN(File, s$, #PB_Ascii)
   WriteStringN(File, s1$, #PB_Ascii)
EndIf

; ---------------------------------------------------------------
;      write Lathe
; ---------------------------------------------------------------
If pointDataCount > 0
  s0$ = "#declare " + fileName$ +"_lathe ="
  s1$ = "lathe{ "
  s2$ = "      cubic_spline"
  s3$ = "      " + Str(pointDataCount) + ","
  s4$ = "      }"
  ; write Lathe header
  WriteStringN(File, "", #PB_Ascii)
  WriteStringN(File, "//--- lathe", #PB_Ascii)
  WriteStringN(File, s0$, #PB_Ascii)
  WriteStringN(File, s1$, #PB_Ascii)
  WriteStringN(File, s2$, #PB_Ascii)
  WriteStringN(File, s3$, #PB_Ascii)
  For i = 1 To objectCount-1
    s0$ = "      <" + aPosX$(i) + "," +  aPosY$(i) + ">, "
    WriteStringN(File, s0$, #PB_Ascii)
  Next
  s0$ = "      <" + aPosX$(objectCount) + "," +  aPosY$(objectCount) + ">"
  WriteStringN(File, s0$, #PB_Ascii)
  WriteStringN(File, s4$, #PB_Ascii)
 EndIf

; ---------------------------------------------------------------
;      write Sweep Cubic
; ---------------------------------------------------------------
If pointDataCount > 0
  c=pointDataCount+2
  s0$ = "#declare " + fileName$ + "_sweep_cubic ="
  s1$ = "sphere_sweep {"
  s2$ = "     cubic_spline"
  s3$ = "     tolerance 0.000001"
  s4$ = "     }"
  ; write Lathe header
  WriteStringN(File, "", #PB_Ascii)
  WriteStringN(File, "//--- cubic spline sweep", #PB_Ascii)
  WriteStringN(File, "#declare sf=1;", #PB_Ascii)
  WriteStringN(File, s0$, #PB_Ascii)
  WriteStringN(File, s1$, #PB_Ascii)
  WriteStringN(File, s2$, #PB_Ascii)
  WriteStringN(File, "     " + c + ",", #PB_Ascii)
  s0$ = "     " + aPos_POV$(1) + "," +  " " + aScaleX$(1) + "*sf, "
  WriteStringN(File, s0$, #PB_Ascii)
  For i = 1 To objectCount
      s0$ = "     " + aPos_POV$(i) + "," +  " " + aScaleX$(i) + "*sf, "
      WriteStringN(File, s0$, #PB_Ascii)
  Next
  s0$ = "     " + aPos_POV$(objectCount) + "," +  " " + aScaleX$(objectCount) +
"*sf"
  WriteStringN(File, s0$, #PB_Ascii)
  WriteStringN(File, s3$, #PB_Ascii)
  WriteStringN(File, s4$, #PB_Ascii)
EndIf

; ---------------------------------------------------------------
;      write Sweep linear
; ---------------------------------------------------------------
If pointDataCount > 0
  c=pointDataCount+2
  s0$ = "#declare " + fileName$ + "_sweep_linear ="
  s1$ = "sphere_sweep {"
  s2$ = "     linear_spline"
  s3$ = "     tolerance 0.000001"
  s4$ = "     }"
  ; write Lathe header
  WriteStringN(File, "", #PB_Ascii)
  WriteStringN(File, "//--- linear spline sweep", #PB_Ascii)
  WriteStringN(File, "#declare sf=1;", #PB_Ascii)
  WriteStringN(File, s0$, #PB_Ascii)
  WriteStringN(File, s1$, #PB_Ascii)
  WriteStringN(File, s2$, #PB_Ascii)
  WriteStringN(File, "     " + c + ",", #PB_Ascii)
  s0$ = "     " + aPos_POV$(1) + "," +  " " + aScaleX$(1) + "*sf, "
  WriteStringN(File, s0$, #PB_Ascii)
  For i = 1 To objectCount
      s0$ = "     " + aPos_POV$(i) + "," +  " " + aScaleX$(i) + "*sf, "
      WriteStringN(File, s0$, #PB_Ascii)
  Next
  s0$ = "     " + aPos_POV$(objectCount) + "," +  " " + aScaleX$(objectCount) +
"*sf"
  WriteStringN(File, s0$, #PB_Ascii)
  WriteStringN(File, s3$, #PB_Ascii)
  WriteStringN(File, s4$, #PB_Ascii)
EndIf

; ---------------------------------------------------------------
;--- Plot spheres
; ---------------------------------------------------------------
If pointDataCount > 0
  s0$ = "#declare " + fileName$ + "_spheres ="
  s1$ = "union {"
  s2$ = "     }"
  ; write Lathe header
  WriteStringN(File, "", #PB_Ascii)
  WriteStringN(File, "//--- plotted spheres", #PB_Ascii)
  WriteStringN(File, s0$, #PB_Ascii)
  WriteStringN(File, s1$, #PB_Ascii)
  For i = 1 To objectCount
      s0$ = "     sphere{<0,0,0>, " + aScaleX$(i) + " translate " + aPos_POV$(i)
+ " }"
      WriteStringN(File, s0$, #PB_Ascii)
  Next
  WriteStringN(File, s4$, #PB_Ascii)
EndIf

; ---------------------------------------------------------------
;--- Plot cones
; ---------------------------------------------------------------
If pointDataCount > 0
  s0$ = "#declare " + fileName$ + "_cones ="
  s1$ = "union {"
  s2$ = "     }"
  ; write Lathe header
  WriteStringN(File, "", #PB_Ascii)
  WriteStringN(File, "//--- plotted cones", #PB_Ascii)
  WriteStringN(File, s0$, #PB_Ascii)
  WriteStringN(File, s1$, #PB_Ascii)
  For i = 1 To objectCount-1
      s0$ = "     cone{" + aPos_POV$(i) + "," + aScaleX$(i) + "," +
aPos_POV$(i+1) + "," + aScaleX$(i+1) + "}"
      WriteStringN(File, s0$, #PB_Ascii)
    Next
  WriteStringN(File, s4$, #PB_Ascii)
EndIf

; ---------------------------------------------------------------
;--- close file
; ---------------------------------------------------------------
CloseFile(File)

; ---------------------------------------------------------------
;--- Verbose message
; ---------------------------------------------------------------
s$ = fileName$ + ".inc created "          + Chr(13)
s1$ = "" + pointDataCount + "  points"    + Chr(13)
s2$ = "-   array added"    + Chr(13)
s3$ = "-   prism added"    + Chr(13)
s4$ = "-   lathe added"    + Chr(13)
s5$ = "-   cubic sweep added"    + Chr(13)
s5$ = "-   linear sweep added"    + Chr(13)
s6$ = "-   spheres added"  + Chr(13)
s7$ = "-   cones added"  + Chr(13)

MessageRequester(".x3d to POV 0.5  m.miller 8.8.23",
s$+s1$+s2$+s3$+s4$+s5$+s6$+s7$, 0)

Else
    MessageRequester("Info:", "canceled", 0)
EndIf

[jr] Re: robot_fish.zip [976 days 6 hours and 23 minutes ago]

Sat, 12 Aug 2023 14:35:00 GMT

hi,

"Mike Miller" <mil### [at] gmailcom> wrote:
> Scene file and .x3d to POV converter. ... x3d_blender_points.exe ...

thanks, any chance of a different format (or source) ?  have no Microsoft OS.


regards, jr.

[Mike Miller] robot_fish.zip [976 days 21 hours and 23 minutes ago]

Fri, 11 Aug 2023 23:35:00 GMT

Scene file and .x3d to POV converter. I set up a simple blender file to demo the
use of the converter. I'm using this file to model a robotic fish that will be
added to some sci-fi themed renderings.

The x3d_blender_points.exe is in the blender folder of this zip along with a
read_me file. There's a stripped-down Blender file with some of the point arrays
and model data.

Blender is free and the x3d format is easy to parse for a hack programmer. It
also helps with visualizing the modeling process by using the POV rendered
elevations as underlays in blender.
Miller

[ingo] softshape.inc [978 days 14 hours and 53 minutes ago]

Thu, 10 Aug 2023 06:05:00 GMT

// POV-Ray 3.7 Scene File "softshape.inc"
// author:  Ingo Janssen
// date:    2023-07-17
// version: 0.5 beta
//
// SoftShape is inspired by Remco de Korte's SoftText, it does not use the same
// layout of arrays as SoftText. SoftShape traces an object in a predifined
// area in steps op 1 pov-unit. The area is in the xy-plane and starts at
// <0,0,0>.
//
// For each point where the trace is successfull the found coordinate is
// written to an include file, as is the normal at that point. In the demo
// scene at the end of the generated include file the points are used for the
// sphere of a blob object.
//
// At the end of this include file is a demo scene to illustrate its use. Just
// run this include file and a new include file 'test_soft.inc' or 'test_colour'
// is generated. Select one of them at the end of this file.
//
// Run this new include file to see the result of the tracing as a blob object.
//
//--------------------------------------------------------------------------

#version 3.7;
#include "functions.inc"

//--  Local macros

// local macro to write (vector) arrays to file
#macro _WriteArray(ObjName, ArrayName, Array, PCount, NCount)
  #write(SoftInc, "#declare ",ObjName, ArrayName," =
array[",str(PCount,0,0),"]{\n\t")
  #local LineEnd = 1;
  #for (I,0, NCount-1)
    #ifdef(Array[I])
      #write (SoftInc, Array[I],", ")
      #if (LineEnd = 30)
        #write(SoftInc, "\n\t")
        #local LineEnd = 0;
      #end
      #local LineEnd = LineEnd + 1;
    #end
  #end
  #write(SoftInc,"\n}\n\n")
#end


// local macro to write the include file header to file
#macro _WriteHeader(ObjName)
  #write(SoftInc, "#version 3.7;\n\n#ifndef(",ObjName,"_INC_TEMP)
  #declare ",ObjName,"_INC_TEMP = version;
  #ifdef(View_POV_Include_Stack)
    #debug \"including ",ObjName,".inc\"
  #end\n\n" )
#end


// local macro to write the include file footer to file
#macro _WriteFooter(ObjName)
  #write(SoftInc,"\n\n#version ",ObjName,"_INC_TEMP;
#end //#ifndef(",ObjName,"_INC_TEMP)\n")
#end

// local macro to write a simple demoscene to the inc file.
#macro _WriteDemo(ObjName)
#write(SoftInc,"// test scene
#if(input_file_name=\"",ObjName,".inc\")
  global_settings{
    assumed_gamma 1.0
  }

  #default{
     finish{
       ambient 0.1 diffuse 0.9
     }
  }

  blob{
    threshold  .7
    #declare I = 0;
    #for (I,0,",ObjName,"_PCount-1)
      sphere{",ObjName,"_Points[I], ",ObjName,"_SS, 1}
    #end
    pigment{rgb<1,0,1>}
  }

  light_source{
    <",ObjName,"_CentHor, ",ObjName,"_CentVer, -",ObjName,"_SizeHor>
    colour rgb 1
    shadowless
  }

  camera{
    orthographic
    angle 30
    location <",ObjName,"_CentHor, ",ObjName,"_CentVer, -",ObjName,"_SizeHor>
    look_at <",ObjName,"_CentHor, ",ObjName,"_CentVer, ",ObjName,"_SizeHor>
    right x*image_width/image_height
  }
#end"
)
#end


//-- Public macros

//==
// The RenderObject macro is a helper macro to visualise the area and object to
// trace. It will render a green area of the dimension that will be traced and
// the object to be traced.
//
// Use:
// Create a POV-Ray scene, include softshape.inc. In the scene only add an
// object{} and this macro. Render the scene. The macro sets the camera and
// lighting.
//
// TIP: set the image size to match the aspect ration of the scan area.
//
// RenderObject(SizeHor, SizeVer, Obj)
//
// Parameters:
// SizeHor (int): horizontal size of the area to be traced
// SizeVer (int): vertical size of the area to be traced
// Obj (object)  : object to be traced
//
// Result:
// An image.
//
#macro RenderObject(SizeHor, SizeVer, Obj)
  global_settings{
    assumed_gamma 1.0
  }

  #default{
     finish{
       ambient 0.1 diffuse 0.9
     }
  }
  #local CentHor = SizeHor/2;
  #local CentVer = SizeVer/2;

  box{
    <0,0,-0.001>, <SizeHor, SizeVer, -0.0001>
    texture{pigment {rgbt <0,1,0,0.98>}}
  }

  object{Obj}

  light_source{
    <SizeHor/2, SizeVer/2, -SizeHor>
    colour rgb 1
    shadowless
  }

  camera{
    orthographic
    angle 30
    location <SizeHor/2, SizeVer/2, -SizeHor>
    look_at <SizeHor/2, SizeVer/2, SizeHor>
    right x*image_width/image_height
  }
#end


//==
// The TraceObject macro traces the area <0, 0, 0>, <SizeHor, SizeVer, 0> for
// intersections with the Obj object in one pov-unit steps. It writes the found
// intersection points an normals to the file ObjName".inc".
//
// TraceObject(SizeHor, SizeVer, Obj, ObjName)
// Parameters:
// SizeHor (int): horizontal size of the area to be traced
// SizeVer (int): vertical size of the area to be traced
// Obj (object)  : object to be traced
// ObjName (string): the base of the .inc file. The ObjName is also prepend to
// variable names in the include file.
//
// Result:
// An include file containing dimensional data, an array with Points, an array
// with Normals and a demo scene.
//
#macro TraceObject(SizeHor, SizeVer, Obj, ObjName)
  #local CentHor = SizeHor/2;
  #local CentVer = SizeVer/2;
  #local PCount = 0;
  #local NCount = SizeHor * SizeVer;
  #local Points = array[NCount];
  #local Normals = array[NCount];
  #local N = 0;
  #for(J, SizeVer-1,0,-1)
    #for(I, 0, SizeHor-1)
      #local Start = <I, J, -SizeHor>;
      #local Norm = <0,0,0>;
      #local Inter = trace(Obj, Start, <I, J, 0> - Start, Norm);
      #if(vlength(Norm)!=0 )
        #local Points[N] = <I, J, 0>;
        #local Normals[N] = Norm;
        #local PCount = PCount + 1;
      #end
      #local N = N + 1;
    #end
  #end

  #local FileName = concat(ObjName,".inc")
  #fopen SoftInc FileName write

  _WriteHeader(ObjName)
  #write(SoftInc, "#declare ",ObjName,"_SS = 3; //sphere_size\n")
  #write(SoftInc, "#declare ",ObjName,"_PCount = ", str(PCount,0,0), ";\n")
  #write(SoftInc, "#declare ",ObjName,"_SizeHor = ", str(SizeHor,0,0),";\n")
  #write(SoftInc, "#declare ",ObjName,"_SizeVer = ", str(SizeVer,0,0),";\n")
  #write(SoftInc, "#declare ",ObjName,"_CentHor = ", str(CentHor,-1,-1),";\n")
  #write(SoftInc, "#declare ",ObjName,"_CentVer = ", str(CentVer,-1,-1),";\n\n")
  _WriteArray(ObjName, "_Points", Points, PCount, NCount)
  _WriteArray(ObjName, "_Normals", Normals, PCount, NCount)
  _WriteDemo(ObjName)
  _WriteFooter(ObjName)
  #fclose SoftInc
#end

#macro RenderPattern(SizeHor, SizeVer, PatFunc)
  global_settings{
    assumed_gamma 1.0
  }

  #default{
     finish{
       ambient 0.1 diffuse 0.9
     }
  }
  #local CentHor = SizeHor/2;
  #local CentVer = SizeVer/2;

  box{
    <0,0,0>, <SizeHor, SizeVer, 0.0001>
    pigment{
      function{PatFunc(x,y)}
    }
  }

  light_source{
    <SizeHor/2, SizeVer/2, -SizeHor>
    colour rgb 1
    shadowless
  }

  camera{
    orthographic
    angle 30
    location <SizeHor/2, SizeVer/2, -SizeHor>
    look_at <SizeHor/2, SizeVer/2, SizeHor>
    right x*image_width/image_height
  }
#end


#macro TracePattern(SizeHor, SizeVer, PatFunc, Colour, Distance, ObjName)
  #local CentHor = SizeHor/2;
  #local CentVer = SizeVer/2;
  #local PCount = 0;
  #local NCount = SizeHor * SizeVer;
  #local Points = array[NCount];
  #local Distances = array[NCount];
  #local N = 0;
  #for(J, SizeVer-1,0,-1)
    #for(I, 0, SizeHor-1)
      #local Col = PatFunc(I,J);
      #if(vlength(Colour - Col) <= Distance )
        #local Points[N] = <I, J, 0>;
        #local Distances[N] = vlength(Colour - Col);
        #local PCount = PCount + 1;
      #end
      #local N = N + 1;
    #end
  #end

  #local FileName = concat(ObjName,".inc")
  #fopen SoftInc FileName write

  _WriteHeader(ObjName)
  #write(SoftInc, "#declare ",ObjName,"_SS = 3; //sphere_size\n")
  #write(SoftInc, "#declare ",ObjName,"_PCount = ", str(PCount,0,0), ";\n")
  #write(SoftInc, "#declare ",ObjName,"_SizeHor = ", str(SizeHor,0,0),";\n")
  #write(SoftInc, "#declare ",ObjName,"_SizeVer = ", str(SizeVer,0,0),";\n")
  #write(SoftInc, "#declare ",ObjName,"_CentHor = ", str(CentHor,-1,-1),";\n")
  #write(SoftInc, "#declare ",ObjName,"_CentVer = ", str(CentVer,-1,-1),";\n\n")
  _WriteArray(ObjName, "_Points", Points, PCount, NCount)
  _WriteArray(ObjName, "_Distances", Distances, PCount, NCount)
  _WriteDemo(ObjName)
  _WriteFooter(ObjName)
  #fclose SoftInc
#end


//===
#if(input_file_name="softshape.inc")

  //+w600 +h300 +a0.1


  #include "rand.inc"
  #declare Stream = seed(7);

  //object to be traced
  #declare Soft = object{
    union{
      #for (J,0,1)
        #for(I,0,8)
          #declare P = Rand_Bernoulli(0.5, Stream);
          #if (P)
            box{
              <10,10,0>,<20,30,1>
              translate <I*15,J*35,0>
              texture{pigment{rgb 1}}
            }
          #else
            cylinder{
              <15,10,0>,<15,30,0>, 5
              translate <I*15,J*35,0>
              texture{pigment{rgb 1}}
            }
          #end
        #end
      #end
      sphere{
        <0,0,0>,9
        texture{pigment{rgb 1}}
      }
      sphere{
        <150,0,0>,9
        texture{pigment{rgb 1}}
      }
      sphere{
        <150,75,0>,9
        texture{pigment{rgb 1}}
      }
      sphere{
        <0,75,0>,9
        texture{pigment{rgb 1}}
      }
    }
  }

  //uncomment one of the options below

  // option test_soft
  //#declare Name = "test_soft"; //will be the name of the include file
  //RenderObject(150, 75, Soft)
  //TraceObject(150, 75, Soft, Name)

  // option test_colour
  #declare Name = "test_colour";
  #declare FunFunc = function(x,y) {
    f_wood(x/20,y/20,z/20)
  };
  RenderPattern(150, 75, FunFunc)
  TracePattern(150, 75, FunFunc, <0.5,0.5,0.5>, 0.2, Name)


#end

[Mike Miller] brain_attack.zip [983 days 2 hours and 43 minutes ago]

Sat, 5 Aug 2023 18:15:01 GMT

Brain Attack scene files used to create a pulp style book cover. Stylized look
and text done in Photoshop.
Miller

[Mike Miller] Scene file for Weird World Cover - take 1 [995 days 23 hours and 53 minutes ago]

Sun, 23 Jul 2023 21:05:00 GMT

Scene file for Weird World Cover - take 1. I was happy with the 3D
Masthead/Title forms and the way they rendered.
Miller

[Mike Miller] brain_bot_pov.zip [1000 days 4 hours and 43 minutes ago]

Wed, 19 Jul 2023 16:15:00 GMT

Pov scene file of a brain bot character. A prop for a pulp style sci-fi cover.
Work in progress.
Mike.

[ingo] Re: Character number lookup dict - chr.inc [1043 days 3 hours and 38 minutes ago]

Tue, 6 Jun 2023 17:20:00 GMT

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:

>
> Can you not use asc() for this ?`
>

Oh.

Must have a blind spot.

Must have been there for years. :(


Thanks,

ingo

[Tor Olav Kristensen] Re: Character number lookup dict - chr.inc [1043 days 4 hours and 13 minutes ago]

Tue, 6 Jun 2023 16:45:00 GMT

"ingo" <nomail@nomail> wrote:
> A scene file I just added to my tool box directory.
>
> As the #switch #case only compares floats and not strings I always have to
> figure out what character is what number. To scratch that itch a little scene
> that writes an include file for the 'reverse look up' of the chr function using
> a dictionary. It covers the ascii chars 34 to 127 as I don't know how to use a
> 'bell' as key.

Can you not use asc() for this ?`

http://www.povray.org/documentation/view/3.7.1/228/

You can use chr(7) to quote the ASCII bell character.

https://www.povray.org/documentation/view/3.7.2/232/

This code outputs 7

#version 3.7;
global_settings { assumed_gamma 1.0 }
#debug "\n"
#debug str(asc(chr(7)), 0, 0)
#debug "\n"
#error ""

Perhaps chr(7) can also be used as a key in a v3.8 dictionary (?)

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[ingo] Character number lookup dict - chr.inc [1043 days 11 hours and 13 minutes ago]

Tue, 6 Jun 2023 09:45:00 GMT

A scene file I just added to my tool box directory.

As the #switch #case only compares floats and not strings I always have to
figure out what character is what number. To scratch that itch a little scene
that writes an include file for the 'reverse look up' of the chr function using
a dictionary. It covers the ascii chars 34 to 127 as I don't know how to use a
'bell' as key.


---%<------%<------%<---

// Persistence of Vision Ray Tracer Scene / Include File
// File: chars.pov
// Vers: 3.8
//
// Desc: A scenefile to create an include file with a dictionary to look up
// the ascii numbers for characters.
// Author: Ingo Janssen
// Date: 2023-06-06

#version 3.8;

global_settings{ assumed_gamma 1.0 }
#default{ finish{ ambient 0.1 diffuse 0.9 }}

#fopen CHR "chr.inc" write
#write (CHR "#version 3.8;\n
#ifndef(chr_Inc_Temp)
  #declare chr_Inc_Temp = version;
  #ifdef(View_POV_Include_Stack)
    #debug \"including chr.inc\"
  #end\n\n"
)
#write (CHR "#declare Chr = dictionary {\n")
#for (i, 34, 127)
  #if (chr(i) = "\"" | chr(i) = "\\")
  #write (CHR concat("[\"\\", chr(i),"\"] : ", str(i,0,0),"\n"))
  #else
    #write (CHR concat("[\"", chr(i),"\"] : ", str(i,0,0),"\n"))
  #end
#end
#write (CHR "};\n\n")
#write (CHR " #version chr_Inc_Temp;
#end")
#fclose CHR

#include "chr.inc"
#debug concat(str(Chr["\""], 0, 0), "\n")  // The " has to be escaped
#debug concat(str(Chr["\\"], 0, 0), "\n")  // the \ has to be escaped
#debug concat(str(Chr["F"], 0, 0), "\n")
#debug concat(str(Chr["&"], 0, 0), "\n")


---%<------%<------%<---

[Mike Miller] view_materials.zip [1048 days 16 hours and 58 minutes ago]

Thu, 1 Jun 2023 04:00:00 GMT

- Material library and material sample viewer. Includes a simple utility that
reads a material list and generates a formatted POV scene for the viewer.
Info.txt has additional information for creating and using.
- I'm sure something like this has been done. I wrote this to help organize a
growing material count and for building, comparing, and tweaking.
Mike.

[Mike Miller] gear_box.zip [1056 days 4 hours and 8 minutes ago]

Wed, 24 May 2023 16:50:00 GMT

Brass clock gear box. Using for Jack's brain parts. Simple macro for
constructing the gears.
Mike

[jr] Re: box_mapped_box.zip [1057 days 10 hours and 23 minutes ago]

Tue, 23 May 2023 10:35:00 GMT

hi,

"Mike Miller" <mil### [at] gmailcom> wrote:
> Macro and scene file that dices a Round_Box() into a 6 sided uv mapped Round
> Box. Probably re-invented the wheel. I'm sure someone has done this before, but
> I needed the exercise.
> Mike.

thought I'll have a quick look at the contents.  parsing failed because the
'stone_diffuse.png' is missing from the archive.

regards, jr.

[Mike Miller] box_mapped_box.zip [1058 days 19 hours and 28 minutes ago]

Mon, 22 May 2023 01:30:00 GMT

Macro and scene file that dices a Round_Box() into a 6 sided uv mapped Round
Box. Probably re-invented the wheel. I'm sure someone has done this before, but
I needed the exercise.
Mike.

[Mike Miller] corkscrew.zip [1059 days 23 hours and 33 minutes ago]

Sat, 20 May 2023 21:25:00 GMT

Old standard corkscrew / bottle opener. Will hang somewhere in my workbench
scene. Might try to distress the finish a bit more.
Mike.

[Mike Miller] workbench objects [1074 days 2 hours and 48 minutes ago]

Sat, 6 May 2023 18:10:01 GMT

Scene file of workbench area, tools, and misc. objects. Removed the larger maps
used for bench top and cmu. Use freely. The room has a vertical blind object
that can be toggled off to remove the draping shadows.
Mike.

[Mike Miller] screwdrivers.zip [1083 days 6 hours and 8 minutes ago]

Thu, 27 Apr 2023 14:50:01 GMT

Scene file and macro to generate a few screwdriver types.
Miller

[Mike Miller] vault boy blob model [1084 days 16 hours and 43 minutes ago]

Wed, 26 Apr 2023 04:15:00 GMT

Fallout vault boy model. Prop for workbench scene. Don't get to close... it's my
first 'blob' character. It will show up on a shelf in the background.
Hair curls are cubic spline sweeps. ...needs a better comb job.
Mike.

[Mike Miller] Re: screws.zip [1086 days 8 hours and 53 minutes ago]

Mon, 24 Apr 2023 12:05:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "Mike Miller" <mil### [at] gmailcom> wrote:
> > Scene and macros ...
>
> were lost in transit ?  ;-)
>
>
> regards, jr.

I guess so. :)  ....here are the lost screws.

[jr] Re: screws.zip [1086 days 9 hours and 3 minutes ago]

Mon, 24 Apr 2023 11:55:00 GMT

hi,

"Mike Miller" <mil### [at] gmailcom> wrote:
> Scene and macros ...

were lost in transit ?  ;-)


regards, jr.

[Mike Miller] screws.zip [1086 days 22 hours and 43 minutes ago]

Sun, 23 Apr 2023 22:15:00 GMT

Scene and macros for making screw heads, threads, and bolt heads. Controls for
size, length, and thread count. Includes standard & phillips for pan head and
flat head screws.
Miller

[Mike Miller] wood_mannequin_2.zip [1093 days 6 hours and 38 minutes ago]

Mon, 17 Apr 2023 14:20:00 GMT

Wood mannequin update. Added screw heads to the joints, fix hands, added a pose.
Miller

[Mike Miller] wood_mannequin.zip [1093 days 17 hours and 8 minutes ago]

Mon, 17 Apr 2023 03:50:00 GMT

A poseable wood artist mannequin. Modeled for a prop for my jack/workbench. I'll
add more poses as I get the chance. Might try to animate this with a series of
keyed poses - like a walk sequence.
Miller

[Mike Miller] workbench.zip [1095 days 3 hours and 53 minutes ago]

Sat, 15 Apr 2023 17:05:00 GMT

Scene file and maps of workbench area for Jack rendering.
Had to resample maps to fit the 5 meg limit. Added a grunge map for the CMU but
needs enhanced.
Mike

[Mike Miller] soldering_gun.zip POV scene file [1098 days 18 hours and 3 minutes ago]

Wed, 12 Apr 2023 02:55:00 GMT

Previous zip file was missing the underlay image used to model the soldering
gun.
Mike

[Mike Miller] soldering_gun.zip POV scene file [1098 days 18 hours and 13 minutes ago]

Wed, 12 Apr 2023 02:45:00 GMT

Scene file of a soldering gun model. Updated model for new Jack scene.
Miller

[Mike Miller] pc_board.zip - printed circuit board model [1101 days 14 hours and 28 minutes ago]

Sun, 9 Apr 2023 06:30:00 GMT

POV scene file of a printed circuit board model for an updated Jack in the box
rendering.
miller

[Mike Miller] Jack_head.zip - scene file of Jack in the box he... [1104 days 1 hour and 58 minutes ago]

Thu, 6 Apr 2023 19:00:01 GMT

Started as a test to see what I could come up with for a new Jack head for an
updated rendering. The head is modeled with blobs with variants of 'thresholds'
to create inner voids and forms. Work in progress.
Miller

[Mike Miller] flies in sink - scene file [1109 days 17 hours and 48 minutes ago]

Sat, 1 Apr 2023 03:10:00 GMT

Flies surrounding a sink drain. A simple scene to stage my green fly model. The
fly could use some more work.
Miller

[yesbird] Re: beetle2_plants.zip [1126 days 12 hours and 34 minutes ago]

Wed, 15 Mar 2023 08:24:21 GMT

On 15/03/2023 06:41, Mike Miller wrote:
> Scene file for beetle 2 environment. Texture mapping could be better.
> Playing with converting Blender types to POV. ...probably re-inventing the
> wheel. :)

I've rendered it - looks very impressive, this lights on the blobs and
plants ... Also idea is cool - underground life of beetles.

Now I want to explore the 'lamps' structure - I did some experiments in
the past with transparent glass spheres (attached), but your
implementation is much better.

About the wheel, as I mentioned in other thread, did you see this
Blender's plugin ?:
https://docs.blender.org/manual/en/latest/addons/render/povray.html
--
YB

[Mike Miller] beetle2_plants.zip [1126 days 17 hours and 13 minutes ago]

Wed, 15 Mar 2023 03:45:00 GMT

Scene file for beetle 2 environment. Texture mapping could be better.
Playing with converting Blender types to POV. ...probably re-inventing the
wheel. :)
Mike

[yesbird] Re: beetle pov model [1128 days 5 hours and 5 minutes ago]

Mon, 13 Mar 2023 15:53:29 GMT

On 13/03/2023 17:14, Mike Miller wrote:
> Sorry the 0,0,0 insertion point is not centered on the beetle's x. I set my
> underlay at 0 to positive 100 units. I should shift all the union'd parts x-50
> so the model scales better.
No problem, I've fixed it easily, more challenging is to set up good
lighting, but thanks to Thomas, I now have this kit:

http://www.ignorancia.org/index.php/technical/tools-objects/studio-lighting-kit/

Will try to use it.
--
YB

[Mike Miller] Re: beetle pov model [1128 days 6 hours and 43 minutes ago]

Mon, 13 Mar 2023 14:15:00 GMT

yesbird <sya### [at] gmailcom> wrote:
> On 13/03/2023 06:37, Mike Miller wrote:
> > Beetle model using blobs and cubic_splines parsed from a .x3d via Blender. I
> > created some simple utilities to convert primitive types from Blender - I was
> > very happy to see the screen representation of blobs (Mballs) matched pretty
> > close to the POV result. I included the .exe that convert those types.
> Thanks for sharing the model, I've explored and rendered it - looks
> good, done very neat, now preparing animation and appropriate lighting.
> --
> YB


Thanks, YB.
Sorry the 0,0,0 insertion point is not centered on the beetle's x. I set my
underlay at 0 to positive 100 units. I should shift all the union'd parts x-50
so the model scales better.
Mike

[yesbird] Re: beetle pov model [1128 days 15 hours and 28 minutes ago]

Mon, 13 Mar 2023 05:30:43 GMT

On 13/03/2023 06:37, Mike Miller wrote:
> Beetle model using blobs and cubic_splines parsed from a .x3d via Blender. I
> created some simple utilities to convert primitive types from Blender - I was
> very happy to see the screen representation of blobs (Mballs) matched pretty
> close to the POV result. I included the .exe that convert those types.
Thanks for sharing the model, I've explored and rendered it - looks
good, done very neat, now preparing animation and appropriate lighting.
--
YB

[Mike Miller] beetle pov model [1128 days 17 hours and 18 minutes ago]

Mon, 13 Mar 2023 03:40:01 GMT

Beetle model using blobs and cubic_splines parsed from a .x3d via Blender. I
created some simple utilities to convert primitive types from Blender - I was
very happy to see the screen representation of blobs (Mballs) matched pretty
close to the POV result. I included the .exe that convert those types.
Mike

[Thomas de Groot] Re: fish_with_pipes.zip [1132 days 13 hours and 3 minutes ago]

Thu, 9 Mar 2023 07:55:35 GMT

Op 08/03/2023 om 17:37 schreef Mike Miller:
> Thanks Thomas. Very nice - big help.
> Objects not seen by the camera but reflecting in visible surfaces could present
> a problem. I guess you could 'add-back' objects not seen but within a distance
> of the frustum - if that object type was important to the reflections in the
> view.
> Mike.
> 
> 
Indeed. It does not happen often, but then... ;-)

Found the demo. Attached (the macro is written out in the scene again; 
can be replaced by a call to the external macro file of course).

-- 
Thomas

[Bald Eagle] Re: fish_with_pipes.zip [1133 days 2 hours and 13 minutes ago]

Wed, 8 Mar 2023 18:45:00 GMT

"Mike Miller" <mil### [at] gmailcom> wrote:

> Thanks BW.
> I like that idea - using the cameras frustum shape for an inside/outside test.
> Using the cameras' hither and yon planes for space partitioning. BSP?

Nope.  I'm currently too ignorant and unskilled to implement a BSP.  ;)

IIRC, it was just a check to see which side of the 6 planes that bounded the
View Frustum the selected point was on.  Simple.  Fast.

I suppose there might be a way to convert the frustum into a signed distance
function (SDF) and do it that way.   It would be slick, and then you'd have the
distance calculation integrated into each check as well.

- BW

[Mike Miller] Re: fish_with_pipes.zip [1133 days 4 hours and 18 minutes ago]

Wed, 8 Mar 2023 16:40:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 8-3-2023 om 14:59 schreef Mike Miller:
> > "Bald Eagle" <cre### [at] netscapenet> wrote:
> >> "Mike Miller" <mil### [at] gmailcom> wrote:
> >>
> >>> The 'populate' macros are slow to process with the amount of objects I'm using.
> >>> Not well optimized - could us some type of culling to remove unseen plants.
> >>
> >> I tried something like this - I determined what the view frustum was, and then
> >> IIRC did some my own home-brew insidedness tests.
> >>
> >>
http://news.povray.org/povray.binaries.images/message/%3Cweb.587ce70b1652a4dcc437ac910%40news.povray.org%3E/#%3Cwe
b.5
> > 87
> >> ce70b1652a4dcc437ac910%40news.povray.org%3E
> >>
> >> - BW
> >
> > Thanks BW.
> > I like that idea - using the cameras frustum shape for an inside/outside test.
> > Using the cameras' hither and yon planes for space partitioning. BSP?
> >
>
> In another age, long, long ago early in this century, Gilles Tran wrote
> a macro doing just that. I have always used it since then. I attach it
> here. I must have a demo scene somewhere too... I shall try to find it
> tomorrow.
>
> Note: The prefix GT_ is a code referring to the original author. It is a
> way I use to remember who wrote the code ;-)
>
> --
> Thomas

Thanks Thomas. Very nice - big help.
Objects not seen by the camera but reflecting in visible surfaces could present
a problem. I guess you could 'add-back' objects not seen but within a distance
of the frustum - if that object type was important to the reflections in the
view.
Mike.

[Thomas de Groot] Re: fish_with_pipes.zip [1133 days 5 hours and 17 minutes ago]

Wed, 8 Mar 2023 15:41:32 GMT

Op 8-3-2023 om 14:59 schreef Mike Miller:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>> "Mike Miller" <mil### [at] gmailcom> wrote:
>>
>>> The 'populate' macros are slow to process with the amount of objects I'm using.
>>> Not well optimized - could us some type of culling to remove unseen plants.
>>
>> I tried something like this - I determined what the view frustum was, and then
>> IIRC did some my own home-brew insidedness tests.
>>
>>
http://news.povray.org/povray.binaries.images/message/%3Cweb.587ce70b1652a4dcc437ac910%40news.povray.org%3E/#%3Cweb.5
> 87
>> ce70b1652a4dcc437ac910%40news.povray.org%3E
>>
>> - BW
> 
> Thanks BW.
> I like that idea - using the cameras frustum shape for an inside/outside test.
> Using the cameras' hither and yon planes for space partitioning. BSP?
> 

In another age, long, long ago early in this century, Gilles Tran wrote 
a macro doing just that. I have always used it since then. I attach it 
here. I must have a demo scene somewhere too... I shall try to find it 
tomorrow.

Note: The prefix GT_ is a code referring to the original author. It is a 
way I use to remember who wrote the code ;-)

-- 
Thomas

[Mike Miller] Re: fish_with_pipes.zip [1133 days 6 hours and 58 minutes ago]

Wed, 8 Mar 2023 14:00:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Mike Miller" <mil### [at] gmailcom> wrote:
>
> > The 'populate' macros are slow to process with the amount of objects I'm using.
> > Not well optimized - could us some type of culling to remove unseen plants.
>
> I tried something like this - I determined what the view frustum was, and then
> IIRC did some my own home-brew insidedness tests.
>
>
http://news.povray.org/povray.binaries.images/message/%3Cweb.587ce70b1652a4dcc437ac910%40news.povray.org%3E/#%3Cweb.5
87
> ce70b1652a4dcc437ac910%40news.povray.org%3E
>
> - BW

Thanks BW.
I like that idea - using the cameras frustum shape for an inside/outside test.
Using the cameras' hither and yon planes for space partitioning. BSP?

[Bald Eagle] Re: fish_with_pipes.zip [1133 days 9 hours and 33 minutes ago]

Wed, 8 Mar 2023 11:25:00 GMT

"Mike Miller" <mil### [at] gmailcom> wrote:

> The 'populate' macros are slow to process with the amount of objects I'm using.
> Not well optimized - could us some type of culling to remove unseen plants.

I tried something like this - I determined what the view frustum was, and then
IIRC did some my own home-brew insidedness tests.

http://news.povray.org/povray.binaries.images/message/%3Cweb.587ce70b1652a4dcc437ac910%40news.povray.org%3E/#%3Cweb.587
ce70b1652a4dcc437ac910%40news.povray.org%3E

- BW

[Kenneth] Re: fish_with_pipes.zip [1133 days 10 hours and 48 minutes ago]

Wed, 8 Mar 2023 10:10:00 GMT

yesbird <sya### [at] gmailcom> wrote:
>
> ..some optimization is always necessary.
> Write now I can suggest bounded_by:
> https://wiki.povray.org/content/Reference:Bounded_By_Object_Modifier
>
> if you still not using it. It's very effective for the scenes with large
> amount small objects with complex shapes.
> --

It's possible that certain versions of POV-ray mistakenly remove any manual
bounding shapes that a user adds. I remember reading something about this in old
newsgroup posts, but I am not knowledgeable on the subject. Maybe someone else
can give a more definitive answer?

[yesbird] Re: fish_with_pipes.zip [1133 days 13 hours and 47 minutes ago]

Wed, 8 Mar 2023 07:11:01 GMT

On 08/03/2023 08:37, Mike Miller wrote:
> The 'populate' macros are slow to process with the amount of objects I'm using.
> Not well optimized - could us some type of culling to remove unseen plants.

I will think about it, some optimization is always necessary.
Write now I can suggest bounded_by:
https://wiki.povray.org/content/Reference:Bounded_By_Object_Modifier

if you still not using it. It's very effective for the scenes with large
amount small objects with complex shapes.
--
YB

[Mike Miller] Re: fish_with_pipes.zip [1133 days 15 hours and 18 minutes ago]

Wed, 8 Mar 2023 05:40:00 GMT

yesbird <sya### [at] gmailcom> wrote:
> On 08/03/2023 08:09, Mike Miller wrote:
> > Fish underwater blob topo with pipes and flanges.
> > Needs a bit of cleanup to remove some parsing errors.
> > Mostly a material and scene idea study.
>
> It's seems to me that attachment missed.
> --
> YB

Also, a bit of warning.

The 'populate' macros are slow to process with the amount of objects I'm using.
Not well optimized - could us some type of culling to remove unseen plants.

The random scale factor needs tweaked. I messed it up but like the size
variations, so I left it for this rendering. :)

[Mike Miller] Re: fish_with_pipes.zip [1133 days 15 hours and 33 minutes ago]

Wed, 8 Mar 2023 05:25:01 GMT

yesbird <sya### [at] gmailcom> wrote:
> On 08/03/2023 08:09, Mike Miller wrote:
> > Fish underwater blob topo with pipes and flanges.
> > Needs a bit of cleanup to remove some parsing errors.
> > Mostly a material and scene idea study.
>
> It's seems to me that attachment missed.
> --
> YB

Yep...had to resample the bitmaps. Posted a new file. Should be on its way. :)

[Mike Miller] fish_with_pipes.zip [1133 days 15 hours and 33 minutes ago]

Wed, 8 Mar 2023 05:25:00 GMT

Fish underwater blob topo with pipes and flanges.
Needs a bit of cleanup to remove some parsing errors.
Mostly a material and scene idea study.
Miller

....first post attachment failed. had to resample the texture maps

[yesbird] Re: fish_with_pipes.zip [1133 days 15 hours and 41 minutes ago]

Wed, 8 Mar 2023 05:17:32 GMT

On 08/03/2023 08:09, Mike Miller wrote:
> Fish underwater blob topo with pipes and flanges.
> Needs a bit of cleanup to remove some parsing errors.
> Mostly a material and scene idea study.

It's seems to me that attachment missed.
--
YB

[Mike Miller] fish_with_pipes.zip [1133 days 15 hours and 48 minutes ago]

Wed, 8 Mar 2023 05:10:00 GMT

Fish underwater blob topo with pipes and flanges.
Needs a bit of cleanup to remove some parsing errors.
Mostly a material and scene idea study.
Miller

[Mike Miller] Re: negative strength blobs [1144 days 4 hours and 53 minutes ago]

Sat, 25 Feb 2023 16:05:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "Mike Miller" <mil### [at] gmailcom> wrote:
> > ...
> > Also, I there a way to capture an 8 bit alpha channel in rendering?
>
>
<https://wiki.povray.org/content/Reference:Image_Map#The_Filter_and_Transmit_Bitmap_Modifiers>
> <https://wiki.povray.org/content/Reference:File_Output_Options>
>
>
> regards, jr.

I skipped right over the 'background' filter when looking in the help files.
Excellent - forgot about the wiki. Great help.
....and sorry about typos. :)

[jr] Re: negative strength blobs [1144 days 7 hours and 48 minutes ago]

Sat, 25 Feb 2023 13:10:00 GMT

hi,

"Mike Miller" <mil### [at] gmailcom> wrote:
> ...
> Also, I there a way to capture an 8 bit alpha channel in rendering?

<https://wiki.povray.org/content/Reference:Image_Map#The_Filter_and_Transmit_Bitmap_Modifiers>
<https://wiki.povray.org/content/Reference:File_Output_Options>


regards, jr.

[Mike Miller] Re: negative strength blobs [1144 days 7 hours and 58 minutes ago]

Sat, 25 Feb 2023 13:00:00 GMT

Alain Martel <kua### [at] videotronca> wrote:
> > Alain Martel <kua### [at] videotronca> wrote:
> >>> POV scene file using negative strength blobs to form cavities within the blob
> >>> definition.
> >>> Mike
> >>
> >> Using current POV-Ray, max_intersection is pretty much obsolete.
> >> Then, you should use assumed_gamma 1, and set file gamma to sRGB. That
> >> should be the default value.
> >> No issue with lowering the ambient_light multiplier.
> >>
> >> New with version 3.8 :
> >> In the camera, the right vector now defaults to the aspect ratio of the
> >> output image and can be omitted.
> >>
> >> In the finish, with fresnel on, you need an interior statement setting
> >> the IOR to something different than 1. Otherwise, there will be NO
> >> reflection at all. In the present case, for M_gold_paint, using
> >> reflection{.2 .5 metallic} would be a better option.
> >> Then, redefine your floor like this :
> >> //--- floor with fresnel reflection
> >> plane { <0,1,0> 0 material{M_floor_paint}
> >>   interior{ior 1.5}
> >>     }
> >>
> >> conserve_energy only work with transparent pigments. In this scene, it
> >> have no effect as there are no transparent pigment.
> >>
> >> Happy and good poving
> >
> >
> > Thanks. I'll clean that up. Sorry, some of this is carry over from old files and
> > ignorance. :)
> >
> >>>   set file gamma to sRGB
> > is there an output flag for sRGB? thx
> >
> >
> >
> >
> >
> Now, by default, POV-Ray output is of the .PNG format and include the
> information telling that the image should get displayed in the sRGB
> colour space. You don't need to change anything.
> File gamma default to sRGB unless you change it.

Got it, thanks.

Also, I there a way to capture an 8 bit alpha channel in rendering?

Creating a matching scene with matt objects, no lights, rendered against a
white BG is an option. I guess you could use that method with white fog to get a
'sudo' depth of field image.

Thanks for all your help!

[Alain Martel] Re: negative strength blobs [1145 days and 7 minutes ago]

Fri, 24 Feb 2023 20:50:50 GMT

Le 2023-02-24 Ã  15:12, Mike Miller a Ã©critÂ :
> Alain Martel <kua### [at] videotronca> wrote:
>> Le 2023-02-23 Ã  01:22, Mike Miller a Ã©critÂ :
>>> POV scene file using negative strength blobs to form cavities within the blob
>>> definition.
>>> Mike
>>
>> Using current POV-Ray, max_intersection is pretty much obsolete.
>> Then, you should use assumed_gamma 1, and set file gamma to sRGB. That
>> should be the default value.
>> No issue with lowering the ambient_light multiplier.
>>
>> New with version 3.8 :
>> In the camera, the right vector now defaults to the aspect ratio of the
>> output image and can be omitted.
>>
>> In the finish, with fresnel on, you need an interior statement setting
>> the IOR to something different than 1. Otherwise, there will be NO
>> reflection at all. In the present case, for M_gold_paint, using
>> reflection{.2 .5 metallic} would be a better option.
>> Then, redefine your floor like this :
>> //--- floor with fresnel reflection
>> plane { <0,1,0> 0 material{M_floor_paint}
>>   interior{ior 1.5}
>>     }
>>
>> conserve_energy only work with transparent pigments. In this scene, it
>> have no effect as there are no transparent pigment.
>>
>> Happy and good poving
> 
> 
> Thanks. I'll clean that up. Sorry, some of this is carry over from old files and
> ignorance. :)
> 
>>>   set file gamma to sRGB
> is there an output flag for sRGB? thx
> 
> 
> 
> 
> 
Now, by default, POV-Ray output is of the .PNG format and include the 
information telling that the image should get displayed in the sRGB 
colour space. You don't need to change anything.
File gamma default to sRGB unless you change it.

[Mike Miller] Re: negative strength blobs [1145 days and 43 minutes ago]

Fri, 24 Feb 2023 20:15:00 GMT

Alain Martel <kua### [at] videotronca> wrote:
> Le 2023-02-23 à 01:22, Mike Miller a écrit :
> > POV scene file using negative strength blobs to form cavities within the blob
> > definition.
> > Mike
>
> Using current POV-Ray, max_intersection is pretty much obsolete.
> Then, you should use assumed_gamma 1, and set file gamma to sRGB. That
> should be the default value.
> No issue with lowering the ambient_light multiplier.
>
> New with version 3.8 :
> In the camera, the right vector now defaults to the aspect ratio of the
> output image and can be omitted.
>
> In the finish, with fresnel on, you need an interior statement setting
> the IOR to something different than 1. Otherwise, there will be NO
> reflection at all. In the present case, for M_gold_paint, using
> reflection{.2 .5 metallic} would be a better option.
> Then, redefine your floor like this :
> //--- floor with fresnel reflection
> plane { <0,1,0> 0 material{M_floor_paint}
>  interior{ior 1.5}
>    }
>
> conserve_energy only work with transparent pigments. In this scene, it
> have no effect as there are no transparent pigment.
>
> Happy and good poving


Thanks. I'll clean that up. Sorry, some of this is carry over from old files and
ignorance. :)

>>  set file gamma to sRGB
is there an output flag for sRGB? thx

[Alain Martel] Re: negative strength blobs [1146 days 6 hours and 22 minutes ago]

Thu, 23 Feb 2023 14:35:51 GMT

Le 2023-02-23 Ã  01:22, Mike Miller a Ã©critÂ :
> POV scene file using negative strength blobs to form cavities within the blob
> definition.
> Mike

Using current POV-Ray, max_intersection is pretty much obsolete.
Then, you should use assumed_gamma 1, and set file gamma to sRGB. That 
should be the default value.
No issue with lowering the ambient_light multiplier.

New with version 3.8 :
In the camera, the right vector now defaults to the aspect ratio of the 
output image and can be omitted.

In the finish, with fresnel on, you need an interior statement setting 
the IOR to something different than 1. Otherwise, there will be NO 
reflection at all. In the present case, for M_gold_paint, using 
reflection{.2 .5 metallic} would be a better option.
Then, redefine your floor like this :
//--- floor with fresnel reflection
plane { <0,1,0> 0 material{M_floor_paint}
	interior{ior 1.5}
   }

conserve_energy only work with transparent pigments. In this scene, it 
have no effect as there are no transparent pigment.

Happy and good poving

[Mike Miller] negative strength blobs [1146 days 14 hours and 33 minutes ago]

Thu, 23 Feb 2023 06:25:00 GMT

POV scene file using negative strength blobs to form cavities within the blob
definition.
Mike

[yesbird] Re: blob form study [1148 days 7 hours and 59 minutes ago]

Tue, 21 Feb 2023 12:59:15 GMT

On 21/02/2023 05:38, Mike Miller wrote:
> Hi,
> attached is a pov scene file that uses some simple 'point clustering' macros to
> create interesting blob forms. Sorry about all the unused definitions in the
> file. These's lot of stuff #declared that isn't required for the scene.
> Mike
Mike,
thanks a lot - I've rendered it, unused definitions is not a problem,
but the source of new ideas to me.

All the best,
--
YB

[Mike Miller] blob form study [1148 days 18 hours and 18 minutes ago]

Tue, 21 Feb 2023 02:40:00 GMT

Hi,
attached is a pov scene file that uses some simple 'point clustering' macros to
create interesting blob forms. Sorry about all the unused definitions in the
file. These's lot of stuff #declared that isn't required for the scene.
Mike

[Cousin Ricky] Re: Gamut-mapped spectral rendering [1153 days 23 hours and 25 minutes ago]

Wed, 15 Feb 2023 21:33:14 GMT

On 2017-05-08 13:14 (-4), Cousin Ricky wrote:
> I have made two sets of changes to the file SpectralComposer.pov in
> Lilysoft's spectral rendering rig.
> 
> [snip]
> 
> So as not to step on Ive's toes, I am only posting the changes I made,
> and not the entire file.

SpectralRender has recently been dedicated to the public domain, or the
legal equivalent thereof in your country.  I am therefore releasing my
complete modified files:

https://github.com/CousinRicky/POV-SpectralRender-mods

Have fun!

[Tor Olav Kristensen] Rewrite of tubecurves.pov (2D function to 3D tube) [1203 days 17 hours and 23 minutes ago]

Wed, 28 Dec 2022 03:35:00 GMT

In this post:

Newsgroup: povray.general
Subject: Re: 2D function to 3D tube
Date: 2022-12-26 07:05:00
From: Bald Eagle
https://news.povray.org/povray.general/message/%3Cweb.63a98d62560d61681f9dae3025979125%40news.povray.org%3E

- Bald Eagle posted a file; tubecurves.pov, for rendering a 3D tube around
a 2D function.

Here's a modified version of that file.

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[Bill Pragnell] Re: Voronoi cell polygon macro [1236 days 20 hours and 23 minutes ago]

Fri, 25 Nov 2022 00:35:00 GMT

Example usage:

#declare Sd = seed(0);
#declare N = 250;
#declare Points = array[N];
#for (I, 0, N-1)
 #declare Points[I] = <rand(Sd)*20-10, 0, rand(Sd)*20-10>;
#end

#declare Cells = array[1];
VoronoiCells(Points, Cells)

#for (I, 0, N-1)
 #declare NC = dimension_size(Cells[I], 1);
 #if (NC > 2)
  prism {
   0, rand(Sd)*4 + 1,
   NC+1,
   #for (J, 0, NC-1)
    <Cells[I][J].x, Cells[I][J].z>,
   #end
   <Cells[I][0].x, Cells[I][0].z>
   pigment { rgb <rand(Sd)*0.5+0.5, rand(Sd)*0.5+0.5, rand(Sd)*0.5+0.5> }
   finish { ambient 0 }
  }
 #end
#end

[Bill Pragnell] Voronoi cell polygon macro [1236 days 20 hours and 33 minutes ago]

Fri, 25 Nov 2022 00:25:00 GMT

Following threads in p.b.images, here's a more generically-useful version of my
Voronoi cells.

It's a macro that produces an array of Voronoi polygons in the x-z plane given
an input array of seed points. Each polygon is stored as a list of vertices, so
each element in the output array is itself an array of points (NOT a 2D array!).
The macro also removes collinear points, so each polygon might not be the same
size (use dimension_size to find the number of vertices for each polygon).

Also included is my util macro for shrinking a partly-assigned array.

Bill

[Dave Blandston] Website Mockup Animation Utility [1353 days 12 hours and 58 minutes ago]

Sun, 31 Jul 2022 08:00:00 GMT

This is a simple utility to animate a website design using .png images. The
utility will add an animatable mouse pointer and a slider bar if necessary. A
sample animation is posted in the binary animations section.

[Dave Blandston] Re: Master of Puppets Font [1359 days 15 hours and 53 minutes ago]

Mon, 25 Jul 2022 05:05:00 GMT

Added some new characters and a kerning optimization setting.

[Dave Blandston] Re: Weird Loop Behavior [1370 days and 33 minutes ago]

Thu, 14 Jul 2022 20:25:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> ideally that code/macro would take two args - the number of prisoners/boxes, and
> the number of chains (and perhaps dictate their lengths too?).  (have a feeling
> this code can find other uses :-))

If I understand correctly, a chain that's too long can be split into two chains
by altering only two slips. I'm guessing that it would be just as easy to
combine two chains into one. So what you're suggesting is very possible.

I was so intrigued by the riddle that I thought it would be fun to conduct a
successful simulated exercise with one million prisoners. It looks like that
will take about three weeks using POV-Ray so I probably won't do that after all.
But I think the array of randomly numbered slips could be analyzed quickly to
determine the longest chain and therefore if the actual exercise would succeed.

If anyone is interested, here's a version with a much quicker slip randomization
algorithm. That part was a lot of fun too because it depends on balancing two
slow operations (moving large numbers of array elements around versus randomly
picking array elements that haven't already been picked) and the balance point
turned out to be much different than I thought it would be.

Kind regards,
Dave Blandston

[jr] Re: Weird Loop Behavior [1370 days 6 hours and 3 minutes ago]

Thu, 14 Jul 2022 14:55:00 GMT

hi,

"Dave Blandston" <IsN### [at] protonmailch> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > question re code ...
> ... NSuccesses does not count the number of individual prisoners who find
> their numbers, it counts the number of successful exercises in which all
> prisoners find their numbers. ...

thanks  (makes sense, "or all fail together..").


> There is one part of the simulation that needs to be improved first, which is
> the part that puts a random slip in each box. The current code is extremely
> inefficient and will take about a week to complete for one million prisoners. I
> have an idea to speed this operation up significantly, which will be a fun
> exercise of its own.

ideally that code/macro would take two args - the number of prisoners/boxes, and
the number of chains (and perhaps dictate their lengths too?).  (have a feeling
this code can find other uses :-))


regards, jr.

[Dave Blandston] Re: Weird Loop Behavior [1371 days and 48 minutes ago]

Wed, 13 Jul 2022 20:10:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> question re code - NSuccesses only gets updated after all prisoners have looked
> at their boxes?  wondering, ought that not be something like:
>
>   #if (!MatchFound)  // fail
>     #break
>   #else
>     // add to NSuccesses
>   #end

Thanks jr! The #break instruction that gets executed when MatchFound is false
stops one round of the exercise early as soon as one prisoner fails to find his
number, then the next exercise begins which is controlled by the #for (I...)
loop. NSuccesses does not count the number of individual prisoners who find
their numbers, it counts the number of successful exercises in which all
prisoners find their numbers. I think it would be interesting to count how many
individual prisoners succeed though because, due to the inadvertent discovery,
it's obvious that the success or failure of the exercise can be determined well
before all the prisoners have actually completed the search for their numbers.

There is one part of the simulation that needs to be improved first, which is
the part that puts a random slip in each box. The current code is extremely
inefficient and will take about a week to complete for one million prisoners. I
have an idea to speed this operation up significantly, which will be a fun
exercise of its own.

Have an awesome day!

Kind regards,
Dave Blandston

[jr] Re: Weird Loop Behavior [1371 days 12 hours and 23 minutes ago]

Wed, 13 Jul 2022 08:35:00 GMT

hi,

"Dave Blandston" <IsN### [at] protonmailch> wrote:
> ...
> I've attached a file to demonstrate the issue more clearly. The #if ()
> conditional with the comment "//Why is this test necessary?" can be commented
> out for comparison purposes.

afaict the conditional is needed only for 3.7.x, the 3.8.0-beta.2 works without.

question re code - NSuccesses only gets updated after all prisoners have looked
at their boxes?  wondering, ought that not be something like:

  #if (!MatchFound)  // fail
    #break
  #else
    // add to NSuccesses
  #end

also re the "Dummy" making a difference, have looked for, but cannot find, a
link to a story I read a few years ago; in a Californian chip foundry they used
an AI to optimise a chip design, and that (then, too) had a single unconnected
diode in the layout which, when removed, stopped everything working, no
explanation was given :-).

regards, jr.

[jr] Re: bounding box calculator [1372 days 8 hours and 23 minutes ago]

Tue, 12 Jul 2022 12:35:00 GMT

hi,

posting the 5th, and probably final, version :-) of the macro.  a simple demo
scene is included, it uses the 'declare=I=N' syntax, where N is from '0' to '5'.

"Kenneth" <kdw### [at] gmailcom> wrote:
> I'm coming late to this discussion, sorry that I never saw it earlier.
> This looks useful for my current 'city buildings' scene, particularly for my
> 'rooftop greebles' and their correct placement.

it's been a while, so what happened?  ;-)

enjoy, jr.

[Dave Blandston] Re: Weird Loop Behavior [1372 days 12 hours and 13 minutes ago]

Tue, 12 Jul 2022 08:45:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> need to do more/better tests of "Issue number two" but didn't see a difference
> with conditional commented out.

Hey jr, thanks for taking a look at this! I did some more testing with issue
number two and it's really weird. Commenting out the #if () conditional does not
change the results, even with thousands of iterations, which suggests that it
doesn't affect the execution flow. BUT... replacing the "#local Dummy = 0;" line
with this "#debug concat ("Comparing: ", str (J, 0, 0), ", " str (Box
[WhichBox], 0, 0), "\n")" produces interesting/bazaar results. The purpose of
this line is to make sure that the "loop" described in the video is being
followed correctly, which it is. The "J" variable represents each prisoner so it
should go from 0 to N - 1 since each prisoner gets a turn at looking for his
number. The "Box [WhichBox]" variable represents the number on the slip of paper
inside each box.

With the #if () conditional in place, here are the results of the new #debug
statement for six prisoners and random seed 12:

Comparing: 0, 0

Comparing: 1, 4
Comparing: 1, 3
Comparing: 1, 1

Comparing: 2, 2

Comparing: 3, 1
Comparing: 3, 4
Comparing: 3, 3

Comparing: 4, 3
Comparing: 4, 1
Comparing: 4, 4

Comparing: 5, 5

This is exactly the output that I want. It shows that comparisons are made until
the correct number is found, and if it's found before the maximum allowed number
of attempts, the remaining allowed comparisons are skipped.

Here is the output with the #if () conditional commented out:

Comparing: 0, 0

Comparing: 1, 4
Comparing: 1, 3
Comparing: 1, 1

It appears that without the #if () conditional, when the maximum allowed number
of comparisons are made, then the outer loop is exited inappropriately by the
#break instruction. Values for J = 2 through 5 are totally missing, yet the
final computed result is the same! Madness! Here's some more diagnostic
information indicating that the program execution is being affected - for values
of 100 prisoners and 10000 iterations, there was a 16-second difference in
processing times and a large difference in the "Parsing ____K tokens" number
that POV displays. It would take a mathematical genius to figure out why the
final result is unaffected by this issue (I may have inadvertently discovered
something significant and am about to become famous - ha ha) but the issue with
the #for (J...) loop being exited prematurely (in my opinion) does seem to be a
real issue - unless that's how it's supposed to work.

I've attached a file to demonstrate the issue more clearly. The #if ()
conditional with the comment "//Why is this test necessary?" can be commented
out for comparison purposes.

Kind regards,
Dave Blandston

[jr] Re: Weird Loop Behavior [1372 days 14 hours and 3 minutes ago]

Tue, 12 Jul 2022 06:55:00 GMT

hi,

"Dave Blandston" <IsN### [at] protonmailch> wrote:
> ...
> There are two issues with this code. One might be a bug in POV-Ray, and the
> other is probably a feature but it doesn't work the way that would make sense to
> me. (Disclaimer: I'm an amateur so there's probably a reason that it works the
> way that it does that I'm not aware of.)
>
> Issue number one, possible POV bug: When I run the attached file with version
> 3.7, the final result that's displayed is 80% success rate. This is not an
> anticipated result. However, un-commenting the line "#local Dummy = 0;" changes
> the final result to 50% success rate, which appears to be correct. The variable
> "Dummy" is never used and should have no effect on anything.
>
> Issue number two, #break directive behavior: Without the #if () test marked with
> the comment "//Why is this test necessary?" the #break directive will exit not
> only the #for (K...) loop, but also the #for (J...) loop if the #break directive
> is executed on the last iteration of the #for (K...) loop. When that happens,
> the remainder of the #for (J...) loop is not completed as it should be (or as I
> think it should be, anyway).
>
> I'm mentioning these issues in case they might persist into version 3.8...

"Issue number one" -- a beauty :-) -- also happens in 3.8.0-beta.2, on a Linux.
need to do more/better tests of "Issue number two" but didn't see a difference
with conditional commented out.


regards, jr.

[Dave Blandston] Weird Loop Behavior [1372 days 23 hours and 58 minutes ago]

Mon, 11 Jul 2022 21:00:00 GMT

Greetings Friends,

This video https://www.youtube.com/watch?v=iSNsgj1OCLA introduces an algorithm
that's easy to write and I found it intriguing. SDL might not be ideal for this
sort of thing (relatively slow) but it's all I have set up for use at the moment
so that's what I used. It's not necessary to watch the video to see what's going
on with the POV code, by the way.

There are two issues with this code. One might be a bug in POV-Ray, and the
other is probably a feature but it doesn't work the way that would make sense to
me. (Disclaimer: I'm an amateur so there's probably a reason that it works the
way that it does that I'm not aware of.)

Issue number one, possible POV bug: When I run the attached file with version
3.7, the final result that's displayed is 80% success rate. This is not an
anticipated result. However, un-commenting the line "#local Dummy = 0;" changes
the final result to 50% success rate, which appears to be correct. The variable
"Dummy" is never used and should have no effect on anything.

Issue number two, #break directive behavior: Without the #if () test marked with
the comment "//Why is this test necessary?" the #break directive will exit not
only the #for (K...) loop, but also the #for (J...) loop if the #break directive
is executed on the last iteration of the #for (K...) loop. When that happens,
the remainder of the #for (J...) loop is not completed as it should be (or as I
think it should be, anyway).

I'm mentioning these issues in case they might persist into version 3.8...

Have a wonderful day folks!

Kind regards,
Dave Blandston

[Dave Blandston] Re: 3D Text with Sphere_sweeps [1393 days and 38 minutes ago]

Tue, 21 Jun 2022 20:20:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Now, IIRC, Mike Williams has done an impressive amount of work on tubes and
> splines and using them in isosurfaces to mimic sphere sweeps.   So If you wanted
> to implement the smoothing, then maybe the way to go would be to convert the
> code so that you were using proper isosurfaces right out of the gate, rather
> than a slow and inefficient conversion from a primitive.

OK that's interesting. The conversion did not look like it was going to work out
for this particular use because the documentation said that sharp edges would
produce jagged results. Most of the edges of the letters are rounded since
that's the whole point of the project, but the top of the "u" and bottom of the
"n" do have sharp edges. I'll see if Mike Williams' work can be used. Thank you
sir!

[jr] Re: 3D Text with Sphere_sweeps [1393 days 1 hour and 53 minutes ago]

Tue, 21 Jun 2022 19:05:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> ...
> Sacrilege indeed.   That's why we'd want to do something like convert the
> javascript that already does this to SDL.

that's an interesting page, some of the other posts I scanned cursorily looked
worth returning to.  thanks.

(sticking my neck out) I think we'd need WFP to become interested, make 'povr'
export/make visible the TTF data it (as pointed out) already has, in the parser;
pass in a text{} and get back metrics, that sort of thing.

regards, jr.

[Bald Eagle] Re: 3D Text with Sphere_sweeps [1393 days 10 hours and 43 minutes ago]

Tue, 21 Jun 2022 10:15:00 GMT

"Dave Blandston" <IsN### [at] protonmailch> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > Now the thing is, the objects have to be converted into isosurfaces for all of
> > this to work:
> >
> > #declare _Box = function (X, Y, Z) { max((X*X-1),(Y*Y-1),(Z*Z-1)) }
> > #declare _Sphere = function { x*x + y*y + z*z - 1 }
> >
> > And so you'd need to do a Bill P ObjectAsIso type conversion.  Because you can't
> > have the infinite gradient between object and no-object.
> >
> > So it would work, but it might be rather slow...
>
>
> Ah-ha! Thanks for the follow-up! I've been trying to figure out how to make it
> work since your last post - and not getting anywhere.

Now, IIRC, Mike Williams has done an impressive amount of work on tubes and
splines and using them in isosurfaces to mimic sphere sweeps.   So If you wanted
to implement the smoothing, then maybe the way to go would be to convert the
code so that you were using proper isosurfaces right out of the gate, rather
than a slow and inefficient conversion from a primitive.

[Dave Blandston] Re: 3D Text with Sphere_sweeps [1393 days 19 hours and 23 minutes ago]

Tue, 21 Jun 2022 01:35:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Now the thing is, the objects have to be converted into isosurfaces for all of
> this to work:
>
> #declare _Box = function (X, Y, Z) { max((X*X-1),(Y*Y-1),(Z*Z-1)) }
> #declare _Sphere = function { x*x + y*y + z*z - 1 }
>
> And so you'd need to do a Bill P ObjectAsIso type conversion.  Because you can't
> have the infinite gradient between object and no-object.
>
> So it would work, but it might be rather slow...


Ah-ha! Thanks for the follow-up! I've been trying to figure out how to make it
work since your last post - and not getting anywhere.

[Bald Eagle] Re: 3D Text with Sphere_sweeps [1393 days 20 hours and 43 minutes ago]

Tue, 21 Jun 2022 00:15:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Dave Blandston" <IsN### [at] protonmailch> wrote:
> > Here's a question for Bald Eagle - would your SmoothMinFunction code work on
> > this object? I added a picture to the povray.binaries.images thread highlighting
> > some of the areas where sphere_sweeps are unioned together where your
> > SmoothMinFunction would dramatically improve the appearance if it could be
> > applied. I looked at the SmoothMinFunction code and I must admit, the math is
> > way beyond my abilities.
>
> It should work just fine so long as the pieces that you want to smooth between
> are separate parts.
>
> You really don't need to understand any of the math - you just plug in the
> objects to the function - just like macro arguments.

isosurface {
    function {SmoothMin_Poly2 (_Box
(x*cos(Angle)-sin(Angle),y,z*sin(Angle)+cos(Angle)), _Sphere (x-3.5,y,z),
Strength)}
....
}

Now the thing is, the objects have to be converted into isosurfaces for all of
this to work:

#declare _Box = function (X, Y, Z) { max((X*X-1),(Y*Y-1),(Z*Z-1)) }
#declare _Sphere = function { x*x + y*y + z*z - 1 }

And so you'd need to do a Bill P ObjectAsIso type conversion.  Because you can't
have the infinite gradient between object and no-object.

So it would work, but it might be rather slow...

[Bald Eagle] Re: 3D Text with Sphere_sweeps [1393 days 21 hours and 18 minutes ago]

Mon, 20 Jun 2022 23:40:00 GMT

"Dave Blandston" <IsN### [at] protonmailch> wrote:
> Here's a question for Bald Eagle - would your SmoothMinFunction code work on
> this object? I added a picture to the povray.binaries.images thread highlighting
> some of the areas where sphere_sweeps are unioned together where your
> SmoothMinFunction would dramatically improve the appearance if it could be
> applied. I looked at the SmoothMinFunction code and I must admit, the math is
> way beyond my abilities.

It should work just fine so long as the pieces that you want to smooth between
are separate parts.

You really don't need to understand any of the math - you just plug in the
objects to the function - just like macro arguments.

[Bald Eagle] Re: 3D Text with Sphere_sweeps [1393 days 21 hours and 18 minutes ago]

Mon, 20 Jun 2022 23:40:00 GMT

"Dave Blandston" <IsN### [at] protonmailch> wrote:
> "
> It would be great if software existed that allowed one to draw curves over a
> background picture and export the data.

Why not just do what I did with the gear tooth counting project and turn the
image map into a heightfield.  Then you can scan around it with trace () and
compile a list of points.

Obviously this would only scan the exterior envelope, and so a method to get the
holes in letters like B, D, O, P, Q, and R would be required.  Maybe a stepwise
trace () across a vector accumulating a crossing number could be used to find
holes and start a sub-scan in the second "outside" region.

[Dave Blandston] Re: 3D Text with Sphere_sweeps [1393 days 21 hours and 23 minutes ago]

Mon, 20 Jun 2022 23:35:00 GMT

Here's a question for Bald Eagle - would your SmoothMinFunction code work on
this object? I added a picture to the povray.binaries.images thread highlighting
some of the areas where sphere_sweeps are unioned together where your
SmoothMinFunction would dramatically improve the appearance if it could be
applied. I looked at the SmoothMinFunction code and I must admit, the math is
way beyond my abilities.

[Dave Blandston] Re: 3D Text with Sphere_sweeps [1393 days 22 hours and 58 minutes ago]

Mon, 20 Jun 2022 22:00:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> That's why we'd want to do something like convert the
> javascript that already does this to SDL.
>
> http://stevehanov.ca/blog/?id=143

That looks like a promising method. That was what I wanted to do from the
beginning but I don't have the programming skill. Completely automating the
process would be difficult for the reasons you guys have already mentioned but
being able to extract the spline points from a .ttf file would be extremely
useful. POV-Ray can already read the data so I wonder if it would be possible to
export it easily.

I also considered using Jr's idea of using an image_map and that would allow
easier fine-tuning.

It would be great if software existed that allowed one to draw curves over a
background picture and export the data. This is close
https://forums.getpaint.net/topic/27512-trs-splinemaster-v143-a-line-maker-july-1-2019/
but it appears to use a different type of curve. It would still be helpful if it
could export the control points to a .txt file to save having to type them.

Kind regards,
Dave Blandston

[Bald Eagle] Re: 3D Text with Sphere_sweeps [1394 days and 38 minutes ago]

Mon, 20 Jun 2022 20:20:00 GMT

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

> if you have access to the font file.  iiuc, DB's use of a(n intermediate) bitmap
> has the advantage that any text (and not only text shapes) can be used.

Indeed.  But I think it would be possible to implement both, as one is sort of a
subset of the other.

  _and_
> you'd need an external utility to get the ttf data (sacrilege.. :-)).

Sacrilege indeed.   That's why we'd want to do something like convert the
javascript that already does this to SDL.

http://stevehanov.ca/blog/?id=143

> > Might be a little challenging with "forked" glyphs like E, F, K, etc....
>
> could not the same (sphere_sweep) data be used to position/help shape the
> prism(s)?

I was thinking that something like an E would be more than 1 sphere sweep, so
there would have to be some mechanism for determining where the joints/bends
are.
The prisms aren't the problem - that's just a continuous outline, which is easy.
 It's defining the centerline font where it's gets tricky

[jr] Re: 3D Text with Sphere_sweeps [1394 days 1 hour and 8 minutes ago]

Mon, 20 Jun 2022 19:50:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > thinking that some code to "scan" ...
>
> I would say that since most TTF fonts are rendered using Bezier splines, it
> would be most efficient to find a way to load in the control points from the
> font file itself.

if you have access to the font file.  iiuc, DB's use of a(n intermediate) bitmap
has the advantage that any text (and not only text shapes) can be used.  _and_
you'd need an external utility to get the ttf data (sacrilege.. :-)).

> Perhaps one way to transform the outline of the fonts, which is used to render
> them as a prism {}, into a "centerline font" would be to employ the
> inside/outside crossing number testing used for prisms, and calculate the
> gradient and therefore the normal of the outline.  Then find the midpoint of
> that vector to get a centerline control point for the sphere sweep.

prism/"extruded" is interesting, could get sharp-edged shapes with complex
layouts of each "stroke".

> Might be a little challenging with "forked" glyphs like E, F, K, etc....

could not the same (sphere_sweep) data be used to position/help shape the
prism(s)?

regards, jr.

[Bald Eagle] Re: 3D Text with Sphere_sweeps [1394 days 3 hours and 28 minutes ago]

Mon, 20 Jun 2022 17:30:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "Dave Blandston" <IsN### [at] protonmailch> wrote:
> > Some notes:
> > ...
> > It's fairly easy but a little tedious to make characters with this macro. What
> > worked for me was to make a bitmap image of the characters with a paint program
> > then mark locations along a path following the center of the character strokes.
>
> thinking that some code to "scan" a black+white/any high contrast image, as
> image_map texture on a box or a plane, would automate that step (leaving only
> the "tedium" of providing the char/word bitmaps :-))

I would say that since most TTF fonts are rendered using Bezier splines, it
would be most efficient to find a way to load in the control points from the
font file itself.

> > The <x, y> coordinates of the marks can then be typed into Coordinate [] array
> > entries and if necessary the diameter multipliers can be adjusted. With a little
> > practice one can achieve acceptable results. Don't forget that the first and
> > last locations aren't actually plotted since the macro uses the b_spline
> > sphere_sweep method.
>
> am still quite amazed at how few points are needed.

Well, that IS the idea behind using splines to render fonts.

Perhaps one way to transform the outline of the fonts, which is used to render
them as a prism {}, into a "centerline font" would be to employ the
inside/outside crossing number testing used for prisms, and calculate the
gradient and therefore the normal of the outline.  Then find the midpoint of
that vector to get a centerline control point for the sphere sweep.

Might be a little challenging with "forked" glyphs like E, F, K, etc....

[jr] Re: 3D Text with Sphere_sweeps [1394 days 4 hours and 43 minutes ago]

Mon, 20 Jun 2022 16:15:00 GMT

hi,

"Dave Blandston" <IsN### [at] protonmailch> wrote:
> Some notes:
> ...
> It's fairly easy but a little tedious to make characters with this macro. What
> worked for me was to make a bitmap image of the characters with a paint program
> then mark locations along a path following the center of the character strokes.

thinking that some code to "scan" a black+white/any high contrast image, as
image_map texture on a box or a plane, would automate that step (leaving only
the "tedium" of providing the char/word bitmaps :-))

> The <x, y> coordinates of the marks can then be typed into Coordinate [] array
> entries and if necessary the diameter multipliers can be adjusted. With a little
> practice one can achieve acceptable results. Don't forget that the first and
> last locations aren't actually plotted since the macro uses the b_spline
> sphere_sweep method.

am still quite amazed at how few points are needed.


regards, jr.

[Dave Blandston] 3D Text with Sphere_sweeps [1394 days 10 hours and 23 minutes ago]

Mon, 20 Jun 2022 10:35:00 GMT

Some notes:

The MakeCharacter () macro uses the following variables:

Coordinate [] is an array containing <x, y> spline coordinates plus a diameter
multiplier. The actual format is <x, y, multiplier>.

NPoints indicates the number of spline points in the Coordinate [] array.

HeightFactor adjusts the scale of the character without changing the diameter.

BaseRadius is the default sphere_sweep diameter.

UseLastMinsAndMaxs is useful for making multiple parts of a character to be
unioned together.

It's fairly easy but a little tedious to make characters with this macro. What
worked for me was to make a bitmap image of the characters with a paint program
then mark locations along a path following the center of the character strokes.
The <x, y> coordinates of the marks can then be typed into Coordinate [] array
entries and if necessary the diameter multipliers can be adjusted. With a little
practice one can achieve acceptable results. Don't forget that the first and
last locations aren't actually plotted since the macro uses the b_spline
sphere_sweep method.

Happy raytracing!

Kind regards,
Dave Blandston

[jr] Re: counting macro calls [1403 days 12 hours and 8 minutes ago]

Sat, 11 Jun 2022 08:50:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> attached is a small include to provide a "total macro calls" count, for
> specified macros.

posting a cleaned-up version, the macros were renamed in camelCase to fit with
other includes.  in case it ("the obvious") needs saying - counters can also be
used outside of macros, for instance per-case in a '#switch', or per-branch in
some '#if ... #end'.

enjoy, jr.

[jr] counting macro calls [1412 days 7 hours and 18 minutes ago]

Thu, 2 Jun 2022 13:40:00 GMT

hi,

attached is a small include to provide a "total macro calls" count, for
specified macros.

usage is v simple.  after "instrumenting" the macro(s) of interest, in the
scene, write:

  #include "tmc.inc"
  #declare tmc_ = tmc_new();
    ...
  tmc_report(tmc_)

the 'incr' macro is shown as an example of using 'tmc_add()', which does the
counting:

  #macro _incr(v_,optional n_)
    tmc_add(global.tmc_,"incr")
    #if (!defined(local.n_))
      #local n_ = 1;
    #end
    #local v_ = v_ + n_;
  #end

add a call to 'tmc_add()' to every macro of interest, and that's it.  the
'global' is not needed, but hey..  the following output is clipped from a puzzle
solver I'm playing with, from two different runs:

exiting solver, after 7th pass:
  #hexas completed - 16
  #slots completed - 27
  puzzle '211126' solved.
-----[tmc]--------------------------------------------------------------
          48 : setDigit
        1042 : incr
          16 : need2proc
          21 : copySets
         120 : isAvailable
          10 : need3proc
         336 : singleton
           5 : need1proc
  ---------- : ----------
        1598 : 8
------------------------------------------------------------------------

exiting solver, after 6th pass:
  #hexas completed - 16
  #slots completed - 25
  puzzle '220531' solved.
-----[tmc]--------------------------------------------------------------
          48 : setDigit
         905 : incr
          19 : need2proc
          19 : copySets
          88 : isAvailable
           8 : need3proc
         288 : singleton
           7 : need1proc
  ---------- : ----------
        1382 : 8
------------------------------------------------------------------------

perhaps I ought to sort the output by name :-), suggestions/feedback welcome.
in case there's interest,
I'll post the image for the '220531' puzzle in p.b.i.


enjoy, jr.

[Dave Blandston] Re: Master of Puppets Font [1450 days 17 hours and 38 minutes ago]

Mon, 25 Apr 2022 03:20:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> Aaah... the arcane hidden knowledge! I am just a simple apprentice
> sorcerer, burning his fingers every other day. :-)


Oh, I know better than that...

[Thomas de Groot] Re: Master of Puppets Font [1452 days 6 hours and 16 minutes ago]

Sat, 23 Apr 2022 14:41:59 GMT

Op 23-4-2022 om 10:26 schreef Dave Blandston:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> Win10/11: In the include file, I commented-out lines 4061-4063, and the
>> render was correct.
>>
>> Thanks for your work!
> 
> 
> I understand just barely enough about what's going on that I should have thought
> to suggest that. Here's a possible way to restore the functionality that
> commenting out those lines removes, if you happen to want to change settings and
> make a new text object within the same scene - you can #declare new settings
> (MOP_Gap, MOP_Space, MOP_FontRadius, and/or MOP_UseFrenchQuoteMarks) then
> #include the file again. That's inefficiency on a Microsoft scale, but it will
> probably work as a temporary fix.
> 
> You're very welcome! I'm happy to contribute where I can and I greatly
> appreciate what everyone here shares!
> 
> Kind regards,
> Dave Blandston
> 

Aaah... the arcane hidden knowledge! I am just a simple apprentice 
sorcerer, burning his fingers every other day. :-)

Thanks for your suggestion. Great app btw!

-- 
Thomas

[Dave Blandston] Re: Master of Puppets Font [1452 days 12 hours and 28 minutes ago]

Sat, 23 Apr 2022 08:30:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> Win10/11: In the include file, I commented-out lines 4061-4063, and the
> render was correct.
>
> Thanks for your work!

I understand just barely enough about what's going on that I should have thought
to suggest that. Here's a possible way to restore the functionality that
commenting out those lines removes, if you happen to want to change settings and
make a new text object within the same scene - you can #declare new settings
(MOP_Gap, MOP_Space, MOP_FontRadius, and/or MOP_UseFrenchQuoteMarks) then
#include the file again. That's inefficiency on a Microsoft scale, but it will
probably work as a temporary fix.

You're very welcome! I'm happy to contribute where I can and I greatly
appreciate what everyone here shares!

Kind regards,
Dave Blandston

[jr] Re: Master of Puppets Font [1452 days 15 hours and 13 minutes ago]

Sat, 23 Apr 2022 05:45:00 GMT

hi,

Thomas de Groot <tho### [at] degrootorg> wrote:
> Win10/11: In the include file, I commented-out lines 4061-4063, and the
> render was correct.

wow, nice!  same result here, thanks.


regards, jr.

[Thomas de Groot] Re: Master of Puppets Font [1453 days 9 hours and 1 minute ago]

Fri, 22 Apr 2022 11:57:02 GMT

Win10/11: In the include file, I commented-out lines 4061-4063, and the 
render was correct.

Thanks for your work!

-- 
Thomas

[Dave Blandston] Re: Master of Puppets Font [1454 days 1 hour and 43 minutes ago]

Thu, 21 Apr 2022 19:15:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> v 3.8 (qtpovray)
>
> Parse Warning: Encountered 'charset' global
> setting. As of POV-Ray v3.8, this mechanism of specifying character encoding is
> no longer supported, and future versions may treat the presence of the setting
> as an error.
> Possible Parse Error: Invoking macro from here.
> at File: MasterOfPuppetsFont.inc Line: 4062 Col: 43
> Parse Error: Unable to file seek in macro invocation.
> at File: MasterOfPuppetsFont.inc Line: 598 Col: 45
> Fatal error in parser: Cannot parse input.
> Render failed

Sorry about the failure. There's more information here:
http://news.povray.org/povray.binaries.images/thread/%3Cweb.624c0826fffed05bc26296d607c1b34%40news.povray.org%3E/

The charset thing isn't necessary and it just got copy-and-pasted from another
scene. Thanks for letting me know.

Have an awesome day,
Dave Blandston

[Bald Eagle] Re: Master of Puppets Font [1454 days 3 hours and 28 minutes ago]

Thu, 21 Apr 2022 17:30:00 GMT

v 3.8 (qtpovray)

Parse Warning: Encountered 'charset' global
setting. As of POV-Ray v3.8, this mechanism of specifying character encoding is
no longer supported, and future versions may treat the presence of the setting
as an error.
Possible Parse Error: Invoking macro from here.
at File: MasterOfPuppetsFont.inc Line: 4062 Col: 43
Parse Error: Unable to file seek in macro invocation.
at File: MasterOfPuppetsFont.inc Line: 598 Col: 45
Fatal error in parser: Cannot parse input.
Render failed

[jr] Re: Master of Puppets Font [1454 days 7 hours and 38 minutes ago]

Thu, 21 Apr 2022 13:20:00 GMT

hi,

"Dave Blandston" <IsN### [at] protonmailch> wrote:
> Here's a simple scene file to display all the characters for reference (16 x 9
> aspect ratio).

the good news, it works for v3.7.0.8 (and a v3.7.1-alpha). the bad news, does
not work with v3.7.1-rc1 and later (on GNU/Linux).  anyway, thanks + cheers.

regards, jr.

[Dave Blandston] Re: Master of Puppets Font [1454 days 16 hours and 58 minutes ago]

Thu, 21 Apr 2022 04:00:00 GMT

Here's a simple scene file to display all the characters for reference (16 x 9
aspect ratio).

[Dave Blandston] Re: Master of Puppets Font [1454 days 17 hours and 13 minutes ago]

Thu, 21 Apr 2022 03:45:00 GMT

Added a few more characters, improved the smiley face, and fixed the ampersand.

[jr] sweets [1466 days 9 hours and 58 minutes ago]

Sat, 9 Apr 2022 11:00:00 GMT

hi,

I recently discovered Mr Higo's wonderful all things POV-Ray site[*], and have
adapted one of his creations ("Sweets", 'lpntsphr.txt') as a macro:
  #macro HigoSweet(dict)

an example with code, meant to replicate TH's image, will be posted in p.b.i.

note that one of the shapes is quite different from TH's.  the original source
gave me many "degenerate" triangle warnings, which I quieted by adding a couple
of 'abs()' calls in .. likely looking places, obviously not quite the right ones
:-).  in addition, I added a "metallic" finish to his pigmentation (though the
texture can be disabled).

everything in the include (except macro name) is prefixed 'th_', for Tsutomu
Higo, the dictionary keys are documented in the file's header.

[*] <http://www.asahi-net.or.jp/~nj2t-hg/ilpove.htm>


enjoy, jr.

[Alain Martel] Re: Master of Puppets Font [1467 days 5 hours and 34 minutes ago]

Fri, 8 Apr 2022 15:24:39 GMT

Le 2022-04-07 Ã  15:03, Dave Blandston a Ã©critÂ :
> Compatibility update

Works well in version 3.8. Thank you.

[Dave Blandston] Re: Master of Puppets Font [1468 days 1 hour and 53 minutes ago]

Thu, 7 Apr 2022 19:05:00 GMT

Compatibility update

[Dave Blandston] Re: Master of Puppets Font [1469 days 18 hours and 53 minutes ago]

Wed, 6 Apr 2022 02:05:00 GMT

Added support for French quote marks.

[Dave Blandston] Re: Master of Puppets Font [1470 days 11 hours and 53 minutes ago]

Tue, 5 Apr 2022 09:05:00 GMT

Added some new characters, automatic kerning is now good enough that the ability
to turn it off is no longer needed.

[jr] Re: packed variables [1477 days 7 hours and 13 minutes ago]

Tue, 29 Mar 2022 13:45:00 GMT

hi,

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 28/03/2022 om 01:16 schreef jr:
> > the aim of 'pvars.inc' is ...
>
> Interesting stuff. I need to study this carefully as it could help me to
> plant trees (or other objects) in a more streamlined way than what I do now.

thanks v much for looking it over, hope the code will simply .. slot in.

attached is version 2.  there was one typo (boolean misspelled) and the wrong
file name in the '#debug' (an oversight when renaming from "working title");
also took the opportunity to reformat 'pvClear()'.

regards, jr.

[Thomas de Groot] Re: packed variables [1477 days 14 hours and 13 minutes ago]

Tue, 29 Mar 2022 06:45:21 GMT

Op 28/03/2022 om 01:16 schreef jr:
> hi,
> 
> the aim of 'pvars.inc' is to provide a way to reduce the number of global
> variables used in one's POV-Ray scenes, and to have to hand a convenient "type"
> much like a small 'array mixed', for related variables.
> 

Interesting stuff. I need to study this carefully as it could help me to 
plant trees (or other objects) in a more streamlined way than what I do now.

-- 
Thomas

[jr] packed variables [1478 days 21 hours and 38 minutes ago]

Sun, 27 Mar 2022 23:20:00 GMT

hi,

the aim of 'pvars.inc' is to provide a way to reduce the number of global
variables used in one's POV-Ray scenes, and to have to hand a convenient "type"
much like a small 'array mixed', for related variables.

the "idea" came about from a (not infrequent) need to keep two index and one
boolean variable, for each of many objects.  also perhaps influenced by BC's
"PROOF" threads, that is thinking about "abstractions" and such, and about one's
"footprint" in the global namespace.

a "packed variable" is simply a 4-vector where the four components can be
treated as individual variables/elements, addressed via a zero-based index.

the include file contains a small number of macros which make up the
"interface".  visible (global) identifiers in the file are prefixed 'pv'.
POV-Ray's vector operands and functions will work as expected.

the "documentation" consists of a brief description of the macros in the include
file's header, and example usage in the scene code I will post in p.b.a. "Ulam
Spiral Fun" next.

as an example, say I want to animate a number of objects/shapes, and in each
frame need to calculate the new point where each object will be.  my packed
variable might then be '<x,y,z,i>', where 'i' is an index for the 'shapes'
array.  and to update the point, likely, I'd use a small macro, something like:

  #macro calcPoint(pv_,clock_)
    #local (x_,y_,z_,i_) = pvUnpack(pv_);
    /* calc new x,y,z.
     * can, of course, still use 'pv_.x' etc directly.
     */
    #local pv_ = pvPack(x_,y_,z_,i_);
  #end

and then pass the variable to some other macro to place the object, etc.

as always, comments, feedback, criticisms, all (equally) welcome.


enjoy, jr.

[Dave Blandston] Re: Master of Puppets Font [1496 days 3 hours and 23 minutes ago]

Thu, 10 Mar 2022 17:35:00 GMT

Fixed the "@" character.

[Dave Blandston] Re: Master of Puppets Font [1497 days 13 hours and 3 minutes ago]

Wed, 9 Mar 2022 07:55:00 GMT

Added the "@" character and improved the kerning.

[Dave Blandston] Re: Master of Puppets Font [1512 days 13 hours and 23 minutes ago]

Tue, 22 Feb 2022 07:35:00 GMT

Tweak to the kerning rules...

[Dave Blandston] Re: Master of Puppets Font [1512 days 16 hours and 53 minutes ago]

Tue, 22 Feb 2022 04:05:00 GMT

Includes lower case letters now.

[jr] Re: greatest common divisor [1542 days 12 hours and 8 minutes ago]

Sun, 23 Jan 2022 08:50:00 GMT

hi,

kurtz le pirate <kur### [at] gmailcom> wrote:
> To make it easier to use, you can also make :
> (do not pay attention to the order of parameters)
>
> #macro m_gcd(a_,b_)
>   #local ta_ = max(a_,b_);
>   #local tb_ = min(a_,b_);
>   #while (tb_)
>   ...

neat.  although the condition is not the same, accepting A = B makes no
(practical) difference, afaict.  thanks.

regards, jr.

[Dave Blandston] Re: Master of Puppets Font [1542 days 13 hours and 28 minutes ago]

Sun, 23 Jan 2022 07:30:00 GMT

Just one more entry in the "Final" series of posts...

[kurtz le pirate] Re: greatest common divisor [1543 days 4 hours and 7 minutes ago]

Sat, 22 Jan 2022 16:51:20 GMT

On 13/01/2022 17:30, jr wrote:
> hi,
> 
> posting my (naive) implementation of the "Euclidean"[*] method to calculate the
> gcd, in case it'll be of use to others.  googling for "gcd" (and spelled out) on
> the news.povray site, surprising to me, got zero results

To make it easier to use, you can also make :
(do not pay attention to the order of parameters)

#macro m_gcd(a_,b_)
  #local ta_ = max(a_,b_);
  #local tb_ = min(a_,b_);
  #while (tb_)
  ...



;)

-- 
Kurtz le pirate
Compagnie de la Banquise

[jr] Re: greatest common divisor [1551 days 3 hours and 23 minutes ago]

Fri, 14 Jan 2022 17:35:00 GMT

hi,

"Dave Blandston" <IsN### [at] protonmailch> wrote:
> Hey, that's a really interesting algorithm! I'm inspired to learn how that
> works. Thanks!

heh, better you than me!  :-)  I can follow how it works, and given sufficient
time I might even have thought of subtracting all multiples of B from A, but
then to swap B + A, never, I simply lack understanding of even the basic
"properties" of numbers.  hope your brain can take the "edutainment" ;-).

regards, jr.

[Dave Blandston] Re: greatest common divisor [1551 days 22 hours and 43 minutes ago]

Thu, 13 Jan 2022 22:15:00 GMT

Hey, that's a really interesting algorithm! I'm inspired to learn how that
works. Thanks!

Kind regards,
Dave Blandston

[jr] greatest common divisor [1552 days 4 hours and 23 minutes ago]

Thu, 13 Jan 2022 16:35:00 GMT

hi,

posting my (naive) implementation of the "Euclidean"[*] method to calculate the
gcd, in case it'll be of use to others.  googling for "gcd" (and spelled out) on
the news.povray site, surprising to me, got zero results.

[*] <https://en.wikipedia.org/wiki/Greatest_common_divisor#Euclidean_algorithm>


regards, jr.

[Dave Blandston] Re: Master of Puppets Font [1552 days 22 hours and 18 minutes ago]

Wed, 12 Jan 2022 22:40:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> Thanks for this. A nice font. I downloaded it.


You're very welcome, I hope it's useful!

Best regards,
Dave Blandston

[Thomas de Groot] Re: Master of Puppets Font [1553 days 8 hours and 13 minutes ago]

Wed, 12 Jan 2022 12:45:37 GMT

Op 12-1-2022 om 11:48 schreef Dave Blandston:
> I cleaned up the code quite a bit, improved more characters, improved the
> instructions, and added rudimentary automatic kerning.

Thanks for this. A nice font. I downloaded it.

-- 
Thomas

[Dave Blandston] Re: Master of Puppets Font [1553 days 10 hours and 8 minutes ago]

Wed, 12 Jan 2022 10:50:00 GMT

I cleaned up the code quite a bit, improved more characters, improved the
instructions, and added rudimentary automatic kerning.

[Dave Blandston] Re: Master of Puppets Font [1558 days 12 hours and 28 minutes ago]

Fri, 7 Jan 2022 08:30:00 GMT

Well I've decided that I like this totally tubular font so well because of it's
reflective properties as compared to a flat font that I've continued to fine
tune it and here's the current version.

[Paolo Gibellini] Pov30 scene file [1565 days 3 hours and 7 minutes ago]

Fri, 31 Dec 2021 17:51:35 GMT

See reply in p.b.i.

Paolo

[Dave Blandston] Re: Master of Puppets Font [1566 days 11 hours and 33 minutes ago]

Thu, 30 Dec 2021 09:25:00 GMT

I noticed that I forgot to attach the file for that last update so here it is
just in case someone wants to use it someday. This final (?) update has some
significant improvements to the letters "C," "G," "M," "N," and "Z" as well as
more ease-of-use improvements.

[Timothy Groves] The Elder Futhark [1568 days 5 hours and 25 minutes ago]

Tue, 28 Dec 2021 15:33:07 GMT

Source code used to generate the Elder Futhark.  They are in traditional 
order, with runestone(0) being Fehu.

[Dave Blandston] Re: Stone with Veins [1570 days 10 hours and 53 minutes ago]

Sun, 26 Dec 2021 10:05:00 GMT

Cleaned up and added comments...

[Dave Blandston] Stone with Veins [1571 days 12 hours and 23 minutes ago]

Sat, 25 Dec 2021 08:35:00 GMT

This is the source code for a mediocre granite texture, plus a texture that can
be used for veins in the stone. Experimentation is necessary for good results!

Kind regards,
Dave Blandston

[jr] Re: Master of Puppets Font [1581 days 13 hours and 13 minutes ago]

Wed, 15 Dec 2021 07:45:00 GMT

hi,

"Dave Blandston" <IsN### [at] protonmailch> wrote:
> Simple font made mostly of sphere_sweeps, patterned after the "Master of
> Puppets" album cover.

cheers.


regards, jr.

[Dave Blandston] Re: Master of Puppets Font [1581 days 13 hours and 13 minutes ago]

Wed, 15 Dec 2021 07:45:00 GMT

This should be the final version - for real this time. The "W" has been haunting
me so it's finally a real "W" instead of a poorly-modified upside-down "M." Plus
a couple minor ease-of-use improvements.

[Dave Blandston] Re: Master of Puppets Font [1582 days 7 hours and 28 minutes ago]

Tue, 14 Dec 2021 13:30:00 GMT

Shame on me for being too lazy to add a macro to make this a little easier to
use. Here's a much better version...

[Dave Blandston] Master of Puppets Font [1582 days 10 hours and 18 minutes ago]

Tue, 14 Dec 2021 10:40:00 GMT

Simple font made mostly of sphere_sweeps, patterned after the "Master of
Puppets" album cover.

[jr] Re: Filed() macro for CSV data file handling [1625 days 12 hours and 3 minutes ago]

Mon, 1 Nov 2021 08:55:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ... It was a gain of about 3% on the write side and
> %2 percent on the read.
> ...

faster parsing is better of course, but I now think I need to do the read side
different.


regards, jr.

[William F Pokorny] Re: Filed() macro for CSV data file handling [1626 days 6 hours and 11 minutes ago]

Sun, 31 Oct 2021 14:47:09 GMT

On 10/30/21 7:10 PM, William F Pokorny wrote:
> A big chunk of the time is in the scanner.cpp code qualify bits and 
> pieces of potential tokens. As to how to make that all 'significantly' 
> faster within the current framework - no luck thus far. We'll see.

OK. I chased one pocket of scanner expense by changing from a set of 
conditional tests for character classification to a boolean array[256] 
with predetermined answers. I wanted to see how much movement / 
improvement I could get. It was a gain of about 3% on the write side and 
%2 percent on the read.

I think I see my way clear to folding up to eight character 
classifications in the space the boolean array is actually taking. This 
would allow us to change some(all?) of the 'if else if... else' 
conditional chains to a more direct switch construct. A WILD guess is 
we'd at most gain 10-15% total (2/3% above being in that savings).

If the guess about right, it would not be  a game changer - but the 
relative ease of implementation is there. I haven't decided whether to 
attempt the change in my povr branch.

Random thinking.
---------------

- In the end we are working character by character in the parser and 
this is expensive. Further, we are repeatedly classifying characters and 
tokens.

- The non-pure ascii (<=255) character encoding costs. An advantage utf8 
encoding for the SDL has over others is it's smaller and so faster.

- Relatedly, Christoph is using an internal to POV-Ray utf8 class based 
upon std::string. This is common practice with c++ programs and it's 
safe. It's the case though that as we walk that utf8 class by character, 
incrementing pointers the length checking is costing a few percent of 
the overall run time. Well... at least the profiling indicates this 
length checking cost.

- My updates above are related to the newest version of the parser and 
not the older one in v3.8 beta*.

- The newer parser changes in v4.0 and povr are substantial and they 
were only the initial push for what Christoph ultimately had in mind. 
Testing of those changes showed improved performance. I'm not, however, 
sure what all else was intended. Heck, to a degree the new parser is 
still new-ish to me. Until now, I've only dug around in the parser code 
to try and fix particular bugs.

- On staring at the profile results now over some days, I have few wild 
parser ideas banging around in my head for the parser. Unfortunately, 
most all are not that easy to just code up and try.

- A reminder the v4.0 / povr parsing is only faster than v3.8 beta* for 
the test cases in this thread - if a collection of parser asserts is 
turned off (see configparser.h). Christoph was actively working on the 
parser in late 2018 and early 2019. These would have eventually been 
turned off for normal release compiles.

Bill P.

[William F Pokorny] Re: Filed() macro for CSV data file handling [1626 days 21 hours and 48 minutes ago]

Sat, 30 Oct 2021 23:10:25 GMT

On 10/29/21 9:36 AM, William F Pokorny wrote:
> A puzzle I've not been able to run down is the larger 'system' write 
> times post v3.8 beta. It's very roughly around +12.5% of the raw and fld 
> write slow down v3.8 beta to p380 (so it hits povr too though it's 
> faster overall). Something is driving up that system time from raw and 
> fld writes, but I've not been able to find it.

An update.

--- stress_wr.pov
We can improve(1) the write side cpu time by -7.0% and the elapsed time 
by -9.3% by not using rand.inc's (VRand(rng_)) macro, but rather:

#local arr_[i_] = array mixed [2] \ 
{<rand(rng_),rand(rng_),rand(rng_)>,rand(rng_)};

Further, it appears the macro caching of VRand() is somehow tangled in 
the increased system time v3.8 beta to p380 branch/povr - I still don't 
see how. It still might be that if that cause could be run down, one 
could use VRand() without as much penalty.

(1) - To speed compiles I dropped the link time optimization. The 
improvement where configuring with --enable-lto will be somewhat different.

--- stress_rd.pov

A big chunk of the time is in the scanner.cpp code qualify bits and 
pieces of potential tokens. As to how to make that all 'significantly' 
faster within the current framework - no luck thus far. We'll see.

Bill P.

[William F Pokorny] Re: Filed() macro for CSV data file handling [1628 days 7 hours and 22 minutes ago]

Fri, 29 Oct 2021 13:36:04 GMT

On 10/29/21 5:35 AM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> ...
>> Not yet to profiling, but I've turned up a few things. First, I don't
>> see the +700% write side slow down you see, but rather about +280% so
>> this is more in line with your expectations for write vs read.
> 
> intend to install the new povr in the coming days.  will then run some tests,
> including another 100k.  thanks for posting the timings.  (1200% is a high price
> to pay, for convenience..  :-))
>

Ultimately it's user time which matters. If machines are paying and 
users still win measuring task time, it's the right trade off.

---
I understand more as of this morning. A large chunk of the p380 branch / 
povr slow down was due always-active soft asserts Christoph added to 
some of the last parser updates. These took me a while to understand and 
untangle/turn off for the 'regular' povr build.

So! Timing with my in hand povr.

stress_wr.pov
p380b1     ---> povr fld  6.87 -> 5.42 ---> -21.11%

p380b1 raw ---> fld +283.44%
povr   raw ---> fld +234.57% (-40%)

stress_rd.pov
p380b1     ---> povr fld  8.39 -> 6.38 ---> -23.98%

p380b1 raw ---> fld +1140.32%
povr   raw ---> fld +1103.77% (-36%)

So, I'm happy to see povr and likely P380 too, without the soft asserts, 
is quite a bit faster. I expect some of the speed up is due Christoph's 
newer parser updates and some due my changes, but I've not done the p380 
builds and timings to see how the savings break out - I'm not all that 
interested so that work probably won't happen.

A puzzle I've not been able to run down is the larger 'system' write 
times post v3.8 beta. It's very roughly around +12.5% of the raw and fld 
write slow down v3.8 beta to p380 (so it hits povr too though it's 
faster overall). Something is driving up that system time from raw and 
fld writes, but I've not been able to find it.

For now I'm walking away from it - Christoph cleaned up / changed quite 
a lot related to file and text streams over the last months ahead of the 
branch point for povr. I don't see an obvious cause - and my 
guesses(shots in the dark) as to cause have missed.

I hope to get to some actual code profiling today.

Bill P.

[jr] Re: Filed() macro for CSV data file handling [1628 days 11 hours and 18 minutes ago]

Fri, 29 Oct 2021 09:40:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> Not yet to profiling, but I've turned up a few things. First, I don't
> see the +700% write side slow down you see, but rather about +280% so
> this is more in line with your expectations for write vs read.

intend to install the new povr in the coming days.  will then run some tests,
including another 100k.  thanks for posting the timings.  (1200% is a high price
to pay, for convenience..  :-))

regards, jr.

[William F Pokorny] Re: Filed() macro for CSV data file handling [1629 days 8 hours and 9 minutes ago]

Thu, 28 Oct 2021 12:49:03 GMT

On 10/28/21 6:11 AM, William F Pokorny wrote:
> On 10/28/21 3:02 AM, jr wrote:
...
> 
> Thank you. I've grabbed it. I'll need my morning coffee too! :-)
> 
...

Not yet to profiling, but I've turned up a few things. First, I don't 
see the +700% write side slow down you see, but rather about +280% so 
this is more in line with your expectations for write vs read.

I'm interested in where povr is and I was surprised to find it slower 
than p380b1.

On investigation found the parser updates coming after what is in the 
v3.8 betas(1) - which povr adopted / branched from - are themselves 
slower. More significantly so on the write side. My povr branch is 
running faster than the branch point, but... Guess for me that is the 
first thing to try and figure out.

Bill P.

(1) - Christoph backtracked the newest parser updates for the v3.8 release.

Ref:

stress_wr.pov  (100k)
p380   raw - 2.05user 0.25system 0:02.84elapsed 81%CPU
p380   fld - 6.87user 0.33system 0:07.74elapsed 93%CPU

p380b1 raw - 1.57user 0.02system 0:02.14elapsed 74%CPU
p380b1 fld - 6.02user 0.06system 0:06.61elapsed 91%CPU

povr   raw - 1.92user 0.24system 0:02.71elapsed 79%CPU
povr   fld - 6.39user 0.28system 0:07.21elapsed 92%CPU

p380b1 raw ---> fld  1.57 -> 6.02 ---> +283.44%  (You suggested +700%)
p380   raw ---> fld  2.05 -> 6.97 ---> +240.00%
povr   raw ---> fld  1.92 -> 6.39 ---> +232.81%

p380b1 -> p380 raw  1.57 -> 2.05 ---> +30.57% (p380 povr branch point)
p380   -> povr raw  2.05 -> 1.92 ---> -6.34%  (povr < 380 branch point)

p380b1 -> p380 fld  6.02 -> 6.87 ---> +14.12% (p380 povr branch point)
p380   -> povr fld  6.87 -> 6.39 --->  -6.99% (povr < 380 branch point)


stress_rd.pov  (100k)
p380   raw - 0.64user 0.02system 0:01.20elapsed 55%CPU
p380   fld - 8.39user 0.08system 0:09.00elapsed 94%CPU

p380b1 raw - 0.62user 0.03system 0:01.19elapsed 54%CPU
p380b1 fld - 7.69user 0.07system 0:08.29elapsed 93%CPU

povr   raw - 0.61user 0.01system 0:01.17elapsed 53%CPU
povr   fld - 7.90user 0.06system 0:08.50elapsed 93%CPU

p380b1 raw ---> fld  0.62 -> 7.69 ---> +1140.32%
p380   raw ---> fld  0.64 -> 8.39 ---> +1210.94%
povr   raw ---> fld  0.61 -> 7.90 ---> +1195.08%

p380b1 -> p380 raw  0.62 -> 0.64 ---> +3.23% (p380 povr branch point)
p380   -> povr raw  0.64 -> 0.61 ---> -4.69% (povr < 380 branch point)

p380b1 -> p380 fld  7.69 -> 8.39 ---> +9.10% (p380 povr branch point)
p380   -> povr fld  8.39 -> 7.90 ---> -5.84% (povr < 380 branch point)

[William F Pokorny] Re: Filed() macro for CSV data file handling [1629 days 10 hours and 47 minutes ago]

Thu, 28 Oct 2021 10:11:36 GMT

On 10/28/21 3:02 AM, jr wrote:
...
> 
> the reading did not surprise much, every item returned is "handled" three times,
> but the (lack of) write performance I do not understand.
...
>> I'd be willing to play a little with your 100K spheres case - if you
>> want?
> 
> thanks, sure.  have attached a reader and writer scene.  for the writer can use
> 'declare=N=number' to create number records, for both scenes can use
> 'declare=FM=true' to use Filed() instead of "raw" directives.
...

Thank you. I've grabbed it. I'll need my morning coffee too! :-)

Thinking I'll do some real profiling again. It's gotten to be a year or 
more since I've done any - and I'd like to look at rtr that way too.

With rtr I can tell some of the delay with smaller render sizes is the 
mutex locking mechanism itself. This aligning with a note I'd guess 
Chris made way back when in the code. Beyond that I'm not sure what 
profiling might reveal - or not.

Bill P.

[jr] Re: Filed() macro for CSV data file handling [1629 days 13 hours and 53 minutes ago]

Thu, 28 Oct 2021 07:05:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 10/26/21 9:57 AM, jr wrote:
> > with 100k sphere centre and radius records for instance, POV-Ray needs around
> > one second for the writing and the same for the read back.  Filed() comes in at
> > around eight seconds write and ten seconds read.
> >
>
> I'm a little surprised at the magnitude of the slow down. Are you timing
> with a v3.8 beta or something else? I'm expecting the files are all on a
> ramdisk?

the reading did not surprise much, every item returned is "handled" three times,
but the (lack of) write performance I do not understand.

> Thinking aloud...
>
> If a povr branch, ...

ah, no, "stock" alpha.9945627.  fyi (snipped the context below), all POV-Rays
and povr etc built with '-O2'.

> I'd be willing to play a little with your 100K spheres case - if you
> want?

thanks, sure.  have attached a reader and writer scene.  for the writer can use
'declare=N=number' to create number records, for both scenes can use
'declare=FM=true' to use Filed() instead of "raw" directives.

regards, jr.

[William F Pokorny] Re: Filed() macro for CSV data file handling [1630 days 9 hours and 55 minutes ago]

Wed, 27 Oct 2021 11:02:54 GMT

On 10/26/21 9:57 AM, jr wrote:
> "jr" <cre### [at] gmailcom> wrote:
...
> 
> with 100k sphere centre and radius records for instance, POV-Ray needs around
> one second for the writing and the same for the read back.  Filed() comes in at
> around eight seconds write and ten seconds read.
> 

Hi,

I'm a little surprised at the magnitude of the slow down. Are you timing 
with a v3.8 beta or something else? I'm expecting the files are all on a 
ramdisk?

Thinking aloud...

If a povr branch, was it heavily optimized ahead of the build/make via 
configure script options?

Re: The povr branch is running with a C++11 string hash function for the 
symbol tables in the parser / vm over the traditional POV-Ray one. In my 
testing the C++11 one is only faster if the compile options are 
relatively aggressive(1,2).

In general, with the dictionary stuff being relatively new to v3.8, 
there is likely room to make the parser faster around that functionality.

I'd be willing to play a little with your 100K spheres case - if you 
want?

Bill P.

(1) - A reminder, the povr branch build system does NO optimization by 
default when the configure script is run.

(2) - The C++11 hashing of strings is much better, but it's more complex 
code and takes longer than POV-Ray's method. The old hashing tends to 
clump table entries around the leading ascii character value(s).

[jr] Re: Filed() macro for CSV data file handling [1631 days 6 hours and 58 minutes ago]

Tue, 26 Oct 2021 14:00:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > attached include file provides a macro for reading and writing the POV-Ray
> > variant of CSV data files.  the use is documented in a HTML page, and a few
> > demo/example scenes.
>
> version 2.  includes the various improvements to documentation and demo code
> suggested by WFP (thanks!).

after running some tests with larger files, I have added the following paragraph
to the HTML page:

"using the Filed() macro comes at a run-time cost, alas.  for data sets of
hundreds, or low thousands, of records, the time taken is unnoticeable, though
if there are hundreds of thousands or more, it may (in an animation, perhaps)
become enough of an issue to consider sticking with the #read and #write
directives."

with 100k sphere centre and radius records for instance, POV-Ray needs around
one second for the writing and the same for the read back.  Filed() comes in at
around eight seconds write and ten seconds read.

regards, jr.

[jr] Re: Filed() macro for CSV data file handling [1639 days 5 hours and 23 minutes ago]

Mon, 18 Oct 2021 15:35:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> antialias_threshold = 0.0

adopted the settings as suggested.  see a little over 3 seconds improvement for
'toa'.  :-)

> ...
> I'm a fan of seeing the actual file names if relatively easy, but at a
> minimum maybe something like "existing output files()" were found.
> (Missing input...?). Maybe the issue not that important with other
> include sorted.

not easy, hope the compromise will suit.  have posted an updated version
incorporating all suggestions a moment ago.

regards, jr.

[jr] Re: Filed() macro for CSV data file handling [1639 days 5 hours and 23 minutes ago]

Mon, 18 Oct 2021 15:35:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> attached include file provides a macro for reading and writing the POV-Ray
> variant of CSV data files.  the use is documented in a HTML page, and a few
> demo/example scenes.

version 2.  includes the various improvements to documentation and demo code
suggested by WFP (thanks!).

enjoy, jr.

[jr] Re: Filed() macro for CSV data file handling [1641 days 5 hours and 23 minutes ago]

Sat, 16 Oct 2021 15:35:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> I dug a little. The ugly background table AA comes from using
> 'antialias_gamma = 1' though the file_gamma at 1.0 makes the saved
> images linear/dark too. Both settings should go away.
> ...
> First, I screwed up on my recommendation in not have the
> antialias_threshold at 0.0. The fastest good result I see for the
> suggested render sizes, if that's your aim when shipping the package, is
> to use:
>
> sampling_method = 2
> antialias_threshold = 0.0
> antialias_depth = 2
> jitter = off
> // 10.85user 0.09system 0:03.86elapsed

thank you for "digging" and recommending a better set of parameters.  will
simply use those.


> ... That first attempt did create those two output files, but I
> didn't notice. ...

:-)  lost count of the number of times this happened to me, in the later stages
of development.


regards, jr.

[Thomas de Groot] Re: Filed() macro for CSV data file handling [1641 days 14 hours and 7 minutes ago]

Sat, 16 Oct 2021 06:51:18 GMT

Op 15/10/2021 om 16:46 schreef William F Pokorny:

> (1) The initial set of flowers end up orange. Maybe?
> 
> #declare AmericanRose = srgb <1,0.01176,0.24314>;
> ...
> pigment {AmericanRose*0.5}
> 

That is a beautiful colour! I added it to my collection of 
textures/pigments (under construction).


-- 
Thomas

[William F Pokorny] Re: Filed() macro for CSV data file handling [1642 days 6 hours and 12 minutes ago]

Fri, 15 Oct 2021 14:46:17 GMT

On 10/15/21 5:14 AM, jr wrote:
> hi,
> 
...
> 
>> ---
>>
>> The flowers.pov file already has the tabulated.inc guard set to 1
>> contrary to the scene's comments.
> 
> Thomas held up his hand, but I did not "see" it either.  will change the
> default, and thinking of adding an '#if' guard in 'flowers_read.pov' too.
> 

Adding it too flowers_read.pov would be helpful. Aiding my confusion as 
to how the animation was supposed to work was the table being in the 
background showing about half red(1) entries and yellow entries - which 
I rather dumbly took as some indication of what I should see for 
distribution for flower colors.

(1) The initial set of flowers end up orange. Maybe?

#declare AmericanRose = srgb <1,0.01176,0.24314>;
...
pigment {AmericanRose*0.5}

> 
>> ---
>>
>> The flowers_read.pov animation doesn't look to me to be picking up all
>> the yellow flowers? Maybe one or two per asteroid? I didn't investigate
>> though, perhaps it's working as expected?
> 
> the animation runs from planting the last few reds to the first few dozen
> yellows only.
> 

Thanks Thomas, I now understand.

> 
>> ---
>>
>> With the flowers.ini AA, at least on linux with v3.8 and povr, the
>> method 3 AA doesn't look very good. Perhaps something like:
>>
>> sampling_method = 2
>> antialias_threshold = 0.005
>> antialias_depth = 3
>> jitter = on
> 
> as Thomas wrote, setting the 'file_gamma' in the ini was a bad idea, will remove
> it.  does removing it address the issue without changing 'sampling_method' etc?
> 

I dug a little. The ugly background table AA comes from using 
'antialias_gamma = 1' though the file_gamma at 1.0 makes the saved 
images linear/dark too. Both settings should go away.

Of interest, perhaps, regarding aa method 3 here. I measured these times 
and results on my Ubuntu 20.04 system.

  8.16cpu 0:03.16elapsed (antialias_gamma = 1; shipped result ugly)
26.76cpu 0:07.89elapsed (No antialias_gamma = 1; result good)
19.31cpu 0:06.10elapsed (No antialias_gamma = 1; result good; povr(*))

(*) Here the development compile being used is not that optimized and 
it's still faster. This is demonstrating the povr branch's fix to 
prevent the color channel sqrt() of negative values and subsequent 
undefined behavior. With povr the method 3 AA isn't sometimes running 
exhaustively to the recursion limit no matter other settings.

First, I screwed up on my recommendation in not have the 
antialias_threshold at 0.0. The fastest good result I see for the 
suggested render sizes, if that's your aim when shipping the package, is 
to use:

sampling_method = 2
antialias_threshold = 0.0
antialias_depth = 2
jitter = off
// 10.85user 0.09system 0:03.86elapsed

With the background table we have a very regular grid and this a case. 
Ultimately, we have to shoot enough rays to 'see' the detail we want 
cleanly visible.

The method 3 AA often works, but it presently has a known weakness in 
not being able to force an initial minimum set of samples (and this 
should probably be done to some isotropic density of samples).

The faster method 2 approach above might miss detail too at other render 
resolutions / aspect ratios.

...
> 
>> ---
>>
>> With the toa example, where the "toa_state.txt" or "toa_run.log" already
>> exist we get an error message via toal__chkFilesExist(), but the error
>> message only says "existing file(s)" were found.
> 
> or, conversely, "missing file(s)".  my thinking was/is that for animation run, I
> only need to know whether both or neither (state + log) exist, depending on
> frame_number, so the macro only provides a result for that.  how should I write
> the corresponding messages to read better?
> 

I'm a fan of seeing the actual file names if relatively easy, but at a 
minimum maybe something like "existing output files()" were found. 
(Missing input...?). Maybe the issue not that important with other 
include sorted.

My initial animation render didn't work because I was missing an 
include. That first attempt did create those two output files, but I 
didn't notice. And because I'd played around with the earlier demos I 
first thought perhaps I'd created some file which was colliding with the 
toa demo. I was slow to realize I had created files on the first failed 
attempt which were now an issue. If everything is cleaner from the 
start, there will be less potential for confusion.

Bill P.

[jr] Re: Filed() macro for CSV data file handling [1642 days 11 hours and 43 minutes ago]

Fri, 15 Oct 2021 09:15:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 10/13/21 10:43 AM, jr wrote:
> > attached include file provides a macro for reading and writing the POV-Ray
> > variant of CSV data files.  the use is documented in a HTML page, and a few
> > demo/example scenes.
>
> Great work! Another useful macro - and some cool demos too. Robot
> battles... ;-)

thank you.

> Ran through all the demos and didn't pick up any issues with my current
> package of IO fixes / changes. I do have some comments on the Filed()
> package itself.

nice.  (and taken time for feedback.  \o/ yay..  :-)  in order, then)

> ---
>
> "...missing out a field or an empty field..."
>
> perhaps?
>
> "...a missing field or an empty field..."

agree.  will make the change.

> ---
>
> The flowers.pov file already has the tabulated.inc guard set to 1
> contrary to the scene's comments.

Thomas held up his hand, but I did not "see" it either.  will change the
default, and thinking of adding an '#if' guard in 'flowers_read.pov' too.

> ---
>
> The flowers_read.pov animation doesn't look to me to be picking up all
> the yellow flowers? Maybe one or two per asteroid? I didn't investigate
> though, perhaps it's working as expected?

the animation runs from planting the last few reds to the first few dozen
yellows only.

> ---
>
> With the flowers.ini AA, at least on linux with v3.8 and povr, the
> method 3 AA doesn't look very good. Perhaps something like:
>
> sampling_method = 2
> antialias_threshold = 0.005
> antialias_depth = 3
> jitter = on

as Thomas wrote, setting the 'file_gamma' in the ini was a bad idea, will remove
it.  does removing it address the issue without changing 'sampling_method' etc?

> ---
>
> The toa example needs too the jr's ruled.inc - Ruled() and this is not
> mentioned in the documentation and there is no pointer as to where to
> grab it.

yes.  will add a 'references' section to the html, for both 'ruled.inc' and
'tabulated.inc'.

> ---
>
> The toa example needs the arial.ttf font which is not - by default -
> available for most non windows users.

good point too.  will switch to a distribution font.

> ---
>
> With the toa example, where the "toa_state.txt" or "toa_run.log" already
> exist we get an error message via toal__chkFilesExist(), but the error
> message only says "existing file(s)" were found.

or, conversely, "missing file(s)".  my thinking was/is that for animation run, I
only need to know whether both or neither (state + log) exist, depending on
frame_number, so the macro only provides a result for that.  how should I write
the corresponding messages to read better?

regards, jr.

[Thomas de Groot] Re: Filed() macro for CSV data file handling [1642 days 13 hours and 53 minutes ago]

Fri, 15 Oct 2021 07:05:38 GMT

Hi Bill,
I shall just answer on those issues you mention about flowers.

Op 14/10/2021 om 19:38 schreef William F Pokorny:
> On 10/13/21 10:43 AM, jr wrote:
>> hi,
>>
>> attached include file provides a macro for reading and writing the 
>> POV-Ray
>> variant of CSV data files.  the use is documented in a HTML page, and 
>> a few
>> demo/example scenes.
>>
>>
> 
> Great work! Another useful macro - and some cool demos too. Robot 
> battles... ;-)
> 
> Ran through all the demos and didn't pick up any issues with my current 
> package of IO fixes / changes. I do have some comments on the Filed() 
> package itself.
> 
> ---
> 
> "...missing out a field or an empty field..."
> 
> perhaps?
> 
> "...a missing field or an empty field..."
> 
> ---
> 
> The flowers.pov file already has the tabulated.inc guard set to 1 
> contrary to the scene's comments.
> 
I missed that one!

> ---
> 
> The flowers_read.pov animation doesn't look to me to be picking up all 
> the yellow flowers? Maybe one or two per asteroid? I didn't investigate 
> though, perhaps it's working as expected?
> 
If you kept the default numbers of flowers (400 Red; 300 Yellow; total 
of 700 flowers in flowers.txt), those numbers are also rendered in 
flowers_read.pov. At least, that is what I see here. To be certain, just 
delete flowers.txt, and run flowers.pov again, after checking the number 
of flowers to be planted.

However, if you run the flowers.ini animation, be sure to set 
initial_frame and final_frame to the values you want. Standard, a range 
of frames is given, typically showing the passage from the Red flowers 
to the Yellow ones (in the default settings). For a complete animation, 
both values of course should be set accordingly.

> ---
> 
> With the flowers.ini AA, at least on linux with v3.8 and povr, the 
> method 3 AA doesn't look very good. Perhaps something like:
> 
> sampling_method = 2
> antialias_threshold = 0.005
> antialias_depth = 3
> jitter = on
> 
These are jr's settings. Note that I had to comment out the file_gamma = 
1 line, as this command resulted in very dark frames, compared to the 
original renders.

> ---
> 
> The toa example needs too the jr's ruled.inc - Ruled() and this is not 
> mentioned in the documentation and there is no pointer as to where to 
> grab it.
> 
> ---
> 
> The toa example needs the arial.ttf font which is not - by default - 
> available for most non windows users.
> 
> ---
> 
> With the toa example, where the "toa_state.txt" or "toa_run.log" already 
> exist we get an error message via toal__chkFilesExist(), but the error 
> message only says "existing file(s)" were found.
> 
> ---
> 
> Bill P.


-- 
Thomas

[William F Pokorny] Re: Filed() macro for CSV data file handling [1643 days 3 hours and 20 minutes ago]

Thu, 14 Oct 2021 17:38:39 GMT

On 10/13/21 10:43 AM, jr wrote:
> hi,
> 
> attached include file provides a macro for reading and writing the POV-Ray
> variant of CSV data files.  the use is documented in a HTML page, and a few
> demo/example scenes.
> 
> 

Great work! Another useful macro - and some cool demos too. Robot 
battles... ;-)

Ran through all the demos and didn't pick up any issues with my current 
package of IO fixes / changes. I do have some comments on the Filed() 
package itself.

---

"...missing out a field or an empty field..."

perhaps?

"...a missing field or an empty field..."

---

The flowers.pov file already has the tabulated.inc guard set to 1 
contrary to the scene's comments.

---

The flowers_read.pov animation doesn't look to me to be picking up all 
the yellow flowers? Maybe one or two per asteroid? I didn't investigate 
though, perhaps it's working as expected?

---

With the flowers.ini AA, at least on linux with v3.8 and povr, the 
method 3 AA doesn't look very good. Perhaps something like:

sampling_method = 2
antialias_threshold = 0.005
antialias_depth = 3
jitter = on

---

The toa example needs too the jr's ruled.inc - Ruled() and this is not 
mentioned in the documentation and there is no pointer as to where to 
grab it.

---

The toa example needs the arial.ttf font which is not - by default - 
available for most non windows users.

---

With the toa example, where the "toa_state.txt" or "toa_run.log" already 
exist we get an error message via toal__chkFilesExist(), but the error 
message only says "existing file(s)" were found.

---

Bill P.

[jr] Filed() macro for CSV data file handling [1644 days 6 hours and 13 minutes ago]

Wed, 13 Oct 2021 14:45:00 GMT

hi,

attached include file provides a macro for reading and writing the POV-Ray
variant of CSV data files.  the use is documented in a HTML page, and a few
demo/example scenes.


enjoy, jr.

[jr] Re: Tabulated() macro, making tables easy [1657 days 10 hours and 28 minutes ago]

Thu, 30 Sep 2021 10:30:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 9/18/21 5:15 AM, jr wrote:
> > will consider the reference
> > link point; am thinking a wiki page with latest version of each include I've
> > done?
> That would work. Aim, of course, is knowing quickly whether one has the
> latest package/zip in hand, and if not, where to grab it.

would appears to be the operative word.  wrote to Mr Cason re wiki a little over
a week ago, no reply.  seems countering git-hubris with fact may have been ..
counter-productive.  :-)  (anyone seen clipka??)

> Suppose the answer to that second question, depends some on the answer
> to the first. My best guess is '-into' won't be in the next one, if
> another tarball gets publish relatively soon.

personally I'd be happy to play with an unpublished version (hint, hint).

regards, jr.

[William F Pokorny] Re: Tabulated() macro, making tables easy [1668 days 11 hours and 17 minutes ago]

Sun, 19 Sep 2021 09:41:41 GMT

On 9/18/21 5:15 AM, jr wrote:
> will consider the reference
> link point; am thinking a wiki page with latest version of each include I've
> done?
That would work. Aim, of course, is knowing quickly whether one has the 
latest package/zip in hand, and if not, where to grab it.

Bill P.

[jr] Re: Tabulated() macro, making tables easy [1669 days 11 hours and 38 minutes ago]

Sat, 18 Sep 2021 09:20:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:

(that statistical summary table does look properly "intimidating :-))


> A few minor comments after my first use - version 202106.2.
>
> 1)----------
> You can get rid of the high ambient warning by changing:
>
> #declare tabu__data_finishes_ = array [2] {
>    finish {ambient .1 diffuse .8 specular .1},
>    finish {ambient 0 emission .85}
> };
>
> to
>
> #declare tabu__data_finishes_ = array [2] {
>    finish {ambient .1 emission 0 diffuse .8 specular .1},
>    finish {ambient 0 emission .85}
> };

thanks, will do.


> 2)----------
> Documentation. (Great by the way)

(thank you.  always the most difficult part of a project, I think)


> Where you have references to your google drive for your Foreach() and
> Ruled() variation at the bottom of the documentation, it would be handy
> to have a reference/link to the most current Tabulated() too.
>
> A nit, but, indicating the Tabulated() version to which the
> documentation pertains in the html would be helpful.

yes, thanks, will make note of the version in text.  will consider the reference
link point; am thinking a wiki page with latest version of each include I've
done?


> 3)----------
>
> Not unexpectedly ;-) ..., the macro uses all lower case identifiers, but
> well prefixed ones. For the povr branch, this does force a configuration
> and compile without the identifier case checking to make use of it.

heh, mine was already compiled to allow lowercase.  :-)


> Great work jr & Tabulated() development helpers!

both BE + TdeG deserve those cheers.


regards, jr.

[William F Pokorny] Re: Tabulated() macro, making tables easy [1671 days 6 hours and 35 minutes ago]

Thu, 16 Sep 2021 14:22:55 GMT

On 8/15/21 5:53 PM, jr wrote:
> "jr" <cre### [at] gmailcom> wrote:
>> please find attached the new 'Tabulated()' macro, designed to add tables to
>> scene files, displaying related information.
> 
> the second release/version of 'Tabulated()' adds an option for highlighting a
> cell, or a range of.  (fingers crossed) the code now has fewer bugs, and the
> introductory comments have been completed.  as always, comments, tips, and
> critique welcome.
> 

A few minor comments after my first use - version 202106.2.

1)----------
You can get rid of the high ambient warning by changing:

#declare tabu__data_finishes_ = array [2] {
   finish {ambient .1 diffuse .8 specular .1},
   finish {ambient 0 emission .85}
};

to

#declare tabu__data_finishes_ = array [2] {
   finish {ambient .1 emission 0 diffuse .8 specular .1},
   finish {ambient 0 emission .85}
};

2)----------
Documentation. (Great by the way)

Where you have references to your google drive for your Foreach() and 
Ruled() variation at the bottom of the documentation, it would be handy 
to have a reference/link to the most current Tabulated() too.

A nit, but, indicating the Tabulated() version to which the 
documentation pertains in the html would be helpful.

3)----------

Not unexpectedly ;-) ..., the macro uses all lower case identifiers, but 
well prefixed ones. For the povr branch, this does force a configuration 
and compile without the identifier case checking to make use of it.

Great work jr & Tabulated() development helpers!

Bill P.

[jr] Re: Tabulated() macro, making tables easy [1702 days 13 hours and 18 minutes ago]

Mon, 16 Aug 2021 07:40:00 GMT

hi,

Thomas de Groot <tho### [at] degrootorg> wrote:
> To avoid confusion, it might be important to add version/release numbers
> to the zips.

agree, thanks.


regards, jr.

[Thomas de Groot] Re: Tabulated() macro, making tables easy [1702 days 14 hours and 52 minutes ago]

Mon, 16 Aug 2021 06:05:53 GMT

Op 15/08/2021 om 23:53 schreef jr:
> "jr" <cre### [at] gmailcom> wrote:
>> please find attached the new 'Tabulated()' macro, designed to add tables to
>> scene files, displaying related information.
> 
> the second release/version of 'Tabulated()' adds an option for highlighting a
> cell, or a range of.  (fingers crossed) the code now has fewer bugs, and the
> introductory comments have been completed.  as always, comments, tips, and
> critique welcome.
> 
> 
> enjoy, jr.
> 

To avoid confusion, it might be important to add version/release numbers 
to the zips.

-- 
Thomas

[jr] Re: Tabulated() macro, making tables easy [1702 days 23 hours and 3 minutes ago]

Sun, 15 Aug 2021 21:55:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> please find attached the new 'Tabulated()' macro, designed to add tables to
> scene files, displaying related information.

the second release/version of 'Tabulated()' adds an option for highlighting a
cell, or a range of.  (fingers crossed) the code now has fewer bugs, and the
introductory comments have been completed.  as always, comments, tips, and
critique welcome.

enjoy, jr.

[jr] Tabulated() macro, making tables easy [1719 days 7 hours and 13 minutes ago]

Fri, 30 Jul 2021 13:45:00 GMT

hi,

please find attached the new 'Tabulated()' macro, designed to add tables to
scene files, displaying related information.

the archive includes an include file, a "manual"/documentation HTML page, and
several demo/example scenes.  to install, unzip the archive (will create
directory 'tabu'), then link or copy the .inc file to a POV-Ray "library_path"
directory.

two people have volunteered to be guinea pigs, you know who you are, thanks; any
remaining errors/bugs are mine.  feedback, criticisms, tips -- all equally
welcome (more or less ;-))


enjoy, jr.

[Mike Horvath] Re: Pigment is not showing up [1796 days 19 hours and 9 minutes ago]

Fri, 14 May 2021 01:49:14 GMT

On 5/13/2021 8:37 PM, Bald Eagle wrote:
> So, I think you're going to have to do it another way.
> 2 stage render?   1st using slope, then 2nd using that first render as an image
> map?
> 
> 

Yes, thanks.


Mike

[Bald Eagle] Re: Pigment is not showing up [1796 days 20 hours and 18 minutes ago]

Fri, 14 May 2021 00:40:00 GMT

Mike Horvath <mik### [at] gmailcom> wrote:

> The problem seems to be the slope pattern. It does not work when used in
> this manner. Other patterns are okay.

Right, the slope pattern needs something to operate ON.  Otherwise what value
should the slope have?  The slope of WHAT?

http://news.povray.org/povray.advanced-users/thread/%3Cweb.5e9285d148d892ebfb0b41570%40news.povray.org%3E/

So, I think you're going to have to do it another way.
2 stage render?   1st using slope, then 2nd using that first render as an image
map?

[Mike Horvath] Re: Pigment is not showing up [1796 days 20 hours and 54 minutes ago]

Fri, 14 May 2021 00:04:29 GMT

On 5/13/2021 6:30 PM, Mike Horvath wrote:
> I am trying to multiply some pigments together and then apply them to a 
> heightfield. However the render is blank. Compare pigment_5 (average) 
> with pigment_6 (multiply). The latter is blank the former is not.
> 
> What am I doing wrong?
> 
> Render as a square image using this image as input:
> 
> https://en.wikipedia.org/wiki/File:Heightmap.png


The problem seems to be the slope pattern. It does not work when used in 
this manner. Other patterns are okay.


Mike

[Mike Horvath] Pigment is not showing up [1796 days 22 hours and 28 minutes ago]

Thu, 13 May 2021 22:30:33 GMT

I am trying to multiply some pigments together and then apply them to a 
heightfield. However the render is blank. Compare pigment_5 (average) 
with pigment_6 (multiply). The latter is blank the former is not.

What am I doing wrong?

Render as a square image using this image as input:

https://en.wikipedia.org/wiki/File:Heightmap.png

[jr] Re: foreach macro [1797 days 3 hours and 33 minutes ago]

Thu, 13 May 2021 17:25:00 GMT

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

a discussion in another thread made me look at various files in the '/scenes/'
directories, with view of updating code to "modern" v 3.8 SDL.

I have attached a zip with a few files, crudely adapted for 'Foreach()' use[*].
 (ideally they'd be re-written such as not to have a new "dependency")

[*] that is existing code surrounded with '#if (0) ... #end', followed by a
functionally equivalent foreach, and '#version' set where needed.


regards, jr.

[jr] Re: foreach macro [1798 days 23 hours and 48 minutes ago]

Tue, 11 May 2021 21:10:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> ...
> the html "man" page has been updated to reflect all changes, ...

due to faulty thinking and .. laziness </sigh> I had assumed that the underlying
array is not affected when the current element is modified (in the payload).
wrong.  worse, I wrote in the man page that it's safe to do.  then I ran into
trouble with a trashed array in some scene code + realised.  v sorry.  the
corrected man page is attached.

regards, jr.

[jr] Re: foreach macro [1801 days 18 hours and 3 minutes ago]

Sun, 9 May 2021 02:55:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> posting #4 of 'Foreach()', probably final.

posting a new version, #5.

some of the code has been refactored and tidied up.  many changes were
"cosmetic", there are now no comments within any macro, for instance, and the
layout of the '.Verbose' output has been adjusted.  all this has resulted in a
small, but measurable, improvement in "performance"; the 'n19tst.pov' posted
earlier in this thread went from ~4m7s to ~3m59s, and a "monkeyed" version, with
all comments and blank lines etc removed, saves another 6 seconds or so.

the optional '.Arg' has been .. de-coupled from its dependence on the '.Extra'
flag, providing additional flexibility from here on.

the html "man" page has been updated to reflect all changes, and another
(complete) demo scene has been added.  the 'fore_demo.pov' scene is now
accompanied by the (long) overdue 'fore_demo.ini' file.

feedback on how to make 'Foreach()' better will be appreciated.


enjoy, jr.

[jr] Re: foreach macro [1812 days 5 hours and 33 minutes ago]

Wed, 28 Apr 2021 15:25:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> ...
> all v strange.  my hunch is that Parse_String is involved indirectly only.  the
> exact naming seems to matter, ...

took same code as the original 'nesting.pov', changed all macro names to _not_
include numeric digits, and - fine.  hth.


regards, jr.

[jr] Re: foreach macro [1812 days 6 hours and 28 minutes ago]

Wed, 28 Apr 2021 14:30:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 4/27/21 7:56 PM, William F Pokorny wrote:
> > On 4/27/21 6:52 AM, jr wrote:
> >> ...
> Is it worth further chasing and changing, if this is how v3.8 works
> today? I vote NO.

(sorry, forgot)

agree it's no real problem, will make note in foreach docs that a handful of
levels (ie sane usage) is ok, beyond you take chances.

regards, jr.

[jr] Re: foreach macro [1812 days 6 hours and 33 minutes ago]

Wed, 28 Apr 2021 14:25:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> Played a few minutes with this just now and you can get your original
> code to run if you change the tail m_l10 macro to:
>
> #macro m_l10(i_,n_)
>    #debug concat("----------> level 10, n = ",str(n_,0,0),".\n")
>    #fopen FID "parse_fore.tmp" write
>    #write (FID,"#---\n")
>    #fclose FID
> #end
>
> Though by the time it finishes it's consumed 1.6G or more of memory
> after maybe five minutes. My wild guess is all those Parse_String(s) end
> up sitting in memory until parsing is finished. In other words I think
> at the end we have unrolled more or less the whole recursion.
>
> Parse_String is involved in what's happening, but it's not clear to me,
> why - some scope issue maybe as it comes after the last "call" to m_l10.

all v strange.  my hunch is that Parse_String is involved indirectly only.  the
exact naming seems to matter, so I wonder what happens when 'm_l10' gets
inserted in the symbol table (cf TOK's error message).  the level of nesting --
thinking of calling it "voluntary recursion" :-) -- is not the problem I think,
attached a scene that nests/recurses to 19 levels, no problems (except time +
memory consumption ;-))  will try and find a little time in next days to play
with different naming "schemes".

regards, jr.

[William F Pokorny] Re: foreach macro [1812 days 7 hours and 10 minutes ago]

Wed, 28 Apr 2021 13:48:29 GMT

On 4/27/21 7:56 PM, William F Pokorny wrote:
> On 4/27/21 6:52 AM, jr wrote:
>> hi,
>>
> 
> Played a few minutes with this just now and you can get your original 
> code to run if you change the tail m_l10 macro to:
> 
> #macro m_l10(i_,n_)
>    #debug concat("----------> level 10, n = ",str(n_,0,0),".\n")
>    #fopen FID "parse_fore.tmp" write
>    #write (FID,"#---\n")
>    #fclose FID
> #end
> 
...
> 
> Parse_String is involved in what's happening, but it's not clear to me, 
> why - some scope issue maybe as it comes after the last "call" to m_l10.
> 

OK.

Not 100% sure, in that I've not proven it by making all the 
'parse_fore.tmp' names unique, but I believe we are reading (or I 
suspect continuing to read) via a now back in scope #include to a common 
file with updated, and longer contents written in the previous deeper 
scope(1).

If in your include we add two lines to 'empty' the included file after 
including / dynamically interpreting the intended string:

#macro fore_exec(s_)
   #local fn_ = "parse_fore.tmp";
   #fopen fp_ fn_ write
   #write (fp_,s_)
   #fclose fp_
   #include fn_
   #fopen fp_ fn_ write  // Making file empty here fixes issue too
   #fclose fp_
#end

The code runs OK.

You ask, "So, this is an issue to which the strings.inc's
Parse_String() macro has always been exposed too?" Yes, I suspect so 
though I've not gone back to older versions of POV-Ray to try and 
reproduce the issue.

Is it worth further chasing and changing, if this is how v3.8 works 
today? I vote NO.

I'm thinking the practical fix is our 'Parse_String()'s should always 
empty the file just included.

We should remember too the Parse_String() method is a hack; It's bad 
practice to be writing and reading the same file name from multiple 
scene 'scopes' or invocations of POV-Ray.

(1) - POV-Ray re-reads files by file positions while working with macros 
and includes. What I think you hit on in changing the tail macro name 
and finding the code working, was changing to a macro name with the same 
(or shorter) length as (all) the earlier ones in the recursion. Meaning 
the file position markers didn't change (with respect to the file 
contents) in a way causing additional characters to be read from the 
'common' parse_fore.tmp file name. This theory can be tested by, say, 
changing the m_l10 name to say ml10 - should run?

Bill P.

[William F Pokorny] Re: foreach macro [1812 days 21 hours and 2 minutes ago]

Tue, 27 Apr 2021 23:56:24 GMT

On 4/27/21 6:52 AM, jr wrote:
> hi,
> 

Played a few minutes with this just now and you can get your original 
code to run if you change the tail m_l10 macro to:

#macro m_l10(i_,n_)
   #debug concat("----------> level 10, n = ",str(n_,0,0),".\n")
   #fopen FID "parse_fore.tmp" write
   #write (FID,"#---\n")
   #fclose FID
#end

Though by the time it finishes it's consumed 1.6G or more of memory 
after maybe five minutes. My wild guess is all those Parse_String(s) end 
up sitting in memory until parsing is finished. In other words I think 
at the end we have unrolled more or less the whole recursion.

Parse_String is involved in what's happening, but it's not clear to me, 
why - some scope issue maybe as it comes after the last "call" to m_l10.

Bill P.

[jr] Re: foreach macro [1813 days 6 hours and 58 minutes ago]

Tue, 27 Apr 2021 14:00:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi WFP + TOK
> ...
> rename 'm_l10' to, say, 'mFoo', and it just works.  well, the parser's still "at
> it".  :-)  something to do with the actual name!

was rushed, earlier.  just did another quick test just with names.  I thought
there might be a limit on the number of identifiers with some identical prefix,
but it isn't so straightforward; may try other stuff nearer weekend (if still
"aktuell").


regards, jr.


Script started on Tue 27 Apr 2021 14:46:10 BST

jr@swift:8:foreach$ c### [at] namebugpov
#version 3.8;

global_settings {assumed_gamma 1}

#include "foreach_d.inc"

#declare A = array [1] {1};

#macro mac_01(i_,n_)
  #debug concat("macro 01",".\n")
#end
#macro mac_02(i_,n_)
  #debug concat("macro 02",".\n")
#end
#macro mac_03(i_,n_)
  #debug concat("macro 03",".\n")
#end
#macro mac_04(i_,n_)
  #debug concat("macro 04",".\n")
#end
#macro mac_05(i_,n_)
  #debug concat("macro 05",".\n")
#end
#macro mac_06(i_,n_)
  #debug concat("macro 06",".\n")
#end
#macro mac_07(i_,n_)
  #debug concat("macro 07",".\n")
#end
#macro mac_08(i_,n_)
  #debug concat("macro 08",".\n")
#end
#macro mac_09(i_,n_)
  #debug concat("macro 09",".\n")
#end
#macro mac_10(i_,n_)
  #debug concat("macro 10",".\n")
#end
#macro mac_11(i_,n_)
  #debug concat("macro 11",".\n")
#end
#macro mac_12(i_,n_)
  #debug concat("macro 12",".\n")
#end

#for (i_, 1, 12)
  Foreach(A, dictionary {.Macro: concat("mac_",str(i_,-2,0))})
#end

jr@swift:9:foreach$ povparse !$
  ...
==== [Parsing...] ==========================================================
macro 01.
macro 02.
macro 03.
macro 04.
macro 05.
macro 06.
macro 07.
macro 08.
macro 09.
macro 10.
macro 11.
macro 12.
File 'namebug.pov' line 48: Parse Warning: No objects in scene.

[jr] Re: foreach macro [1813 days 9 hours and 3 minutes ago]

Tue, 27 Apr 2021 11:55:00 GMT

hi WFP + TOK

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

rename 'm_l10' to, say, 'mFoo', and it just works.  well, the parser's still "at
it".  :-)  something to do with the actual name!


regards, jr.

[jr] Re: foreach macro [1813 days 10 hours and 3 minutes ago]

Tue, 27 Apr 2021 10:55:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 4/26/21 3:59 PM, jr wrote:
> > tried to see how many levels of nested calls of 'Foreach()' POV-Ray ...
>
> Short on time today, but maybe something with turning and starting back
> up the macro stack? The parse_fore.tmp file looks to contain the last
> m_l10 'execution string'. Is it somehow getting run an extra time on the
> ascent?

thanks for the quick look.  (I don't know the code base)  all foreach calls use
the only array in scene.  no idea where an extra run/invocation [cw]ould come
from.


> If I change m_l8 to call m_l10, I get the same error and it happens
> after all four calls to m_l10 at a depth of 8.

neat.  never even occurred to me.  the 'nesting.pov' "evolved", copy+paste
style, by level, so the "last" macro always was just a '#debug concat', to tie
in with above.

the output below was done with an alpha with three of your patches, plus
clipka's to get it to build.  just .. strange.


> Aside: I don't think any v3.7 version will work to debug this as the
> dictionary feature is new to v3.8.

interestingly, after rigging version and removing the 'global' in line 73 (I
think), the parser does not object to the .inc, in spite of my using 'dict.key'
notation throughout.  may have a play with this Debian build (todo list. :-))


regards, jr.


Script started on Tue 27 Apr 2021 11:23:30 BST

jr@swift:1:foreach$ tail -n15 nesting.pov
#end

#macro m_l2(i_,n_)
  #debug concat("--> level 2, n = ",str(n_,0,0),".\n")
//  Foreach(A, dictionary {.Macro: "m_l3"})
//  Foreach(A, dictionary {.Macro: "m_l10"})
#end

#macro m_l1(i_,n_)
  #debug concat("-> level 1, n = ",str(n_,0,0),".\n")
  Foreach(A, dictionary {.Macro: "m_l2"})
#end

Foreach(A, dictionary {.Macro: "m_l1"})


jr@swift:2:foreach$ povparse nesting.pov
Persistence of Vision(tm) Ray Tracer Version 3.8.0-alpha.10064268.unofficial
  ...
==== [Parsing...] ==========================================================
-> level 1, n = 1.
--> level 2, n = 1.
--> level 2, n = 2.
--> level 2, n = 3.
--> level 2, n = 4.
-> level 1, n = 2.
--> level 2, n = 1.
--> level 2, n = 2.
--> level 2, n = 3.
--> level 2, n = 4.
-> level 1, n = 3.
--> level 2, n = 1.
--> level 2, n = 2.
--> level 2, n = 3.
--> level 2, n = 4.
-> level 1, n = 4.
--> level 2, n = 1.
--> level 2, n = 2.
--> level 2, n = 3.
--> level 2, n = 4.
File 'nesting.pov' line 327: Parse Warning: No objects in scene.


jr@swift:3:foreach$ tail -n15 nesting.pov
#end

#macro m_l2(i_,n_)
  #debug concat("--> level 2, n = ",str(n_,0,0),".\n")
//  Foreach(A, dictionary {.Macro: "m_l3"})
  Foreach(A, dictionary {.Macro: "m_l10"})
#end

#macro m_l1(i_,n_)
  #debug concat("-> level 1, n = ",str(n_,0,0),".\n")
  Foreach(A, dictionary {.Macro: "m_l2"})
#end

Foreach(A, dictionary {.Macro: "m_l1"})


jr@swift:4:foreach$ povparse nesting.pov
  ...
==== [Parsing...] ==========================================================
-> level 1, n = 1.
--> level 2, n = 1.
----------> level 10, n = 1.
----------> level 10, n = 2.
----------> level 10, n = 3.
----------> level 10, n = 4.
File '/tmp/parse_fore.tmp' line 1: Parse Error: Expected 'object or directive',
 ) found instead
Fatal error in parser: Cannot parse input.
Render failed


jr@swift:5:foreach$ tail -n15 nesting.pov
#end

#macro m_l2(i_,n_)
  #debug concat("--> level 2, n = ",str(n_,0,0),".\n")
  Foreach(A, dictionary {.Macro: "m_l3"})
//  Foreach(A, dictionary {.Macro: "m_l10"})
#end

#macro m_l1(i_,n_)
  #debug concat("-> level 1, n = ",str(n_,0,0),".\n")
  Foreach(A, dictionary {.Macro: "m_l2"})
#end

Foreach(A, dictionary {.Macro: "m_l1"})


jr@swift:6:foreach$ povparse nesting.pov
  ...
==== [Parsing...] ==========================================================
-> level 1, n = 1.
--> level 2, n = 1.
---> level 3, n = 1.
---> level 3, n = 2.
  ...
---> level 3, n = 4.
--> level 2, n = 4.
---> level 3, n = 1.
---> level 3, n = 2.
---> level 3, n = 3.
---> level 3, n = 4.
File 'nesting.pov' line 327: Parse Warning: No objects in scene.

(the last with foreach in 'm_l3' commented out)

[William F Pokorny] Re: foreach macro [1813 days 11 hours ago]

Tue, 27 Apr 2021 09:58:17 GMT

On 4/26/21 3:59 PM, jr wrote:
> "jr" <cre### [at] gmailcom> wrote:
>> posting #4 of 'Foreach()'...
> 
> tried to see how many levels of nested calls of 'Foreach()' POV-Ray will do,
> given that the documentation[*] does not mention a limit.  got to nine.  when I
> uncomment the line in 'm_l9', the error shown below code (attached) occurs.
> this is the "call stack" getting trashed?
> 

Short on time today, but maybe something with turning and starting back 
up the macro stack? The parse_fore.tmp file looks to contain the last 
m_l10 'execution string'. Is it somehow getting run an extra time on the 
ascent?

If I change m_l8 to call m_l10, I get the same error and it happens 
after all four calls to m_l10 at a depth of 8.

Aside: I don't think any v3.7 version will work to debug this as the 
dictionary feature is new to v3.8.

Bill P.

[jr] Re: foreach macro [1813 days 12 hours and 13 minutes ago]

Tue, 27 Apr 2021 08:45:00 GMT

hi,

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > tried to see how many levels of nested calls of 'Foreach()' POV-Ray will do,
> > given that the documentation[*] does not mention a limit.  got to nine.  when I
> > uncomment the line in 'm_l9', the error shown below code (attached) occurs.
> > this is the "call stack" getting trashed?
> >...
> ...
> I just made a macro call itself - and then I got this error after about 99
> calls:
> "Parse Error: Too many nested symbol tables"
>
> This was with POV-Ray in Ubuntu 20.04.2 LTS:
>
> Persistence of Vision(tm) Ray Tracer Version 3.7.0.8.unofficial (g++ @
> x86_64-pc-linux-gnu)
> This is an unofficial version compiled by:
>  Dimitri John Ledkov <xno### [at] ubuntucom> for Debian <www.debian.org>

thanks for checking.

> Since you don't get the same error message: Could this possible be some other
> problem in your code ?

unsure.  there are, now, two problems.  on the nesting issue + error - I read
(but forgot to take notes) that Debian maintainers do not use the '-ffast-math'
flag, so wonder whether it's an optimisation thing.  second prob - I only have a
Debian VM, pre-installed on the Chromebook, v 3.7.0.8 compiled by Andreas B.
that does not like the .inc, parse errors when it hits the '#ifndef (global...)'
etc; which changes did you (have to) make to the file(s), other than version
change?

regards, jr.

[Tor Olav Kristensen] Re: foreach macro [1813 days 19 hours and 58 minutes ago]

Tue, 27 Apr 2021 01:00:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > posting #4 of 'Foreach()'...
>
> tried to see how many levels of nested calls of 'Foreach()' POV-Ray will do,
> given that the documentation[*] does not mention a limit.  got to nine.  when I
> uncomment the line in 'm_l9', the error shown below code (attached) occurs.
> this is the "call stack" getting trashed?
>...

I don't know.

I just made a macro call itself - and then I got this error after about 99
calls:
"Parse Error: Too many nested symbol tables"

This was with POV-Ray in Ubuntu 20.04.2 LTS:

Persistence of Vision(tm) Ray Tracer Version 3.7.0.8.unofficial (g++ @
x86_64-pc-linux-gnu)
This is an unofficial version compiled by:
 Dimitri John Ledkov <xno### [at] ubuntucom> for Debian <www.debian.org>

Since you don't get the same error message: Could this possible be some other
problem in your code ?

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[jr] Re: foreach macro [1814 days and 58 minutes ago]

Mon, 26 Apr 2021 20:00:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> posting #4 of 'Foreach()'...

tried to see how many levels of nested calls of 'Foreach()' POV-Ray will do,
given that the documentation[*] does not mention a limit.  got to nine.  when I
uncomment the line in 'm_l9', the error shown below code (attached) occurs.
this is the "call stack" getting trashed?

[*]
<https://wiki.povray.org/content/Reference:User_Defined_Macros#The_macro_Directive>


regards, jr.


/* nesting.pov */

#version 3.8;

global_settings {assumed_gamma 1}

#include "foreach.inc"

#declare A = array [4] {1, 2, 3, 4};

#macro m_l10(i_,n_)
  #debug concat("----------> level 10, n = ",str(n_,0,0),".\n")
#end

#macro m_l9(i_,n_)
  #debug concat("---------> level 9, n = ",str(n_,0,0),".\n")
//Foreach(A, dictionary {.Macro: "m_l10"})
#end

#macro m_l8(i_,n_)
  #debug concat("--------> level 8, n = ",str(n_,0,0),".\n")
  Foreach(A, dictionary {.Macro: "m_l9"})
#end

#macro m_l7(i_,n_)
  #debug concat("-------> level 7, n = ",str(n_,0,0),".\n")
  Foreach(A, dictionary {.Macro: "m_l8"})
#end

#macro m_l6(i_,n_)
  #debug concat("------> level 6, n = ",str(n_,0,0),".\n")
  Foreach(A, dictionary {.Macro: "m_l7"})
#end

#macro m_l5(i_,n_)
  #debug concat("-----> level 5, n = ",str(n_,0,0),".\n")
  Foreach(A, dictionary {.Macro: "m_l6"})
#end

#macro m_l4(i_,n_)
  #debug concat("----> level 4, n = ",str(n_,0,0),".\n")
  Foreach(A, dictionary {.Macro: "m_l5"})
#end

#macro m_l3(i_,n_)
  #debug concat("---> level 3, n = ",str(n_,0,0),".\n")
  Foreach(A, dictionary {.Macro: "m_l4"})
#end

#macro m_l2(i_,n_)
  #debug concat("--> level 2, n = ",str(n_,0,0),".\n")
  Foreach(A, dictionary {.Macro: "m_l3"})
#end

#macro m_l1(i_,n_)
  #debug concat("-> level 1, n = ",str(n_,0,0),".\n")
  Foreach(A, dictionary {.Macro: "m_l2"})
#end

Foreach(A, dictionary {.Macro: "m_l1"})



Persistence of Vision(tm) Ray Tracer Version 3.8.0-alpha.10064268.unofficial
  ...
==== [Parsing...] ==========================================================
-> level 1, n = 1.
--> level 2, n = 1.
---> level 3, n = 1.
----> level 4, n = 1.
-----> level 5, n = 1.
------> level 6, n = 1.
-------> level 7, n = 1.
--------> level 8, n = 1.
---------> level 9, n = 1.
----------> level 10, n = 1.
----------> level 10, n = 2.
----------> level 10, n = 3.
----------> level 10, n = 4.
File '/tmp/parse_fore.tmp' line 1: Parse Error: Expected 'object or directive',
 ) found instead
Fatal error in parser: Cannot parse input.
Render failed

[jr] Re: foreach macro [1816 days 5 hours and 58 minutes ago]

Sat, 24 Apr 2021 15:00:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> ...  I wanted to add another demo/"teaser" scene but run out of time, in
> the coming days perhaps.

a kind soul advised me that if I want to get people interested in the
'Foreach()' macro, I need to _sell_ it.  hence the teaser below (and attached
for convenience).


enjoy, jr.



/* obfusc.pov */

#version 3.8;

global_settings {assumed_gamma 1}

#include "foreach.inc"
#include "logo.inc"

camera {
  location <3.25,0,-4.5>
  direction z
  right x * (4/3)
  up y
  angle 80
  look_at <3.25,0,0>
}

/* the data.  the character codes are obscured 'rot13' style */
#declare A = array {
  array mixed {<0, 1, 0>, .75, 0,
          array {122, 110, 113, 114, 45, 130, 128, 118, 123, 116}},
  array mixed {<0, 0, 0>, 1, 1,
          array {93, 92, 99, 58, 95, 110, 134}},
  array mixed {<0, -1, 0>, .75, 0,
          array {64, 59, 69, 59, 61, 58, 110, 121, 125, 117, 110}}
};

#declare font_ = array {"comic.ttf", "comicbd.ttf"};

/* make plain text */
#macro m_ch(i_,elem_)
  chr(elem_ - 13)
#end

#declare str_ = array [3];

#for (i_,0,2)
  #declare str_[i_] = concat(Foreach(A[i_][3], dictionary {.Macro: "m_ch"}));
#end

/* et voila */
object {
  Povray_Logo
  texture {
    pigment {color rgb <1,1,0>}
    finish {ambient 0 emission 1}
  }
  scale 1.5
  translate <5.3, .3, 0>
}

#macro m_text(i_,elem_)
  text {
    ttf font_[elem_[2]] str_[i_], .1, 0
    texture {
      pigment {color rgb <1,1,0>}
      finish {ambient 0 emission 1}
    }
    scale (<1,1,1> * elem_[1])
    translate elem_[0]
  }
#end

Foreach(A, dictionary {.Macro: "m_text"})

[jr] Re: foreach macro [1818 days 1 hour and 8 minutes ago]

Thu, 22 Apr 2021 19:50:00 GMT

hi,

posting #4 of 'Foreach()', probably final.  the attached zip contains the
include file, a demo scene, and (html) documentation with hopefully no further
errors[*].  I wanted to add another demo/"teaser" scene but run out of time, in
the coming days perhaps.


enjoy, jr.

[*] WFP's correction of "showed" led me to find, and get rid of, another
confusing (egregious :-)) copy+paste error.

[jr] Re: foreach macro [1820 days 7 hours and 23 minutes ago]

Tue, 20 Apr 2021 13:35:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 4/20/21 4:39 AM, jr wrote:
> ...
>
> Quickly on the html.

(thanks)

> ---
> ...to avoid potential name clashes, own key names should be captialised...
>
> should be:
>
> ...to avoid potential name clashes, your own key names should be
> captialised...
>
>
> ---
> A vote to avoid the 'otoh' acronym and write out the words.

agree, both.

> ---
> the '.Walk' examples showed...
>
> Perhaps better as:
>
> the '.Walk' examples show...

I used past tense because the examples come before and the assumption was/is
that they'd just been read/perused.  will have a closer look/re-assessment.

> ---
> At the very bottom of the html I see the word 'bool' ?

that one's "harmless", I have no examples yet for 'void vs bool', only in the
demo scene.  :-)

regards, jr.

[William F Pokorny] Re: foreach macro [1820 days 7 hours and 54 minutes ago]

Tue, 20 Apr 2021 13:03:57 GMT

On 4/20/21 4:39 AM, jr wrote:
> "jr" <cre### [at] gmailcom> wrote:
>> "jr" <cre### [at] gmailcom> wrote:
>>> and now a snapshot of #3.  ...
>> another snapshot of #3.  ...
> 
> posting the last snapshot/wip version #3.  both the .inc and demo scene files
> are now in their final form, more or less.  the .html page needs a little more
> work; an example or two to add, and improving the writing.  to that end I'd be
> grateful for people highlighting errors, and suggesting better English where
> needed[*].
...
> 

Quickly on the html.


---
...to avoid potential name clashes, own key names should be captialised...

should be:

...to avoid potential name clashes, your own key names should be 
captialised...


---
A vote to avoid the 'otoh' acronym and write out the words.


---
the '.Walk' examples showed...

Perhaps better as:

the '.Walk' examples show...


---
At the very bottom of the html I see the word 'bool' ?


Bill P.

[jr] Re: foreach macro [1820 days 12 hours and 18 minutes ago]

Tue, 20 Apr 2021 08:40:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > and now a snapshot of #3.  ...
> another snapshot of #3.  ...

posting the last snapshot/wip version #3.  both the .inc and demo scene files
are now in their final form, more or less.  the .html page needs a little more
work; an example or two to add, and improving the writing.  to that end I'd be
grateful for people highlighting errors, and suggesting better English where
needed[*].

enjoy, jr.

[*] though I won't capitalise the first word in each sentence.  :-)

[gibe] Re: 85 [1822 days 18 hours and 23 minutes ago]

Sun, 18 Apr 2021 02:35:00 GMT

"gibe" <p.g### [at] gmailcom> wrote:
> See image in p.b.i.
>
> Paolo

Version with an irregular border.
Paolo

[jr] Re: foreach macro [1823 days 23 hours and 8 minutes ago]

Fri, 16 Apr 2021 21:50:00 GMT

hi,

ingo <ing### [at] tagpovrayorg> wrote:
> in news:web.6079f615d564bfd479819d986cde94f1@news.povray.org jr wrote:
>
> ></sigh>
>
> Ah, the sound of enthousiasm :)

</grin>  thanks.

btw, as Robert writes, the mp3 plays fine.  checked with 'mpg123' on another
machine.


regards, jr.

[ingo] Re: foreach macro [1823 days 23 hours and 52 minutes ago]

Fri, 16 Apr 2021 21:05:51 GMT

in news:web.6079f615d564bfd479819d986cde94f1@news.povray.org jr wrote:

></sigh>

Ah, the sound of enthousiasm :)

Ingo

[jr] Re: foreach macro [1824 days and 13 minutes ago]

Fri, 16 Apr 2021 20:45:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> ...
> the 'fore_demo.pov' scene has been re-written.  ...

looking at the scene code just now I noticed a couple of (potentially) confusing
copy+paste errors.  </sigh>  the 'm_2arg' and 'm_dict' macros display wrong
names, sorry.


regards, jr.

[jr] Re: foreach macro [1824 days 3 hours and 53 minutes ago]

Fri, 16 Apr 2021 17:05:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> ...
> and now a snapshot of #3.  ...

another snapshot of #3.  minor progress in .inc and .html files.  the
'fore_demo.pov' scene has been re-written.  now call:

  $ povray fore_demo.pov declare=N=i

where 1 <= i <= 5.  all but 5 (default when declare omitted) only output text
info during parsing.

enjoy, jr.

[jr] Re: foreach macro [1826 days and 8 minutes ago]

Wed, 14 Apr 2021 20:50:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > I re-wrote the first, buggy version ...
> this second version ...

and now a snapshot of #3.  some new features, improved documentation.  I will
have to put in some more work to provide a good set of tutorial examples, a new
demo scene, etc, but would meanwhile ask interested parties to give 'Foreach' a
try, see which bugs still lurk :-).

not documented because I've only done two tests so far is nesting of 'Foreach'
calls; I have managed to call the macro from a payload macro (with different
array + payload, of course).

an example of calling 'Foreach' with the new 'Indices' and 'Arg' features:

#version 3.8;

global_settings {assumed_gamma 1}

#include "foreach.inc"

#declare A = array [2][2][3] {
  {{1, 2, 3}, {4, 5, 6}},
  {{7, 8, 9}, {10, 11, 12}}
};

#macro m_walka(i_, j_, k_, elem_, arg_)
  #local n_ = elem_ * elem_;
  #debug concat("m_walka i = ",str(i_,0,0),", elem = ",str(elem_,0,0),
          "  arg = '",arg_.foo,"' and ",str(arg_.bar,0,0),".\n")
#end

#declare foober = dictionary {
  .foo: "this is nice.",
  .bar: 12345
};

#declare D = dictionary {
  .Macro:   "m_walka",
  .Arg:     "foober",
  .Walk:    1,
  .To:      3,
  .Extra:   on,
  .Indices: on,
  .Verbose: on
};

Foreach(A, D)

enjoy, jr.

[ingo] Re: foreach macro [1830 days 9 hours and 32 minutes ago]

Sat, 10 Apr 2021 11:26:10 GMT

in news:web.607154f7d564bfd479819d986cde94f1@news.povray.org jr wrote:

> I see you're "knee-deep" in arrays right now

Arrays (and dicts) are indispensable imo.

Ingo

[jr] Re: foreach macro [1830 days 13 hours and 23 minutes ago]

Sat, 10 Apr 2021 07:35:00 GMT

hi,

ingo <ing### [at] tagpovrayorg> wrote:
> > 'Foreach()'
>
> This is useful. Thanks,

cheers.  (I see you're "knee-deep" in arrays right now :-))

btw, 'pluck a string' sounds pretty real.  amazing.


regards, jr.

[ingo] Re: foreach macro [1831 days 3 hours and 31 minutes ago]

Fri, 9 Apr 2021 17:26:53 GMT

in news:web.60705575d564bfd479819d986cde94f1@news.povray.org jr wrote:

> 'Foreach()'

This is useful. Thanks,

Ingo

[jr] Re: foreach macro [1831 days 7 hours and 23 minutes ago]

Fri, 9 Apr 2021 13:35:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> I re-wrote the first, buggy version ...

this second version is slightly changed (keys) and, as a result, more flexible
in choosing the dimension(s).  I've done more testing, added proper
documentation, and the demo scene too has been tidied up.  in all, version 2 of
'Foreach()' is as it should have been from the beginning.


enjoy, jr.

[jr] foreach macro [1834 days 22 hours and 28 minutes ago]

Mon, 5 Apr 2021 22:30:00 GMT

hi,

I re-wrote the first, buggy version[*] of the macro, with much needed help from
tic & tok -- the in-crowd & Tor Olav.  thanks.

so, after some basic testing, here's the second version.  as discussed in the
other thread, there are two types of "payload" macros: returning (some) boolean
value, and returning nothing ("void").  the former are useful for computation
type code, the latter for all else.  there is as yet no documentation, hope to
finish that in a few days.  meanwhile the included demo scene doubles as draft
documentation slash tutorial.  anyway..


enjoy, jr.

[*]
<http://news.povray.org/povray.bugreports/thread/%3Cweb.606b7e4b54e5aaba1f9dae3025979125%40news.povray.org%3E/>

[gibe] 85 [1837 days 1 hour and 3 minutes ago]

Sat, 3 Apr 2021 19:55:00 GMT

See image in p.b.i.

Paolo

[Uncle Josh] Animator.inc - new version [1837 days 19 hours and 55 minutes ago]

Sat, 3 Apr 2021 01:02:48 GMT

I know somewhere in the documents it advises keeping your clock value 
between 0 and 1, but for more complex animations I find it easier to 
think of the clock as an actual clock, going from 0 to however long the 
animation takes in seconds. I wanted to be able to adjust the timing of 
each shot in the final render. So I wrote this include file that 
generates both an include file and an .ini file to control the animation.

EXAMPLE USAGE

    #declare shotlengths = array[4] {1, 3, 2.4, 0.5}
    #declare scriptname = "camerascript.inc";
    #if(!file_exists(scriptname))
      #include "animator.inc"
      CreateScript(shotlengths, scriptname, "Variable")
    #end // if not file_exists
    #include scriptname

The include file adds 8 variables to the scene:

    VariableShot // sequential shot number; 1, 2, 3, ...
    VariableLength // length of clock time (number of seconds if clock=1 
is 1 second)
    VariableSceneClock // clock value starting at 0 and ending at 
VariableLength
    VariableLocalClock // normalized value of 0 to 1 through length of shot
    VariableStart // first clock value
    VariableEnd // last clock value
    VariableFirstFrame // first frame number of the scene
    VariableLastFrame // last frame number of the scene

This provides much needed flexibility in managing the action in each shot.

The INI file provides options to render each scene individually for testing.

I re-wrote this for my Pellet Power redo last year and I've been wanting 
to share it ever since.

If you reset the shotlengths, delete the include file and both the 
include and ini file will be recreated.

[Mike Horvath] Re: Lens flare macro not working [1879 days 14 hours and 44 minutes ago]

Sat, 20 Feb 2021 06:14:01 GMT

On 2/19/2021 8:06 PM, Mike Horvath wrote:
> On 2/18/2021 5:32 PM, Kenneth wrote:
>> "Kenneth" <kdw### [at] gmailcom> wrote:
>>> I had to comment-out your
>>>          #include Lens_Mod.inc
>>> to get the scene to run, as that include file is not part of Chris 
>>> Colefax's
>>> Lens Flare macros...
>>
>> I replaced that .inc file with Chris's LNSEFCTS.inc ; maybe that's 
>> what you
>> meant to #include?
>>
>> Now, on frame 3, the render turns pure white. Is that what you're 
>> seeing as
>> well?
>>
>>
>>
> 
> Sorry about that.
> 
> I think you're supposed to replace it with LENS.INC.
> 
> I don't get a white screen.
> 
> 
> Mike


The problem was with the camera code. I had the Camera_Location and 
Camera_LookAt set incorrectly.


Mike

[Mike Horvath] Re: Lens flare macro not working [1879 days 19 hours and 49 minutes ago]

Sat, 20 Feb 2021 01:08:57 GMT

On 2/18/2021 4:55 PM, Kenneth wrote:
> I don't have CIE.inc or lightsys.inc, so I ran the scene without those. I assume
> that they are not necessary for the lens flare effect(?)

You are correct.


Mike

[Mike Horvath] Re: Lens flare macro not working [1879 days 19 hours and 51 minutes ago]

Sat, 20 Feb 2021 01:06:49 GMT

On 2/18/2021 5:32 PM, Kenneth wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>> I had to comment-out your
>>          #include Lens_Mod.inc
>> to get the scene to run, as that include file is not part of Chris Colefax's
>> Lens Flare macros...
> 
> I replaced that .inc file with Chris's LNSEFCTS.inc ; maybe that's what you
> meant to #include?
> 
> Now, on frame 3, the render turns pure white. Is that what you're seeing as
> well?
> 
> 
> 

Sorry about that.

I think you're supposed to replace it with LENS.INC.

I don't get a white screen.


Mike

[Kenneth] Re: Lens flare macro not working [1880 days 22 hours and 23 minutes ago]

Thu, 18 Feb 2021 22:35:01 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> I had to comment-out your
>         #include Lens_Mod.inc
> to get the scene to run, as that include file is not part of Chris Colefax's
> Lens Flare macros...

I replaced that .inc file with Chris's LNSEFCTS.inc ; maybe that's what you
meant to #include?

Now, on frame 3, the render turns pure white. Is that what you're seeing as
well?

[Kenneth] Re: Lens flare macro not working [1880 days 22 hours and 58 minutes ago]

Thu, 18 Feb 2021 22:00:00 GMT

At first, I thought the code was only producing a 5-frame animation, then
crasing on frame 6-- until I changed my INI file's animation setting to
Initial_Frame=0  ;-)  I usually start at 1, the default.

I do see a tiny planet sphere on frame 3-- but I had to comment-out your
        #include Lens_Mod.inc
to get the scene to run, as that include file is not part of Chris Colefax's
Lens Flare macros at
      http://www.oocities.org/ccolefax/lenseffects.html

I don't have CIE.inc or lightsys.inc, so I ran the scene without those. I assume
that they are not necessary for the lens flare effect(?)

[Mike Horvath] Lens flare macro not working [1881 days 16 hours and 16 minutes ago]

Thu, 18 Feb 2021 04:41:50 GMT

I am unable to get the lens flare macro to show up in the attached 
scene. What am I doing wrong?

It's a 6 frame animation. The lens flare should appear over the sun in 
frame 3 out of 6.

Thank you.


Mike

[Mike Horvath] Re: Ringworld scene [1881 days 20 hours and 21 minutes ago]

Thu, 18 Feb 2021 00:37:45 GMT

On 10/13/2013 2:18 AM, posfan12 wrote:
> Here's the scene file for my ringworld attempt. Any suggestions? Especially on
> how to make the atmosphere appear?
> 
> 
> Mike
> 


Latest code can be found here:

https://github.com/mjhorvath/Mike-Wikipedia-Illustrations/tree/master/Miscellaneous/ringworld


Mike

[Alain Martel] Re: Ringworld scene [1888 days 4 hours and 46 minutes ago]

Thu, 11 Feb 2021 16:12:24 GMT

Le 2021-02-10 à 05:29, Mike Horvath a écrit :
> On 2/9/2021 2:36 AM, Thomas de Groot wrote:
>> I wonder if at that distance an area_light is really effective. A 
>> point light (with parallel) would probably be much faster and without 
>> any visual difference.
>>
> 
> The area light is necessary to create the fuzzy shadows. (Otherwise 
> shadows would have a sharp edge and the lighted regions would be larger 
> than the shadow regions IIRC.)
> 
> A 6x6 area light may be excessive though. Dunno.
> 
> 
> Mike
If using adaptive, that 6x6 become 9x9.

As for using parallel... That would only work for a small part of the 
ring.  parallel can't be used when the light_source is surrounded by 
shadow casting elements.

[Thomas de Groot] Re: Ringworld scene [1888 days 13 hours and 30 minutes ago]

Thu, 11 Feb 2021 07:28:16 GMT

Op 10/02/2021 om 11:29 schreef Mike Horvath:
> On 2/9/2021 2:36 AM, Thomas de Groot wrote:
>> I wonder if at that distance an area_light is really effective. A 
>> point light (with parallel) would probably be much faster and without 
>> any visual difference.
>>
> 
> The area light is necessary to create the fuzzy shadows. (Otherwise 
> shadows would have a sharp edge and the lighted regions would be larger 
> than the shadow regions IIRC.)
> 
> A 6x6 area light may be excessive though. Dunno.
> 
> 
> Mike

Ah, yes. Forgot about the shadow squares indeed. I seem to remember now 
that I had some trouble of the kind, back when I modelled the Ringworld 
(ten years ago? I am not sure)

-- 
Thomas

[Bald Eagle] Re: Ringworld scene [1889 days 8 hours and 38 minutes ago]

Wed, 10 Feb 2021 12:20:00 GMT

Mike Horvath <mik### [at] gmailcom> wrote:

> The area light is necessary to create the fuzzy shadows. (Otherwise
> shadows would have a sharp edge and the lighted regions would be larger
> than the shadow regions IIRC.)

What if you gave the shadow squares a bit of transparency at the edges to allow
the formation of a penumbra on the ring?  It's a cheap cheat, but it may go
WAAAY faster.

Also Martijn just posted this recently:
https://www.shadertoy.com/view/WsyBDz

[Mike Horvath] Re: Ringworld scene [1889 days 10 hours and 28 minutes ago]

Wed, 10 Feb 2021 10:29:54 GMT

On 2/9/2021 2:36 AM, Thomas de Groot wrote:
> I wonder if at that distance an area_light is really effective. A point 
> light (with parallel) would probably be much faster and without any 
> visual difference.
> 

The area light is necessary to create the fuzzy shadows. (Otherwise 
shadows would have a sharp edge and the lighted regions would be larger 
than the shadow regions IIRC.)

A 6x6 area light may be excessive though. Dunno.

Mike

[Thomas de Groot] Re: Ringworld scene [1890 days 13 hours and 22 minutes ago]

Tue, 9 Feb 2021 07:36:21 GMT

Op 08/02/2021 om 09:13 schreef Mike Horvath:
> On 2/8/2021 2:35 AM, Thomas de Groot wrote:
>> I don't know. Just rendering your atmosphere, with a supporting ring 
>> added, took me about 30 seconds. Probably other conditions prevail in 
>> your scene (landscape? cloudscape? shadow squares? area_light sun?)
>>
> 
> Yes, the sun is a 6x6 (probably excessive) area light.
> 
> Without the atmosphere the scene takes about 2 hours to render.
> 
> 
> Mike

I wonder if at that distance an area_light is really effective. A point 
light (with parallel) would probably be much faster and without any 
visual difference.

-- 
Thomas

[Mike Horvath] Re: Ringworld scene [1891 days 12 hours and 44 minutes ago]

Mon, 8 Feb 2021 08:13:48 GMT

On 2/8/2021 2:35 AM, Thomas de Groot wrote:
> I don't know. Just rendering your atmosphere, with a supporting ring 
> added, took me about 30 seconds. Probably other conditions prevail in 
> your scene (landscape? cloudscape? shadow squares? area_light sun?)
> 

Yes, the sun is a 6x6 (probably excessive) area light.

Without the atmosphere the scene takes about 2 hours to render.

Mike

[Thomas de Groot] Re: Ringworld scene [1891 days 13 hours and 23 minutes ago]

Mon, 8 Feb 2021 07:35:06 GMT

Op 07/02/2021 om 23:26 schreef Mike Horvath:
> On 2/7/2021 2:41 AM, Thomas de Groot wrote:
>> Nicely done indeed. Media should not pose too much of a problem in 
>> this context as you are outside of the atmosphere.
>>
> 
> Well, I am on hour 13 of my current render. About 35% done.
> 
> 
> Mike

I don't know. Just rendering your atmosphere, with a supporting ring 
added, took me about 30 seconds. Probably other conditions prevail in 
your scene (landscape? cloudscape? shadow squares? area_light sun?)

-- 
Thomas

[Mike Horvath] Re: Ringworld scene [1891 days 22 hours and 32 minutes ago]

Sun, 7 Feb 2021 22:26:09 GMT

On 2/7/2021 2:41 AM, Thomas de Groot wrote:
> Nicely done indeed. Media should not pose too much of a problem in this 
> context as you are outside of the atmosphere.
> 

Well, I am on hour 13 of my current render. About 35% done.


Mike

[Thomas de Groot] Re: Ringworld scene [1892 days 13 hours and 16 minutes ago]

Sun, 7 Feb 2021 07:41:48 GMT

Op 07/02/2021 om 02:53 schreef Mike Horvath:
> On 10/13/2013 2:18 AM, posfan12 wrote:
>> Here's the scene file for my ringworld attempt. Any suggestions? 
>> Especially on
>> how to make the atmosphere appear?
>>
>>
>> Mike
>>
> 
> Some panoramas:
> 
> http://isometricland.net/panorama/pannellum.htm?config=pano-ringworld-01.json 
> 
> 
> http://isometricland.net/panorama/pannellum.htm?config=pano-ringworld-02.json 
> 
> 
> 
> Mike

Nicely done indeed. Media should not pose too much of a problem in this 
context as you are outside of the atmosphere.

-- 
Thomas

[Mike Horvath] Re: Ringworld scene [1892 days 19 hours and 4 minutes ago]

Sun, 7 Feb 2021 01:53:48 GMT

On 10/13/2013 2:18 AM, posfan12 wrote:
> Here's the scene file for my ringworld attempt. Any suggestions? Especially on
> how to make the atmosphere appear?
> 
> 
> Mike
> 

Some panoramas:

http://isometricland.net/panorama/pannellum.htm?config=pano-ringworld-01.json

http://isometricland.net/panorama/pannellum.htm?config=pano-ringworld-02.json


Mike

[Robert McGregor] 2D QRD Design Visualization Scene File [1914 days 22 hours and 48 minutes ago]

Fri, 15 Jan 2021 22:10:00 GMT

By request, here is the scene file for the image posted in my thread at
http://news.povray.org/povray.binaries.images/thread/%3Cweb.5ff3a99b1bc6d66387570eab0%40news.povray.org%3E/

[Kenneth] Re: bounding box calculator [2017 days 16 hours and 23 minutes ago]

Mon, 5 Oct 2020 04:35:01 GMT

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

>
> posting the 4th, and probably final, version of the 'Bounder', which ties up a
> couple of loose ends.
>
I'm coming late to this discussion, sorry that I never saw it earlier.

This looks useful for my current 'city buildings' scene, particularly for my
'rooftop greebles' and their correct placement.

Thanks for all the hard work (and Thomas too for his earlier testing and
suggestions.)

[jr] Re: bounding box calculator [2018 days 9 hours and 43 minutes ago]

Sun, 4 Oct 2020 11:15:01 GMT

"jr" <cre### [at] gmailcom> wrote:
> find attached the second update of the 'Bounder'.
>
> things have changed a little.  now, if the object's BB is found to be "(near)
> optimal", the macro prints that and ends, otherwise, ie having some "slack", the
> macro prints the difference lines as before, plus the optimised extents and
> dimensions, as per Thomas's feedback.
>
> also new, if "slack" is reported, two variables with the differences from the
> BB's min/max extents are declared, to allow use of the info from in-scene.
> after 'Bounder' has run, one can for instance:
>
> #ifdef(Bounder_min_diff)
>   // do something
> #end
>
> so.  version 3.  fingers crossed.
>

posting the 4th, and probably final, version of the 'Bounder', which ties up a
couple of loose ends.

an addition to the code removes existing 'Bounder_{min,max}_diff' variables,
whenever the macro is run.  this means that if you call the macro multiple
times, you can be confident that existing variables were created by the most
recent call.  this then allows automating the (re)bounding of objects, as
illustrated in the code below.

second, I added a thanks to TdG, whose input was (is) appreciated.  kept
forgetting.  :-(


enjoy, jr.


# ------------------------------------------------------------------------

jr@crow:5:bounder$ c### [at] bt1apov
#version 3.8;

global_settings {assumed_gamma 1}

background {color srgbt 0}

#ifndef (global.I)
  #declare I = 0;
#end

#declare R = <20,20,20>;

#switch (I)
  #case (0)
    #debug concat("cylinder","\n")
    #declare O = cylinder {
      0, 1, .25
      translate 5
    };
  #break
  #case (1)
    #debug concat("box","\n")
    #declare O = box {
      0, 1
    };
  #break
  #case (2)
    #debug concat("sphere","\n")
    #declare O = sphere {
      0, 1
    };
  #break
  #case (3)
    #debug concat("blob","\n")
    #declare O = blob {
      threshold .6
      sphere {0, 1, 1}
      scale 2
    };
    #declare R = <25,25,25>;
  #break
  #case (4)
    #debug concat("superellipsoid","\n")
    #declare O = superellipsoid {
      <.5,3.5>
      translate 5
    };
  #break
  #case (5)
    #debug concat("superellipsoid rotated","\n")
    #declare O = superellipsoid {
      <.5,3.5>
      rotate 45
      translate 5
    };
    #declare R = <25,25,25>;
  #break
  #else
    #error concat("oops, no object for I=",str(I,0,0),".\n")
#end

#include "bounder.inc"
Bounder(O,R)

#ifdef (Bounder_min_diff)
  #local nlb_ = min_extent(O) + Bounder_min_diff;
  #local nub_ = max_extent(O) - Bounder_max_diff;
  #declare O = object {
    O
    clipped_by {box {nlb_, nub_}}
    bounded_by {clipped_by}
  };
#end

Bounder(O,R)


jr@crow:6:bounder$ povparse bt1a.pov declare=I=5
Persistence of Vision(tm) Ray Tracer Version 3.8.0-alpha.10064268.unofficial
   ...
==== [Parsing...] ==========================================================
superellipsoid rotated
----------[Bounder info]------------------------------------------------
  resolutions (per POV unit): <25, 25, 25>
       min_extent "as is" BB: <3.499850, 3.499850, 3.292722>
       max_extent "as is" BB: <6.500150, 6.500150, 6.707277>
       BB aligned dimensions: <3.000300, 3.000300, 3.414555>
    'X' axis scan resolution: 75
              scans per face: 6375
         scan axis increment: 0.04000400
          face col increment: 0.04017124
          face row increment: 0.04000400
                           -: ...scanning...
Parsing 5069K tokensParsing 10221K tokens
              inside() calls: 280500
    'Y' axis scan resolution: 75
              scans per face: 6375
         scan axis increment: 0.04000400
          face col increment: 0.04000400
          face row increment: 0.04017124
                           -: ...scanning...
Parsing 15363K tokensParsing 20530K tokens
              inside() calls: 153000
    'Z' axis scan resolution: 85
              scans per face: 5625
         scan axis increment: 0.04017124
          face col increment: 0.04000400
          face row increment: 0.04000400
                           -: ...scanning...
Parsing 25672K tokensParsing 30802K tokens
              inside() calls: 225000

  object bounding box has at least 5% "slack".

      difference from BB min: <0.800080, 0.400040, 0.723082>
      difference from BB max: <0.800080, 0.400040, 0.723082>
     min_extent optimised BB: <4.299930, 3.899890, 4.015805>
     max_extent optimised BB: <5.700070, 6.100110, 5.984195>
     BB optimised dimensions: <1.400140, 2.200220, 1.968391>
------------------------------------------------------------------------
----------[Bounder info]------------------------------------------------
  resolutions (per POV unit): <25, 25, 25>
       min_extent "as is" BB: <4.299930, 3.899890, 4.015805>
       max_extent "as is" BB: <5.700070, 6.100110, 5.984195>
       BB aligned dimensions: <1.400140, 2.200220, 1.968391>
    'X' axis scan resolution: 35
              scans per face: 2695
         scan axis increment: 0.04000400
          face col increment: 0.04017124
          face row increment: 0.04000400
                           -: ...scanning...
              inside() calls: 10780
    'Y' axis scan resolution: 55
              scans per face: 1715
         scan axis increment: 0.04000400
          face col increment: 0.04000400
          face row increment: 0.04017124
                           -: ...scanning...
              inside() calls: 6860
    'Z' axis scan resolution: 49
              scans per face: 1925
         scan axis increment: 0.04017124
          face col increment: 0.04000400
          face row increment: 0.04000400
                           -: ...scanning...
              inside() calls: 7700

  object bounding box is (near) optimal.
------------------------------------------------------------------------
File 'bt1a.pov' line 295: Parse Warning: No objects in scene.
==== [Rendering...] ========================================================
Rendered 1024 of 1024 pixels (100%)
POV-Ray finished

jr@crow:7:bounder$ povparse bt1a.pov declare=I=0
  ...
==== [Parsing...] ==========================================================
cylinder
----------[Bounder info]------------------------------------------------
  resolutions (per POV unit): <20, 20, 20>
       min_extent "as is" BB: <4.750000, 4.750000, 4.711325>
       max_extent "as is" BB: <6.250000, 6.250000, 6.288675>
       BB aligned dimensions: <1.500000, 1.500000, 1.577350>
    'X' axis scan resolution: 30
              scans per face: 960
         scan axis increment: 0.05000000
          face col increment: 0.04929219
          face row increment: 0.05000000
                           -: ...scanning...
              inside() calls: 3840
    'Y' axis scan resolution: 30
              scans per face: 960
         scan axis increment: 0.05000000
          face col increment: 0.05000000
          face row increment: 0.04929219
                           -: ...scanning...
              inside() calls: 3840
    'Z' axis scan resolution: 32
              scans per face: 900
         scan axis increment: 0.04929219
          face col increment: 0.05000000
          face row increment: 0.05000000
                           -: ...scanning...
              inside() calls: 5400

  object bounding box is good, less than 5% "slack".

      difference from BB min: <0.000000, 0.000000, 0.049292>
      difference from BB max: <0.000000, 0.000000, 0.049292>
     min_extent optimised BB: <4.750000, 4.750000, 4.760617>
     max_extent optimised BB: <6.250000, 6.250000, 6.239383>
     BB optimised dimensions: <1.500000, 1.500000, 1.478766>
------------------------------------------------------------------------
----------[Bounder info]------------------------------------------------
  resolutions (per POV unit): <20, 20, 20>
       min_extent "as is" BB: <4.750000, 4.750000, 4.760617>
       max_extent "as is" BB: <6.250000, 6.250000, 6.239383>
       BB aligned dimensions: <1.500000, 1.500000, 1.478766>
    'X' axis scan resolution: 30
              scans per face: 900
         scan axis increment: 0.05000000
          face col increment: 0.04929219
          face row increment: 0.05000000
                           -: ...scanning...
              inside() calls: 3600
    'Y' axis scan resolution: 30
              scans per face: 900
         scan axis increment: 0.05000000
          face col increment: 0.05000000
          face row increment: 0.04929219
                           -: ...scanning...
              inside() calls: 3600
    'Z' axis scan resolution: 30
              scans per face: 900
         scan axis increment: 0.04929219
          face col increment: 0.05000000
          face row increment: 0.05000000
                           -: ...scanning...
              inside() calls: 3600

  object bounding box is (near) optimal.
------------------------------------------------------------------------
File 'bt1a.pov' line 295: Parse Warning: No objects in scene.

[jr] scale modelling backgrounds [2060 days and 58 minutes ago]

Sun, 23 Aug 2020 20:00:01 GMT

hi,

I played with F Lohmüller's (fascinating) "Squared Background" macros[*], and
have modified, and re-packaged, that code for "modern" POV-Ray.

[*] <http://f-lohmueller.de/pov_tut/scale_model/s_mod_100e.htm>

the zip contains an include file, a demo scene, and a simple html documentation
page.  comments, tips, and constructive criticism welcomed.


enjoy, jr.

[Thomas de Groot] Into the Wild - test scene [2069 days 14 hours and 42 minutes ago]

Fri, 14 Aug 2020 06:16:11 GMT

See p.b.i for explanation etc.

-- 
Thomas

[Alain Martel] Re: POVEarth: once more mesh2writer.pov [2079 days 3 hours and 25 minutes ago]

Tue, 4 Aug 2020 17:33:43 GMT

Le 2020-08-03 à 14:30, Tor Olav Kristensen a écrit :

> Yadgar,
> 
> Your array V_vec_Arr is a 1 dimensional array.
> But it seems like you are using it as if it was a 2 dimensional array.
> 
> If so, then you could have defined and used it like this:
> 
> #declare V_vec_Arr = array[ydim][xdim];
> V_vec_Arr[a][b]
> 
> - but instead you seem to define and use it like this:
> 
> #declare V_vec_Arr = array[ydim*xdim];
> V_vec_Arr[a*xdim + b]
> 
> This makes the indexing more awkward and error prone than it needs to be.
> 
> E.g.:
> 
> You have several lines that look somewhat like this:
> 
> #declare nno =
>      nno +
>      vcross(
>          V_vec_Arr[(a + 1)*ydim + (b - 1)] - V_vec_Arr[(a + 1)*xdim + b],
>          V_vec_Arr[                b     ] - V_vec_Arr[(a + 1)*xdim + b]
>      )
> ;
> 
> - where the "*ydim" part seems wrong to me.
> 
> And then you have a line like this:
> 
> #if (a > 0 & a < ydim - 1 & b = ydim - 1) // rightmost column except lower
> 
> - where I suspect that "b = ydim - 1" should be "b = xdim - 1".
> 
> If these are bugs, they will probably not bite you until xdim becomes different
> from ydim.
> 
> So I suggest that you do your array indexing in a different way.
> 
> --
> Tor Olav
> http://subcube.com
> https://github.com/t-o-k
> 
> 
Arghhh! That DO hurt !
That kind of array indexing gymnastic is only acceptable if you are 
using a language that don't support multidimensional arrays.


Alain

[Bald Eagle] Re: POVEarth: once more mesh2writer.pov [2080 days and 38 minutes ago]

Mon, 3 Aug 2020 20:20:05 GMT

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:

> Yadgar,
[... lots of excellent points ...]
> So I suggest that you do your array indexing in a different way.


TOK has spoken.   I can tell you from experience that listening and heeding his
advice is highly recommended.

[Tor Olav Kristensen] Re: POVEarth: once more mesh2writer.pov [2080 days 2 hours and 23 minutes ago]

Mon, 3 Aug 2020 18:35:00 GMT

=?UTF-8?Q?J=c3=b6rg_=22Yadgar=22_Bleimann?= <yaz### [at] gmxde> wrote:
> Hi(gh)!
>
> By request in the process of debugging, here the current version of the
> script file mentioned in the subject:
>
> // begin of code
> ...
> // end of code

Yadgar,

Your array V_vec_Arr is a 1 dimensional array.
But it seems like you are using it as if it was a 2 dimensional array.

If so, then you could have defined and used it like this:

#declare V_vec_Arr = array[ydim][xdim];
V_vec_Arr[a][b]

- but instead you seem to define and use it like this:

#declare V_vec_Arr = array[ydim*xdim];
V_vec_Arr[a*xdim + b]

This makes the indexing more awkward and error prone than it needs to be.

E.g.:

You have several lines that look somewhat like this:

#declare nno =
    nno +
    vcross(
        V_vec_Arr[(a + 1)*ydim + (b - 1)] - V_vec_Arr[(a + 1)*xdim + b],
        V_vec_Arr[                b     ] - V_vec_Arr[(a + 1)*xdim + b]
    )
;

- where the "*ydim" part seems wrong to me.

And then you have a line like this:

#if (a > 0 & a < ydim - 1 & b = ydim - 1) // rightmost column except lower

- where I suspect that "b = ydim - 1" should be "b = xdim - 1".

If these are bugs, they will probably not bite you until xdim becomes different
from ydim.

So I suggest that you do your array indexing in a different way.

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[Bald Eagle] Re: POVEarth: once more mesh2writer.pov [2081 days 3 hours and 13 minutes ago]

Sun, 2 Aug 2020 17:45:00 GMT

> By request in the process of debugging, here the current version of the
> script file mentioned in the subject:

A few points of observation:

1. _attach_ the scene as a .pov file to avoid the split-line / wrapping issue

2. You load the same image twice
     #declare P_Heightfield=
     #declare P_Texture=
why not just reuse the same image_map pigment pattern?

3. THEN, you scan the entire image TWICE, which has to take forever
#declare hcolor = eval_pigment(P_Heightfield, <(0.5+b)*(1/xdim),
(0.5+a)*(1/ydim), 1>);
// #declare C_Texture = eval_pigment(P_Texture, <(0.5+b)*(1/(xdim-1)),
(0.5+a)*(1/(ydim-1)), 0>);
and why is one calculation using xdim & ydim, and the other using xdim-1 &
ydim-1 ?

4. it's presently unclear to me how your calculations are working, but it does
seem to me that you are working on the images in the default unit square pigment
pattern.   You should get rid of

#declare xdim=1000; // full resolution: 3601;
#declare ydim=1000; // full resolution: 3601;

and use something like
#declare ImageMap = pigment {image_map {"yourimage.jpg" once} };
#declare Resolution = max_extent (ImageMap);
#declare Resolution = Resolution + <0, 0, 1>;

in order to automatically give you the correct number of pixels in the image.
then if you

scale Resolution

You will have an image_map pigment pattern where you can use integers in your
loops for pixel positions.


5.  I think you're breaking things up into several sequential loops where there
are a lot of redundant things happening, and you would do far better to perform
all of your operations in a single loop.
You store a lot of values in large arrays, but I'm not sure that if it were all
in one loop that you would need to store all of those values.  And of course
that would free up a LOT of memory.

[Jörg "Yadgar" Bleimann] POVEarth: once more mesh2writer.pov [2081 days 4 hours and 15 minutes ago]

Sun, 2 Aug 2020 16:43:44 GMT

Hi(gh)!

By request in the process of debugging, here the current version of the 
script file mentioned in the subject:

// begin of code

#version 3.6;

#include "functions.inc"

#declare rds=false;

global_settings
{
   assumed_gamma 2.2
   #if (rds = true)
     #declare amb=0;
     radiosity { } // most basic radiosity, to be detailed in the future!
   #else
     #declare amb=0.05;
   #end
}



#declare path="Rohdaten/"; // path for ASCII file containg elevation data
#declare path_textures="Texturen/";


#declare xdim=1000; // full resolution: 3601;
#declare ydim=1000; // full resolution: 3601;

#declare rd=6378140-422;
#declare rng=9270;
#declare flattening=0;

#declare latstart=41;
#declare latend=42;
#declare longstart=44;
#declare longend=45;
#declare latsize=latend-latstart;
#declare longsize=longend-longstart;
#declare month=7;

#declare res=1000; // full resolution: 3601;

#if (latstart-1 < 0)
   #declare lat="s";
#else
   #declare lat="n";
#end

#if (longstart < 0)
   #declare long="w";
#else
   #declare long="e";
#end

#declare tilename=concat(lat, str(latstart, -2, 0), long, str(longstart, 
-3, 0));

// tiles are named by the coordinates of their southwestern corner!

#declare altdataname = concat(path, tilename, ".txt");

#declare NumVertices = xdim*ydim;
#declare NumFaces = (xdim-1)*(ydim-1)*2;
#declare NumNormals = NumVertices;
#declare NumTextures = NumVertices;
#declare V_vec_Arr = array[NumVertices];
#declare Face_Arr = array[NumFaces];
#declare N_vec_Arr = array[NumNormals];
#declare T_Arr = array[NumTextures];

#declare a = 0;

#declare P_Heightfield=
pigment
{
   image_map
   {
     "Heightfields/n41e044_1000x1000.png"
     interpolate 2
   }
}

#declare P_Texture=
pigment
{
   image_map
   {
     "Texturen/n41e044_2004-07.png"
     interpolate 2
   }
}


#declare a=0;
#declare c=0;
#while (a < ydim)
   #declare b=0;
   #while (b < xdim)
     #declare hcolor = eval_pigment(P_Heightfield, <(0.5+b)*(1/xdim), 
(0.5+a)*(1/ydim), 1>);
     #declare hval = hcolor.red*rng+hcolor.green*(rng/255);
     #declare V_vec_Arr[c] = 
(rd+hval)*<sin(radians(-longstart-(b/xdim)*longsize))*(1-flattening)*cos(radians(latstart+(a/ydim)*latsize)),
		(1-flattening)*sin(radians(latstart+(a/ydim)*latsize)), 
cos(radians(-longstart-(b/xdim)*longsize))*(1-flattening)*cos(radians(latstart+(a/ydim)*latsize))>;
     #declare c=c+1;		
     #declare b=b+1;
   #end
   #declare a=a+1;
#end

#declare a = 0;
#declare c = 0;
#while (a < ydim-1)
   #declare b = 0;
   #while (b < xdim-1)
     #declare Face_Arr[c] = <a*res+b, a*res+b+1, (a+1)*res+b>;
     #declare Face_Arr[c+1] = <a*res+b+1, (a+1)*res+b+1, (a+1)*res+b>;
     #declare c = c+2;
     #declare b = b+1;
   #end
   #declare a = a+1;
#end

#declare a=0; // vcross(C-B,A-B)
#declare c=0;
#while (a < ydim)
   #declare b=0;
   #while (b < xdim)
     #if (a=0 & b=0) // lower left corner: 1 adjacent face
       #declare nno = vcross(V_vec_Arr[xdim]-V_vec_Arr[1], 
V_vec_Arr[0]-V_vec_Arr[1]);
     #else
       #if (a=0 & b>0 & b<xdim-1) // row 0 except lower left and lower 
right corner: 3 adjacent faces per vertex
	#declare nno = vcross(V_vec_Arr[(a+1)*xdim+(b-1)]-V_vec_Arr[b], 
V_vec_Arr[b-1]-V_vec_Arr[b]);
	#declare nno = nno + 
vcross(V_vec_Arr[(a+1)*ydim+(b-1)]-V_vec_Arr[(a+1)*xdim+b], 
V_vec_Arr[b]-V_vec_Arr[(a+1)*xdim+b]);
	#declare nno = nno + 
vcross(V_vec_Arr[(a+1)*ydim+b]-V_vec_Arr[(a+1)*xdim+b+1], 
V_vec_Arr[b]-V_vec_Arr[(a+1)*xdim+b+1]);
	#declare nno = nno/3;
       #else
	#if (a=0 & b=xdim-1) // lower right corner: 2 adjacent faces
	  #declare nno = vcross(V_vec_Arr[xdim*2-2]-V_vec_Arr[xdim-1], 
V_vec_Arr[xdim-2]-V_vec_Arr[xdim-1]);
	  #declare nno = nno + vcross(V_vec_Arr[xdim*2-2]-V_vec_Arr[xdim*2-1], 
V_vec_Arr[xdim-1]-V_vec_Arr[xdim*2-1]);
	  #declare nno = nno/2;
	#else
	  #if (a>0 & a<ydim-1 & b=0) // leftmost column except lower left and 
upper left corner: 3 adjacent faces per vertex
	    #declare nno = vcross(V_vec_Arr[a*ydim]-V_vec_Arr[(a-1)*ydim+1], 
V_vec_Arr[(a-1)*ydim]-V_vec_Arr[(a-1)*ydim+1]);
	    #declare nno = nno + 
vcross(V_vec_Arr[a*ydim+1]-V_vec_Arr[(a-1)*ydim+1], 
V_vec_Arr[a*ydim]-V_vec_Arr[(a-1)*ydim+1]);
	    #declare nno = nno + 
vcross(V_vec_Arr[(a+1)*ydim]-V_vec_Arr[a*ydim+1], 
V_vec_Arr[a*ydim]-V_vec_Arr[a*ydim+1]);
	    #declare nno = nno/3;
	  #else
	    #if (a>0 & a<ydim-1 & b>0 & b<xdim-1) // all rows and columns not 
touching any edge: 6 adjacent faces per vertex
	      #declare nno = 
vcross(V_vec_Arr[(a-1)*xdim+b]-V_vec_Arr[a*xdim+b-1], 
V_vec_Arr[a*xdim+b]-V_vec_Arr[a*xdim+b-1]);
	      #declare nno = nno + 
vcross(V_vec_Arr[(a-1)*xdim+b+1]-V_vec_Arr[(a-1)*xdim+b], 
V_vec_Arr[a*xdim+b]-V_vec_Arr[(a-1)*xdim+b]);
	      #declare nno = nno + 
vcross(V_vec_Arr[a*xdim+b+1]-V_vec_Arr[(a-1)*xdim+b+1], 
V_vec_Arr[a*xdim+b]-V_vec_Arr[(a-1)*xdim+b+1]);
	      #declare nno = nno + 
vcross(V_vec_Arr[(a+1)*xdim+b]-V_vec_Arr[a*xdim+b+1], 
V_vec_Arr[a*xdim+b]-V_vec_Arr[a*xdim+b+1]);
	      #declare nno = nno + 
vcross(V_vec_Arr[(a+1)*xdim+b-1]-V_vec_Arr[(a+1)*xdim+b], 
V_vec_Arr[a*xdim+b]-V_vec_Arr[(a+1)*xdim+b]);
	      #declare nno = nno + 
vcross(V_vec_Arr[a*xdim+b-1]-V_vec_Arr[(a+1)*xdim+b-1], 
V_vec_Arr[a*ydim+b]-V_vec_Arr[(a+1)*xdim+b-1]);
	      #declare nno = nno/6;
	    #else
	      #if (a>0 & a<ydim-1 & b=ydim-1) // rightmost column except lower 
right and upper right corner: 3 adjacent faces per vertex
		#declare nno = 
vcross(V_vec_Arr[(a-1)*xdim+(xdim-1)]-V_vec_Arr[a*xdim+(xdim-2)], 
V_vec_Arr[a*xdim+(xdim-1)]-V_vec_Arr[a*xdim+(xdim-2)]);
		#declare nno = nno + 
vcross(V_vec_Arr[a*xdim+(xdim-2)]-V_vec_Arr[(a+1)*xdim+(xdim-2)], 
V_vec_Arr[a*xdim+(xdim-1)]-V_vec_Arr[(a+1)*xdim+(xdim-2)]);
		#declare nno = nno + 
vcross(V_vec_Arr[(a+1)*xdim+(xdim-2)]-V_vec_Arr[(a+1)*xdim+(xdim-1)], 
V_vec_Arr[a*xdim+(xdim-1)]-V_vec_Arr[(a+1)*xdim+(xdim-1)]);
		#declare nno = nno/3;
	      #else
		#if (a=ydim-1 & b=0) // upper left corner: 2 adjacent faces
		  #declare nno = vcross(V_vec_Arr[(a-1)*xdim+1]-V_vec_Arr[(a-1)*xdim], 
V_vec_Arr[a*xdim]-V_vec_Arr[(a-1)*xdim]);
		  #declare nno = nno + 
vcross(V_vec_Arr[a*xdim+1]-V_vec_Arr[(a-1)*xdim+1], 
V_vec_Arr[a*xdim]-V_vec_Arr[(a-1)*xdim+1]);
		  #declare nno = nno/2;
		#else
		  #if (a=ydim-1 & b>0 & b<xdim-1) // row 3600 except upper left and 
upper right corner: 3 adjacent faces per vertex
		    #declare nno = 
vcross(V_vec_Arr[(a-1)*xdim+b]-V_vec_Arr[a*xdim+b-1], 
V_vec_Arr[a*xdim+b]-V_vec_Arr[a*xdim+b-1]);
		    #declare nno = nno + 
vcross(V_vec_Arr[(a-1)*xdim+b+1]-V_vec_Arr[(a-1)*xdim+b], 
V_vec_Arr[a*xdim+b]-V_vec_Arr[(a-1)*xdim+b]);
		    #declare nno = nno + 
vcross(V_vec_Arr[a*xdim+b+1]-V_vec_Arr[(a-1)*xdim+b+1], 
V_vec_Arr[a*xdim+b]-V_vec_Arr[(a-1)*ydim+b+1]);
		    #declare nno = nno/3;
		  #else
		    #if (a=ydim-1 & b=xdim-1) // upper right corner, 1 adjacent face
		      #declare nno = 
vcross(V_vec_Arr[xdim*ydim-xdim]-V_vec_Arr[xdim*ydim-2], 
V_vec_Arr[xdim*ydim-1]-V_vec_Arr[xdim*ydim-2]);
		    #end
		  #end
		#end
	      #end
	    #end
	  #end
	#end
       #end
     #end
     #warning str(c, 1, 0)
     #declare N_vec_Arr[c] = vnormalize(nno);
     #declare b=b+1;
     #declare c=c+1;
   #end
   #declare a=a+1;
#end



#declare 
lNormVect=vnormalize(<sin(radians(-longstart-0.5))*cos(radians(latstart+0.5)), 
sin(radians(latstart+0.5)),
cos(radians(-longstart-0.5))*cos(radians(latstart+0.5))>);
#declare ApproxLook = lNormVect * rd;

#fopen ES concat(tilename, ".inc") write
#write (ES, concat("#declare ApproxLook = <", vstr(3, 
ApproxLook,",",3,4), ">;\n"))
#write (ES, concat("#declare F_Earthslice = finish {ambient ",str(amb, 
1, 2)," diffuse 1 brilliance 0.25 }\n"))
#write (ES, concat("#declare Earth_Slice_",tilename,"=\nmesh2\n{\n 
vertex_vectors\n     {\n",str(xdim*ydim, 1, 0),"\n"))

#declare sf=1;

#declare i=0;
#while (i<NumVertices)
   #write (ES, concat("    <",vstr(3, V_vec_Arr[i]-ApproxLook, 
",",3,4),">"))
   #if (i=NumVertices-1)
     #write (ES, "\n")
   #else
     #write (ES, ",\n")
   #end
   #declare i=i+1;
#end
#write (ES,"    }\n")
#write (ES,"	normal_vectors\n")
#write (ES,"	{\n")
#write (ES, concat("    ",str(xdim*ydim, 1, 0),"\n"))
#declare i=0;
#while (i<NumNormals)
   #write (ES, concat("    <",vstr(3, N_vec_Arr[i], ",",3,4),">"))
   #if (i=NumNormals-1)
     #write (ES, "\n")
   #else
     #write (ES, ",\n")
   #end
   #declare i=i+1;
#end

#write (ES,"    }\n")
#if (!(tilename="n80e014" | tilename="n80e016" | tilename="n80e017"))
   #declare i=0;
   #write (ES, "  texture_list")
   #write (ES, "  {\n")
   #write (ES, concat("    ",str(NumTextures, 1, 0),"\n"))
   #declare a=0;
   // #declare c=0;
   #while (a<ydim)
     #declare b=0;
     #while (b<xdim)
       // #declare C_Texture = eval_pigment(P_Texture, 
<(0.5+b)*(1/(xdim-1)), (0.5+a)*(1/(ydim-1)), 0>);
       #declare C_Texture = color rgb <0.5, 0.5, 0.5>;
       #warning concat("Iteration ", str(a, 1, 0), "-", str(b, 1, 0))
       #write (ES, "    texture\n")
       #write (ES, "    {\n")
       #write (ES, "      pigment\n")
       #write (ES, "      {\n")
       #write (ES, concat("	   color rgb <",vstr(3, C_Texture, ",", 1, 
7),">\n"))
       #write (ES, "      }\n")
       #write (ES  "	 finish{ F_Earthslice }\n")
       #write (ES, "    }\n"
       // #declare c=c+1;
       #declare b=b+1;
     #end
     #declare a=a+1;
   #end
   #write (ES, "  }\n")
#end


#write (ES, concat("  face_indices\n{\n    ",str(NumFaces, 7, 0),"\n"))
#declare i=0;
#while (i<NumFaces)
   #write (ES, concat("    <",vstr(3, Face_Arr[i], ",",0, 
0),">,",str(div(i,2), 1, 0)))
   #if (i=NumFaces-1)
     #write (ES, "\n")
   #else
     #write (ES, ",\n")
   #end
   #declare i=i+1;
#end
#write (ES, "  }\n")




/* #while (i < NumTextures)
   #write (ES, concat("texture { T_Arr[",str(i, 1, 0)))
   #if (i=NumTextures-1)
     #write (ES, "\n")
   #else
     #write (ES, ",\n")
   #end
   #declare i=i+1;
#end */

#if (tilename="n80e014" | tilename="n80e016" | tilename="n80e017")
   #write (ES, "  texture\n")
   #write (ES, "  {\n")
   #write (ES, "    pigment { color rgb <0.66, 0.65, 0.65> }\n")
   #write (ES, "    finish { ambient 0.1 diffuse 1 brilliance 0.4 }\n")
   #write (ES, "  }\n")
#end
#write (ES, "  double_illuminate\n")
#write (ES, "  translate ApproxLook\n")
#write (ES, "}\n")
#fclose ES

// end of code

See you in Khyberspace!

Yadgar

[Bald Eagle] Attempted displacement mapping [2102 days 22 hours and 53 minutes ago]

Sat, 11 Jul 2020 22:05:00 GMT

Here's the code for a recent problem posted in advanced users section.

[Cousin Ricky] Re: Machine screw isosurface functions [2123 days 4 hours and 23 minutes ago]

Sun, 21 Jun 2020 16:35:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
> radius.  Since it's likely use is at parse time, not in isosurfaces, I
                   ^

AAAARGH!!!  I hate it when I do that!

[kurtz le pirate] Re: Machine screw isosurface functions [2123 days 11 hours and 33 minutes ago]

Sun, 21 Jun 2020 09:24:57 GMT

On 19/06/2020 04:39, Cousin Ricky wrote:
> This function will create standard machine screw right-handed threading. 
>  Â It accepts major diameter and thread count as arguments, and it should 
> work for both USA and metric sizes.Â  (The geometry has been standardized 
> internationally.)Â  The shaft is oriented vertically.Â  In order
to 
> minimize square root calculations within the runtime loop, a constant is 
> declared outside the function.
> ...
> 
  I made a simple scene to compare the first two functions.
Image contains 100 screws :

             without aa   with aa
Function 1    12.133"    38.230"
Function 2    11.752"    34.931
               -3.1%       -8.6%

The second function is definitely the best.
Better and faster rendering.


Very good job Cousin Ricky !


-- 
Kurtz le pirate
Compagnie de la Banquise

[Cousin Ricky] Machine screw isosurface functions [2125 days 18 hours and 18 minutes ago]

Fri, 19 Jun 2020 02:39:56 GMT

This function will create standard machine screw right-handed threading. 
  It accepts major diameter and thread count as arguments, and it should 
work for both USA and metric sizes.  (The geometry has been standardized 
internationally.)  The shaft is oriented vertically.  In order to 
minimize square root calculations within the runtime loop, a constant is 
declared outside the function.

----------[BEGIN CODE]----------
#include "functions.inc"

#local HTRI2 = sqrt(3);

#declare fn_Screw = function (x, y, z, P0_Dmajor, P1_Thread_count)
{ max
   ( min
     ( f_helix1
       ( -x, y, z, 1, 2*pi * P1_Thread_count,
         HTRI2 / (2 * P1_Thread_count),
         P0_Dmajor / 2 - 0.4375 * HTRI2 / P1_Thread_count,
         1 / HTRI2, 2, 0
       ),
       f_sphere (x, 0, z, P0_Dmajor / 2 - 0.3125 * HTRI2 / P1_Thread_count)
     ),
     f_sphere (x, 0, z, P0_Dmajor / 2)
   )
}
-----------[END CODE]-----------

To get left-handed threading, replace the -x with x.

As a sanity check, I compared my function to Robert Munyer's post from 
last June.  Despite the differences in form, the numbers turn out to be 
the same.

This next function is less straightforward, because it entails twisting 
a square and the re-scaling that entails, but it renders slightly 
faster.  I saved about 7% in tests.

----------[BEGIN CODE]----------
#include "functions.inc"

#local HTRI2 = sqrt(3);
#local P2FACTOR = sqrt(3/8);

#declare fn_Screw = function (x, y, z, P0_Dmajor, P1_Thread_count)
{ max
   ( min
     ( f_helix1
       ( -x, y, z, 1, 2*pi * P1_Thread_count,
         P2FACTOR / P1_Thread_count,
         P0_Dmajor / 2 - 0.4375 * HTRI2 / P1_Thread_count,
         1 / HTRI2, 0, 45
       ),
       f_sphere (x, 0, z, P0_Dmajor / 2 - 0.3125 * HTRI2 / P1_Thread_count)
     ),
     f_sphere (x, 0, z, P0_Dmajor / 2)
   )
}
-----------[END CODE]-----------

The one disadvantage of the above functions is that they are too 
perfect.  With the sharp angles, it is difficult to get good highlights 
and avoid that "ray-traced look."  I'm sure there's some normals trick 
or proximity macro that can improve the look, and I'm even 
half-considering writing a tedious function for a softer version of 
those hills and valleys; but if there's no need for a close-up of the 
screws, this next function can get you some shiny screws of a reasonable 
form.

----------[BEGIN CODE]----------
#include "functions.inc"

#local HTRI = sqrt (3/4);

#declare fn_Screw = function
( x, y, z, P0_Dmajor, P1_Thread_count
)
{ f_sphere
   (   x, 0, z,
       P0_Dmajor / 2
     - (1 - cos (y * 2*pi * P1_Thread_count + atan2 (x, z)))
     * 0.3125 * HTRI / P1_Thread_count
   )
}
-----------[END CODE]-----------

If you wish to model screw holes but don't want to bother modeling the 
internal threads, this function will give you the proper internal 
radius.  Since it's likely use is at parse time, not in isosurfaces, I 
have not bothered to pre-declare any constants.  Note that, as written, 
it accepts a diameter but returns a radius.

----------[BEGIN CODE]----------
#declare fn_Screw_hole_radius = function (P0_Dmajor, P1_Thread_count)
{ P0_Dmajor / 2 - 5 * sqrt(3) / (16 * P1_Thread_count)
}
-----------[END CODE]-----------

[William F Pokorny] Supertoroid parametric scene. [2159 days 4 hours and 2 minutes ago]

Sat, 16 May 2020 16:56:00 GMT

Should others want to play. It's a neat de-formable shape for sure.

Bill P.

[Jörg "Yadgar" Bleimann] POVEarth: scene file [2203 days 19 hours and 15 minutes ago]

Thu, 2 Apr 2020 01:43:07 GMT

Hi(gh)!

Finally, the actual POVEarth scene file - this will grow to GIGANTIC 
dimensions in the coming months, years, decades and centuries by 
including more and more terrain slices and placing more and more detail 
objects!

See you in Khyberspace!

Yadgar

[Jörg "Yadgar" Bleimann] POVEarth: smooth mesh2 generator [2203 days 19 hours and 20 minutes ago]

Thu, 2 Apr 2020 01:38:31 GMT

Hi(gh)!

After several months, I finally found a solution for reducing the 
parsing time when calculating normals for smooth triangles. With 
Melody's original macro, generating a mesh2 of 3601 by 3601 points from 
ASTER terrain data tiles would take about 170 trillion (!!!) iterations 
resulting in 200 days of render time, as the macro just scans the whole 
array of vertices by a nested loop...

...instead, my solution takes the constant patterns of adjacent vertices 
for corner, edge and central points of the mesh2 into account, thus 
reducing parsing time to a mere 2 hours (on an AMD FX-62000 with 24 GiB 
RAM).

Here it is!

See you in Khyberspace!

Yadgar

[Jörg "Yadgar" Bleimann] POVEarth: heightfield generator [2203 days 19 hours and 30 minutes ago]

Thu, 2 Apr 2020 01:28:04 GMT

Hi(gh)!

To generate 16-bit red/green POV-Ray heightfields of 3601 by 3601 pixels 
from the ASTER ASCII elevation data (see my posting "POVEarth: Norway, 
Svalbard, Moffen Island" on p.b.i.) I have written a POV-Ray script 
attached here.

See you in Khyberspace!

Yadgar

[Samuel B ] Something abstract scene file [2229 days 19 hours and 3 minutes ago]

Sat, 7 Mar 2020 01:55:00 GMT

Scene file to go with this:
http://news.povray.org/povray.binaries.images/thread/<web.5e5c41305cd1ad92e57675270%40news.povray.org>/

[Bald Eagle] Roman Ballista Edits [2229 days 20 hours and 38 minutes ago]

Sat, 7 Mar 2020 00:20:01 GMT

Scene file for thread at:

http://news.povray.org/povray.binaries.images/thread/%3Cweb.5e62e6c45f4031dc4eec112d0%40news.povray.org%3E/

[jr] Re: GTS samples as mesh2 [2235 days 1 hour and 43 minutes ago]

Sun, 1 Mar 2020 19:15:01 GMT

"jr" <cre### [at] gmailcom> wrote:
> the attached archive contains the tidied-up source of the 'gts2pov' utility used
> to create the meshes in the zip.  version 0.2.0, GPL v3+.

now version 0.3.0, but completely re-written[*] to optionally calculate vertex
normals.  I've posted two images in p.b.images, both showing meshes with and
without smoothing (cones.png, seashells.png).

since I have not really played with, nor calculated, normals before, I cannot
tell whether the outline above the right side cone is due to some bug in my code
(likely :-)), or the optical "make believe" breaking down.

enjoy, jr.

[*] to use the GTS library.  <http://gts.sourceforge.net/index.html>

[jr] Re: GTS samples as mesh2 [2269 days 9 hours and 48 minutes ago]

Mon, 27 Jan 2020 11:10:00 GMT

hi,

the attached archive contains the tidied-up source of the 'gts2pov' utility used
to create the meshes in the zip.  version 0.2.0, GPL v3+.


enjoy, jr.

[Tor Olav Kristensen] Re: Stepped function offset (attempt #2) [2271 days 2 hours and 18 minutes ago]

Sat, 25 Jan 2020 18:40:00 GMT

Mike Horvath <mik### [at] gmailcom> wrote:
> I have created the attached scene.
>
> It works well, except the pigment function needs to be offset at the
> beginning and end of the gradients "CSolid_HSLSphere_Saturation" and
> "CSolid_HSLSphere_Lightness". The end result is supposed to look like this:
>
> https://commons.wikimedia.org/wiki/File:HSLSphere.svg
>
> Can someone clue me in on how to do this? Thanks.

Hi Mike

Perhaps the code below will help you advance.

--
Tor Olav
http://subcube.com
https://github.com/t-o-k


// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

#version 3.7;

global_settings { assumed_gamma 1.0 }

#include "functions.inc"

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

#declare AngleFn = function { f_th(x, 0, z) + pi };


#declare D = 2*pi/6;
#declare H = D/2;

#declare SectorFn =
    function(s) {
        0
        + select(s - (0*D    ), 0, select(s - (1*D - H), 0, 0))
        + select(s - (1*D - H), 0, select(s - (2*D - H), 1, 0))
        + select(s - (2*D - H), 0, select(s - (3*D - H), 2, 0))
        + select(s - (3*D - H), 0, select(s - (4*D - H), 3, 0))
        + select(s - (4*D - H), 0, select(s - (5*D - H), 4, 0))
        + select(s - (5*D - H), 0, select(s - (6*D - H), 5, 0))
        + select(s - (6*D - H), 0, select(s - (6*D    ), 6, 0))
    }
;


#declare Colors =
    array[7] {
        color rgb <1, 0, 0>,  // Rd
        color rgb <1, 0, 1>,  // Mg
        color rgb <0, 0, 1>,  // Bu
        color rgb <0, 1, 1>,  // Cy
        color rgb <0, 1, 0>,  // Gn
        color rgb <1, 1, 0>,  // Ye
        color rgb <1, 0, 0>   // Rd
    }
;


#declare C = 1/6;
#declare G = C/2;

#declare SectorPigment =
    pigment {
        function { SectorFn(AngleFn(x, y, z))*C }
        color_map {
            [ 0*C     Colors[0] ]
            [ 1*C - G Colors[0] ]
            [ 1*C - G Colors[1] ]
            [ 2*C - G Colors[1] ]
            [ 2*C - G Colors[2] ]
            [ 3*C - G Colors[2] ]
            [ 3*C - G Colors[3] ]
            [ 4*C - G Colors[3] ]
            [ 4*C - G Colors[4] ]
            [ 5*C - G Colors[4] ]
            [ 5*C - G Colors[5] ]
            [ 6*C - G Colors[5] ]
            [ 6*C - G Colors[6] ]
            [ 6*C     Colors[6] ]
        }
    }

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

#declare Rmaj = 9;
#declare Rmin = 1;

torus {
    Rmaj, Rmin
    pigment { SectorPigment }
}

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

#declare R = 7;

#declare RND = seed(7352);

#for (N, 0, 1000)
    #declare X = R*(1 - 2*rand(RND));
    #declare Z = R*(1 - 2*rand(RND));
    #if (f_r(X, 0, Z) < R)
        #declare Angle = AngleFn(X, 0, Z);
        #declare Sector = SectorFn(Angle);
        sphere {
            <X, 0, Z>, 0.2
            pigment { Colors[Sector] }
        }
    #end // if
#end // for

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

camera {
    location 24*y
    look_at 0*y
}

light_source {
    100*<-1, 3, 2>
    color rgb <1, 1, 1>
}

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

[Mike Horvath] Re: Stepped function offset [2271 days 22 hours and 53 minutes ago]

Fri, 24 Jan 2020 22:05:11 GMT

On 1/21/2020 5:25 PM, Bald Eagle wrote:
> Mike Horvath <mik### [at] gmailcom> wrote:
>> I have created the attached scene.
>>
>> It works well, except the pigment function needs to be offset at the
>> beginning and end of the gradients "CSolid_HSLSphere_Saturation" and
>> "CSolid_HSLSphere_Lightness". The end result is supposed to look like this:
>>
>> https://commons.wikimedia.org/wiki/File:HSLSphere.svg
>>
>> Can someone clue me in on how to do this? Thanks.
>>
>>
>> Michael
> 
> This just looks like a 12-section radial pattern.
> Make a color_map or pigment_map and start 1/2-way out of section 12, move along
> normally, and you'll wind up ending 1/2-way through section 12.
> 
> 
> 
> 

Okay, but there are also 7 saturation steps, 7 lightness steps. So 12 x 
7 x 7 sphere chunks total! That will take too much effort for the time 
being.


Mike

[Bald Eagle] Re: Stepped function offset [2274 days 22 hours and 28 minutes ago]

Tue, 21 Jan 2020 22:30:01 GMT

Mike Horvath <mik### [at] gmailcom> wrote:
> I have created the attached scene.
>
> It works well, except the pigment function needs to be offset at the
> beginning and end of the gradients "CSolid_HSLSphere_Saturation" and
> "CSolid_HSLSphere_Lightness". The end result is supposed to look like this:
>
> https://commons.wikimedia.org/wiki/File:HSLSphere.svg
>
> Can someone clue me in on how to do this? Thanks.
>
>
> Michael

This just looks like a 12-section radial pattern.
Make a color_map or pigment_map and start 1/2-way out of section 12, move along
normally, and you'll wind up ending 1/2-way through section 12.

[Melody] Re: Stepped function offset (attempt #2) [2275 days 16 hours and 3 minutes ago]

Tue, 21 Jan 2020 04:55:00 GMT

Mike Horvath <mik### [at] gmailcom> wrote:
> Never mind. Please DO NOT ignore this thread. I finally got the
> explanation right.
>
>
>
>
> On 1/20/2020 1:01 AM, Mike Horvath wrote:
> > Ignore this thread. I will make a third attempt.
> >
> >
> > (I am starting to hate newsgroups.)
> >
> >
> >
> >
> > On 1/20/2020 12:20 AM, Mike Horvath wrote:
> >> I have created the attached scene.
> >>
> >> It works well, except the pigment function needs to be offset at the
> >> beginning and end of the gradients "CSolid_HSLSphere_Saturation" and
> >> "CSolid_HSLSphere_Lightness". The end result is supposed to look like
> >> this:
> >>
> >> https://commons.wikimedia.org/wiki/File:HSLSphere.svg
> >>
> >> Can someone clue me in on how to do this? Thanks.
> >>
> >>
> >> Michael
> >
not ignoring,
befuddling is the dread of going on another day with such heart-breaking sadness
of a world in crisis of dignity vision vitality and character. don't know who
they are, where they are or what they are doing there. u don't like newsgroups,
try and remember that. answers are out there, only cure for your case is age.

she asked me do you like children. well I knew the right answer. but I just
can't lie! everyone is a terminal child, never made it to adulthood. I'm up to
here ^ with children. she never called back. thank goodness.

[Melody] Re: Heads Up [2276 days 10 hours and 23 minutes ago]

Mon, 20 Jan 2020 10:35:00 GMT

BIG correction ...
Here is text2.inc for labels and heads up.

You have invertmatrix(), rotation(r,axis,pnt),
and stuff you need to swim in 3D, or mathematically drown.

[Mike Horvath] Re: Stepped function offset (attempt #2) [2276 days 14 hours and 23 minutes ago]

Mon, 20 Jan 2020 06:34:55 GMT

Never mind. Please DO NOT ignore this thread. I finally got the 
explanation right.




On 1/20/2020 1:01 AM, Mike Horvath wrote:
> Ignore this thread. I will make a third attempt.
> 
> 
> (I am starting to hate newsgroups.)
> 
> 
> 
> 
> On 1/20/2020 12:20 AM, Mike Horvath wrote:
>> I have created the attached scene.
>>
>> It works well, except the pigment function needs to be offset at the 
>> beginning and end of the gradients "CSolid_HSLSphere_Saturation" and 
>> "CSolid_HSLSphere_Lightness". The end result is supposed to look like 
>> this:
>>
>> https://commons.wikimedia.org/wiki/File:HSLSphere.svg
>>
>> Can someone clue me in on how to do this? Thanks.
>>
>>
>> Michael
>

[Mike Horvath] Re: Stepped function offset (attempt #2) [2276 days 14 hours and 24 minutes ago]

Mon, 20 Jan 2020 06:34:14 GMT

Okay, in the attached screenshot there is a horizontal axis that 
represents the saturation axis of the HSL color model. The left box is 
pure gray. The right box is pure red. The other boxes are 1/6, 2/6, 3/6, 
4/6, and 5/6 saturation. The left-most and right-most boxes are 1/2 the 
width of the other boxes.

Does this make sense?




On 1/20/2020 12:40 AM, Mike Horvath wrote:
> Kind of hate newsgroups sometimes, meh.
> 
> Anyway, by offset scale I mean:
> 
> |-0-|---1--|---2--|---3--|---4--|---5--|-6-|
> 
> Notice how the beginning and end sections are 1/2 length.
> 
> Better yet I should draw a diagram explaining the above. Which I will 
> start working on now.
> 
> 
> 
> 
> On 1/20/2020 12:20 AM, Mike Horvath wrote:
>> I have created the attached scene.
>>
>> It works well, except the pigment function needs to be offset at the 
>> beginning and end of the gradients "CSolid_HSLSphere_Saturation" and 
>> "CSolid_HSLSphere_Lightness". The end result is supposed to look like 
>> this:
>>
>> https://commons.wikimedia.org/wiki/File:HSLSphere.svg
>>
>> Can someone clue me in on how to do this? Thanks.
>>
>>
>> Michael
>

[Mike Horvath] Re: Stepped function offset (attempt #2) [2276 days 14 hours and 57 minutes ago]

Mon, 20 Jan 2020 06:01:31 GMT

Ignore this thread. I will make a third attempt.


(I am starting to hate newsgroups.)




On 1/20/2020 12:20 AM, Mike Horvath wrote:
> I have created the attached scene.
> 
> It works well, except the pigment function needs to be offset at the 
> beginning and end of the gradients "CSolid_HSLSphere_Saturation" and 
> "CSolid_HSLSphere_Lightness". The end result is supposed to look like this:
> 
> https://commons.wikimedia.org/wiki/File:HSLSphere.svg
> 
> Can someone clue me in on how to do this? Thanks.
> 
> 
> Michael

[Mike Horvath] Re: Stepped function offset (attempt #2) [2276 days 15 hours and 18 minutes ago]

Mon, 20 Jan 2020 05:40:41 GMT

Kind of hate newsgroups sometimes, meh.

Anyway, by offset scale I mean:

|-0-|---1--|---2--|---3--|---4--|---5--|-6-|

Notice how the beginning and end sections are 1/2 length.

Better yet I should draw a diagram explaining the above. Which I will 
start working on now.

On 1/20/2020 12:20 AM, Mike Horvath wrote:
> I have created the attached scene.
> 
> It works well, except the pigment function needs to be offset at the 
> beginning and end of the gradients "CSolid_HSLSphere_Saturation" and 
> "CSolid_HSLSphere_Lightness". The end result is supposed to look like this:
> 
> https://commons.wikimedia.org/wiki/File:HSLSphere.svg
> 
> Can someone clue me in on how to do this? Thanks.
> 
> 
> Michael

[Mike Horvath] Stepped function offset (attempt #2) [2276 days 15 hours and 38 minutes ago]

Mon, 20 Jan 2020 05:20:22 GMT

I have created the attached scene.

It works well, except the pigment function needs to be offset at the 
beginning and end of the gradients "CSolid_HSLSphere_Saturation" and 
"CSolid_HSLSphere_Lightness". The end result is supposed to look like this:

https://commons.wikimedia.org/wiki/File:HSLSphere.svg

Can someone clue me in on how to do this? Thanks.


Michael

[Mike Horvath] Re: Stepped function offset [2276 days 15 hours and 40 minutes ago]

Mon, 20 Jan 2020 05:18:44 GMT

Ignore this thread, I will start a new one without the dependencies.


On 1/20/2020 12:17 AM, Mike Horvath wrote:
> I have created the attached scene.
> 
> It works well, except the pigment function needs to be offset at the 
> beginning and end of the gradients "CSolid_HSLSphere_Saturation" and 
> "CSolid_HSLSphere_Lightness". The end result is supposed to look like this:
> 
> https://commons.wikimedia.org/wiki/File:HSLSphere.svg
> 
> Can someone clue me in on how to do this? Thanks.
> 
> 
> Michael

[Mike Horvath] Stepped function offset [2276 days 15 hours and 41 minutes ago]

Mon, 20 Jan 2020 05:17:09 GMT

I have created the attached scene.

It works well, except the pigment function needs to be offset at the 
beginning and end of the gradients "CSolid_HSLSphere_Saturation" and 
"CSolid_HSLSphere_Lightness". The end result is supposed to look like this:

https://commons.wikimedia.org/wiki/File:HSLSphere.svg

Can someone clue me in on how to do this? Thanks.


Michael

[Melody] Re: Heads Up [2277 days 19 hours and 28 minutes ago]

Sun, 19 Jan 2020 01:30:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "Melody" <nomail@nomail> wrote:
> > jr wanted ...
>
> very kind, I'm sure, but, mix-up, you got the wrong person.
>
>
> regards, jr

right.
> > Kurtz le pirate

[jr] Re: Heads Up [2277 days 21 hours and 8 minutes ago]

Sat, 18 Jan 2020 23:50:00 GMT

hi,

"Melody" <nomail@nomail> wrote:
> jr wanted ...

very kind, I'm sure, but, mix-up, you got the wrong person.


regards, jr.

[Melody] Heads Up [2277 days 21 hours and 53 minutes ago]

Sat, 18 Jan 2020 23:05:01 GMT

jr wanted on screen text. object label is a bit different. this is on screen
info. one needs both, someday.

InfoDisplay2(concat("Frame: ",str(frame,0,0)),18.8)
InfoDisplay2(concat("Az ",str(360 - _rascension(),0,2)),16.6)
InfoDisplay2(concat("Dec ",str(declination(campos - lastpos),0,2)),14.4)
InfoDisplay2(concat("Roll ",str(roll,0,2)),12.2)
InfoDisplay2(concat("Alt ",str(campos.y,0,2)),10)
InfoDisplay2(concat("Cam ",str(Camera,0,0)),7.8)

this cant be done ... unless u grok 3D

#declare asa_sin = function(a,s,b) {
   sin(b) * (s / sin(pi-(a+b)))
} // ASA solve opposing side of angle2 (b)

know your trig laws.
cant run this. well maybe if you tied all loose ends,
this is just example.

[jr] GTS samples as mesh2 [2286 days 7 hours and 3 minutes ago]

Fri, 10 Jan 2020 13:55:02 GMT

hi,

the attached .zip has mesh2 versions of each of the samples shown on
<http://gts.sourceforge.net/samples.html>.


enjoy, jr.

[Bald Eagle] Re: Tangents between circles [2299 days 19 hours and 53 minutes ago]

Sat, 28 Dec 2019 01:05:01 GMT

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

> ah, that is multi-pass.

Right.  The idea was to have all of the rounded parts in place, the macros puked
out every possible tangent, and then you picked which one you wanted.

> in other words, the values index the 'LastTangent' + 'CurrentTangent' arrays?

Right.  So if you follow the renders in the earlier development posts, you can't
really pick an arc until 2 tangents are picked.  Then one those two tangent line
endpoints are defined, you can then pick one or the other arc connecting the
two.

> from my (obviously) naive point of view, I thought re overlap, the circles are
> in a plane and overlap can be calculated given centres and radii are known.  in
> a macro, that would be part of checking the arguments beforehand.

I think I already did that part and output some stuff to the debug stream.
There are also some flags that get set/unset to skip over nonexistent tangents
that would throw an error in the calculations.

> wrt
> determining which tangent, it should be selected from the combination of
> respective directions and centres; I assume that one can deal in "quadrants" and
> perhaps use some pre-calculated lookup table?

I don't really know what you mean.  I'd need pictures or something.  It would
probably be easy if all of your circle centers were describing a convex hull,
but once you get a concave spot, then it gets super tricky.
Just calculate a "centroid" of sorts by averaging all the center coordinates,
and pick which external tangent based on which endpoint is farthest away from
the centroid.

> yeah, he posted a "teaser" (ie some core (array) missing).  I think it's an
> ..inc, anyway, too will have a look in the next few days or so.

I just downloaded it, and haven't extracted the file to see what it is.

[jr] Re: Tangents between circles [2300 days 18 hours and 13 minutes ago]

Fri, 27 Dec 2019 02:45:01 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > phew, and I'm floundering..  :-(  cannot see how you've arrived at the data in
> > 'CircleArray' elements 6 + 8/9.
> An initial circle array should have everything defined with _All or _Both to
> render a starting image to starting picking tangents and arcs.

ah, that is multi-pass.

> > (part of the confusion is that calculations and representation are so
> > intertwined, like when you use a colour ([n][6]) to select a tangent.  and what
> > is special about the order of indices in 'TangentList'?)
>
> All of the calculations should be nice and neat and tidy in the upper part of
> the scene file. BezierArcs and analyticalTangents

they are, and I've abstracted the "do work" macros in an .inc.  still 700+ lines
remaining after.  :-)

> The TangentList array takes the [named] numerical values that you use to select
> the colored tangent lines and "converts"/indexes that to which tangents in the
> AnalyticalTangent macro output array they correspond to.

in other words, the values index the 'LastTangent' + 'CurrentTangent' arrays?

> > choice of tangents and which part of
> > circumference to draw should be derived.
> I had this idea in mind - but it's never going to be quite that simple, and the
> logic involved in doing that ---- it's going to be challenging.   I had started
> to look into serpentine belt design software to see if I could deivine some
> rules or see some code ---- but that is a LONG tangent [sic] that I thought best
> not to pursue.  "Get the PRISM rendered." was the goal - and that took a mighty
> effort.
> ...
> Well, you'd have to flowchart it out and see what happens.  What happens if the
> circles aren't laid out in the array just like that?  What happens if they
> overlap or one is inside the other (just by mistake).  How do you determine
> which tangent is the "outside" one - to give you the intended, desired "convex
> hull" truncated/rounded triangle that we're talking about?  That seemed like an
> unnecessary mountain to climb over.

from my (obviously) naive point of view, I thought re overlap, the circles are
in a plane and overlap can be calculated given centres and radii are known.  in
a macro, that would be part of checking the arguments beforehand.  wrt
determining which tangent, it should be selected from the combination of
respective directions and centres; I assume that one can deal in "quadrants" and
perhaps use some pre-calculated lookup table?

I suspect the climbing over is worth it though, given the existing "toolbox" of
macros.  you've done most of the sweat-work, now it's more (re)organising code
and writing "wrappers".

> > ...
> > and one more question, a prism made using just two circles, will that be doable
> > (wrt comment above 'ArrayIsLinear')?
> That was the idea.  I put that in there when considering just that - but I don't
> know if I tested that out and saw if it worked properly or not.

ok.

> Got some residual holiday / RL stuff to get out of the way and hopefully I willl
> have a block of uninterrupted time and enough of an energy spurt to make another
> meaningful contribution to this.
> I would also like to see what Leroy has come up with - I'm not sure if his stuff
> only runs under Windows or what...

yeah, he posted a "teaser" (ie some core (array) missing).  I think it's an
..inc, anyway, too will have a look in the next few days or so.


regards, jr.

[Bald Eagle] Re: Tangents between circles [2300 days 19 hours and 38 minutes ago]

Fri, 27 Dec 2019 01:20:00 GMT

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

> phew, and I'm floundering..  :-(  cannot see how you've arrived at the data in
> 'CircleArray' elements 6 + 8/9.

An initial circle array should have everything defined with _All or _Both to
render a starting image to starting picking tangents and arcs.

> (part of the confusion is that calculations and representation are so
> intertwined, like when you use a colour ([n][6]) to select a tangent.  and what
> is special about the order of indices in 'TangentList'?)

All of the calculations should be nice and neat and tidy in the upper part of
the scene file. BezierArcs and analyticalTangents

The TangentList array takes the [named] numerical values that you use to select
the colored tangent lines and "converts"/indexes that to which tangents in the
AnalyticalTangent macro output array they correspond to.

> choice of tangents and which part of
> circumference to draw should be derived.

I had this idea in mind - but it's never going to be quite that simple, and the
logic involved in doing that ---- it's going to be challenging.   I had started
to look into serpentine belt design software to see if I could deivine some
rules or see some code ---- but that is a LONG tangent [sic] that I thought best
not to pursue.  "Get the PRISM rendered." was the goal - and that took a mighty
effort.

> well, that is the idea(l).  Q - can you provide guidance, please?

Well, you'd have to flowchart it out and see what happens.  What happens if the
circles aren't laid out in the array just like that?  What happens if they
overlap or one is inside the other (just by mistake).  How do you determine
which tangent is the "outside" one - to give you the intended, desired "convex
hull" truncated/rounded triangle that we're talking about?  That seemed like an
unnecessary mountain to climb over.

> this is just for drawing prisms, getting an understanding, really; ignore
> pulleys for now.
>
> and one more question, a prism made using just two circles, will that be doable
> (wrt comment above 'ArrayIsLinear')?

That was the idea.  I put that in there when considering just that - but I don't
know if I tested that out and saw if it worked properly or not.

Got some residual holiday / RL stuff to get out of the way and hopefully I willl
have a block of uninterrupted time and enough of an energy spurt to make another
meaningful contribution to this.
I would also like to see what Leroy has come up with - I'm not sure if his stuff
only runs under Windows or what...

[jr] Re: Tangents between circles [2300 days 20 hours and 3 minutes ago]

Fri, 27 Dec 2019 00:55:00 GMT

hi,

sorry for the delay, not forgotten, just occupied with fussing over a new
machine.  :-)  plus RL stuff.

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Current full WIP for your perusal.
> In all it's glorious chaos.

phew, and I'm floundering..  :-(  cannot see how you've arrived at the data in
'CircleArray' elements 6 + 8/9.

(part of the confusion is that calculations and representation are so
intertwined, like when you use a colour ([n][6]) to select a tangent.  and what
is special about the order of indices in 'TangentList'?)

ideally, I would like only to input, per circle, centre, radius, and
(counter)clockwise direction.  choice of tangents and which part of
circumference to draw should be derived.

for instance, say three small circles forming a "nice" triangle.  if all three
run clockwise, it should render a triangular shape with rounded corners, but if
they run counterclockwise the triangle should have cut-out corners (bit like a
jigsaw piece).  iiuc, "inner tangents" would come into play when the next
circle's direction is the opposite of the current.

well, that is the idea(l).  Q - can you provide guidance, please?

this is just for drawing prisms, getting an understanding, really; ignore
pulleys for now.

and one more question, a prism made using just two circles, will that be doable
(wrt comment above 'ArrayIsLinear')?

thanks.

> I haven't worked much on this recently because I got sucked into hounding like a
> dozen people about info on SVD, and so far I haven't gotten much except annoyed
> and maybe a headache.    I think I do have some ideas - I just need to get some
> time to hammer out some test code, etc.   Somehow I always have insights when
> I'm trying to sleep, rather than when I'm in front of the keyboard.   :|

:-)

(the program working to satisfaction now, I take it)

regards, jr.

[Thomas de Groot] Re: Tangents between circles [2317 days 13 hours and 24 minutes ago]

Tue, 10 Dec 2019 07:33:55 GMT

Op 10/12/2019 om 00:42 schreef Bald Eagle:
> Somehow I always have insights when
> I'm trying to sleep, rather than when I'm in front of the keyboard.   :|
> 

Ha! /That/, is a quite common phenomenon indeed. ;-)

-- 
Thomas

[Bald Eagle] Re: Tangents between circles [2317 days 21 hours and 13 minutes ago]

Mon, 9 Dec 2019 23:45:01 GMT

Current full WIP for your perusal.
In all it's glorious chaos.


I haven't worked much on this recently because I got sucked into hounding like a
dozen people about info on SVD, and so far I haven't gotten much except annoyed
and maybe a headache.    I think I do have some ideas - I just need to get some
time to hammer out some test code, etc.   Somehow I always have insights when
I'm trying to sleep, rather than when I'm in front of the keyboard.   :|

[jr] Re: Tangents between circles [2323 days 9 hours and 48 minutes ago]

Wed, 4 Dec 2019 11:10:01 GMT

hi,

"Leroy" <whe### [at] gmailcom> wrote:
> just a little test sample while I clean up things

natty.  made me think of a film projector.  :-)  what if the belt was replaced
with .. transparencies and a light shone through.  should work, no?

looking forward to seeing how it's done.


regards, jr.

[Leroy] Re: Tangents between circles [2323 days 23 hours and 38 minutes ago]

Tue, 3 Dec 2019 21:20:01 GMT

just a little test sample while I clean up things

[jr] Re: Tangents between circles [2327 days 8 hours and 48 minutes ago]

Sat, 30 Nov 2019 12:10:00 GMT

hi,

"Leroy" <whe### [at] gmailcom> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > your code ...
> I need to clean it up a bit.
>  Right now I have several POV files. A few for placing and making pulleys and
> then of course the mesh belt.
>  I've been thinking of making a pulley belt system along the lines of Eagle
> started. The trouble with pulleys is that they really start with the
> belt/rope/chain they use. I've been playing with the standard V belt. There is a
> lot of files! I got to go to work Now. So I'll just drop a few here to make a
> mesh belt.

problem.  'V8dat.inc' is missing, so there's no 'Bpnts' array.  commented out
the 'Macs.inc' include too, what do you need that for?


regards, jr.

[jr] Re: queues [2330 days 21 hours and 8 minutes ago]

Tue, 26 Nov 2019 23:50:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > the new in version 3.8 features have made it easier to implement some "standard"
> > data structures, so here's my version of a couple of queue types:
> > a conventional first in - first out (FIFO) type and a last in - first out
> > (LIFO/stack).
> >
> > the 'queues.inc' file is standalone.  the usage of the macros is documented in
> > the 'queues.html' page.  the archive also includes two (simple) demo scenes.
>
> here's an update, to version 2.  it fixes a bug ...

and introduced another, as I found not long after.  </sigh>

anyway, version 3 then.  I fixed that bug, added some more functionality to the
priority queue type, amended the documentation, and the demo scene.  even
remembered that a zip is the container of choice.  :-)

> > feedback on both the '.inc' and the '.html' is wanted, and welcome, as are
> > criticisms, tips, etc to make "the package" better.


enjoy, jr.

[jr] Re: Tangents between circles [2332 days and 43 minutes ago]

Mon, 25 Nov 2019 20:15:12 GMT

"Leroy" <whe### [at] gmailcom> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > your code is compiled for Windows, which I do not have.  have you published the
> > source?
>
> I need to clean it up a bit.
>  Right now I have several POV files. A few for placing and making pulleys and
> then of course the mesh belt.
>  I've been thinking of making a pulley belt system along the lines of Eagle
> started. The trouble with pulleys is that they really start with the
> belt/rope/chain they use.

yes.  a small set of profiles to select from, perhaps?

> I've been playing with the standard V belt. There is a
> lot of files! I got to go to work Now. So I'll just drop a few here to make a
> mesh belt.
>
> Have Fun!

phew.  a lot of code.  thank you.  intend to look into it in the coming days.


regards, jr.

[jr] Re: queues [2332 days and 43 minutes ago]

Mon, 25 Nov 2019 20:15:07 GMT

"jr" <cre### [at] gmailcom> wrote:
> the new in version 3.8 features have made it easier to implement some "standard"
> data structures, so here's my version of a couple of queue types:
> a conventional first in - first out (FIFO) type and a last in - first out
> (LIFO/stack).
>
> the 'queues.inc' file is standalone.  the usage of the macros is documented in
> the 'queues.html' page.  the archive also includes two (simple) demo scenes.

here's an update, to version 2.  it fixes a bug which limited a queue's max
length to one element less than requested, the 'q?Destroy' macros have been
renamed to (more accurate) 'q?Discard', a new type of queue, priority based, has
been added, the documentation has been updated, and a simple usage example
(tstqp.pov) has been added.

> feedback on both the '.inc' and the '.html' is wanted, and welcome, as are
> criticisms, tips, etc to make "the package" better.

enjoy, jr.

[Leroy] Re: Tangents between circles [2332 days 3 hours and 58 minutes ago]

Mon, 25 Nov 2019 17:00:00 GMT

"jr" <cre### [at] gmailcom> wrote:
>
> Leroy:
>
> your code is compiled for Windows, which I do not have.  have you published the
> source?
>
>
> regards. jr.

I need to clean it up a bit.
 Right now I have several POV files. A few for placing and making pulleys and
then of course the mesh belt.
 I've been thinking of making a pulley belt system along the lines of Eagle
started. The trouble with pulleys is that they really start with the
belt/rope/chain they use. I've been playing with the standard V belt. There is a
lot of files! I got to go to work Now. So I'll just drop a few here to make a
mesh belt.

Have Fun!
// belt maker.pov
// make mesh2 belt
// Vers: 3.7
// Auth: Leroy Whetstone
// Email whe### [at] gmailcom
//====================================================================
#version 3.7;
global_settings {assumed_gamma 1 max_trace_level 20}

#include "colors.inc"
#include "finish.inc"
#include "Math.inc"
#include"Macs.inc"

camera{ orthographic
        location <10,2.5,-10>
        look_at <0,2.5,0>
        right x*15//image_width/image_height
        up y*15
        }

/*/ Test camera
camera{ orthographic
        location <-2.19942,-5.1885,1>
        look_at <-2.19942,-3.1885,0>
        right x*2//image_width/image_height
        up y*2
        }
*/

//#default{ finish{ambient .5}}
  light_source{<0,0,-10> color White}
  light_source{<0,20,10> color White}
  light_source{<0,-20,-10> color White}
background{Pink}

//================================= Change
====================================================

 #include"V8dat.inc"//Pulley & belt placement data

 // belt shape
 #declare L1=5/16;
 #declare L2=L1;
 #declare T1=8/16;
 #declare T4=4/16;

 #declare Dc=.1;//mesh cut size

 #declare Teeth=no;// y/n tooth belt
 #declare Twid= 8/16;//tooth width
 #declare Tspc= 4/16;//space between teeth

 #declare Rate=.1;//test animation

 #declare Dr=1;//animation test direction

 #declare SaveMesh="Belt1.inc";//Belt1.inc save Mesh for including
 #declare Remark="Testing";//remark for save

//=========================== end of Change
====================================================


//-------------============== Belt mesh Shape / uv pigment_map values
===========----------------

//#declare
Mase=array[6]{<0,-T1/2,L2>,<0,-T1/2,0>,<0,-T4/2,-L1>,<0,T4/2,-L1>,<0,T1/2,0>,<0,T1/2,L2>}
#declare
Mase=array[6]{<0,L2,-T1/2>,<0,0,-T1/2>,<0,-L1,-T4/2>,<0,-L1,T4/2>,<0,0,T1/2>,<0,L2,T1/2>}

#declare PL=L2+L1+T4+L1+L2+T1;
#declare BPase=array[7];
#declare BPase[0]=0;  #debug concat("\n___ Belt texture Map Points___\nBPase[0]
=",str(BPase[0],3,3),"\n")
#declare BPase[1]=L2/PL; #debug concat("BPase[1] =",str(BPase[1],3,3),"\n")
#declare BPase[2]=(L2+L1)/PL; #debug concat("BPase[2] =",str(BPase[2],3,3),"\n")
#declare BPase[3]=(L2+L1+T4)/PL; #debug concat("BPase[3]
=",str(BPase[3],3,3),"\n")
#declare BPase[4]=(L2+L1+T4+L2)/PL; #debug concat("BPase[4]
=",str(BPase[4],3,3),"\n")
#declare BPase[5]=(L2+L1+T4+L2+L1)/PL;#debug concat("BPase[5]
=",str(BPase[5],3,3),"\n")
#declare BPase[6]=(L2+L1+T4+L2+L1+T1)/PL;#debug concat("BPase[6]
=",str(BPase[6],3,3),"\n")

//-------------============== clac Belt length
======================------------------------
#declare Ang=array[Pnts];
#declare Plen=array[Pnts];

#declare TL=0;
#for(I,0,Pnts-1)
  #declare TL=TL+vlength(Bpnts[0][I]-Bpnts[1][I]);
  //sphere{Bpnts[0][i]-z*Bsize,.2}
  //sphere{Bpnts[1][i]-z*Bsize,.2 pigment{rgb 1}}
#end
//#debug concat("LineLength =",str(TL,3,3),"\n")

#for(I,0,Pnts-1)
  #declare J=Rod(I+1,Pnts);
  #declare W1=Bpnts[1][I]-Loc[J]; #declare W2=Bpnts[0][J]-Loc[J];
  #declare A=VAngleD(W1,W2);

  #if(Type[J]) //check for super wide
   #if(vlength((Bpnts[1][I]+Bpnts[0][J])/2)<vlength(Loc[J]))
    #declare A=(360-A); //#debug concat("i1 =",str(J,0,0),"\n")
    //sphere {(Bpnts[1][i]+Bpnts[0][J])/2-Bsize*z,.2}
   #end
  #else
   #if(vlength((Bpnts[1][I]+Bpnts[0][J])/2)>vlength(Loc[J]))
    #declare A=(360-A); //#debug concat("i2 =",str(J,0,0),"\n")
   #end
  #end
   //#debug concat(str(J,0,0)," A =",str(A,3,3)," ")
   #declare Ang[J]=A;
   #declare A=A/360;
  #declare D=2*Rad[J]; //#debug concat("D =",str(D*pi,9,6),"  L
=",str(D*pi*A,-9,6),"  A =",str(A,-9,6),"\n")
  #declare Plen[J]=D*pi*A;
  #declare TL=TL+(D*pi*A);
#end
#debug concat("\nBelt Length =",str(TL,3,3),"\n")
//#debug concat("Tri_Points =",str(int(TL/Dc+.5)*6,3,3),"\n")

//-------------============== End of clac Belt length
======================------------------------

//---------------------================= Points
============================--------------
#declare MaxMpnts=int(TL/Dc+.5)*6;

#declare Mpnts=array[MaxMpnts];// mesh points

#declare Cnt=0;
#for(I,0,Pnts-1)
  #declare J=Rod(I+1,Pnts);
  //#debug concat("I =",str(I,0,0),"  Cnt =",str(Cnt,0,0),"\n")
  //Belt-rods

  #declare An= VAngleD(Bpnts[1][I]-Bpnts[0][I],x);
  #if(Bpnts[1][I].y<Bpnts[0][I].y)  #declare An=-An; #end

  //cylinder{Bpnts[0][I]-z,Bpnts[0][I]+z,Bsize pigment{rgb 0}}
  //cylinder{Bpnts[1][I]-z,Bpnts[1][I]+z,Bsize pigment{rgb 1}}

//  cylinder{Bpnts[0][I],Bpnts[1][I],Bsize
//   pigment{PigB translate -x*(RL+ML) rotate An*z translate Bpnts[0][I]}}
  #declare VL=vlength(Bpnts[0][I]-Bpnts[1][I]);

  #for(P,0,VL,Dc)
   #for(W,0,5)
    #declare Mpnts[Cnt]= vrotate(Mase[W]+x*P,An*z)+Bpnts[0][I];
   //  #if(Cnt<27) sphere{Mpnts[Cnt],.02 pigment{rgb W/5}} #end
    #declare Cnt=Cnt+1;//#debug concat("Cnt =",str(Cnt,0,0),"\n")
   #end
  #end

  #declare H=Plen[J]/Dc;//#debug concat("H =",str(H,3,3),"\n")
  #declare Da=Ang[J]/H; //#debug concat("Da =",str(Da,3,3),"\n")
  // pully curves

  #if(Type[J]) #declare Rm=-1;
  #else        #declare Rm=1;
  #end
  //#debug " \n"
  #declare Q= Bpnts[1][I]-Loc[J];
  #declare Sa=VAngleD(Q,-x);
  #declare Rn=1; #if(Q.y>0) #declare Rn=-1;#end

  #for(P,0,Ang[J]-Da,Da)
   #for(W,0,5)
    #declare Tp=vrotate(vrotate(Mase[W],-Rm*90*z)-x*Rad[J],Rn*Sa*z);
    #declare Mpnts[Cnt]= vrotate(Tp,Rm*P*z)+Loc[J];
    //#if(Cnt>3065) sphere{Mpnts[Cnt],.01 pigment{rgb W/5}} #end
    #declare Cnt=Cnt+1; //#debug concat("Cnt =",str(Cnt,0,0),"\n")
   #end
  #end
  //#debug "pass\n"

#end //loop


//--------------------------Teeth-------------------------------------
 #if(Teeth)
   #declare TLen=Twid+Tspc;
   #declare Gt=int(TLen/Dc)*6; #debug concat("Gt =",str(Gt,0,0),"\n")
   #declare Gu=int(Tspc/Dc); #debug concat("Gu =",str(Gu,0,0),"\n")
   #for(I,Gt,Cnt-1,Gt)
    #declare Tat= I-3;    #debug concat("Tat =",str(Tat,0,0),"\n")
    #for(J,0,Gu-1)
     #declare TV=vnormalize(Mpnts[I-2]-Mpnts[I-1]);
     #declare Mpnts[Tat]=Mpnts[Tat]-TV*L2;
     #declare Mpnts[Tat-1]=Mpnts[Tat-1]-TV*L2;
     #declare Tat= Tat-6;
    #end
   #end

 #end

//---------------------================= Triangles
============================--------------

  #debug concat("\nvertex_vectors->Cnt =",str(Cnt,0,0),"\n")
#declare Tris=array[4*Cnt];

#declare Cnt2=0;
#for(I,0,Cnt-1,6)
   #for(J,0,4)
    #declare K=mod(J+I,Cnt);
    #declare Tris[Cnt2]=<K,mod(K+6,Cnt),mod(K+7,Cnt)>;
     #declare Cnt2=Cnt2+1;
    #declare Tris[Cnt2]=<K,mod(K+7,Cnt),mod(K+1,Cnt)>;
     #declare Cnt2=Cnt2+1;
   #end
    #declare K=mod(I+5,Cnt);
    #declare Tris[Cnt2]=<I,mod(K+1,Cnt),mod(K+6,Cnt)>;
     #declare Cnt2=Cnt2+1;
    #declare Tris[Cnt2]=<mod(I,Cnt),mod(K,Cnt),mod(I+11,Cnt)>;
     #declare Cnt2=Cnt2+1;
#end
  #debug concat("face_indices->Cnt2 =",str(Cnt2,0,0),"\n")

//---------------------================= UV Values
============================--------------
#declare Tcn=Cnt2+TL; #debug concat("uv_vectors->Tcn = ",str(Tcn,0,0),"\n")

#declare UVar=array[Tcn];
#for(I,0,Tcn-1)
   #declare K=mod(I,7);
   #declare J=int(I/7);
   #declare UVar[I]=<J*Dc,BPase[K]>;
#end


#declare UVin=array[Cnt2];
#declare Cnt3=0;#declare Trs=0;
#for(W,0,Cnt-1,6)
   #declare I=Trs+W;
   #for(J,0,4)
    #declare K=mod(J+I,Tcn);
    #declare UVin[Cnt3]=<K,mod(K+7,Tcn),mod(K+8,Tcn)>;
     #declare Cnt3=Cnt3+1;
    #declare UVin[Cnt3]=<K,mod(K+8,Tcn),mod(K+1,Tcn)>;
     #declare Cnt3=Cnt3+1;
   #end
    #declare K=mod(I+6,Tcn);
    #declare UVin[Cnt3]=<I+5,mod(K+6,Tcn),mod(K+7,Tcn)>;
     #declare Cnt3=Cnt3+1;
    #declare UVin[Cnt3]=<mod(I+5,Tcn),mod(K,Tcn),mod(K+7,Tcn)>;
     #declare Cnt3=Cnt3+1;
  #declare Trs=Trs+1;
#end
 //#debug concat("I+12 =",str(I+12,0,0),"\n")
 #debug concat("UV_indices->Cnt3 =",str(Cnt3,0,0),"\n")

//---------------------=========== Mesh2 Test textures
============================--------------

#declare Pig1=pigment{agate}
#declare Pig2=pigment{bozo}
#declare Pig3=pigment{agate}
#declare Pig4=pigment{agate color_map{[0 Gold][1 Brown]}}

#declare Pig9=pigment{gradient y }

#declare PigY=pigment{gradient y
               color_map{ [BPase[1]  Red]
                          [BPase[1]  Blue]
                          [BPase[2]  Blue]
                          [BPase[2]  Green]
                          [BPase[3]  Green]
                          [BPase[3]  Gold]
                          [BPase[4]  Gold]
                          [BPase[4]  Pink]
                          [BPase[5]  Pink]
                          [BPase[5]  rgb 0]
                         }
                         }



#declare PigX=pigment{gradient y
               pigment_map{ [BPase[1]  Pig1]
                            [BPase[1]  Pig2]
                            [BPase[2]  Pig2]
                            [BPase[2]  Pig3]
                            [BPase[3]  Pig3]
                            [BPase[3]  Pig4]
                            [BPase[4]  Pig4]
                            [BPase[4]  Pig3]
                            [BPase[5]  Pig3]
                            [BPase[5]  Pig2]
                          }
                         }

#declare Tex=texture{pigment{PigX} normal{granite scale<1/TL,.5,1>} }

#declare Cm=color_map{[.4 rgb 0][.5 rgb .5][1 rgb .25]}

#declare Tex1=texture{pigment{granite color_map{Cm} scale<5,.01,1>}
              normal{agate  scale<10/TL,.05,.1>}finish{brilliance 4}}
#declare Tex2=texture{pigment{granite color_map{Cm} scale<2,.01,1>}
              normal{agate  scale<1/TL,.1,1>} finish{brilliance 3}}
#declare Tex3=texture{pigment{rgb .25} normal{agate scale<.2,1,1>} finish{Dull}}
#declare Tex4=texture{pigment{image_map {sys "Belt2.bmp" }scale
<6,T1/PL,1>}finish{Phong_Glossy}}
//#declare Tex5=texture{pigment{agate} }//normal{agate } }

#debug concat("T1/PL =",str(T1/PL,3,3),"\n")
#declare TexX=texture{gradient y
               texture_map{ [BPase[1]  Tex1]
                            [BPase[1]  Tex2]
                            [BPase[2]  Tex2]
                            [BPase[2]  Tex3]
                            [BPase[3]  Tex3]
                            [BPase[3]  Tex2]
                            [BPase[4]  Tex2]
                            [BPase[4]  Tex1]
                            [BPase[5]  Tex1]
                            [BPase[5]  Tex4]
                          }
                         }

//---------------------================= Mesh2
============================--------------


mesh2{
      vertex_vectors{
      Cnt
      #for(I,0,Cnt-1)
       Mpnts[I]
      #end
      }
      uv_vectors{
      Tcn
      #for(I,0,Tcn-1)
       UVar[I]
      #end
      }

      face_indices{
      Cnt2
      #for(I,0,Cnt2-1)
       Tris[I]
      #end
      }

      uv_indices{
      Cnt3
      #for(I,0,Cnt3-1)
       UVin[I]
      #end
     }

     uv_mapping
     texture{TexX translate x*Dr*Rate*frame_number}}

/*/show ring
#for(I,0,5)
 #declare K=mod(I+1,6);
 cylinder{Mpnts[I],Mpnts[K],.01 pigment{rgb I/5}}
#end
*/

//===========================Save Mesh
=============================================++++++

#if(strlen(SaveMesh))
 #fopen Mfile SaveMesh write
 #write (Mfile "// ",Remark,"\n")
  #write (Mfile "#local TL=",TL,";\n")
 #write (Mfile "#local Tex1=texture{pigment{granite scale<5,.01,1>} normal{agate
 scale<10/TL,.05,.1>}}\n")
 #write (Mfile "#local Tex2=texture{pigment{granite scale<2,.01,1>} normal{agate
 scale<1/TL,.1,1>} }\n")
 #write (Mfile "#local Tex3=texture{pigment{rgb .25} normal{agate scale<.2,1,1>}
finish{Dull}}\n")
 #write (Mfile "#local Tex4=texture{pigment{agate} normal{bozo }
finish{Dull}}\n\n")
 #write (Mfile "#local TexX=texture{gradient y \n")
 #write (Mfile "              texture_map{ [",BPase[1]," Tex1] // top left
side\n")
 #write (Mfile "                           [",BPase[1]," Tex2] // bottom left
side\n")
 #write (Mfile "                           [",BPase[2]," Tex2]\n")
 #write (Mfile "                           [",BPase[2]," Tex3] // bottom :
inside\n")
 #write (Mfile "                           [",BPase[3]," Tex3]\n")
 #write (Mfile "                           [",BPase[3]," Tex2] // bottom right
side\n")
 #write (Mfile "                           [",BPase[4]," Tex2]\n")
 #write (Mfile "                           [",BPase[4]," Tex1] // top right
side\n")
 #write (Mfile "                           [",BPase[5]," Tex1]\n")
 #write (Mfile "                           [",BPase[5]," Tex4] // top :
outside\n")
 #write (Mfile "                         } \n")
 #write (Mfile "                        }  \n")

 #write (Mfile "#declare Belt=\n")
 #write (Mfile "mesh2{\n")
 #write (Mfile "      vertex_vectors{\n")
 #write (Mfile "       ",Cnt,"\n")
   #declare Tdf=0;
   #for(I,0,Cnt-1)
    #if(Tdf=0) #write (Mfile "       ")  #end
       #write (Mfile Mpnts[I])
    #if(I<Cnt-1) #write (Mfile ",")  #end
    #declare Tdf=Tdf+1;
    #if(Tdf=3) #declare Tdf=0;#write (Mfile "\n") #end
   #end
    #if(Tdf) #write (Mfile "\n") #end
  #write (Mfile "        }\n")

 #write (Mfile "      uv_vectors{\n")
 #write (Mfile "       ",int(Tcn),"\n")
   #declare Tdf=0;
   #for(I,0,Tcn-1)
    #if(Tdf=0) #write (Mfile "       ")  #end
       #write (Mfile UVar[I])
    #if(I<Tcn-1) #write (Mfile ",")    #end
    #declare Tdf=Tdf+1;
    #if(Tdf=5) #declare Tdf=0;#write (Mfile "\n") #end
   #end
    #if(Tdf) #write (Mfile "\n") #end
  #write (Mfile "        }\n")

 #write (Mfile "      face_indices{\n")
 #write (Mfile "       ",Cnt2,"\n")
   #declare Tdf=0;
   #for(I,0,Cnt2-1)
    #if(Tdf=0) #write (Mfile "       ") #end
       #write (Mfile Tris[I])
    #if(I<Cnt2-1) #write (Mfile ",")   #end
    #declare Tdf=Tdf+1;
    #if(Tdf=5) #declare Tdf=0;#write (Mfile "\n") #end
   #end
    #if(Tdf) #write (Mfile "\n") #end
  #write (Mfile "        }\n")

 #write (Mfile "      uv_indices{\n")
 #write (Mfile "       ",Cnt3,"\n")
   #declare Tdf=0;
   #for(I,0,Cnt3-1)
    #if(Tdf=0) #write (Mfile "       ") #end
       #write (Mfile UVin[I])
    #if(I<Cnt3-1) #write (Mfile ",")   #end
    #declare Tdf=Tdf+1;
    #if(Tdf=5) #declare Tdf=0; #write (Mfile "\n") #end
   #end
    #if(Tdf) #write (Mfile "\n") #end
  #write (Mfile "        }\n")
  #write (Mfile "  uv_mapping\n")
  #write (Mfile "  texture{TexX translate x*Tloc}\n")

  #write (Mfile "    }\n")
#end



// V8dat.inc  Data for belt

#declare Pnts=4;

#declare Bsize=0.3;

#declare Loc=array[Pnts]{<0,-3,0> ,<-5.25,4.5,0> ,<0,3.1,0> ,
                         <5.25,4.5,0> }

#declare Rad=array[Pnts]{2,1.5,1,1.5}

#declare Type=array[Pnts]{1,1,0,1}

#declare Bpnts=array[2][Pnts]{{<-1.69866,-4.05573,0> ,<-4.23998,5.60899,0>
,<0.673345,2.36067,0> ,
                               <6.52399,3.7082,0> }
                              {<-6.52399,3.7082,0> ,<-0.673345,2.36067,0>
,<4.23998,5.60899,0> ,
                               <1.69866,-4.05573,0> }
                             }

[jr] Re: Tangents between circles [2334 days 4 hours and 53 minutes ago]

Sat, 23 Nov 2019 16:05:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
>
> > one question is: in the #for() loop near bottom, you test for IFlag and OFlag.
> > naively, given two circles A + B which do not touch/overlap, you always get 4
> > tangents, no?  by mandating "sane" scenarios you might be able to get rid of
> > some conditional code.
>
> Right, but computing the arcs and tangent lines wasn't meant to solely address
> the "belt/pulley problem" - the point was to get tangent lines to circles to
> design a prism.  I don't much care about the conditional code, and it all seems
> fast enough, especially since it won't be in a loop that gets executed 1000
> times.
>
> It would also be nice to have a block of code that doesn't crap out if the
> "wrong" data gets entered into the circle array.

that's kind of what I meant by "sane".  should be easy enough to write a bit of
code which checks the input arguments.

I think the existing macros/code can easily be "wrapped" in two distinct,
specialised macros: one to make prisms, the other for pulley systems.

> > the comments in the code suggest that you can "classify" the tangents (order +
> > direction) and used colour to see that info; is that code available too?
>
> Right.  If you look at the original thread, ALL the tangents and arcs get shown.
> Then you can eliminate the tangents that don't apply, and then with only two
> endpoints on a circle, you can then highlight two discrete arcs to choose from.
> Then you can select/correct the direction so that the ordering of the points to
> generate the prism is correct.

all the arc stuff is missing from the code, as posted, though.  ;-)

> Let me see where I'm at with that scene file - just put it back on my radar if I
> don't get back to you on it in the next week or so.
>
> > > Certainly I'd love to work out the logic of animating it, and doing something
> > > like a toothed belt or chain to run along gears or sprockets.
> > given knowledge of radius of A, and the number of degrees it revolves from one
> > frame to the next, it would just require to map that length of arc to B to get
> > the corresponding angle (not that I could actually do it).
>
> That's great for - one arc.  Now picture 5 pulleys and you want to highlight one
> link in the chain and follow that around the whole system.
>
> It's sounds - excessive to do, but from an animator's standpoint - to give the
> viewer that visual cue with which to infer motion and direction... it makes a
> BIG difference.

number of pulleys is a bit of a red herring.  for me, the focus is (ought to be)
on the chain/belt/cable.

say you have a structure like

#declare D = dictionary {
  .pulleys:  array {
               array mixed {<x,y,z>, r, cc, texture{}},
                 ...
             },
  .route:    array {3,1,0,2},
  .ndegree:  n.n
};

then "only" .route needs processing, and the belt gets "threaded" according to
pulley index and counter-clockwise (cc) flag; assuming .ndegree is number of
degrees first pulley turns per frame all other pulleys can be derived knowing
the frame number.  and some other keys for belt texture, start and end points
(if provided draw a cable), etc too.

but I just read Leroy's post, and while I've no idea of the complexity involved,
having one mesh vs many separate parts does sound good/better.

> > I hope I can make some headway understanding the code, and hopefully learn how
> > to "assemble" the correct tangents into a belt or cable.  I probably won't be
> > able to avoid stumbling into problems.  :-)
>
> Well in that end section, there's the parts that control the outer tangents, and
> the inner tangents.  Just change "pigment {LinePigment}" into something
> different for all 4 lines, and you'll see exactly which one is which.

now the main "problem" is not having a code example to glean the usage of the
Bezier_* macros to shape the connecting arcs.


Leroy:

your code is compiled for Windows, which I do not have.  have you published the
source?


regards. jr.

[Leroy] Re: Tangents between circles [2334 days 17 hours and 58 minutes ago]

Sat, 23 Nov 2019 03:00:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
>

>
> > > Certainly I'd love to work out the logic of animating it, and doing something
> > > like a toothed belt or chain to run along gears or sprockets.
> >
> > given knowledge of radius of A, and the number of degrees it revolves from one
> > frame to the next, it would just require to map that length of arc to B to get
> > the corresponding angle (not that I could actually do it).
>
> That's great for - one arc.  Now picture 5 pulleys and you want to highlight one
> link in the chain and follow that around the whole system.
>
> It's sounds - excessive to do, but from an animator's standpoint - to give the
> viewer that visual cue with which to infer motion and direction... it makes a
> BIG difference.
>

I'm back. I glances over Eagles code. A lot of math there!
But I'm here to talk about the animated belt. I through away all my belt parts.
(pieces of prisms and lathes) and made a large mesh2 using the same variables
that where use to cut and place the belt parts. Now with UV mapping I can have a
different texture on each of the 6 faces of a belt.
 While I was playing with the textures I can up with idea for that toothed belt.
Every where there is a space between the teeth move the vertex_vectors in that
area so that they are flush.
 I haven't done a done a complete animation yet. But the plain belt should be no
problem, just translate late the textures. The tooth belt would have to be
remade for every scene.

Have fun! I have.

[Bald Eagle] Re: Tangents between circles [2336 days 22 hours and 18 minutes ago]

Wed, 20 Nov 2019 22:40:01 GMT

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

> one question is: in the #for() loop near bottom, you test for IFlag and OFlag.
> naively, given two circles A + B which do not touch/overlap, you always get 4
> tangents, no?  by mandating "sane" scenarios you might be able to get rid of
> some conditional code.

Right, but computing the arcs and tangent lines wasn't meant to solely address
the "belt/pulley problem" - the point was to get tangent lines to circles to
design a prism.  I don't much care about the conditional code, and it all seems
fast enough, especially since it won't be in a loop that gets executed 1000
times.

It would also be nice to have a block of code that doesn't crap out if the
"wrong" data gets entered into the circle array.

> the comments in the code suggest that you can "classify" the tangents (order +
> direction) and used colour to see that info; is that code available too?

Right.  If you look at the original thread, ALL the tangents and arcs get shown.
Then you can eliminate the tangents that don't apply, and then with only two
endpoints on a circle, you can then highlight two discrete arcs to choose from.
Then you can select/correct the direction so that the ordering of the points to
generate the prism is correct.

Let me see where I'm at with that scene file - just put it back on my radar if I
don't get back to you on it in the next week or so.

> > Certainly I'd love to work out the logic of animating it, and doing something
> > like a toothed belt or chain to run along gears or sprockets.
>
> given knowledge of radius of A, and the number of degrees it revolves from one
> frame to the next, it would just require to map that length of arc to B to get
> the corresponding angle (not that I could actually do it).

That's great for - one arc.  Now picture 5 pulleys and you want to highlight one
link in the chain and follow that around the whole system.

It's sounds - excessive to do, but from an animator's standpoint - to give the
viewer that visual cue with which to infer motion and direction... it makes a
BIG difference.

> I hope I can make some headway understanding the code, and hopefully learn how
> to "assemble" the correct tangents into a belt or cable.  I probably won't be
> able to avoid stumbling into problems.  :-)

Well in that end section, there's the parts that control the outer tangents, and
the inner tangents.  Just change "pigment {LinePigment}" into something
different for all 4 lines, and you'll see exactly which one is which.

[jr] Re: Tangents between circles [2336 days 23 hours and 13 minutes ago]

Wed, 20 Nov 2019 21:45:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Right-o.   I just got a quick demo scene posted before it dropped off the
> back-burner.
> ...
> I'd say that the best help at the moment might be to just look it over and do a
> parallel implementation, starting from what I posted.   That would give me new
> ideas for how to process the data, and other things with what to do with the
> results that I might not have thought of yet.
>
> Also, asking any questions you may have about specific bits of the code would
> help me document it, and in the process re-read and re-think what I've already
> done.

one question is: in the #for() loop near bottom, you test for IFlag and OFlag.
naively, given two circles A + B which do not touch/overlap, you always get 4
tangents, no?  by mandating "sane" scenarios you might be able to get rid of
some conditional code.

the comments in the code suggest that you can "classify" the tangents (order +
direction) and used colour to see that info; is that code available too?

> Certainly I'd love to work out the logic of animating it, and doing something
> like a toothed belt or chain to run along gears or sprockets.

given knowledge of radius of A, and the number of degrees it revolves from one
frame to the next, it would just require to map that length of arc to B to get
the corresponding angle (not that I could actually do it).

provides all needed info when combined with the frame number.

> I haven't done much pathological case testing, because it's already a miracle
> that it even works at all.

I hope I can make some headway understanding the code, and hopefully learn how
to "assemble" the correct tangents into a belt or cable.  I probably won't be
able to avoid stumbling into problems.  :-)

regards, jr.

[Bald Eagle] Re: [Minimum Volume] Bounding Ellipsoid via SVD [2338 days 21 hours and 28 minutes ago]

Mon, 18 Nov 2019 23:30:01 GMT

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

> some small progress.  I shortened the data to ten rows, prefixed by cols + rows,
> run it with:
>   $ tr ' ' '\n' < be-vectors | svd

So just replace any spaces with a newline and pipe it to the svd script.

> the "bugbear" is that the code expects to see square matrices.

meh.  For the time being we can just create/resize all matrices with the
optional appending of ", 0)" like so:

inv_matrix[index].resize(matrix[index].size(), 0);

> compare this to the previous, wrt loop (counter) limit.  I suspect all functions
> dealing with matrices will need similar change(s).

I'm not sure what the limit is, but I doubt that you or I would be using more
than 500 points just to do some orienting.  I think right now, just keep it
simple, and get a "flow" working so that we can integrate POV-Ray's .ini and
post-render capabilities so that an object can be "scanned", the vectors written
to disk, SVD can spit out an orientation matrix, and the scene can be re-run: at
which point it checks to see if a data file and/or matrix file has been written,
and then it just skips over to the part where it renders the oriented object.

I'll look it over and see what I can hammer out.   Busy day.
Thanks for the tips.   :)

Having fun with our new friend I see  ;)

[jr] Re: [Minimum Volume] Bounding Ellipsoid via SVD [2339 days 7 hours and 13 minutes ago]

Mon, 18 Nov 2019 13:45:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > please post a data file.
> done.
> ...
> 400 x 3 matrix.   A "vector" data type that uses 400 povray vectors split up
> into x, y, and z values.
hi,

some small progress.  I shortened the data to ten rows, prefixed by cols + rows,
run it with:
  $ tr ' ' '\n' < be-vectors | svd


3 10
0.0883597 -0.326943 -0.337204
-0.405332 0.103699 0.242547
0.421881 0.0228523 -0.10112
0.432184 0.124463 -0.081805
-0.397722 -0.42712 0.00183197
0.176067 -0.254352 -0.364851
-0.0141579 0.454459 -0.317524
0.354473 0.731663 -0.0403544
0.188762 -0.165013 0.215763
0.267797 0.895557 -0.10793


the "bugbear" is that the code expects to see square matrices.  the following
modifications get me to the point where 'svd()' is called in main; I think the
transpose_matrix is next in need of .. attention.


int main(int argc, char* argv[]) {
  std::size_t mncols = 0,
              mnrows = 0;
  std::vector<std::vector<cpp_bin_float_4096> > u, v;
  std::vector<std::vector<cpp_bin_float_4096> > matrix, s;
  std::cout << "Singular Value Decomposition (SVD):\n";

  std::cin >> mncols;  std::cout << "number columns: " << mncols << ".\n";
  std::cin >> mnrows;  std::cout << "number rows: " << mnrows << ".\n";

  if (mnrows <= 500)
  {
    generate_matrix(matrix, mnrows, mncols);
    std::cout << "\nA = \n"; print_matrix(matrix);
    svd(matrix, s, u, v);
    std::cout << "\nS = \n"; print_matrix(s);
    std::cout << "\nU = \n"; print_matrix(u);
    std::cout << "\nV = \n"; print_matrix(v);
  }
  else std::cout << "Wrong matrix size... (matrix decomposition recommended)";

  return 0;
}


template<typename Arg = cpp_bin_float_4096>
void print_matrix(std::vector<std::vector<cpp_bin_float_4096> >  matrix)
{
  for (std::size_t row = 0; row < matrix.size(); row++)
  {
    for (std::size_t col = 0; col < matrix[row].size(); col++)
      std::cout << std::setprecision(1) << std::fixed << matrix[row][col]
              << " "; std::cout << "\n";
  }

//  std::cout << "\n";
}

compare this to the previous, wrt loop (counter) limit.  I suspect all functions
dealing with matrices will need similar change(s).


template<typename Arg = cpp_bin_float_4096>
void generate_matrix(std::vector<std::vector<cpp_bin_float_4096> >& \
  matrix, std::size_t rows, std::size_t cols)
{
  std::srand((unsigned int)std::time(nullptr)); matrix.resize(rows);
  for (std::size_t row = 0; row < matrix.size(); row++)
  {
    matrix[row].resize(cols);
    for (std::size_t col = 0; col < matrix[row].size(); col++)
      std::cin >> matrix[row][col];
  }
}


regards, jr.

[jr] Re: [Minimum Volume] Bounding Ellipsoid via SVD [2339 days 18 hours and 13 minutes ago]

Mon, 18 Nov 2019 02:45:01 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > please post a data file.
> done.

cheers.

> >  when you say "400", are you trying to run a 400x400
> > matrix?  not sure but you *might* hit the limits -- the code's recursive, no?
>
> 400 x 3 matrix.   A "vector" data type that uses 400 povray vectors split up
> into x, y, and z values.
>
> So I just figured I'd read in the 400 first, size my array according to that,
> and then just pipe the whole file into the compiled SVD processor.
>
> Right now I just wanted to see if that worked, so I'm just gonna import the
> data, and then print it back out to show that that part works, then copy that
> working code into the SVD .cpp file.
>
> This is mid-hack, so it's uglier than usual    ;)

first glance -- I'd advise to supply both cols + rows as part of the matrix
data, rather than hardwiring the inner loop.

bedtime now, here.  hasta manana.


regards, jr.

[Bald Eagle] Re: [Minimum Volume] Bounding Ellipsoid via SVD [2339 days 18 hours and 43 minutes ago]

Mon, 18 Nov 2019 02:15:01 GMT

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

> please post a data file.

done.

>  when you say "400", are you trying to run a 400x400
> matrix?  not sure but you *might* hit the limits -- the code's recursive, no?

400 x 3 matrix.   A "vector" data type that uses 400 povray vectors split up
into x, y, and z values.

So I just figured I'd read in the 400 first, size my array according to that,
and then just pipe the whole file into the compiled SVD processor.

Right now I just wanted to see if that worked, so I'm just gonna import the
data, and then print it back out to show that that part works, then copy that
working code into the SVD .cpp file.

This is mid-hack, so it's uglier than usual    ;)


#include <vector>
#include <iostream>
#include <iomanip>
#include <ctime>
#include <algorithm>


#include <boost/multiprecision/cpp_bin_float.hpp>
#include <boost/math/special_functions/gamma.hpp>

using namespace boost::multiprecision;

typedef number<backends::cpp_bin_float<4096, backends::digit_base_2, void,
boost::int16_t, -16382, 16383>, et_off>  cpp_bin_float_4096;

using namespace std;



std::vector<std::vector<cpp_bin_float_4096> > matrix_i;

template<typename Arg = cpp_bin_float_4096>
void print_matrix(std::vector<std::vector<cpp_bin_float_4096> > matrix)
{
    std::cout << "Printing matrix . . . \n\n";
 for (std::size_t row = 0; row < matrix.size(); row++)
 {
  for (std::size_t col = 0; col < matrix[row].size(); col++)
   std::cout << std::setprecision(1) << std::fixed << matrix[row][col] << " ";
std::cout << "\n";
 }

 //std::cout << "\n";
}

template<typename Arg = cpp_bin_float_4096>
void generate_matrix(std::vector<std::vector<cpp_bin_float_4096> >& \
 matrix, std::size_t rows, std::size_t cols)

{
    std::cin >> rows;
 std::srand((unsigned int)std::time(nullptr)); matrix.resize(rows);
 for (std::size_t row = 0; row < matrix.size(); row++)
 {
  matrix[row].resize(3);
  for (std::size_t col = 0; col < 3; col++)
   //std::cin >> ignore(100, '\n') >> matrix[rows][cols];
            std::cin >> matrix[rows][cols];
 }
    std::cout << "Data imported. \n\n";
}




int main(int argc, char* argv[])
{
 std::size_t matrix_size = 0;
 std::vector<std::vector<cpp_bin_float_4096> > u, v;
 std::vector<std::vector<cpp_bin_float_4096> > matrix, s;
 std::cout << "Importing data into matrix . . . \n\n";


  generate_matrix(matrix, matrix_size, matrix_size);

  std::cout << "\nA = \n"; print_matrix(matrix);

  //svd(matrix, s, u, v);

  //std::cout << "\nS = \n"; print_matrix(s);
  //std::cout << "\nU = \n"; print_matrix(u);
  //std::cout << "\nV = \n"; print_matrix(v);

 std::cin.get();
 //std::cin.get();

 return 0;
}

[jr] Re: [Minimum Volume] Bounding Ellipsoid via SVD [2339 days 18 hours and 53 minutes ago]

Mon, 18 Nov 2019 02:05:01 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> So, since I don't code in c++, I'm kinda coding by imitation and trial and
> error.
>
> I get the current small bit of test code to compile, but when I run it with my
> dataset: "400" followed by 1200 numbers "value\n"
>
> #write (Output, NumPoints, "\n")
>  #write (Output, P[PonS].x, "\n")
>  #write (Output, P[PonS].y, "\n")
>  #write (Output, P[PonS].z, "\n")
>
> I get a segmentation fault.

> ...

please post a data file.  when you say "400", are you trying to run a 400x400
matrix?  not sure but you *might* hit the limits -- the code's recursive, no?

I'll monkey my version + try the data, in coming days.

regards, jr.

[jr] Re: Tangents between circles [2339 days 18 hours and 53 minutes ago]

Mon, 18 Nov 2019 02:05:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
>
> Right-o.   I just got a quick demo scene posted before it dropped off the
> back-burner.
>
> > for the 'pulleys', in addition to centre + radius, having a texture would be
> > cool.  either as a "parallel" array, or perhaps using the new mixed array type.
> > now wondering how one could prepare for/support animation.
>
> Well there's no reason that can't be appended to the scene.
> Just make a cylinder or disc right below the circle array.
> Or a separate texture array that will use the current loop value in the arc/line
> plotting section.
>
> > if a start and end point get specified, that would get a "cable", while no
> > points would be a "belt", ie closed.  either way, the belt/cable goes around a
> > pulley either clockwise or counter (a boolean), so could be represented as an
> > array of floats for automatic "routing", 'N.0' for clockwise and 'N.1' for the
> > reverse, where N is the pulley array index.
>
> There are two portions of the post-calculation section.   one to make the
> bezier-arcs, one to make all 4 (if they exist) tangents.
> I have oh-so much of that in the developmental "full" version.   The logic and
> flags and texturing is bewildering, thus, the cut-down version.
> See the original developmental renders with the colored lines, arcs, and the
> color coded oriented/Boolean directional final belt path.

won't look at the code too closely for now.  just .. speculating.  :-)

> > anyway.  will be happy to do testing and help document, and what other (small)
> > help I can give.
>
> I'd say that the best help at the moment might be to just look it over and do a
> parallel implementation, starting from what I posted.   That would give me new
> ideas for how to process the data, and other things with what to do with the
> results that I might not have thought of yet.

will do this, sometime nearer weekend.  sorry.

> Also, asking any questions you may have about specific bits of the code would
> help me document it, and in the process re-read and re-think what I've already
> done.
>
> Certainly I'd love to work out the logic of animating it, and doing something
> like a toothed belt or chain to run along gears or sprockets.

just support for the pulley rotation should do, I think.

> I haven't done much pathological case testing, because it's already a miracle
> that it even works at all.

will play with it etc.  cheers.


regards, jr.

[Bald Eagle] Re: [Minimum Volume] Bounding Ellipsoid via SVD [2339 days 19 hours and 33 minutes ago]

Mon, 18 Nov 2019 01:25:00 GMT

So, since I don't code in c++, I'm kinda coding by imitation and trial and
error.

I get the current small bit of test code to compile, but when I run it with my
dataset: "400" followed by 1200 numbers "value\n"

#write (Output, NumPoints, "\n")
 #write (Output, P[PonS].x, "\n")
 #write (Output, P[PonS].y, "\n")
 #write (Output, P[PonS].z, "\n")

I get a segmentation fault.


template<typename Arg = cpp_bin_float_4096>
void generate_matrix(std::vector<std::vector<cpp_bin_float_4096> >& \
 matrix, std::size_t rows, std::size_t cols)

{
    std::cin >> rows;
 std::srand((unsigned int)std::time(nullptr)); matrix.resize(rows);
 for (std::size_t row = 0; row < matrix.size(); row++)
 {
  matrix[row].resize(3);
  for (std::size_t col = 0; col < 3; col++)
   //std::cin >> ignore(100, '\n') >> matrix[rows][cols];
            std::cin >> matrix[rows][cols];
 }
    std::cout << "Data imported. \n\n";
}




int main(int argc, char* argv[])
{
 std::size_t matrix_size = 0;
 std::vector<std::vector<cpp_bin_float_4096> > u, v;
 std::vector<std::vector<cpp_bin_float_4096> > matrix, s;
 std::cout << "Importing data into matrix . . . \n\n";


  generate_matrix(matrix, matrix_size, matrix_size);

  std::cout << "\nA = \n"; print_matrix(matrix);

  //svd(matrix, s, u, v);

  //std::cout << "\nS = \n"; print_matrix(s);
  //std::cout << "\nU = \n"; print_matrix(u);
  //std::cout << "\nV = \n"; print_matrix(v);

 std::cin.get();
 //std::cin.get();

 return 0;
}

[Bald Eagle] Re: Tangents between circles [2339 days 19 hours and 38 minutes ago]

Mon, 18 Nov 2019 01:20:01 GMT

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

Right-o.   I just got a quick demo scene posted before it dropped off the
back-burner.

> for the 'pulleys', in addition to centre + radius, having a texture would be
> cool.  either as a "parallel" array, or perhaps using the new mixed array type.
> now wondering how one could prepare for/support animation.

Well there's no reason that can't be appended to the scene.
Just make a cylinder or disc right below the circle array.
Or a separate texture array that will use the current loop value in the arc/line
plotting section.

> if a start and end point get specified, that would get a "cable", while no
> points would be a "belt", ie closed.  either way, the belt/cable goes around a
> pulley either clockwise or counter (a boolean), so could be represented as an
> array of floats for automatic "routing", 'N.0' for clockwise and 'N.1' for the
> reverse, where N is the pulley array index.

There are two portions of the post-calculation section.   one to make the
bezier-arcs, one to make all 4 (if they exist) tangents.
I have oh-so much of that in the developmental "full" version.   The logic and
flags and texturing is bewildering, thus, the cut-down version.
See the original developmental renders with the colored lines, arcs, and the
color coded oriented/Boolean directional final belt path.

> anyway.  will be happy to do testing and help document, and what other (small)
> help I can give.

I'd say that the best help at the moment might be to just look it over and do a
parallel implementation, starting from what I posted.   That would give me new
ideas for how to process the data, and other things with what to do with the
results that I might not have thought of yet.

Also, asking any questions you may have about specific bits of the code would
help me document it, and in the process re-read and re-think what I've already
done.

Certainly I'd love to work out the logic of animating it, and doing something
like a toothed belt or chain to run along gears or sprockets.

I haven't done much pathological case testing, because it's already a miracle
that it even works at all.

[jr] Re: Tangents between circles [2339 days 23 hours and 23 minutes ago]

Sun, 17 Nov 2019 21:35:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Minimal scene to show the basics.

thanks.

> Still LONG due to all the calculations, etc.

to make it useful to .. numpties like me, a documented interface of sorts is
needed[*], a few thoughts on this below (disclaimer, working on some non-POV-Ray
stuff and haven't thought everything through in full).

[*] cf semver.org.  ;-)

for the 'pulleys', in addition to centre + radius, having a texture would be
cool.  either as a "parallel" array, or perhaps using the new mixed array type.
now wondering how one could prepare for/support animation.

if a start and end point get specified, that would get a "cable", while no
points would be a "belt", ie closed.  either way, the belt/cable goes around a
pulley either clockwise or counter (a boolean), so could be represented as an
array of floats for automatic "routing", 'N.0' for clockwise and 'N.1' for the
reverse, where N is the pulley array index.

and a belt/cable texture.

then bundle those in a dictionary to keep everything in one place? packaged in a
"standalone" include file.

anyway.  will be happy to do testing and help document, and what other (small)
help I can give.

regards, jr.

[Bald Eagle] Tangents between circles [2340 days 5 hours and 28 minutes ago]

Sun, 17 Nov 2019 15:30:01 GMT

Minimal scene to show the basics.
Still LONG due to all the calculations, etc.

[Bald Eagle] Re: [Minimum Volume] Bounding Ellipsoid via SVD [2342 days 20 hours and 13 minutes ago]

Fri, 15 Nov 2019 00:45:00 GMT

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

> thank you for this link.  watching the film helped somewhat.

You, Sir, are hilarious.
That thing didn't help me a single bit.  :D

Try this.
https://towardsdatascience.com/svd-8c2f72e264f

There are dozens of other pretty decent summaries / explanations.

Now that I have a functional reorientation, I'm waiting on some feedback from
someone, anyone as to a last bit of the puzzle (unconnected to the present
application).

Also going to try to get some c++ code written, and then hopefully the SVD will
be able to be integrated into a easy-to-use POV-Ray workflow.

If THAT works, then I have some other ideas for what to try it on.

[jr] Re: [Minimum Volume] Bounding Ellipsoid via SVD [2343 days 23 hours and 18 minutes ago]

Wed, 13 Nov 2019 21:40:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Just an interesting aside:
>
>
https://blogs.mathworks.com/cleve/2012/12/10/1976-matrix-singular-value-decomposition-film/

thank you for this link.  watching the film helped somewhat.  (shades of Tron
:-))


regards, jr.

[Bald Eagle] Re: [Minimum Volume] Bounding Ellipsoid via SVD [2345 days 21 hours and 43 minutes ago]

Mon, 11 Nov 2019 23:15:02 GMT

Just an interesting aside:

https://blogs.mathworks.com/cleve/2012/12/10/1976-matrix-singular-value-decomposition-film/

[Bald Eagle] Re: [Minimum Volume] Bounding Ellipsoid via SVD [2345 days 22 hours and 53 minutes ago]

Mon, 11 Nov 2019 22:05:01 GMT

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

> after posting _that_ I remembered you mentioning your being new to Linux etc in
> another thread.  so some more on command lines etc below.  (I really feel old -

I was new 20 years ago, I just haven't been involved in administration of the
NMR computers or had the SGI O2 to play with for about a decade.  So every
little bit helps, whether it's something I "know" or not.

> and can be just a set of data points, ie no "shape" required?  powerful.

Correct.   Data is data is data.  It doesn't have to be geometric at all.
It could be correlating customer purchases with zip codes or what movie watchers
might also like to watch, or what their most likely preferred theatre snack is,
or just about anything that you can think of.

> > 2D data can be aligned so that the most elongated part is along one axis, and
> > the rest of the data perpendicular to that gets rotated to be in the cardinal
> > plane,
>
> interesting too but cannot visualise use cases.  when (what kind of data) would
> you use that?

Just search "application of singular value decomposition to ...."  and it goes
on and on and on....

> testing, testing..  :-)

Yeah.   I upped my test case to 400 points, switched over from the "narrow"
version to the "wide" version, found that all of that introduces some problems,
learned a bit more (logical in retrospect) about the resulting matrices, and now
am awaiting some replies from hopefully helpful experts On The Internet.

I used to write shell scripts, and do a bunch of regular expression stuff, but I
have to get back into that - time, energy, focus, round tuits allowing....

Good progress so far, just have to make it past the usual frustrating roadblocks
to reach the end....

[jr] Re: [Minimum Volume] Bounding Ellipsoid via SVD [2345 days 23 hours and 8 minutes ago]

Mon, 11 Nov 2019 21:50:01 GMT

"jr" <cre### [at] gmailcom> wrote:
> ...
> (fingers crossed wrt typos):
>
>   function fnsvd () {
>     if [ 1 -ne $# ]; then
>       echo usage: $FUNCNAME matrix_data
>     else
>       grep -v -e ^# | tr -s ' ' '\n' < $1 | grep -v -e ^$ | /path/to/svd/a.out
>     fi
>   }

</sigh>  blindly copying + pasting does that.  :-(  corrected:

  grep -v -e ^# $1 | tr -s ' ' '\n' | grep -v -e ^$ | /path/to/svd/a.out


regards, jr.

[jr] Re: [Minimum Volume] Bounding Ellipsoid via SVD [2345 days 23 hours and 58 minutes ago]

Mon, 11 Nov 2019 21:00:16 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > looks great.
> >
> > > Thanks for the line of code - that will be the next step after some more
> > > tinkering:  packaging it up into an easy to use utility.
> >
> > after posting it occurred to me that you might want your data files resemble the
> > matrix, rather than having a value per line.
>
> Yes, that's what I was planning on.

after posting _that_ I remembered you mentioning your being new to Linux etc in
another thread.  so some more on command lines etc below.  (I really feel old --
not so many years ago I'd have covered the salient points in a single reply.
thinking is getting harder.  :-()

> > looking forward to more on svd.  is it useful only for (vaguely)
> > spherical/elliptical shapes?
>
> Nah.  Anything that doesn't have a symmetric distribution.
> so I'd say that off-axis linear data can be oriented,

and can be just a set of data points, ie no "shape" required?  powerful.

> 2D data can be aligned so that the most elongated part is along one axis, and
> the rest of the data perpendicular to that gets rotated to be in the cardinal
> plane,

interesting too but cannot visualise use cases.  when (what kind of data) would
you use that?

> and the ellipsoid is just the easy 3D version of that, but any set of vectors
> could be used.
>
> Hopefully some of the finer points become clearer in the near future.
>
> Looking at what I just posted, and how I've noticed changes in the SVD output
> with different data, maybe all I need for a better alignment is more points ...

testing, testing..  :-)

so, "..you might want your data files resemble the matrix, rather than having a
value per line."

and also, conceivably :-), you might want to document the data.  that
command-line for cleaning ("re-formatting") the data -- no one likes to type
stuff like it all the time.  but there's no need since the tools are all
provided.

typically, a '#' in the first column of a line starts a comment, so the matrix
data file could be:

  # mydata - from some/url.
  2
  123.0    4.56
  7.89    -2.0

the shell (BASH) lets you create functions[*], though they do not have to return
a value, which in use are indistinguishable from "real" utilities.  they can be
typed in on the command-line or sourced from file.  my usual method (ymmv) is to
create a function in a scratch file, test it "to death" ;-), then transfer it to
my '~/.bash_functions' file (think personal library); sourced from the
'~/.bashrc', so gets loaded automatically.

[*] an 'alias' would be no good since you can only append to them, the
alternative would be a "proper" shell script.

for the svd invocation, presuming that you'll go with the above file format (can
have more than one comment line, of course), one way of writing that function is
(fingers crossed wrt typos):

  function fnsvd () {
    if [ 1 -ne $# ]; then
      echo usage: $FUNCNAME matrix_data
    else
      grep -v -e ^# | tr -s ' ' '\n' < $1 | grep -v -e ^$ | /path/to/svd/a.out
    fi
  }

same as before but removing the comments first.  if you're in the (bad, imo)
habit of having spaces in file names, you'd need to put the '$1' parameter in
double quotes.  _is_ extra work, but you only type it once.  wrt the name, I
generally use a 'fn' prefix to remind self.

once that is available in the shell, ie has been 'source'd, you can simply:

  $ fnsvd mydata

the last line in my '~/.bashrc' reads:

  if [ -f ~/.bash_functions ]; then source ~/.bash_functions; fi

note that I tend to write out 'source', usually you'll see people use the
shorthand, a period/dot.  hope that helps in some way, and, yeah, sorry about
the .. noise.

regards, jr.

[Bald Eagle] Re: [Minimum Volume] Bounding Ellipsoid via SVD [2346 days 19 hours and 18 minutes ago]

Mon, 11 Nov 2019 01:40:00 GMT

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

> looks great.
>
> > Thanks for the line of code - that will be the next step after some more
> > tinkering:  packaging it up into an easy to use utility.
>
> after posting it occurred to me that you might want your data files resemble the
> matrix, rather than having a value per line.

Yes, that's what I was planning on.

> looking forward to more on svd.  is it useful only for (vaguely)
> spherical/elliptical shapes?

Nah.  Anything that doesn't have a symmetric distribution.

so I'd say that off-axis linear data can be oriented,

2D data can be aligned so that the most elongated part is along one axis, and
the rest of the data perpendicular to that gets rotated to be in the cardinal
plane,

and the ellipsoid is just the easy 3D version of that, but any set of vectors
could be used.

Hopefully some of the finer points become clearer in the near future.

Looking at what I just posted, and how I've noticed changes in the SVD output
with different data, maybe all I need for a better alignment is more points ...

[jr] Re: [Minimum Volume] Bounding Ellipsoid via SVD [2346 days 20 hours and 13 minutes ago]

Mon, 11 Nov 2019 00:45:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > > it's been .. quiet.
>
> Well, been busy with RL, reading, re-reading, watching vids, filtering, taking
> notes, processing, etc.
>
> I think I have enough of an understanding of what goes on and what to do with
> it, that it ought to be a viable method.
>
> Will start a new thread in pbi so I can show results.

looks great.

> Thanks for the line of code - that will be the next step after some more
> tinkering:  packaging it up into an easy to use utility.

after posting it occurred to me that you might want your data files resemble the
matrix, rather than having a value per line.  :-)  assuming a justified (with
space chars) layout like:
2
123.0    4.56
  7.89  -2.0

you can use standard *NIX text processing tools to "massage" the data:
$ tr -s ' ' '\n' < myfile | grep -v -e ^$ | ./a.out

in English, 'tr' ("translate") converts spaces to newlines, the '-s' option
"squeezes" any number of consecutive chars into one, the grep looks for lines
which do not match an empty line.

looking forward to more on svd.  is it useful only for (vaguely)
spherical/elliptical shapes?

regards, jr.

[Bald Eagle] Re: [Minimum Volume] Bounding Ellipsoid via SVD [2346 days 21 hours and 18 minutes ago]

Sun, 10 Nov 2019 23:40:00 GMT

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

> > it's been .. quiet.

Well, been busy with RL, reading, re-reading, watching vids, filtering, taking
notes, processing, etc.

I think I have enough of an understanding of what goes on and what to do with
it, that it ought to be a viable method.

Will start a new thread in pbi so I can show results.

Thanks for the line of code - that will be the next step after some more
tinkering:  packaging it up into an easy to use utility.

[jr] Re: [Minimum Volume] Bounding Ellipsoid via SVD [2347 days 5 hours and 48 minutes ago]

Sun, 10 Nov 2019 15:10:01 GMT

"jr" <cre### [at] gmailcom> wrote:
> ...
> it's been .. quiet.  in case you haven't addressed 1/2 yet, here's a quick,
> though inefficient (and inelegant), hack.  in the 'generate_matrix' function,
> there's an assignment in the innermost 'for()'.  if you change that line to
> read:
>   std::cin >> matrix[row[col];

uh, typo.  effing always.  :-(

std::cin >> matrix[row][col];

> ...


regards, jr.

[jr] Re: [Minimum Volume] Bounding Ellipsoid via SVD [2347 days 6 hours and 8 minutes ago]

Sun, 10 Nov 2019 14:50:01 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
>
> > the latter, I'm confident, although somewhat unsure of exact syntax.
>
> OK - I just usually search-engine my way to a solution   :)
>
> > suggestion: attach your working version of svd.cpp, so we talk same code.  I'll
> > play with it here to test; are the matrices filled just with floats?
>
> Right on.
> At the moment, my thoughts are:
>
> 1. the data must get read into a faux-matrix std::vector container, which I
> suppose has to be created before assigning the data to it
>
> 2. it should have m rows - the number of vectors to process, and m columns - the
> first 3 are x, y, and z, and all the remaining columns are zeros
>
> Then hopefully I can use that lesson to apply the SVD output to the data in the
> SDL scene.
>
>
> There's hardly any data in the header file - I'm assuming that can just be added
> to the top of the .cpp file to keep it all self-contained.

it's been .. quiet.  in case you haven't addressed 1/2 yet, here's a quick,
though inefficient (and inelegant), hack.  in the 'generate_matrix' function,
there's an assignment in the innermost 'for()'.  if you change that line to
read:
  std::cin >> matrix[row[col];
then you can pipe your data in.  inefficient because you're reading one value at
a time.  say you want a 2x2 matrix:
1.0 2.0
3.0 4.0

then your data file should read:
2
1.0
2.0
3.0
4.0

and you'd execute:
$ ./a.out < myfile

while I haven't actually tried it here, I'm quite confident it'll work.  in the
long run you'd want to read and process a row of data at a time though.  hth.

regards, jr.

[jr] Re: [Minimum Volume] Bounding Ellipsoid via SVD [2350 days 18 hours and 43 minutes ago]

Thu, 7 Nov 2019 02:15:01 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
>
> > > my command line directive is:
> > > c++ SVD_BW.cpp -std=c++11
> >          ^^^
> > spot the difference.  ;-)  no matter though, it can wait until you've changed it
> > to read data from stdin.
>
> Spot the identity.  ;P
>
http://news.povray.org/povray.text.scene-files/message/%3Cweb.5dc33dd7f7b9a3af4eec112d0%40news.povray.org%3E/#%3Cweb.
5d
> c33dd7f7b9a3af4eec112d0%40news.povray.org%3E
>
> I don't know what construct to use to "catch" the data from stdin...

the program does already though.  where in main you have "std::cin >> matrix",
that's reading from stdin, after it put the message on stdout.  cin/cout/cerr ==
stdin/stdout/stderr.

> But I will look.
> Hangin' it up for the day - got a day tomorrow, hopefully it's not a disaster
> <crosses fingers>
>
> > it is .. seductive.  _if_ I can understand yr code well enough, I've plans for a
> > platform on tank-like tracks I'd like to build.
>
> I'll see if I can put together a simplified version minus all the gobbledygook.

great, cheers.

> > > I hope the lesson pdf clarifies the whole point of all of this and to some
> > > extent how it's done.
> >
> > you're pulling my leg..
>
> Nope.
> Just look at the pretty pictures.
>
> > had a quick scan, the formulae just make my eyes bleed.
> >  the 1st scan main benefit was seeing the virtual "mass", as an assumption and
> > how it can then be applied.  that, as a concept, is v interesting, need to think
> > on it.
>
> Well that's basically it - don't look at the formulae.

well, re-orienting a given object to obtain a best fit BB seems to be necessary,
so, no choices.  :-)

> ...


regards, jr.

[Bald Eagle] Re: [Minimum Volume] Bounding Ellipsoid via SVD [2350 days 19 hours and 23 minutes ago]

Thu, 7 Nov 2019 01:35:00 GMT

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

> > my command line directive is:
> > c++ SVD_BW.cpp -std=c++11
>          ^^^
> spot the difference.  ;-)  no matter though, it can wait until you've changed it
> to read data from stdin.

Spot the identity.  ;P
http://news.povray.org/povray.text.scene-files/message/%3Cweb.5dc33dd7f7b9a3af4eec112d0%40news.povray.org%3E/#%3Cweb.5d
c33dd7f7b9a3af4eec112d0%40news.povray.org%3E

I don't know what construct to use to "catch" the data from stdin...
But I will look.
Hangin' it up for the day - got a day tomorrow, hopefully it's not a disaster
<crosses fingers>

> it is .. seductive.  _if_ I can understand yr code well enough, I've plans for a
> platform on tank-like tracks I'd like to build.

I'll see if I can put together a simplified version minus all the gobbledygook.

> > I hope the lesson pdf clarifies the whole point of all of this and to some
> > extent how it's done.
>
> you're pulling my leg..

Nope.
Just look at the pretty pictures.

> had a quick scan, the formulae just make my eyes bleed.
>  the 1st scan main benefit was seeing the virtual "mass", as an assumption and
> how it can then be applied.  that, as a concept, is v interesting, need to think
> on it.

Well that's basically it - don't look at the formulae.

The real gist looks to be that matrices encode (mostly) scaling and rotations.
 One matrix can be split up (factored) into a rotation matrix, a reverse
rotation matrix (which obviously cancel) and a matrix of scaling factors.

So "How is your data stretched?"  It stretches along "x" by this much, "Y" by
this much, and "z" by this much.
And the rotation matrix tells you what direction "x", "y" and "z" are from the
real, cardinal basis vectors of <x, y, z>.

[jr] Re: [Minimum Volume] Bounding Ellipsoid via SVD [2350 days 20 hours and 33 minutes ago]

Thu, 7 Nov 2019 00:25:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> ...
> > anyway, the source you posted does not compile, so it's clearly not meant to be.
> my command line directive is:
> c++ SVD_BW.cpp -std=c++11
         ^^^
spot the difference.  ;-)  no matter though, it can wait until you've changed it
to read data from stdin.

> Not sure what your system is spitting out as complaints.
>
> I can give you the current version of the tangent macro, and hopefully that will
> be all you need.

cool, thanks.  any chance of a/the scene file?  to see it in-use.

>  Looks like Leroy couldn't help himself and has his own version
> going as well. :D

it is .. seductive.  _if_ I can understand yr code well enough, I've plans for a
platform on tank-like tracks I'd like to build.

> I hope the lesson pdf clarifies the whole point of all of this and to some
> extent how it's done.

you're pulling my leg..  had a quick scan, the formulae just make my eyes bleed.
 the 1st scan main benefit was seeing the virtual "mass", as an assumption and
how it can then be applied.  that, as a concept, is v interesting, need to think
on it.

regards, jr.

[Bald Eagle] Re: [Minimum Volume] Bounding Ellipsoid via SVD [2350 days 21 hours and 3 minutes ago]

Wed, 6 Nov 2019 23:55:01 GMT

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

>   $ ./a.out < mydata.xyz

Righteous.

> my (elderly) gcc manual does not list '#pragma once' but the clue seems to be in
> the name.

Specifies that the compiler includes the header file only once, when compiling a
source code file.
Syntax
#pragma once

The use of #pragma once can reduce build times, as the compiler won't open and
read the file again after the first #include of the file in the translation
unit. It's called the multiple-include optimization. It has an effect similar to
the include guard idiom, which uses preprocessor macro definitions to prevent
multiple inclusions of the contents of the file.

Commenting out the include doesn't affect the compile, so good to go.

> anyway, the source you posted does not compile, so it's clearly not meant to be.

my command line directive is:

c++ SVD_BW.cpp -std=c++11

Not sure what your system is spitting out as complaints.

I can give you the current version of the tangent macro, and hopefully that will
be all you need.  Looks like Leroy couldn't help himself and has his own version
going as well. :D

I hope the lesson pdf clarifies the whole point of all of this and to some
extent how it's done.

[jr] Re: [Minimum Volume] Bounding Ellipsoid via SVD [2350 days 21 hours and 48 minutes ago]

Wed, 6 Nov 2019 23:10:01 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > re 1.  why can you not simply change the 'generate_matrix' (I think) function,
> > to fill that matrix with the file values?
> Well that's what I meant by
> "Should I supply a filename and loop down the rows, reading in x, y, and z?"

if you read everything from std::cin you won't need to bother with file name
handling, just do something like
  $ ./a.out < mydata.xyz

> > re 2. keep the current way of supplying the size, more flexibility; in a file
> > that could be the dimensions row/line before the data lines.
>
> Why not just read in the first value of the file which will be the number of
> vectors...

we're talking the same thing.  :-)  the size of your matrix, followed by the
data values.

> > > There's hardly any data in the header file - I'm assuming that can just be added
> > > to the top of the .cpp file to keep it all self-contained.
> > not sure I follow.
>
> SVD_BW.cpp has:
> #include "stdafx.h"
>
> but all that file has is :
>
> #pragma once           (whatever that is) and
> #include <stdio.h>
>
> So, can't I just copy/paste those lines to the top of the .cpp file and do away
> with the #include "stdafx.h" ?

my (elderly) gcc manual does not list '#pragma once' but the clue seems to be in
the name.  as to 'stdafx.h' -- it's not a "standard header" here, Windows
perhaps?  I'd get rid of the include, and 'stdio.h' is probably included
already.

anyway, the source you posted does not compile, so it's clearly not meant to be.
 on a different subject, when will there be news/code for the pulley stuff?
thinking that, with minor modifications, it would be useful for modelling
tracked vehicles.  :-)

regards, jr.

[Bald Eagle] Re: [Minimum Volume] Bounding Ellipsoid via SVD [2350 days 22 hours and 18 minutes ago]

Wed, 6 Nov 2019 22:40:01 GMT

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

> re 1.  why can you not simply change the 'generate_matrix' (I think) function,
> to fill that matrix with the file values?

Well that's what I meant by
"Should I supply a filename and loop down the rows, reading in x, y, and z?"

> re 2. keep the current way of supplying the size, more flexibility; in a file
> that could be the dimensions row/line before the data lines.

Why not just read in the first value of the file which will be the number of
vectors...

> > There's hardly any data in the header file - I'm assuming that can just be added
> > to the top of the .cpp file to keep it all self-contained.
>
> not sure I follow.

SVD_BW.cpp has:
#include "stdafx.h"

but all that file has is :

#pragma once           (whatever that is) and
#include <stdio.h>

So, can't I just copy/paste those lines to the top of the .cpp file and do away
with the #include "stdafx.h" ?

[jr] Re: [Minimum Volume] Bounding Ellipsoid via SVD [2350 days 22 hours and 53 minutes ago]

Wed, 6 Nov 2019 22:05:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > the latter, I'm confident, although somewhat unsure of exact syntax.
>
> OK - I just usually search-engine my way to a solution   :)

can be v productive.

> > suggestion: attach your working version of svd.cpp, so we talk same code.  I'll
> > play with it here to test; are the matrices filled just with floats?
>
> Right on.
> At the moment, my thoughts are:
>
> 1. the data must get read into a faux-matrix std::vector container, which I
> suppose has to be created before assigning the data to it
>
> 2. it should have m rows - the number of vectors to process, and m columns - the
> first 3 are x, y, and z, and all the remaining columns are zeros

couple of thoughts before I download the file, for which thanks.

re 1.  why can you not simply change the 'generate_matrix' (I think) function,
to fill that matrix with the file values?

re 2. keep the current way of supplying the size, more flexibility; in a file
that could be the dimensions row/line before the data lines.


> Then hopefully I can use that lesson to apply the SVD output to the data in the
> SDL scene.
>
>
> There's hardly any data in the header file - I'm assuming that can just be added
> to the top of the .cpp file to keep it all self-contained.

not sure I follow.


regards, jr.

[Bald Eagle] Re: [Minimum Volume] Bounding Ellipsoid via SVD [2350 days 23 hours and 13 minutes ago]

Wed, 6 Nov 2019 21:45:01 GMT

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

> the latter, I'm confident, although somewhat unsure of exact syntax.

OK - I just usually search-engine my way to a solution   :)

> suggestion: attach your working version of svd.cpp, so we talk same code.  I'll
> play with it here to test; are the matrices filled just with floats?

Right on.
At the moment, my thoughts are:

1. the data must get read into a faux-matrix std::vector container, which I
suppose has to be created before assigning the data to it

2. it should have m rows - the number of vectors to process, and m columns - the
first 3 are x, y, and z, and all the remaining columns are zeros

Then hopefully I can use that lesson to apply the SVD output to the data in the
SDL scene.

There's hardly any data in the header file - I'm assuming that can just be added
to the top of the .cpp file to keep it all self-contained.

[jr] Re: [Minimum Volume] Bounding Ellipsoid via SVD [2350 days 23 hours and 53 minutes ago]

Wed, 6 Nov 2019 21:05:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > great stuff.
> It is  :)
>
> Even better is this computer graphics lesson on bounding boxes  :D
> https://www.cs.tau.ac.il/~dcor/Graphics/cg-slides/3d_geometry_lesson2.pdf

cheers.  I'll have a look at this tonight.

> ...
> I'm going to work on creating a test data set, and try to  show the SVD results
> and maybe implement the reorientation.
> Given that the code generates a random matrix using
>
> generate_matrix(matrix, matrix_size, matrix_size);
>
> and then computes the svd via
>
> svd(matrix, s, u, v);
>
> Tell me, Master Yoda,
>
> How do I take a file with the <x, y, z> vectors and read it into the compiled
> program so that _that_ is now the "matrix" argument for the svd function call?
>
> Should I supply a filename and loop down the rows, reading in x, y, and z?
>
> or is the a way to just do some kind of OS command line thing, adding in a
>
> std::cin >> matrix;      line?

the latter, I'm confident, although somewhat unsure of exact syntax.
suggestion: attach your working version of svd.cpp, so we talk same code.  I'll
play with it here to test; are the matrices filled just with floats?


regards, jr.

[Bald Eagle] Re: [Minimum Volume] Bounding Ellipsoid via SVD [2351 days and 13 minutes ago]

Wed, 6 Nov 2019 20:45:05 GMT

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

> great stuff.

It is  :)

Even better is this computer graphics lesson on bounding boxes  :D

https://www.cs.tau.ac.il/~dcor/Graphics/cg-slides/3d_geometry_lesson2.pdf

> no urgent need, use the OS tools.  when you dump (CSV) values, you could:
>   $ ./a.out {arg}  |  tee myfile.csv
>
> 'tee(1)' splits its input, displaying it _and_ writing it to file.

Most excellent.

I'm going to work on creating a test data set, and try to  show the SVD results
and maybe implement the reorientation.

Given that the code generates a random matrix using

generate_matrix(matrix, matrix_size, matrix_size);

and then computes the svd via

svd(matrix, s, u, v);

Tell me, Master Yoda,

How do I take a file with the <x, y, z> vectors and read it into the compiled
program so that _that_ is now the "matrix" argument for the svd function call?

Should I supply a filename and loop down the rows, reading in x, y, and z?

or is the a way to just do some kind of OS command line thing, adding in a

std::cin >> matrix;      line?

[jr] Re: bounding box calculator [2351 days 7 hours and 8 minutes ago]

Wed, 6 Nov 2019 13:50:01 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > > The test (using version 2 of bounder.inc) for quartic objects is
> > > interesting. Using the Lemniscate object the BB seems to be infinite and
> > > the test is considered optimal. See image attached.
> > I see the BB change in size when the object is aligned, no idea(s).
> > interesting.
>
> I guess add some #debug output, and maybe show some or all of the trace ()
> tests, coloring them red or green according to if they "hit" or not.  Show each
> successive BB with a different color, and that would help show what was going on
> and give a better idea.

I'd play with something like that, no doubt, but won't put effort into (cf my
"rant" in an earlier reply to Thomas).

the 'Bounder' does not use 'trace()' though, it's all 'inside()' testing.

> I would imagine that if POV-Ray can see and render the object, then the macro
> ought to give sensible results.

agree, provided the object is amenable to 'inside()' testing.

ideally, I'd like a developer who knows POV-Ray's 'inside()' inside out (pun
intended) to chime in, giving us POV-Ray's "perspective" of processing an object
using 'inside()'.

> Given an infinite (or sufficiently large) object along one axis, perhaps a
> bounding rectangle (a cross-section of the infinitely long BB) could be shown /
> reported.

I'm more inclined[*] to provide a list of unsuitable object types, then the onus
is on the user to avoid things like the "Lemniscate"s reported by Thomas.

[*] currently.

> Maybe after the SVD adventure, we coulld throw some function {} foo in there and
> do a semi-transparent isosurface as a representation, which would allow
> "infinite" objects to be easily displayed (by 'scaling' one axis to 0)

again, nice but who'd write the code?

> Just some early-morning thoughts.

(one hand on keyboard, the other cradling the first cup of coffee, no doubt
:-))

regards, jr.

[jr] Re: bounding box calculator [2351 days 7 hours and 8 minutes ago]

Wed, 6 Nov 2019 13:50:00 GMT

hi,

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 06/11/2019 om 11:15 schreef jr:
> > the '#ifdef()' idiom though ought to work in any case (it does here).
>
> It does! My bad.
>
> Interesting test following this earlier post:
> ...
> (1) use the following object: superellipsoid {<0.50, 3.50>}. The test is
> optimal.
> (2) change the object to: superellipsoid {<0.50, 3.50> rotate 45}. The
> BB has now 'at least 5% "slack".'

another candidate.  nice.  :-)  (more in reply to BE)


regards, jr.

[Bald Eagle] Re: bounding box calculator [2351 days 8 hours and 33 minutes ago]

Wed, 6 Nov 2019 12:25:00 GMT

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

> > The test (using version 2 of bounder.inc) for quartic objects is
> > interesting. Using the Lemniscate object the BB seems to be infinite and
> > the test is considered optimal. See image attached.
>
> I see the BB change in size when the object is aligned, no idea(s).
> interesting.

I guess add some #debug output, and maybe show some or all of the trace ()
tests, coloring them red or green according to if they "hit" or not.  Show each
successive BB with a different color, and that would help show what was going on
and give a better idea.

I would imagine that if POV-Ray can see and render the object, then the macro
ought to give sensible results.

Given an infinite (or sufficiently large) object along one axis, perhaps a
bounding rectangle (a cross-section of the infinitely long BB) could be shown /
reported.

Maybe after the SVD adventure, we coulld throw some function {} foo in there and
do a semi-transparent isosurface as a representation, which would allow
"infinite" objects to be easily displayed (by 'scaling' one axis to 0)

Just some early-morning thoughts.

[Thomas de Groot] Re: bounding box calculator [2351 days 8 hours and 35 minutes ago]

Wed, 6 Nov 2019 12:23:30 GMT

Op 06/11/2019 om 11:15 schreef jr:
> the '#ifdef()' idiom though ought to work in any case (it does here).
> 

It does! My bad.

Interesting test following this earlier post:

Op 04/11/2019 om 09:09 schreef Thomas de Groot:
 > - rotating the object changes the 'tightness' of the standard BB. I 
did that with a simple cylinder: when properly aligned along one of the 
axis, the BB test is always optimal; rotate the cylinder (e.g. 
<45,45,45>) and do the test, and the standard BB becomes too wide.
 >

I have to correct this: The BB only becomes slightly less optimal in the 
example cited. With increasing complexity of the object however, 
optimisation kicks in.

(1) use the following object: superellipsoid {<0.50, 3.50>}. The test is 
optimal.

(2) change the object to: superellipsoid {<0.50, 3.50> rotate 45}. The 
BB has now 'at least 5% "slack".'

-- 
Thomas

[Thomas de Groot] Re: bounding box calculator [2351 days 9 hours and 7 minutes ago]

Wed, 6 Nov 2019 11:51:13 GMT

Op 06/11/2019 om 11:15 schreef jr:
> hi,
> 
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> Op 05/11/2019 om 01:19 schreef jr:
>>> "jr" <cre### [at] gmailcom> wrote:
>>>> ...
>>> also new, if "slack" is reported, two variables with the differences from the
>>> BB's min/max extents are declared, to allow use of the info from in-scene.
>>> after 'Bounder' has run, one can for instance:
>>>
>>> #ifdef(Bounder_min_diff)
>>>     // do something
>>> #end
>>
>> With version 3, I get a parser error in the scene file when the object
>> is considered as near optimal: "Expected 'numeric expression',
>> undeclared 'Bounder_min_diff' found instead"
> 
> pls read the added comments in the file.  the vars are only 'declare'd _if_
> there's any worthwhile "slack" to report.
> 
> the '#ifdef()' idiom though ought to work in any case (it does here).
> 
> 

Yes, I thought so. The problem is not with the macro but with my test 
scene. I shall try to add something there which bypasses this.

-- 
Thomas

[jr] Re: bounding box calculator [2351 days 9 hours and 33 minutes ago]

Wed, 6 Nov 2019 11:25:00 GMT

hi,

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 04/11/2019 om 09:09 schreef Thomas de Groot:
> > - the test is also useful with hyperboloid, superellipsoid, and
> > isosurface objects. Quartic and parametric objects do no comply,
> > probably they are not 'solid'? I did not test this thoroughly.
>
> The test (using version 2 of bounder.inc) for quartic objects is
> interesting. Using the Lemniscate object the BB seems to be infinite and
> the test is considered optimal. See image attached.

I think I will add, in the header/comments of the file, a list of "unsuitable
for use with this macro" shapes.  what do you (and others) think?  thanks.


regards, jr.

[jr] Re: bounding box calculator [2351 days 10 hours and 38 minutes ago]

Wed, 6 Nov 2019 10:20:00 GMT

hi,

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 05/11/2019 om 01:19 schreef jr:
> > "jr" <cre### [at] gmailcom> wrote:
> >> ...
> > also new, if "slack" is reported, two variables with the differences from the
> > BB's min/max extents are declared, to allow use of the info from in-scene.
> > after 'Bounder' has run, one can for instance:
> >
> > #ifdef(Bounder_min_diff)
> >    // do something
> > #end
>
> With version 3, I get a parser error in the scene file when the object
> is considered as near optimal: "Expected 'numeric expression',
> undeclared 'Bounder_min_diff' found instead"

pls read the added comments in the file.  the vars are only 'declare'd _if_
there's any worthwhile "slack" to report.

the '#ifdef()' idiom though ought to work in any case (it does here).


regards, jr.

[jr] Re: bounding box calculator [2351 days 10 hours and 43 minutes ago]

Wed, 6 Nov 2019 10:15:01 GMT

hi,

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 04/11/2019 om 09:09 schreef Thomas de Groot:
> > - the test is also useful with hyperboloid, superellipsoid, and
> > isosurface objects. Quartic and parametric objects do no comply,
> > probably they are not 'solid'? I did not test this thoroughly.
>
> The test (using version 2 of bounder.inc) for quartic objects is
> interesting. Using the Lemniscate object the BB seems to be infinite and
> the test is considered optimal. See image attached.

I see the BB change in size when the object is aligned, no idea(s).
interesting.


regards, jr.

[jr] Re: [Minimum Volume] Bounding Ellipsoid via SVD [2351 days 10 hours and 43 minutes ago]

Wed, 6 Nov 2019 10:15:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Looks like the nan values were because the matrix.resize operations didn't fill
> in the new positions with 0.

another (valuable) lesson.  initialise all your vars, always.

> Fixed it one way, until I needed to fix it another ;)
> But now it runs without errors or nan entries.

great stuff.

> > I suppose I need to dump everything to a text file, rather than to std::cout ...

no urgent need, use the OS tools.  when you dump (CSV) values, you could:
  $ ./a.out {arg}  |  tee myfile.csv

'tee(1)' splits its input, displaying it _and_ writing it to file.

regards, jr

[Thomas de Groot] Re: bounding box calculator [2351 days 12 hours and 19 minutes ago]

Wed, 6 Nov 2019 08:39:27 GMT

Op 05/11/2019 om 01:19 schreef jr:
> "jr" <cre### [at] gmailcom> wrote:
>> ... I wrote a macro which "scans" an object's BB ...
> 
> find attached the second update of the 'Bounder'.
> 
> things have changed a little.  now, if the object's BB is found to be "(near)
> optimal", the macro prints that and ends, otherwise, ie having some "slack", the
> macro prints the difference lines as before, plus the optimised extents and
> dimensions, as per Thomas's feedback.
> 
> also new, if "slack" is reported, two variables with the differences from the
> BB's min/max extents are declared, to allow use of the info from in-scene.
> after 'Bounder' has run, one can for instance:
> 
> #ifdef(Bounder_min_diff)
>    // do something
> #end
> 
> so.  version 3.  fingers crossed.
> 
> 
> enjoy, jr.
> 

With version 3, I get a parser error in the scene file when the object 
is considered as near optimal: "Expected 'numeric expression', 
undeclared 'Bounder_min_diff' found instead"

-- 
Thomas

[Thomas de Groot] Re: bounding box calculator [2351 days 12 hours and 31 minutes ago]

Wed, 6 Nov 2019 08:26:53 GMT

Op 04/11/2019 om 09:09 schreef Thomas de Groot:
> - the test is also useful with hyperboloid, superellipsoid, and 
> isosurface objects. Quartic and parametric objects do no comply, 
> probably they are not 'solid'? I did not test this thoroughly.
> 

The test (using version 2 of bounder.inc) for quartic objects is 
interesting. Using the Lemniscate object the BB seems to be infinite and 
the test is considered optimal. See image attached.

-- 
Thomas

[Bald Eagle] Re: [Minimum Volume] Bounding Ellipsoid via SVD [2351 days 18 hours and 18 minutes ago]

Wed, 6 Nov 2019 02:40:00 GMT

Looks like the nan values were because the matrix.resize operations didn't fill
in the new positions with 0.

Fixed it one way, until I needed to fix it another ;)

But now it runs without errors or nan entries.

So, now to see if any of this makes any sense in terms of processing a long list
of 3D vectors, and then plug it into the bounding ellipsoid code.

If this only processes square matrices, we'll probably need to use the gsl-bin
svd library to process the vectors.

But here we go  :)


Singular Value Decomposition (SVD):

Enter size of matrix N = (50x50 max): 10

A =
8.0 4.0 2.0 4.0 3.0 9.0 0.0 8.0 4.0 9.0
8.0 4.0 2.0 0.0 8.0 9.0 5.0 2.0 4.0 4.0
4.0 3.0 5.0 5.0 9.0 0.0 3.0 5.0 0.0 9.0
9.0 0.0 3.0 1.0 6.0 9.0 2.0 9.0 9.0 7.0
8.0 9.0 3.0 2.0 9.0 1.0 3.0 6.0 4.0 8.0
0.0 8.0 1.0 8.0 5.0 0.0 8.0 8.0 7.0 0.0
7.0 6.0 3.0 3.0 0.0 1.0 2.0 2.0 0.0 3.0
1.0 0.0 2.0 4.0 4.0 2.0 6.0 8.0 8.0 2.0
8.0 1.0 2.0 9.0 9.0 8.0 2.0 9.0 6.0 9.0
2.0 4.0 8.0 5.0 9.0 8.0 6.0 3.0 2.0 9.0


[matrix]transposed =
8.0 8.0 4.0 9.0 8.0 0.0 7.0 1.0 8.0 2.0
4.0 4.0 3.0 0.0 9.0 8.0 6.0 0.0 1.0 4.0
2.0 2.0 5.0 3.0 3.0 1.0 3.0 2.0 2.0 8.0
4.0 0.0 5.0 1.0 2.0 8.0 3.0 4.0 9.0 5.0
3.0 8.0 9.0 6.0 9.0 5.0 0.0 4.0 9.0 9.0
9.0 9.0 0.0 9.0 1.0 0.0 1.0 2.0 8.0 8.0
0.0 5.0 3.0 2.0 3.0 8.0 2.0 6.0 2.0 6.0
8.0 2.0 5.0 9.0 6.0 8.0 2.0 8.0 9.0 3.0
4.0 4.0 0.0 9.0 4.0 7.0 0.0 8.0 6.0 2.0
9.0 4.0 9.0 7.0 8.0 0.0 3.0 2.0 9.0 9.0


[matrices]multiplied =
351.0 257.0 222.0 352.0 286.0 173.0 150.0 172.0 384.0 280.0
257.0 290.0 187.0 299.0 262.0 158.0 121.0 148.0 304.0 272.0
222.0 187.0 271.0 224.0 276.0 178.0 119.0 146.0 303.0 280.0
352.0 299.0 224.0 423.0 298.0 192.0 127.0 231.0 415.0 293.0
286.0 262.0 276.0 298.0 365.0 236.0 168.0 174.0 342.0 291.0
173.0 158.0 178.0 192.0 236.0 331.0 107.0 222.0 257.0 211.0
150.0 121.0 119.0 127.0 168.0 107.0 121.0 61.0 152.0 130.0
172.0 148.0 146.0 231.0 174.0 222.0 61.0 209.0 250.0 184.0
384.0 304.0 303.0 415.0 342.0 257.0 152.0 250.0 497.0 358.0
280.0 272.0 280.0 293.0 291.0 211.0 130.0 184.0 358.0 384.0


[matrices]multiplied =
407.0 206.0 158.0 184.0 344.0 322.0 142.0 329.0 237.0 380.0
206.0 239.0 118.0 160.0 237.0 127.0 158.0 206.0 138.0 214.0
158.0 118.0 133.0 125.0 215.0 153.0 118.0 162.0 106.0 219.0
184.0 160.0 125.0 241.0 263.0 170.0 165.0 276.0 185.0 247.0
344.0 237.0 215.0 263.0 474.0 314.0 242.0 373.0 273.0 424.0
322.0 127.0 153.0 170.0 314.0 377.0 144.0 291.0 237.0 339.0
142.0 158.0 118.0 165.0 242.0 144.0 191.0 213.0 178.0 175.0
329.0 206.0 162.0 276.0 373.0 291.0 213.0 432.0 325.0 366.0
237.0 138.0 106.0 185.0 273.0 237.0 178.0 325.0 282.0 235.0
380.0 214.0 219.0 247.0 424.0 339.0 175.0 366.0 235.0 466.0


Eigenvectors =
0.9 0.6 0.5 0.6 1.0 0.8 0.5 1.0 0.7 1.0

Hermitian matrix =
1.1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
-0.6 1.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
-0.5 0.0 1.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
-0.7 0.0 0.0 1.0 0.0 0.0 0.0 0.0 0.0 0.0
-1.1 0.0 0.0 0.0 1.0 0.0 0.0 0.0 0.0 0.0
-0.9 0.0 0.0 0.0 0.0 1.0 0.0 0.0 0.0 0.0
-0.6 0.0 0.0 0.0 0.0 0.0 1.0 0.0 0.0 0.0
-1.1 0.0 0.0 0.0 0.0 0.0 0.0 1.0 0.0 0.0
-0.8 0.0 0.0 0.0 0.0 0.0 0.0 0.0 1.0 0.0
-1.1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 1.0


[matrices]multiplied =
458.9 232.3 178.2 207.5 387.9 363.1 160.1 371.0 267.2 428.5
-53.3 107.8 17.3 42.8 17.9 -78.1 67.5 -3.6 -13.0 -28.1
-63.0 6.1 47.2 25.1 28.2 -21.9 40.9 -16.7 -22.7 12.6
-110.0 11.2 10.9 108.1 14.5 -62.6 62.4 38.3 13.8 -27.5
-123.7 0.3 33.5 51.6 78.7 -56.0 78.8 -5.0 0.7 -12.6
-49.5 -61.0 8.8 2.1 0.0 83.1 14.4 -9.3 20.7 -7.9
-105.1 33.0 22.1 53.3 33.2 -51.5 104.8 13.3 34.1 -55.7
-111.2 -16.8 -8.9 77.0 0.9 -57.3 59.4 76.2 68.7 -45.0
-87.1 -26.1 -19.8 38.5 -1.0 -19.4 64.9 63.0 93.3 -67.6
-78.9 -18.3 40.8 39.5 36.1 -24.1 14.9 -5.0 -32.2 37.5


Hermitian matrix inverse =
0.9 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
-0.6 1.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
-0.5 0.0 1.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
-0.6 0.0 0.0 1.0 0.0 0.0 0.0 0.0 0.0 0.0
-1.0 0.0 0.0 0.0 1.0 0.0 0.0 0.0 0.0 0.0
-0.8 0.0 0.0 0.0 0.0 1.0 0.0 0.0 0.0 0.0
-0.5 0.0 0.0 0.0 0.0 0.0 1.0 0.0 0.0 0.0
-1.0 0.0 0.0 0.0 0.0 0.0 0.0 1.0 0.0 0.0
-0.7 0.0 0.0 0.0 0.0 0.0 0.0 0.0 1.0 0.0
-1.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 1.0


[matrices]multiplied =
-1691.4 232.3 178.2 207.5 387.9 363.1 160.1 371.0 267.2 428.5
-94.5 107.8 17.3 42.8 17.9 -78.1 67.5 -3.6 -13.0 -28.1
-111.8 6.1 47.2 25.1 28.2 -21.9 40.9 -16.7 -22.7 12.6
-195.1 11.2 10.9 108.1 14.5 -62.6 62.4 38.3 13.8 -27.5
-219.3 0.3 33.5 51.6 78.7 -56.0 78.8 -5.0 0.7 -12.6
-87.8 -61.0 8.8 2.1 0.0 83.1 14.4 -9.3 20.7 -7.9
-186.3 33.0 22.1 53.3 33.2 -51.5 104.8 13.3 34.1 -55.7
-197.3 -16.8 -8.9 77.0 0.9 -57.3 59.4 76.2 68.7 -45.0
-154.5 -26.1 -19.8 38.5 -1.0 -19.4 64.9 63.0 93.3 -67.6
-140.0 -18.3 40.8 39.5 36.1 -24.1 14.9 -5.0 -32.2 37.5


Reduced matrix =
107.8 17.3 42.8 17.9 -78.1 67.5 -3.6 -13.0 -28.1
6.1 47.2 25.1 28.2 -21.9 40.9 -16.7 -22.7 12.6
11.2 10.9 108.1 14.5 -62.6 62.4 38.3 13.8 -27.5
0.3 33.5 51.6 78.7 -56.0 78.8 -5.0 0.7 -12.6
-61.0 8.8 2.1 0.0 83.1 14.4 -9.3 20.7 -7.9
33.0 22.1 53.3 33.2 -51.5 104.8 13.3 34.1 -55.7
-16.8 -8.9 77.0 0.9 -57.3 59.4 76.2 68.7 -45.0
-26.1 -19.8 38.5 -1.0 -19.4 64.9 63.0 93.3 -67.6
-18.3 40.8 39.5 36.1 -24.1 14.9 -5.0 -32.2 37.5


Eigenvectors =
3.2 1.3 3.7 3.1 -0.6 3.8 3.6 2.9 1.0

Hermitian matrix =
0.3 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
-0.4 1.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
-1.1 0.0 1.0 0.0 0.0 0.0 0.0 0.0 0.0
-1.0 0.0 0.0 1.0 0.0 0.0 0.0 0.0 0.0
0.2 0.0 0.0 0.0 1.0 0.0 0.0 0.0 0.0
-1.2 0.0 0.0 0.0 0.0 1.0 0.0 0.0 0.0
-1.1 0.0 0.0 0.0 0.0 0.0 1.0 0.0 0.0
-0.9 0.0 0.0 0.0 0.0 0.0 0.0 1.0 0.0
-0.3 0.0 0.0 0.0 0.0 0.0 0.0 0.0 1.0


[matrices]multiplied =
33.2 5.3 13.2 5.5 -24.0 20.8 -1.1 -4.0 -8.6
-35.9 40.4 8.4 21.2 8.6 14.6 -15.3 -17.6 23.6
-110.8 -8.8 59.7 -5.7 25.8 -14.0 42.4 28.5 4.3
-103.9 16.7 10.2 61.5 19.6 13.5 -1.6 13.2 14.5
-39.8 12.2 10.5 3.5 67.7 27.7 -10.0 18.1 -13.4
-93.8 1.7 3.0 12.2 40.4 25.4 17.5 49.4 -22.6
-137.3 -28.3 29.2 -19.0 30.1 -16.1 80.2 83.2 -13.6
-120.8 -35.1 0.9 -16.6 49.2 5.6 66.1 104.7 -42.9
-51.4 35.5 26.4 30.6 -0.0 -5.9 -3.9 -28.2 46.2


Hermitian matrix inverse =
3.2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
-1.3 1.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
-3.7 0.0 1.0 0.0 0.0 0.0 0.0 0.0 0.0
-3.1 0.0 0.0 1.0 0.0 0.0 0.0 0.0 0.0
0.6 0.0 0.0 0.0 1.0 0.0 0.0 0.0 0.0
-3.8 0.0 0.0 0.0 0.0 1.0 0.0 0.0 0.0
-3.6 0.0 0.0 0.0 0.0 0.0 1.0 0.0 0.0
-2.9 0.0 0.0 0.0 0.0 0.0 0.0 1.0 0.0
-1.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 1.0


[matrices]multiplied =
-35.4 5.3 13.2 5.5 -24.0 20.8 -1.1 -4.0 -8.6
-233.3 40.4 8.4 21.2 8.6 14.6 -15.3 -17.6 23.6
-720.1 -8.8 59.7 -5.7 25.8 -14.0 42.4 28.5 4.3
-675.3 16.7 10.2 61.5 19.6 13.5 -1.6 13.2 14.5
-258.9 12.2 10.5 3.5 67.7 27.7 -10.0 18.1 -13.4
-609.5 1.7 3.0 12.2 40.4 25.4 17.5 49.4 -22.6
-892.2 -28.3 29.2 -19.0 30.1 -16.1 80.2 83.2 -13.6
-785.0 -35.1 0.9 -16.6 49.2 5.6 66.1 104.7 -42.9
-334.3 35.5 26.4 30.6 -0.0 -5.9 -3.9 -28.2 46.2


Reduced matrix =
40.4 8.4 21.2 8.6 14.6 -15.3 -17.6 23.6
-8.8 59.7 -5.7 25.8 -14.0 42.4 28.5 4.3
16.7 10.2 61.5 19.6 13.5 -1.6 13.2 14.5
12.2 10.5 3.5 67.7 27.7 -10.0 18.1 -13.4
1.7 3.0 12.2 40.4 25.4 17.5 49.4 -22.6
-28.3 29.2 -19.0 30.1 -16.1 80.2 83.2 -13.6
-35.1 0.9 -16.6 49.2 5.6 66.1 104.7 -42.9
35.5 26.4 30.6 -0.0 -5.9 -3.9 -28.2 46.2


Eigenvectors =
0.8 -3.8 -1.5 -1.8 -3.7 -6.8 -7.4 1.0

Hermitian matrix =
1.2 0.0 0.0 0.0 0.0 0.0 0.0 0.0
4.5 1.0 0.0 0.0 0.0 0.0 0.0 0.0
1.7 0.0 1.0 0.0 0.0 0.0 0.0 0.0
2.1 0.0 0.0 1.0 0.0 0.0 0.0 0.0
4.4 0.0 0.0 0.0 1.0 0.0 0.0 0.0
8.0 0.0 0.0 0.0 0.0 1.0 0.0 0.0
8.7 0.0 0.0 0.0 0.0 0.0 1.0 0.0
-1.2 0.0 0.0 0.0 0.0 0.0 0.0 1.0


[matrices]multiplied =
47.9 9.9 25.1 10.2 17.2 -18.1 -20.9 27.9
173.3 97.5 89.9 64.6 51.5 -26.3 -51.0 110.5
86.2 24.6 97.9 34.3 38.5 -27.8 -17.1 55.1
98.9 28.5 49.0 86.2 58.9 -42.7 -19.7 37.2
180.6 40.1 106.1 78.5 89.7 -50.0 -28.7 81.7
296.1 96.5 151.2 99.0 100.6 -42.3 -58.4 175.6
317.3 74.0 168.3 124.2 132.3 -66.9 -49.1 162.6
-12.4 16.4 5.5 -10.2 -23.1 14.2 -7.3 18.2


Hermitian matrix inverse =
0.8 0.0 0.0 0.0 0.0 0.0 0.0 0.0
3.8 1.0 0.0 0.0 0.0 0.0 0.0 0.0
1.5 0.0 1.0 0.0 0.0 0.0 0.0 0.0
1.8 0.0 0.0 1.0 0.0 0.0 0.0 0.0
3.7 0.0 0.0 0.0 1.0 0.0 0.0 0.0
6.8 0.0 0.0 0.0 0.0 1.0 0.0 0.0
7.4 0.0 0.0 0.0 0.0 0.0 1.0 0.0
-1.0 0.0 0.0 0.0 0.0 0.0 0.0 1.0


[matrices]multiplied =
-106.6 9.9 25.1 10.2 17.2 -18.1 -20.9 27.9
292.7 97.5 89.9 64.6 51.5 -26.3 -51.0 110.5
145.5 24.6 97.9 34.3 38.5 -27.8 -17.1 55.1
167.0 28.5 49.0 86.2 58.9 -42.7 -19.7 37.2
305.0 40.1 106.1 78.5 89.7 -50.0 -28.7 81.7
500.0 96.5 151.2 99.0 100.6 -42.3 -58.4 175.6
535.9 74.0 168.3 124.2 132.3 -66.9 -49.1 162.6
-20.9 16.4 5.5 -10.2 -23.1 14.2 -7.3 18.2


Reduced matrix =
97.5 89.9 64.6 51.5 -26.3 -51.0 110.5
24.6 97.9 34.3 38.5 -27.8 -17.1 55.1
28.5 49.0 86.2 58.9 -42.7 -19.7 37.2
40.1 106.1 78.5 89.7 -50.0 -28.7 81.7
96.5 151.2 99.0 100.6 -42.3 -58.4 175.6
74.0 168.3 124.2 132.3 -66.9 -49.1 162.6
16.4 5.5 -10.2 -23.1 14.2 -7.3 18.2


Eigenvectors =
45.4 27.6 25.3 43.8 72.1 75.5 1.0

Hermitian matrix =
0.0 0.0 0.0 0.0 0.0 0.0 0.0
-0.6 1.0 0.0 0.0 0.0 0.0 0.0
-0.6 0.0 1.0 0.0 0.0 0.0 0.0
-1.0 0.0 0.0 1.0 0.0 0.0 0.0
-1.6 0.0 0.0 0.0 1.0 0.0 0.0
-1.7 0.0 0.0 0.0 0.0 1.0 0.0
-0.0 0.0 0.0 0.0 0.0 0.0 1.0


[matrices]multiplied =
2.1 2.0 1.4 1.1 -0.6 -1.1 2.4
-34.7 43.2 -5.0 7.2 -11.8 13.9 -12.2
-25.8 -1.0 50.2 30.2 -28.1 8.7 -24.3
-54.0 19.3 16.1 40.0 -24.6 20.6 -25.0
-58.2 8.5 -3.5 18.9 -0.5 22.5 0.1
-88.1 18.8 16.8 46.7 -23.1 35.7 -21.2
14.3 3.5 -11.6 -24.3 14.8 -6.2 15.8


Hermitian matrix inverse =
45.4 0.0 0.0 0.0 0.0 0.0 0.0
-27.6 1.0 0.0 0.0 0.0 0.0 0.0
-25.3 0.0 1.0 0.0 0.0 0.0 0.0
-43.8 0.0 0.0 1.0 0.0 0.0 0.0
-72.1 0.0 0.0 0.0 1.0 0.0 0.0
-75.5 0.0 0.0 0.0 0.0 1.0 0.0
-1.0 0.0 0.0 0.0 0.0 0.0 1.0


[matrices]multiplied =
81.2 2.0 1.4 1.1 -0.6 -1.1 2.4
-3151.5 43.2 -5.0 7.2 -11.8 13.9 -12.2
-2341.1 -1.0 50.2 30.2 -28.1 8.7 -24.3
-4899.1 19.3 16.1 40.0 -24.6 20.6 -25.0
-5285.4 8.5 -3.5 18.9 -0.5 22.5 0.1
-7997.8 18.8 16.8 46.7 -23.1 35.7 -21.2
1295.9 3.5 -11.6 -24.3 14.8 -6.2 15.8


Reduced matrix =
43.2 -5.0 7.2 -11.8 13.9 -12.2
-1.0 50.2 30.2 -28.1 8.7 -24.3
19.3 16.1 40.0 -24.6 20.6 -25.0
8.5 -3.5 18.9 -0.5 22.5 0.1
18.8 16.8 46.7 -23.1 35.7 -21.2
3.5 -11.6 -24.3 14.8 -6.2 15.8


Eigenvectors =
-0.9 -2.1 -2.1 -1.2 -2.8 1.0

Hermitian matrix =
-1.1 0.0 0.0 0.0 0.0 0.0
-2.2 1.0 0.0 0.0 0.0 0.0
-2.3 0.0 1.0 0.0 0.0 0.0
-1.2 0.0 0.0 1.0 0.0 0.0
-3.0 0.0 0.0 0.0 1.0 0.0
1.1 0.0 0.0 0.0 0.0 1.0


[matrices]multiplied =
-46.5 5.4 -7.7 12.7 -15.0 13.2
-97.2 61.3 14.2 -1.9 -22.4 2.9
-80.6 27.6 23.4 2.6 -11.7 3.3
-45.4 2.8 9.9 14.2 5.1 15.4
-110.0 31.6 25.3 12.0 -5.9 15.3
50.0 -17.0 -16.5 2.1 8.8 2.6


Hermitian matrix inverse =
-0.9 0.0 0.0 0.0 0.0 0.0
2.1 1.0 0.0 0.0 0.0 0.0
2.1 0.0 1.0 0.0 0.0 0.0
1.2 0.0 0.0 1.0 0.0 0.0
2.8 0.0 0.0 0.0 1.0 0.0
-1.0 0.0 0.0 0.0 0.0 1.0


[matrices]multiplied =
-2.3 5.4 -7.7 12.7 -15.0 13.2
180.5 61.3 14.2 -1.9 -22.4 2.9
149.7 27.6 23.4 2.6 -11.7 3.3
84.4 2.8 9.9 14.2 5.1 15.4
204.2 31.6 25.3 12.0 -5.9 15.3
-92.9 -17.0 -16.5 2.1 8.8 2.6


Reduced matrix =
61.3 14.2 -1.9 -22.4 2.9
27.6 23.4 2.6 -11.7 3.3
2.8 9.9 14.2 5.1 15.4
31.6 25.3 12.0 -5.9 15.3
-17.0 -16.5 2.1 8.8 2.6


Eigenvectors =
-2.4 -1.5 -0.4 -1.8 1.0

Hermitian matrix =
-0.4 0.0 0.0 0.0 0.0
-0.6 1.0 0.0 0.0 0.0
-0.2 0.0 1.0 0.0 0.0
-0.7 0.0 0.0 1.0 0.0
0.4 0.0 0.0 0.0 1.0


[matrices]multiplied =
-25.4 -5.9 0.8 9.3 -1.2
-11.0 14.5 3.8 2.4 1.5
-7.7 7.5 14.5 8.9 14.9
-14.2 14.7 13.4 10.9 13.1
8.4 -10.6 1.3 -0.5 3.8


Hermitian matrix inverse =
-2.4 0.0 0.0 0.0 0.0
1.5 1.0 0.0 0.0 0.0
0.4 0.0 1.0 0.0 0.0
1.8 0.0 0.0 1.0 0.0
-1.0 0.0 0.0 0.0 1.0


[matrices]multiplied =
70.6 -5.9 0.8 9.3 -1.2
52.8 14.5 3.8 2.4 1.5
36.9 7.5 14.5 8.9 14.9
68.6 14.7 13.4 10.9 13.1
-40.6 -10.6 1.3 -0.5 3.8


Reduced matrix =
14.5 3.8 2.4 1.5
7.5 14.5 8.9 14.9
14.7 13.4 10.9 13.1
-10.6 1.3 -0.5 3.8


Eigenvectors =
-2.4 -4.4 -5.3 1.0

Hermitian matrix =
-0.4 0.0 0.0 0.0
-1.8 1.0 0.0 0.0
-2.2 0.0 1.0 0.0
0.4 0.0 0.0 1.0


[matrices]multiplied =
-6.0 -1.6 -1.0 -0.6
-18.8 7.6 4.6 12.3
-17.3 5.0 5.6 9.9
-4.6 2.9 0.5 4.4


Hermitian matrix inverse =
-2.4 0.0 0.0 0.0
4.4 1.0 0.0 0.0
5.3 0.0 1.0 0.0
-1.0 0.0 0.0 1.0


[matrices]multiplied =
2.9 -1.6 -1.0 -0.6
90.3 7.6 4.6 12.3
82.9 5.0 5.6 9.9
22.1 2.9 0.5 4.4


Reduced matrix =
7.6 4.6 12.3
5.0 5.6 9.9
2.9 0.5 4.4


Eigenvectors =
3.2 2.7 1.0

Hermitian matrix =
0.3 0.0 0.0
-0.8 1.0 0.0
-0.3 0.0 1.0


[matrices]multiplied =
2.4 1.4 3.8
-1.4 1.8 -0.4
0.6 -0.9 0.6


Hermitian matrix inverse =
3.2 0.0 0.0
-2.7 1.0 0.0
-1.0 0.0 1.0


[matrices]multiplied =
0.0 1.4 3.8
-8.7 1.8 -0.4
3.6 -0.9 0.6


Reduced matrix =
1.8 -0.4
-0.9 0.6


Eigenvectors =
-1.6 1.0

Hermitian matrix =
-0.6 0.0
0.6 1.0


[matrices]multiplied =
-1.1 0.3
0.2 0.4


Hermitian matrix inverse =
-1.6 0.0
-1.0 1.0


[matrices]multiplied =
1.5 0.3
-0.7 0.4


Reduced matrix =
0.4


Eigenvectors =
0.9 0.6 0.5 0.6 1.0 0.8 0.5 1.0 0.7 1.0

Eigenvectors =
1.4 -1.1 -0.0 -1.2 -0.3 1.7 -1.5 -0.7 -0.6 1.0

Eigenvectors =
0.2 1.4 0.9 -0.0 0.8 -0.9 0.0 -1.2 -1.8 1.0

Eigenvectors =
-3.1 -3.2 1.6 0.9 1.9 1.2 0.8 -0.8 -0.6 1.0

Eigenvectors =
0.0 -0.6 -0.2 1.2 -0.4 -1.1 -1.3 1.0 -0.5 1.0

Eigenvectors =
1.7 -3.8 -1.4 -7.9 8.1 -7.7 -0.9 1.5 3.4 1.0


[ remainder of message truncated in this digest view due to length ]

[Bald Eagle] Re: [Minimum Volume] Bounding Ellipsoid via SVD [2351 days 19 hours and 48 minutes ago]

Wed, 6 Nov 2019 01:10:00 GMT

I copied an pasted / modified the print_matrix () function into all of the other
functions, and puzzled out how to print out a vector ("list").

Got that to compile, and now we can step-by-step what happens, and where it goes
off the rails.   Looks like the trouble starts when trying to create the
Hermitian matrix.

In any event, this is way farther along than I'd thought I'd be by now...   :)

I suppose I need to dump everything to a text file, rather than to std::cout <<

Singular Value Decomposition (SVD):

Enter size of matrix N = (50x50 max): 10

A =
9.0 7.0 3.0 3.0 6.0 5.0 0.0 9.0 3.0 4.0
8.0 4.0 0.0 4.0 7.0 3.0 2.0 6.0 6.0 6.0
1.0 9.0 5.0 3.0 6.0 7.0 5.0 1.0 2.0 8.0
5.0 3.0 7.0 8.0 6.0 6.0 6.0 7.0 5.0 1.0
3.0 5.0 8.0 3.0 0.0 5.0 8.0 2.0 3.0 5.0
0.0 6.0 6.0 6.0 9.0 2.0 5.0 4.0 5.0 9.0
3.0 2.0 3.0 0.0 3.0 1.0 6.0 9.0 8.0 4.0
0.0 2.0 9.0 0.0 7.0 1.0 5.0 8.0 3.0 1.0
3.0 6.0 7.0 1.0 2.0 7.0 5.0 9.0 3.0 0.0
0.0 8.0 2.0 3.0 1.0 7.0 7.0 9.0 6.0 5.0


[matrix]transposed =
9.0 8.0 1.0 5.0 3.0 0.0 3.0 0.0 3.0 0.0
7.0 4.0 9.0 3.0 5.0 6.0 2.0 2.0 6.0 8.0
3.0 0.0 5.0 7.0 8.0 6.0 3.0 9.0 7.0 2.0
3.0 4.0 3.0 8.0 3.0 6.0 0.0 0.0 1.0 3.0
6.0 7.0 6.0 6.0 0.0 9.0 3.0 7.0 2.0 1.0
5.0 3.0 7.0 6.0 5.0 2.0 1.0 1.0 7.0 7.0
0.0 2.0 5.0 6.0 8.0 5.0 6.0 5.0 5.0 7.0
9.0 6.0 1.0 7.0 2.0 4.0 9.0 8.0 9.0 9.0
3.0 6.0 2.0 5.0 3.0 5.0 8.0 3.0 3.0 6.0
4.0 6.0 8.0 1.0 5.0 9.0 4.0 1.0 0.0 5.0


[matrices]multiplied =
315.0 265.0 214.0 259.0 167.0 229.0 194.0 173.0 230.0 231.0
265.0 266.0 195.0 234.0 147.0 235.0 194.0 142.0 169.0 206.0
214.0 195.0 295.0 224.0 220.0 281.0 148.0 159.0 196.0 242.0
259.0 234.0 224.0 330.0 222.0 266.0 209.0 219.0 252.0 250.0
167.0 147.0 220.0 222.0 234.0 214.0 158.0 157.0 200.0 217.0
229.0 235.0 281.0 266.0 214.0 340.0 201.0 212.0 192.0 247.0
194.0 194.0 148.0 209.0 158.0 201.0 229.0 183.0 190.0 223.0
173.0 142.0 159.0 219.0 157.0 212.0 183.0 234.0 202.0 178.0
230.0 169.0 196.0 252.0 200.0 192.0 190.0 202.0 263.0 250.0
231.0 206.0 242.0 250.0 217.0 247.0 223.0 178.0 250.0 318.0


[matrices]multiplied =
198.0 158.0 121.0 114.0 161.0 145.0 108.0 225.0 144.0 124.0
158.0 324.0 245.0 169.0 236.0 267.0 249.0 311.0 211.0 256.0
121.0 245.0 326.0 153.0 232.0 219.0 273.0 301.0 192.0 184.0
114.0 169.0 153.0 153.0 171.0 151.0 151.0 176.0 139.0 152.0
161.0 236.0 232.0 171.0 301.0 178.0 195.0 290.0 204.0 225.0
145.0 267.0 219.0 151.0 178.0 248.0 222.0 273.0 176.0 183.0
108.0 249.0 273.0 151.0 195.0 222.0 289.0 297.0 221.0 207.0
225.0 311.0 301.0 176.0 290.0 273.0 297.0 494.0 303.0 222.0
144.0 211.0 192.0 139.0 204.0 176.0 221.0 303.0 226.0 194.0
124.0 256.0 184.0 152.0 225.0 183.0 207.0 222.0 194.0 265.0


Eigenvectors =
0.7 1.2 1.1 0.8 1.1 1.0 1.1 1.5 1.0 1.0

Hermitian matrix =
1.4 nan nan nan nan nan nan nan nan nan
-1.7 1.0 nan nan nan nan nan nan nan nan
-1.5 nan 1.0 nan nan nan nan nan nan nan
-1.0 nan nan 1.0 nan nan nan nan nan nan
-1.5 nan nan nan 1.0 nan nan nan nan nan
-1.4 nan nan nan nan 1.0 nan nan nan nan
-1.5 nan nan nan nan nan 1.0 nan nan nan
-2.0 nan nan nan nan nan nan 1.0 nan nan
-1.4 nan nan nan nan nan nan nan 1.0 nan
-1.4 nan nan nan nan nan nan nan nan 1.0


[matrices]multiplied =
nan nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan nan


Hermitian matrix inverse =
0.7 nan nan nan nan nan nan nan nan nan
-1.2 1.0 nan nan nan nan nan nan nan nan
-1.1 nan 1.0 nan nan nan nan nan nan nan
-0.8 nan nan 1.0 nan nan nan nan nan nan
-1.1 nan nan nan 1.0 nan nan nan nan nan
-1.0 nan nan nan nan 1.0 nan nan nan nan
-1.1 nan nan nan nan nan 1.0 nan nan nan
-1.5 nan nan nan nan nan nan 1.0 nan nan
-1.0 nan nan nan nan nan nan nan 1.0 nan
-1.0 nan nan nan nan nan nan nan nan 1.0


[matrices]multiplied =
nan nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan nan


Reduced matrix =
nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan


Eigenvectors =
nan nan nan nan nan nan nan nan 1.0

Hermitian matrix =
nan nan nan nan nan nan nan nan nan
nan 1.0 nan nan nan nan nan nan nan
nan nan 1.0 nan nan nan nan nan nan
nan nan nan 1.0 nan nan nan nan nan
nan nan nan nan 1.0 nan nan nan nan
nan nan nan nan nan 1.0 nan nan nan
nan nan nan nan nan nan 1.0 nan nan
nan nan nan nan nan nan nan 1.0 nan
nan nan nan nan nan nan nan nan 1.0


[matrices]multiplied =
nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan


Hermitian matrix inverse =
nan nan nan nan nan nan nan nan nan
nan 1.0 nan nan nan nan nan nan nan
nan nan 1.0 nan nan nan nan nan nan
nan nan nan 1.0 nan nan nan nan nan
nan nan nan nan 1.0 nan nan nan nan
nan nan nan nan nan 1.0 nan nan nan
nan nan nan nan nan nan 1.0 nan nan
nan nan nan nan nan nan nan 1.0 nan
-1.0 nan nan nan nan nan nan nan 1.0


[matrices]multiplied =
nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan


Reduced matrix =
nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan


Eigenvectors =
nan nan nan nan nan nan nan 1.0

Hermitian matrix =
nan nan nan nan nan nan nan nan
nan 1.0 nan nan nan nan nan nan
nan nan 1.0 nan nan nan nan nan
nan nan nan 1.0 nan nan nan nan
nan nan nan nan 1.0 nan nan nan
nan nan nan nan nan 1.0 nan nan
nan nan nan nan nan nan 1.0 nan
nan nan nan nan nan nan nan 1.0


[matrices]multiplied =
nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan


Hermitian matrix inverse =
nan nan nan nan nan nan nan nan
nan 1.0 nan nan nan nan nan nan
nan nan 1.0 nan nan nan nan nan
nan nan nan 1.0 nan nan nan nan
nan nan nan nan 1.0 nan nan nan
nan nan nan nan nan 1.0 nan nan
nan nan nan nan nan nan 1.0 nan
-1.0 nan nan nan nan nan nan 1.0


[matrices]multiplied =
nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan


Reduced matrix =
nan nan nan nan nan nan nan
nan nan nan nan nan nan nan
nan nan nan nan nan nan nan
nan nan nan nan nan nan nan
nan nan nan nan nan nan nan
nan nan nan nan nan nan nan
nan nan nan nan nan nan nan


Eigenvectors =
nan nan nan nan nan nan 1.0

Hermitian matrix =
nan nan nan nan nan nan nan
nan 1.0 nan nan nan nan nan
nan nan 1.0 nan nan nan nan
nan nan nan 1.0 nan nan nan
nan nan nan nan 1.0 nan nan
nan nan nan nan nan 1.0 nan
nan nan nan nan nan nan 1.0


[matrices]multiplied =
nan nan nan nan nan nan nan
nan nan nan nan nan nan nan
nan nan nan nan nan nan nan
nan nan nan nan nan nan nan
nan nan nan nan nan nan nan
nan nan nan nan nan nan nan
nan nan nan nan nan nan nan


Hermitian matrix inverse =
nan nan nan nan nan nan nan
nan 1.0 nan nan nan nan nan
nan nan 1.0 nan nan nan nan
nan nan nan 1.0 nan nan nan
nan nan nan nan 1.0 nan nan
nan nan nan nan nan 1.0 nan
-1.0 nan nan nan nan nan 1.0


[matrices]multiplied =
nan nan nan nan nan nan nan
nan nan nan nan nan nan nan
nan nan nan nan nan nan nan
nan nan nan nan nan nan nan
nan nan nan nan nan nan nan
nan nan nan nan nan nan nan
nan nan nan nan nan nan nan


Reduced matrix =
nan nan nan nan nan nan
nan nan nan nan nan nan
nan nan nan nan nan nan
nan nan nan nan nan nan
nan nan nan nan nan nan
nan nan nan nan nan nan


Eigenvectors =
nan nan nan nan nan 1.0

Hermitian matrix =
nan nan nan nan nan nan
nan 1.0 nan nan nan nan
nan nan 1.0 nan nan nan
nan nan nan 1.0 nan nan
nan nan nan nan 1.0 nan
nan nan nan nan nan 1.0


[matrices]multiplied =
nan nan nan nan nan nan
nan nan nan nan nan nan
nan nan nan nan nan nan
nan nan nan nan nan nan
nan nan nan nan nan nan
nan nan nan nan nan nan


Hermitian matrix inverse =
nan nan nan nan nan nan
nan 1.0 nan nan nan nan
nan nan 1.0 nan nan nan
nan nan nan 1.0 nan nan
nan nan nan nan 1.0 nan
-1.0 nan nan nan nan 1.0


[matrices]multiplied =
nan nan nan nan nan nan
nan nan nan nan nan nan
nan nan nan nan nan nan
nan nan nan nan nan nan
nan nan nan nan nan nan
nan nan nan nan nan nan


Reduced matrix =
nan nan nan nan nan
nan nan nan nan nan
nan nan nan nan nan
nan nan nan nan nan
nan nan nan nan nan


Eigenvectors =
nan nan nan nan 1.0

Hermitian matrix =
nan nan nan nan nan
nan 1.0 nan nan nan
nan nan 1.0 nan nan
nan nan nan 1.0 nan
nan nan nan nan 1.0


[matrices]multiplied =
nan nan nan nan nan
nan nan nan nan nan
nan nan nan nan nan
nan nan nan nan nan
nan nan nan nan nan


Hermitian matrix inverse =
nan nan nan nan nan
nan 1.0 nan nan nan
nan nan 1.0 nan nan
nan nan nan 1.0 nan
-1.0 nan nan nan 1.0


[matrices]multiplied =
nan nan nan nan nan
nan nan nan nan nan
nan nan nan nan nan
nan nan nan nan nan
nan nan nan nan nan


Reduced matrix =
nan nan nan nan
nan nan nan nan
nan nan nan nan
nan nan nan nan


Eigenvectors =
nan nan nan 1.0

Hermitian matrix =
nan nan nan nan
nan 1.0 nan nan
nan nan 1.0 nan
nan nan nan 1.0


[matrices]multiplied =
nan nan nan nan
nan nan nan nan
nan nan nan nan
nan nan nan nan


Hermitian matrix inverse =
nan nan nan nan
nan 1.0 nan nan
nan nan 1.0 nan
-1.0 nan nan 1.0


[matrices]multiplied =
nan nan nan nan
nan nan nan nan
nan nan nan nan
nan nan nan nan


Reduced matrix =
nan nan nan
nan nan nan
nan nan nan


Eigenvectors =
nan nan 1.0

Hermitian matrix =
nan nan nan
nan 1.0 nan
nan nan 1.0


[matrices]multiplied =
nan nan nan
nan nan nan
nan nan nan


Hermitian matrix inverse =
nan nan nan
nan 1.0 nan
-1.0 nan 1.0


[matrices]multiplied =
nan nan nan
nan nan nan
nan nan nan


Reduced matrix =
nan nan
nan nan


Eigenvectors =
nan 1.0

Hermitian matrix =
nan nan
nan 1.0


[matrices]multiplied =
nan nan
nan nan


Hermitian matrix inverse =
nan nan
-1.0 1.0


[matrices]multiplied =
nan nan
nan nan


Reduced matrix =
nan


Eigenvectors =
0.7 1.2 1.1 0.8 1.1 1.0 1.1 1.5 1.0 1.0

Eigenvectors =
nan nan nan nan nan nan nan nan nan 1.0

Eigenvectors =
nan nan nan nan nan nan nan nan nan 1.0

Eigenvectors =
nan nan nan nan nan nan nan nan nan 1.0

Eigenvectors =
nan nan nan nan nan nan nan nan nan 1.0

Eigenvectors =
nan nan nan nan nan nan nan nan nan 1.0

Eigenvectors =
nan nan nan nan nan nan nan nan nan 1.0

Eigenvectors =
nan nan nan nan nan nan nan nan nan 1.0

[ remainder of message truncated in this digest view due to length ]

[Bald Eagle] Re: [Minimum Volume] Bounding Ellipsoid via SVD [2351 days 20 hours and 33 minutes ago]

Wed, 6 Nov 2019 00:25:01 GMT

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

> looked a little closer at the stuff.  so, (best teacher's voice) "let the lesson
> begin".  :-)

Super.  I had blithely assumed that anyone capable of writing the code would
write it so that it compiled properly, but the files that I downloaded
apparently don't work as written.

So I just moved the two big functions that require the smaller functions to the
bottom, and - voila.   a.out gets compiled.

Now to dubug the cause of so many nan's.

Enter size of matrix N = (50x50 max): 10

A =
1.00000 3.00000 8.00000 8.00000 5.00000 6.00000 0.00000 6.00000 9.00000 4.00000
7.00000 4.00000 3.00000 2.00000 2.00000 8.00000 3.00000 1.00000 1.00000 8.00000
4.00000 6.00000 9.00000 6.00000 9.00000 9.00000 1.00000 4.00000 6.00000 2.00000
6.00000 9.00000 7.00000 7.00000 7.00000 3.00000 5.00000 9.00000 1.00000 7.00000
3.00000 1.00000 1.00000 9.00000 5.00000 5.00000 7.00000 8.00000 7.00000 8.00000
6.00000 1.00000 4.00000 8.00000 9.00000 5.00000 9.00000 2.00000 9.00000 5.00000
5.00000 8.00000 6.00000 4.00000 5.00000 4.00000 9.00000 0.00000 3.00000 1.00000
7.00000 9.00000 4.00000 1.00000 0.00000 9.00000 6.00000 9.00000 7.00000 5.00000
7.00000 5.00000 7.00000 3.00000 3.00000 8.00000 0.00000 4.00000 1.00000 2.00000
9.00000 8.00000 0.00000 6.00000 2.00000 7.00000 2.00000 4.00000 9.00000 7.00000


S =
52.17460 nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan nan


U =
nan nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan nan
nan nan nan nan nan nan nan nan nan nan


V =
0.32948 nan nan nan nan nan nan nan nan nan
0.32858 nan nan nan nan nan nan nan nan nan
0.29328 nan nan nan nan nan nan nan nan nan
0.33434 nan nan nan nan nan nan nan nan nan
0.29083 nan nan nan nan nan nan nan nan nan
0.38177 nan nan nan nan nan nan nan nan nan
0.25788 nan nan nan nan nan nan nan nan nan
0.29742 nan nan nan nan nan nan nan nan nan
0.33315 nan nan nan nan nan nan nan nan nan
0.29899 nan nan nan nan nan nan nan nan nan

[jr] Re: [Minimum Volume] Bounding Ellipsoid via SVD [2351 days 21 hours and 13 minutes ago]

Tue, 5 Nov 2019 23:45:01 GMT

"jr" <cre### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > So, I've managed to trim down the number of errors that this gives me, but it
> > looks like there are a few things that need to be ironed out.
> :-)
> > ...
> > declarations were found by argument-dependent lookup at the point of
> > instantiation [-fpermissive]
> >   matrix_transpose(matrix, matrix_t);
> >                   ^
> and from here on it looks like complaints about functions which are called but
> not provided.

looked a little closer at the stuff.  so, (best teacher's voice) "let the lesson
begin".  :-)

in C, as in C++, the compiler must "know" (from a prototype), or "have seen", a
function _before_ it can be used.  so the error messages will go away if you
re-order the functions.

conventionally, you read a c/c++ source from the bottom of the file (ie 'main'
in most cases) upwards, and programming follows that -- if you call some
function from main, it must have been actually provided or prototyped "above".

regards, jr.

[jr] Re: [Minimum Volume] Bounding Ellipsoid via SVD [2351 days 21 hours and 33 minutes ago]

Tue, 5 Nov 2019 23:25:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> So, I've managed to trim down the number of errors that this gives me, but it
> looks like there are a few things that need to be ironed out.

:-)

> ...

> tried to compile:

ok, you know I don't speak this language (and man, is it ugly to read!), so I'm
... sticking my neck out.

> oem@oem-Inspiron-N5110 ~/Documents/POV-Ray-3.8/ThirdParty/jr/SVD/SVD $ c++
> SVD.cpp -std=c++11
> SVD.cpp: In function ‘int main(int, char**)’:
> SVD.cpp:350:68: error: expected primary-expression before ‘>’ token
>   std::cout << "Enter size of matrix N = (50x50 max): "; std::cin > >
> matrix_size;

a semicolon terminates a statement, the one before std::cin is the cause.

> SVD.cpp: In instantiation of ‘void svd(std::vector<std::vector<_RealType> >,
> std::vector<std::vector<_RealType> >&, std::vector<std::vector<_RealType> >&,
> std::vector<std::vector<_RealType> >&) [with Arg =
> boost::multiprecision::number<boost::multiprecision::backends::cpp_bin_float<4096u,
> (boost::multiprecision::backends::digit_base_type)2u, void, short int, -16382,
> 16383>, (boost::multiprecision::expression_template_option)0u>]’:
> SVD.cpp:358:22:   required from here
> SVD.cpp:31:18: error: ‘matrix_transpose’ was not declared in this scope,
and no
> declarations were found by argument-dependent lookup at the point of
> instantiation [-fpermissive]
>   matrix_transpose(matrix, matrix_t);
>                   ^

and from here on it looks like complaints about functions which are called but
not provided.  so presumably there's a library (like 'libm' for 'C' users) that
needs to be added to the command-line (to let the linker know).  hth.

good start though.


regards, jr.

[Bald Eagle] [Minimum Volume] Bounding Ellipsoid via SVD [2351 days 22 hours and 33 minutes ago]

Tue, 5 Nov 2019 22:25:01 GMT

So, I've managed to trim down the number of errors that this gives me, but it
looks like there are a few things that need to be ironed out.



stdafx.h is just (commented out what looked to me like Windows specific stuff):

// stdafx.h : include file for standard system include files,
// or project specific include files that are used frequently, but
// are changed infrequently
//

#pragma once

//#include "targetver.h"

#include <stdio.h>
//#include <tchar.h>



// TODO: reference additional headers your program requires here



-------------------------------------------------------------------
tried to compile:


oem@oem-Inspiron-N5110 ~/Documents/POV-Ray-3.8/ThirdParty/jr/SVD/SVD $ c++
SVD.cpp -std=c++11
SVD.cpp: In function ‘int main(int, char**)’:
SVD.cpp:350:68: error: expected primary-expression before ‘>’ token
  std::cout << "Enter size of matrix N = (50x50 max): "; std::cin > >
matrix_size;
                                                                    ^
SVD.cpp: In instantiation of ‘void svd(std::vector<std::vector<_RealType> >,
std::vector<std::vector<_RealType> >&, std::vector<std::vector<_RealType> >&,
std::vector<std::vector<_RealType> >&) [with Arg =
boost::multiprecision::number<boost::multiprecision::backends::cpp_bin_float<4096u,
(boost::multiprecision::backends::digit_base_type)2u, void, short int, -16382,
16383>, (boost::multiprecision::expression_template_option)0u>]’:
SVD.cpp:358:22:   required from here
SVD.cpp:31:18: error: ‘matrix_transpose’ was not declared in this scope, and
no
declarations were found by argument-dependent lookup at the point of
instantiation [-fpermissive]
  matrix_transpose(matrix, matrix_t);
                  ^
SVD.cpp:186:6: note: ‘template<class Arg> void
matrix_transpose(std::vector<std::vector<_RealType> >,
std::vector<std::vector<_RealType> >&)’ declared here, later in the translation
unit
 void matrix_transpose(std::vector<std::vector<Arg> > matrix1,
      ^
SVD.cpp:34:18: error: ‘matrix_by_matrix’ was not declared in this scope, and
no
declarations were found by argument-dependent lookup at the point of
instantiation [-fpermissive]
  matrix_by_matrix(matrix, matrix_t, matrix_product1);
                  ^
SVD.cpp:199:6: note: ‘template<class Arg> void
matrix_by_matrix(std::vector<std::vector<_RealType> >,
std::vector<std::vector<_RealType> >&, std::vector<std::vector<_RealType> >&)’
declared here, later in the translation unit
 void matrix_by_matrix(std::vector<std::vector<Arg> > matrix1,
      ^
SVD.cpp:37:18: error: ‘matrix_by_matrix’ was not declared in this scope, and
no
declarations were found by argument-dependent lookup at the point of
instantiation [-fpermissive]
  matrix_by_matrix(matrix_t, matrix, matrix_product2);
                  ^
SVD.cpp:199:6: note: ‘template<class Arg> void
matrix_by_matrix(std::vector<std::vector<_RealType> >,
std::vector<std::vector<_RealType> >&, std::vector<std::vector<_RealType> >&)’
declared here, later in the translation unit
 void matrix_by_matrix(std::vector<std::vector<Arg> > matrix1,
      ^
SVD.cpp:43:13: error: ‘compute_evd’ was not declared in this scope, and no
declarations were found by argument-dependent lookup at the point of
instantiation [-fpermissive]
  compute_evd(matrix_product2, eigenvalues, v_1, 0);
             ^
SVD.cpp:65:6: note: ‘template<class Arg> void
compute_evd(std::vector<std::vector<_RealType> >, std::vector<_RealType>&,
std::vector<std::vector<_RealType> >&, std::size_t)’ declared here, later in the
translation unit
 void compute_evd(std::vector<std::vector<Arg> > matrix,
      ^
SVD.cpp:45:18: error: ‘matrix_transpose’ was not declared in this scope, and
no
declarations were found by argument-dependent lookup at the point of
instantiation [-fpermissive]
  matrix_transpose(v_1, v);
                  ^
SVD.cpp:186:6: note: ‘template<class Arg> void
matrix_transpose(std::vector<std::vector<_RealType> >,
std::vector<std::vector<_RealType> >&)’ declared here, later in the translation
unit
 void matrix_transpose(std::vector<std::vector<Arg> > matrix1,
      ^
SVD.cpp:55:29: error: ‘get_inverse_diagonal_matrix’ was not declared in this
scope, and no declarations were found by argument-dependent lookup at the point
of instantiation [-fpermissive]
  get_inverse_diagonal_matrix(s, s_inverse);
                             ^
SVD.cpp:277:6: note: ‘template<class Arg> void
get_inverse_diagonal_matrix(std::vector<std::vector<_RealType> >,
std::vector<std::vector<_RealType> >&)’ declared here, later in the translation
unit
 void get_inverse_diagonal_matrix(std::vector<std::vector<Arg> > matrix,
      ^
SVD.cpp:58:18: error: ‘matrix_by_matrix’ was not declared in this scope, and
no
declarations were found by argument-dependent lookup at the point of
instantiation [-fpermissive]
  matrix_by_matrix(matrix, v, av_matrix);
                  ^
SVD.cpp:199:6: note: ‘template<class Arg> void
matrix_by_matrix(std::vector<std::vector<_RealType> >,
std::vector<std::vector<_RealType> >&, std::vector<std::vector<_RealType> >&)’
declared here, later in the translation unit
 void matrix_by_matrix(std::vector<std::vector<Arg> > matrix1,
      ^
SVD.cpp:59:18: error: ‘matrix_by_matrix’ was not declared in this scope, and
no
declarations were found by argument-dependent lookup at the point of
instantiation [-fpermissive]
  matrix_by_matrix(av_matrix, s_inverse, u);
                  ^
SVD.cpp:199:6: note: ‘template<class Arg> void
matrix_by_matrix(std::vector<std::vector<_RealType> >,
std::vector<std::vector<_RealType> >&, std::vector<std::vector<_RealType> >&)’
declared here, later in the translation unit
 void matrix_by_matrix(std::vector<std::vector<Arg> > matrix1,

[Thomas de Groot] Re: bounding box calculator [2352 days 12 hours and 11 minutes ago]

Tue, 5 Nov 2019 08:47:40 GMT

Op 04/11/2019 om 09:09 schreef Thomas de Groot:
> - rotating the object changes the 'tightness' of the standard BB. I did 
> that with a simple cylinder: when properly aligned along one of the 
> axis, the BB test is always optimal; rotate the cylinder (e.g. 
> <45,45,45>) and do the test, and the standard BB becomes too wide.
> 

I have to correct this: The BB only becomes slightly less optimal in the 
example cited. With increasing complexity of the object however, 
optimisation kicks in.

-- 
Thomas

[Thomas de Groot] Re: bounding box calculator [2352 days 12 hours and 54 minutes ago]

Tue, 5 Nov 2019 08:04:30 GMT

Op 04/11/2019 om 20:01 schreef Bald Eagle:
> Great job Thomas - those results are surprising, given the absolute mathematical
> nature of those shapes.
>

Thank you indeed, sir. I was curious to see if bounder.inc was universal 
or not. I assumed it was given the nature of the tests, and like you, I 
was surprised.

> I would have imagined that with something like a parametric, you'd be able to
> cycle through u and v real quick, and get a min and max value for each axis to
> use for the AABB dimensions.   I'm also still completely mystified as to why the
> parametric is such a slow-to-render object, and why the triangle approximation
> isn't a source-coded native primitive.
> 

These are mysteries on Earth and below the heavens which we may not be 
permitted to fathom...

-- 
Thomas

[Thomas de Groot] Re: bounding box calculator [2352 days 13 hours ago]

Tue, 5 Nov 2019 07:58:38 GMT

Op 04/11/2019 om 15:07 schreef jr:
> "jr" <cre### [at] gmailcom> wrote:
>> Thomas de Groot <tho### [at] degrootorg> wrote:
>>> ...
>>> - I include the test scene file for you to play with.
>>
>> thank you v much for this.  not only do I get those natty presentation settings
>> :-), but looking at the code I surmise you replaced the 'local's of the
>> difference vectors with 'declare's?  that's given me another idea for an
>> improvement: create two variables, 'Bounder_{min,max}_diff' and export
>> ('declare') them for in-scene use.  thoughts?
>

I did. Just changed #local to #declare.  ;-)
I suppose that using #local inside the macros is ok; #declare in the 
resuming section could be more useful for subsequent use.

> d'oh!  finally got the "why".  :-)  with yr permission will add the calculator,
> also will adopt the "proper" labelling in existing output.  thanks.
> 

Be my guest :-)

-- 
Thomas

[jr] Re: bounding box calculator [2352 days 19 hours and 28 minutes ago]

Tue, 5 Nov 2019 01:30:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > 'C', not 'C++'.  ;-)  (in an ideal world, anyway)
>
> I can't really ever tell the difference just by looking   :P
>
> > I think cutting and pasting that c++ code into a single source and getting that
> > to compile, or at least spit out errors, would be a good exercise, then.
>
> .... a single source.  a .c file and then do a gcc compile to make a ... .bin?
> ..exe?

one file, yes.  the usual extension is '.cpp'.  then compiling with:
  $ c++ myfile.cpp
should create an 'a.out' executable.

> > first I suggest get that c++ to build, as exercise.
>
> this one:
>
https://www.codeproject.com/Articles/1268576/Singular-Values-Decomposition-SVD-In-Cplusplus11-B
>
> I have never "built" anything from scratch, so I really have no idea what I'm
> doing or why.

now's the time.

> > I did not read the article too closely but am under the impression that if one
> > re-assembles the functions in one source file, it'll build.  do you want to use
> > this code as a starting point?  if yes, then that will determine/influence the
> > data format.
>
> Sure, whatever.   but that guy's code is redundant to the gsl library.  If I've
> already installed that - isn't that ... built? (*)

sure, but a library is just (a bag of) components.

> > yes, in all likelihood _but_ how's your 'C', Bill?  or are you .. wedded to
> > 'C++'?
>
> I used to write a bunch of stuff for different Arduinos - ATMega and Leonardo...
>  still some confusion as to whether that's C or c++

Arduino has a 'C' SDK afaik.

> But I'm sure I could learn.  I _would_ rather stick with one language, to
> minimize confusion, and if POV-Ray source is in c++, then I'd prefer that, but
> I'm sure one translates over to the other to some extent.

it does, and it doesn't.  while c++ was developed from c, and so has some vague
visual semblance, that exactly is a big problem -- people tend to overestimate
the "some extent".

from a practical point of view, forget the POV-Ray source for now, other than
for reading.  get working experience of the tool chain.

since I do not speak c++, I won't be too much help when, as we all do, you find
yourself in a battle with the finer points of the language, however, maybe Dick
Balaska will chip in.

> (*)
> oem@oem-Inspiron-N5110 ~/Desktop $ apt-cache show gsl-bin
> Package: gsl-bin

looks like you're good to go.  (effing weird this gratuitous splitting of
packages in to 'bin' and 'dev'.  but hey, "you pays your money and takes your
choice")

regards, jr.

[Bald Eagle] Re: bounding box calculator [2352 days 19 hours and 58 minutes ago]

Tue, 5 Nov 2019 01:00:00 GMT

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

> 'C', not 'C++'.  ;-)  (in an ideal world, anyway)

I can't really ever tell the difference just by looking   :P

> I think cutting and pasting that c++ code into a single source and getting that
> to compile, or at least spit out errors, would be a good exercise, then.

.... a single source.  a .c file and then do a gcc compile to make a ... .bin?
..exe?

> first I suggest get that c++ to build, as exercise.

this one:
https://www.codeproject.com/Articles/1268576/Singular-Values-Decomposition-SVD-In-Cplusplus11-B

I have never "built" anything from scratch, so I really have no idea what I'm
doing or why.

> I did not read the article too closely but am under the impression that if one
> re-assembles the functions in one source file, it'll build.  do you want to use
> this code as a starting point?  if yes, then that will determine/influence the
> data format.

Sure, whatever.   but that guy's code is redundant to the gsl library.  If I've
already installed that - isn't that ... built? (*)

> yes, in all likelihood _but_ how's your 'C', Bill?  or are you .. wedded to
> 'C++'?

I used to write a bunch of stuff for different Arduinos - ATMega and Leonardo...
 still some confusion as to whether that's C or c++

But I'm sure I could learn.  I _would_ rather stick with one language, to
minimize confusion, and if POV-Ray source is in c++, then I'd prefer that, but
I'm sure one translates over to the other to some extent.

(*)

oem@oem-Inspiron-N5110 ~/Desktop $ apt-cache show gsl-bin
Package: gsl-bin
Source: gsl
Priority: optional
Section: math
Installed-Size: 63
Maintainer: Dirk Eddelbuettel <edd### [at] debianorg>
Architecture: amd64
Version: 2.5+dfsg-6~16.04
Replaces: gsl
Depends: libc6 (>= 2.7), libgsl23 (>= 2.5)
Conflicts: gsl
Filename: pool/main/g/gsl/gsl-bin_2.5+dfsg-6~16.04_amd64.deb
Size: 29470
MD5sum: d91cad88f7767c41d41d9194e79c5b51
SHA1: 722962da0169254fee7bc14b48b1ba948514df7f
SHA256: d2e80f2cabcdec706397145d324ea57c425b9184b1fb1afe8d80de711438468e
Description-en: GNU Scientific Library (GSL) -- binary package
 The GNU Scientific Library (GSL) is a collection of routines for
 numerical analysis.  The routines are written from scratch by the GSL
 team in C, and present a modern API for C programmers, while allowing
 wrappers to be written for very high level languages.
 .
 This package provides several example binaries.
 .
 URL: http://www.gnu.org/software/gsl/
Description-md5: 7553709bb194c39b6d774e61c06ec157
Multi-Arch: foreign

Package: gsl-bin
Priority: optional
Section: universe/math
Installed-Size: 62
Maintainer: Ubuntu Developers <ubu### [at] listsubuntucom>
Original-Maintainer: Dirk Eddelbuettel <edd### [at] debianorg>
Architecture: amd64
Source: gsl
Version: 2.1+dfsg-2
Replaces: gsl
Depends: libc6 (>= 2.7), libgsl2
Conflicts: gsl
Filename: pool/universe/g/gsl/gsl-bin_2.1+dfsg-2_amd64.deb
Size: 11250
MD5sum: d182e4dfa1ce45358d88dbf728871e3d
SHA1: b23fab8ea5f411ebfb6be076c0f43fd1271b613d
SHA256: 826ee499196a9fa12aabcd4ca66616334ae9abf8f11467c7b007f63666f56732
Description-en: GNU Scientific Library (GSL) -- binary package
 The GNU Scientific Library (GSL) is a collection of routines for
 numerical analysis.  The routines are written from scratch by the GSL
 team in C, and present a modern API for C programmers, while allowing
 wrappers to be written for very high level languages.
 .
 This package provides several example binaries.
 .
 URL: http://www.gnu.org/software/gsl/
Description-md5: 7553709bb194c39b6d774e61c06ec157
Multi-Arch: foreign
Homepage: http://www.gnu.org/software/gsl
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Origin: Ubuntu

[jr] Re: bounding box calculator [2352 days 20 hours and 23 minutes ago]

Tue, 5 Nov 2019 00:35:01 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > had a quick look, the page appears to give you the lot.
> Right, it looked solid enough to pursue, though it will require a lot of
> fiddling to adapt to SDL.
>
> > thinking you ought to have a look at the GSL (GNU Scientific Library); I just
> > found an index entry for singular value decomp.
>
> I got that set up, and now need to learn how to use such things.
> It appears that I have to write a c++ program and compile it, and then run it.

'C', not 'C++'.  ;-)  (in an ideal world, anyway)

I think cutting and pasting that c++ code into a single source and getting that
to compile, or at least spit out errors, would be a good exercise, then.

> Looks like this guy has a short program written, where we could just delete or
> comment out the Eigen stuff:
>
>
https://stackoverflow.com/questions/36959506/eigen-library-svd-is-slow-compared-to-gsl

I'll look at that later.  one thing at a time.

> If you can work something out that runs - tell me what format we need for the
> data input - CSV would be nice ;) and then we can see what this thing _does_.

first I suggest get that c++ to build, as exercise.

I did not read the article too closely but am under the impression that if one
re-assembles the functions in one source file, it'll build.  do you want to use
this code as a starting point?  if yes, then that will determine/influence the
data format.

> Can we run POV-Ray to #write trace() results to disk, and then call the c++ to
> write the SVD data to a file?  Can that c++ program then restart POV-Ray to use
> the SVD data? (have an if file exists block to switch between write data and
> read data)?

yes, in all likelihood _but_ how's your 'C', Bill?  or are you .. wedded to
'C++'?

regards, jr.

[jr] Re: bounding box calculator [2352 days 20 hours and 38 minutes ago]

Tue, 5 Nov 2019 00:20:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> ... I wrote a macro which "scans" an object's BB ...

find attached the second update of the 'Bounder'.

things have changed a little.  now, if the object's BB is found to be "(near)
optimal", the macro prints that and ends, otherwise, ie having some "slack", the
macro prints the difference lines as before, plus the optimised extents and
dimensions, as per Thomas's feedback.

also new, if "slack" is reported, two variables with the differences from the
BB's min/max extents are declared, to allow use of the info from in-scene.
after 'Bounder' has run, one can for instance:

#ifdef(Bounder_min_diff)
  // do something
#end

so.  version 3.  fingers crossed.


enjoy, jr.

[Bald Eagle] Re: bounding box calculator [2352 days 20 hours and 43 minutes ago]

Tue, 5 Nov 2019 00:15:00 GMT

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

> had a quick look, the page appears to give you the lot.

Right, it looked solid enough to pursue, though it will require a lot of
fiddling to adapt to SDL.

> thinking you ought to have a look at the GSL (GNU Scientific Library); I just
> found an index entry for singular value decomp.

I got that set up, and now need to learn how to use such things.

It appears that I have to write a c++ program and compile it, and then run it.

Looks like this guy has a short program written, where we could just delete or
comment out the Eigen stuff:

https://stackoverflow.com/questions/36959506/eigen-library-svd-is-slow-compared-to-gsl

If you can work something out that runs - tell me what format we need for the
data input - CSV would be nice ;) and then we can see what this thing _does_.

Can we run POV-Ray to #write trace() results to disk, and then call the c++ to
write the SVD data to a file?  Can that c++ program then restart POV-Ray to use
the SVD data? (have an if file exists block to switch between write data and
read data)?

[jr] Re: bounding box calculator [2353 days and 13 minutes ago]

Mon, 4 Nov 2019 20:45:02 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> ...
> So right now, I'm working off of this:
> ...
> and this:
>
https://www.codeproject.com/Articles/1268576/Singular-Values-Decomposition-SVD-In-Cplusplus11-B

had a quick look, the page appears to give you the lot.

thinking you ought to have a look at the GSL (GNU Scientific Library); I just
found an index entry for singular value decomp.

<https://www.gnu.org/software/gsl/>

regards, jr.

[Bald Eagle] Re: bounding box calculator [2353 days 1 hour and 8 minutes ago]

Mon, 4 Nov 2019 19:50:06 GMT

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

> off the top of my head, write out the points/vectors to a CSV format file, then
> either use your spreadsheet-fu or describe the the necessary actions in kinda
> pseudo code so we can discuss whether/how to implement as a script/compiled
> utility.

From what I can gather, there are several approaches to this, and most of them
are iterative - which makes the spreadsheet thing difficult.
It's been a loooong time since I've written macros for spreadsheets, and the
last mammoth spreadsheet I wrote used _zero_ macros - for "security" (you can't
complain about having to enable macros, can you?) and as a sort of little
challenge.  ;)

> quick viewed the vids.  agree with 3Blue1Brown that "confusion" arises from
> having a "shaky" understanding of the basics.  :-)  (although a frown would be
> more appropriate)
>
> so, anything .. matrix you'd have to work through with me -- bite size.

Yeah, I've been watching Grant's videos for a while, and working through the
matrix stuff and linear algebra bit by bit for a while now.  I think there's
like 14 episodes in the linear algebra series, and if you just pop them on while
you're chilling out for a while, you'll get the gist and figure out which ones
focus on specific parts that make everything clear.   I usually cycle through 2
or 3 at a time and rewatch them so I can start to put it all together.

But like I said - all of the code exists already, so it's mostly a matter of
choosing whether to call it for use as an outside routine where the results are
then used by POV-Ray, finding a way insert the relevant code to perform the SVD
into a POV-Ray fork, or converting the code to SDL where anyone can play with
it.

But since the code is complicated, I'd rather have a reliable library that we
just implement to get the right results, so that if we decide we want to do the
work of converting it, then we can compare the output to what we know is right.
Otherwise debugging will be an unimaginable nightmare.

So I think it's less "understanding what SVD does and how it works" and just
blindly getting the code that does it to work for us.  Once it reliably spits
out the right numbers, then it's a toy/tool to use to learn what and how it does
it - if you want.

I'm envisioning a test scene where we take a unit sphere and scale it by 1/2
along one axis, by 1/3 along another, and then give it a < 45deg rotation around
all three axes.
When we "Undo" the rotations with SVD (which I think is what the eigenvectors
allow us to do), we already know exactly what we should end up with - the axis
aligned, scaled sphere (ellipsoid).

Using the
VRand_On_Sphere(Stream): Returns a random vector on the surface of a unit-radius
sphere located at the origin.
from rand.inc
and applying the scaling and rotations to those points (vectors), we can run the
SVD on that data and see what it does.

> > ...
> > "This is crazy, Bill."
> > (No it's not, Thomas - the dried frog pills are _working_!!!)
>
> chorus: "Oh no, they're not."  :-)

No really - TRY SOME.   :D
"Like, dude - if you thought that sRGB with radiosity was good, wait 'till you
see THESE colors...!"   B)

> I can "see" the concept, and like it.  potential problem: registration, to get
> exact re-alignment.

Well, I wasn't so much worried about that, as with how to integrate such a thing
with the ray-object root solver code.

Take any object, matrix transform it, and then just apply the inverse, and you
get exactly what you started with.

transform { Whatever }
followed by
transform { Whatever inverse }
is the same as doing nothing.

So the idea is sorta like trying to render the side of a cube that juuuuuust
slightly rotated so that you can just barely get a glimpse of the side that
rotated toward you.   Instead of trying to squint or zoom in to get a better
look, just rotate the cube the full 90 deg, get a solid unambiguous view of that
face, and then rotate it back once you KNOW what's there.

Eventually you can push things to the point where you run into rounding and
floating point precision, and propagated error - but that's true with everything
we do now.

> I'm working myself up to trying Bill P's custom POV-Ray soon.  but yes, support
> in the program source sounds like the way forward.

Well if you get it installed, give me some tips on how to shoe-horn it onto my
system.  I'm still not so good with the github and compile-it-yourself approach
to software installation.  For most things, I cross my fingers and hope that
there's a package.

[Bald Eagle] Re: bounding box calculator [2353 days 1 hour and 53 minutes ago]

Mon, 4 Nov 2019 19:05:00 GMT

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

> need to let this info .. stew :-) for a while.  looks like BE's idea of an ini
> driven animation to explore the possible orientations and post-process results
> is a way to go.

The ini was just to showcase what you've got and point out that the initial
object orientation might not yield the tightest bounding box possible.

As a tool, I'd probably do some sort of iteration with loops, first fixing one
axis, then another, then another, and then checking to see if there's any
improvement on a second go-'round.  If there is, repeat, if not, all done.

> > - the test is also useful with hyperboloid, superellipsoid, and
> > isosurface objects. Quartic and parametric objects do no comply,
> > probably they are not 'solid'? I did not test this thoroughly.
>
> great news.  I'd initially assumed the macro would be a .. single trick pony,
> only good for CSG.

Great job Thomas - those results are surprising, given the absolute mathematical
nature of those shapes.

I would have imagined that with something like a parametric, you'd be able to
cycle through u and v real quick, and get a min and max value for each axis to
use for the AABB dimensions.   I'm also still completely mystified as to why the
parametric is such a slow-to-render object, and why the triangle approximation
isn't a source-coded native primitive.

[jr] Re: bounding box calculator [2353 days 6 hours and 48 minutes ago]

Mon, 4 Nov 2019 14:10:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> > ...
> > - I include the test scene file for you to play with.
>
> thank you v much for this.  not only do I get those natty presentation settings
> :-), but looking at the code I surmise you replaced the 'local's of the
> difference vectors with 'declare's?  that's given me another idea for an
> improvement: create two variables, 'Bounder_{min,max}_diff' and export
> ('declare') them for in-scene use.  thoughts?

d'oh!  finally got the "why".  :-)  with yr permission will add the calculator,
also will adopt the "proper" labelling in existing output.  thanks.


regards, jr.

[jr] Re: bounding box calculator [2353 days 8 hours and 28 minutes ago]

Mon, 4 Nov 2019 12:30:01 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > as I wrote, I'm game for collaboration.  if you can express the spherical
> > bounding you're thinking off as "pseudo code" at least, I'm sure we could work
> > on something.
> ...
> > that's an interesting thought, re-orienting the object.  need to think about
> > that.
> (*)  Well that's what I was getting at with the ellipsoid and the rotating
> calipers.
>
> Right now, you can imagine the the bounding box is determined in a very
> hands-off kinda way.   If you took a book that was not axis-aligned, and
> squeezed it with axis-aligned calipers, it would "straighten out" until it was
> aligned with the minimal width parallel to the axis of measurement.
> ...
> It has to do with analyzing the orientation of the vectors - the trace ()
> results that you get from your "scan".

off the top of my head, write out the points/vectors to a CSV format file, then
either use your spreadsheet-fu or describe the the necessary actions in kinda
pseudo code so we can discuss whether/how to implement as a script/compiled
utility.

> ...
> This goes by many names, but I found Singular Value Decomposition (SVD)
> but I guess there's Principal Component Analysis (PCA), Eigen Value
> Decomposition, etc.  Which can be different but are more or less equivalent and
> are often used interchangeably.
>
> Over here (1/4 to 1/3 of the way down):
> https://blog.statsbot.co/singular-value-decomposition-tutorial-52c695315254
> he says, "Suppose we have two, two-dimensional vectors, x₁=(x₁,
> y₁), and x₂=(x₂, y₂). We can fit an ellipse with major
> axis, a, and minor axis, b, to these two vectors as shown in the figure."
>
> And then look here at the 7:00 mark:
> https://www.youtube.com/watch?v=_4jaLZCoLPI
>
>
https://www.youtube.com/watch?v=PFDu9oVAE-g&list=PLZHQObOWTQDPD3MizzM2xVFitgF8hE_ab&index=14

quick viewed the vids.  agree with 3Blue1Brown that "confusion" arises from
having a "shaky" understanding of the basics.  :-)  (although a frown would be
more appropriate)

so, anything .. matrix you'd have to work through with me -- bite size.

> ...
> "This is crazy, Bill."
> (No it's not, Thomas - the dried frog pills are _working_!!!)

chorus: "Oh no, they're not."  :-)

> Well, yes - and no.  Because I can already see an application to your sphere
> slicing troubles in POV-Ray, the existing root-finding problems that Bill
> Pokorny is grappling with, and SVD.
>
> If the problem with your sphere slicing arises from root-finding troubles that
> POV-Ray experiences when trying to solve for rays that are parallel, or nearly
> so, to the object surface, then maybe if you added a "wiggle" to the object,
> solved for the root, and then unwiggled the intersection before rendering the
> result - then you'd get better renders with less holes.

I can "see" the concept, and like it.  potential problem: registration, to get
exact re-alignment.

> So if we implemented it in source - them maybe it could be applied to solve a
> lot of long-standing, underlying problems.  Or something like it.

I'm working myself up to trying Bill P's custom POV-Ray soon.  but yes, support
in the program source sounds like the way forward.

> ...


regards, jr.

[jr] Re: bounding box calculator [2353 days 8 hours and 28 minutes ago]

Mon, 4 Nov 2019 12:30:00 GMT

hi,

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 03/11/2019 om 16:40 schreef jr:
> > "Bald Eagle" <cre### [at] netscapenet> wrote:
> >>>>> ... I wrote a macro which "scans" an object's BB ...
> >>>> find attached an updated version of 'Bounder'.
> > ...
> A few thoughts derived from this.
>
> - rotating the object changes the 'tightness' of the standard BB. I did
> that with a simple cylinder: when properly aligned along one of the
> axis, the BB test is always optimal; rotate the cylinder (e.g.
> <45,45,45>) and do the test, and the standard BB becomes too wide.

need to let this info .. stew :-) for a while.  looks like BE's idea of an ini
driven animation to explore the possible orientations and post-process results
is a way to go.

> - the test is also useful with hyperboloid, superellipsoid, and
> isosurface objects. Quartic and parametric objects do no comply,
> probably they are not 'solid'? I did not test this thoroughly.

great news.  I'd initially assumed the macro would be a .. single trick pony,
only good for CSG.

> - I include the test scene file for you to play with.

thank you v much for this.  not only do I get those natty presentation settings
:-), but looking at the code I surmise you replaced the 'local's of the
difference vectors with 'declare's?  that's given me another idea for an
improvement: create two variables, 'Bounder_{min,max}_diff' and export
('declare') them for in-scene use.  thoughts?

regards, jr.

[Thomas de Groot] Re: bounding box calculator [2353 days 12 hours and 49 minutes ago]

Mon, 4 Nov 2019 08:09:16 GMT

Op 03/11/2019 om 16:40 schreef jr:
> hi,
> 
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>>>>> ... I wrote a macro which "scans" an object's BB ...
>>>> find attached an updated version of 'Bounder'.
>>
>> So - those are pretty impressive differences between what POV-Ray does and what
>> you trim it down to!  :O
> 
> agree.  for the Boy's Surface which got me going, the BB went from 11^3 units to
> 8.2^3, a reduction of well over 50%.
> 
>> The methods I suggested are probably too complex to see any implementation any
>> time soon, but maybe if someone who reads and translates c++ or other languages
>> into SDL faster (and more accurately) than I can, converts a script or two -
>> then it would be a powerful tool for this as well as point clouds and other
>> tasks.
>> I doubt they'd be included into source - but I can dream a little.
> 
> as I wrote, I'm game for collaboration.  if you can express the spherical
> bounding you're thinking off as "pseudo code" at least, I'm sure we could work
> on something.
> 
>> I'm curious about how your BB compares to the native one aside from just size.
>> Does it shift?
>> Does the center move?  Is the space on either side equal for all 3 axes?
>> Presumably your bounding box is TIGHT - if you difference away an inverse box,
>> do you get points of overlap / coincident surfaces?
>> I'm just wondering if you ought to include a tiny buffer of 2x10E-6 or whatever
>> the safe distance is on either side, depending on usage.
> 
> the algorithm goes something like this, for each axis:
>    - using the resolution, work out the required axis scan increments.
>    - work along the scan axis until you hit the object:
>      - scan the "face" looking +axis.  if no inside() test succeeded, remember
>        that face as outside.
>      - scan the "face" looking -axis.  as above.
> 
> the advantage is that the last stored coords are always outside of the object.
> the art, I guess, will be finding the lowest resolution "good" for the object.
> (low res like for the Boy's Surface wouldn't work for, say, a model of a sea
> urchin, where one would presumably miss many of the spikes)
> 
>> Maybe have a switch in the macro call to omit or include that buffer space.
> 
> the 'Bounder' is only meant to give you (the user) guide figures, by up to which
> you can tighten the BB if useful.
> 
>> Perhaps an interesting addition would be to add an animation .ini file that
>> rotates the CSG object around an axis by some fraction of 45 degrees and then
>> does the analysis - to see if the _AA_BB gets any smaller.
> 
> that's an interesting thought, re-orienting the object.  need to think about
> that.
> 
>> Pretty nice work, and a striking demonstration of how much empty space an
>> automatically generated bounding box can have.
>> I knew there was some, but:   WOW.
> 
> yeah, Thomas's "reference"-style image did that for me too.  :-)
> 
>> I can see this being really useful for BB dependent operations like scanning
>> with trace (), and probably a few others that I can't clearly envision at the
>> moment.  Basically anywhere that a lot of ray-object intersections need to be
>> tested.
> 
> gut feeling: scenes with a number of CSG shapes with "difficult" materials, like
> glass, will benefit.  also, after a first glance, 'blob' shapes too look like
> good candidates.
> 

A few thoughts derived from this.

- rotating the object changes the 'tightness' of the standard BB. I did 
that with a simple cylinder: when properly aligned along one of the 
axis, the BB test is always optimal; rotate the cylinder (e.g. 
<45,45,45>) and do the test, and the standard BB becomes too wide.

- the test is also useful with hyperboloid, superellipsoid, and 
isosurface objects. Quartic and parametric objects do no comply, 
probably they are not 'solid'? I did not test this thoroughly.

- I include the test scene file for you to play with.
-- 
Thomas

[jr] Re: bounding box calculator [2354 days 2 hours and 23 minutes ago]

Sun, 3 Nov 2019 18:35:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > as I wrote, I'm game for collaboration.  if you can express the spherical
> > bounding you're thinking off as "pseudo code" at least, I'm sure we could work
> > on something.
>
> So the issues I'm running into currently, are that SDL doesn't have the syntax
> needed to replicate statements in python or c++, or POV-Ray simply doesn't have
> the ability to perform certain of the operations.

unfortunately I'll not be much help there, I do not speak c++ nor python.
however, the SDL is Turing complete aiui.  (though too cumbersome for all sorts
of stuff)

> So I need to interpret certain statements to first even understand what they do,
>
http://news.povray.org/povray.programming/thread/%3Cweb.5db79f027e60be924eec112d0%40news.povray.org%3E/
>
> and then rewrite those parts in a way that can be performed in SDL.
>
> for (std::uint32_t row = 0; row < m_size && (index % 100) == 0; row++)
>
> m[row].resize(m[row].size() + 100);
>
> etc.

what is it you're doing that requires a row to grow?


> That's why I figured using the existing, working, tested libraries in c++,
> python, Fortran, Ruby, R, Matlab, etc. would be fastest and most reliable.
>
> I mean I could be wrong, but I think it would pay dividends.
>
> And I still can't understand why the value of the FFT isn't understood.  ALL of
> the major graphics packages use FFT for myriad effects, edge detection, etc...

back to the subject on hand.  the problem would be having to scan points on the
surface of a sphere, with some precision/resolution, followed by consecutively
smaller spheres, until "contact".  what did I miss?


regards, jr.

[Bald Eagle] Re: bounding box calculator [2354 days 2 hours and 58 minutes ago]

Sun, 3 Nov 2019 18:00:01 GMT

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

> as I wrote, I'm game for collaboration.  if you can express the spherical
> bounding you're thinking off as "pseudo code" at least, I'm sure we could work
> on something.

So the issues I'm running into currently, are that SDL doesn't have the syntax
needed to replicate statements in python or c++, or POV-Ray simply doesn't have
the ability to perform certain of the operations.

So I need to interpret certain statements to first even understand what they do,

http://news.povray.org/povray.programming/thread/%3Cweb.5db79f027e60be924eec112d0%40news.povray.org%3E/

and then rewrite those parts in a way that can be performed in SDL.

for (std::uint32_t row = 0; row < m_size && (index % 100) == 0; row++)

m[row].resize(m[row].size() + 100);

etc.

That's why I figured using the existing, working, tested libraries in c++,
python, Fortran, Ruby, R, Matlab, etc. would be fastest and most reliable.

I mean I could be wrong, but I think it would pay dividends.

And I still can't understand why the value of the FFT isn't understood.  ALL of
the major graphics packages use FFT for myriad effects, edge detection, etc...

[Bald Eagle] Re: bounding box calculator [2354 days 3 hours and 13 minutes ago]

Sun, 3 Nov 2019 17:45:00 GMT

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

> as I wrote, I'm game for collaboration.  if you can express the spherical
> bounding you're thinking off as "pseudo code" at least, I'm sure we could work
> on something.

See below (*)

> the art, I guess, will be finding the lowest resolution "good" for the object.
> (low res like for the Boy's Surface wouldn't work for, say, a model of a sea
> urchin, where one would presumably miss many of the spikes)

That sounds like something that one of those space-partitioning algorithms might
be useful for.
On the other hand - if the primitives are mathematical equations, then in thory
one should already know where the object is, and this searching in the dark with
rays is not the way to go.
How _exactly_ to do it differently might be why people have taken to ray
marching instead of raytracing.

I think we could use a hybrid to speed up the initial search with a ray march
type phase, and then do the fine tuning / final result with the ray tracing.

> that's an interesting thought, re-orienting the object.  need to think about
> that.

(*)  Well that's what I was getting at with the ellipsoid and the rotating
calipers.

Right now, you can imagine the the bounding box is determined in a very
hands-off kinda way.   If you took a book that was not axis-aligned, and
squeezed it with axis-aligned calipers, it would "straighten out" until it was
aligned with the minimal width parallel to the axis of measurement.

Of course, we can see how difficult it is for POV-Ray to even do the plain old
hands-off AABB determination, so how does one mathemagically determine not only
the bounding box - but one that is the tightest fit, given that the object may
be "UNaligned"?

The answer to that lies in what I envisioned, and has been worked out and
implemented by those clever people out there.

It has to do with analyzing the orientation of the vectors - the trace ()
results that you get from your "scan".

So, just think about how you'd center an off-axis sphere.
You'd add up the vectors to get an average, which would be the off-axis center
of the sphere, and then translate that in the opposite direction in order to
place it at the origin.

So far so good.

If we have a non symmetric shape, however, we need to also rotate it so that the
minimum widths (if there is one) are along the cardinal axes.

So now we just look for rotational fixes rather than a translational one.

Don't get bogged down in the details.  Just think about it like a linear
regression or a curve-fitting thing on a calculator or in a spreadsheet.
It works, it's used _all the time_ everywhere, from IQ scores to search engine
results, to Facebook and Twitter ranking algorithms, to product and video
suggestions, to facial recognition and machine learning.

The way to do this, unfortunately, or perhaps fortunately, is with matrices.
And I always return to these, I guess because they are so fundamental to what we
do with computer graphics and solid geometry.

So the gist is,
1. we enclose the CSG thing in a bounding sphere.
2. we then shrink an axis of the sphere until we touch the CSG
     but the narrowest part may not be on a principal axis,
     so we just do it until we get whatever axis is the narrowest way
     we can do it.
3. do that to the remaining axis (because the original sphere is already
     defined by the largest axis of the final ellipsoid
4. Now look at the rotation of those ellipsoidal axes and align them
     with x, y, and z

But it's accomplished in a much more straightforward manner using the raw
vectors.

This goes by many names, but I found Singular Value Decomposition (SVD)
but I guess there's Principal Component Analysis (PCA), Eigen Value
Decomposition, etc.  Which can be different but are more or less equivalent and
are often used interchangeably.

Over here (1/4 to 1/3 of the way down):
https://blog.statsbot.co/singular-value-decomposition-tutorial-52c695315254
he says, "Suppose we have two, two-dimensional vectors, x₁=(x₁,
y₁), and x₂=(x₂, y₂). We can fit an ellipse with major
axis, a, and minor axis, b, to these two vectors as shown in the figure."

And then look here at the 7:00 mark:
https://www.youtube.com/watch?v=_4jaLZCoLPI

https://www.youtube.com/watch?v=PFDu9oVAE-g&list=PLZHQObOWTQDPD3MizzM2xVFitgF8hE_ab&index=14

So apparently there are libraries that exist to do this reliably, and maybe just
a c++ script could be run to analyze the data and then spit out the rotation
vectors for POV-Ray to use in the scene.

Or some maniac could convert it to SDL just for funsies.

(This is usually where TOK pops in and mentions that he coded this on a lark way
back in 2004 and didn't think anyone would be interested or find it useful or
something...  ;)  )

"This is crazy, Bill."
(No it's not, Thomas - the dried frog pills are _working_!!!)

Well, yes - and no.  Because I can already see an application to your sphere
slicing troubles in POV-Ray, the existing root-finding problems that Bill
Pokorny is grappling with, and SVD.

If the problem with your sphere slicing arises from root-finding troubles that
POV-Ray experiences when trying to solve for rays that are parallel, or nearly
so, to the object surface, then maybe if you added a "wiggle" to the object,
solved for the root, and then unwiggled the intersection before rendering the
result - then you'd get better renders with less holes.

So if we implemented it in source - them maybe it could be applied to solve a
lot of long-standing, underlying problems.  Or something like it.

Essentially, why look at it parallel, when you could rotate it 90 degrees, look
at it perpendicularly, and then rotate it back.  I don't know if that possible
or realistic in the forest of the source code, but it's not far off from the
camera pigment function {} stuff that he's proposing.

So right now, I'm working off of this:
https://github.com/minillinim/ellipsoid/blob/master/ellipsoid.py
and this:
https://www.codeproject.com/Articles/1268576/Singular-Values-Decomposition-SVD-In-Cplusplus11-B

and one of the popular libraries used for this kind of thing is:
https://github.com/opencollab/arpack-ng

It's also available in numpy
https://towardsdatascience.com/pca-and-svd-explained-with-numpy-5d13b0d2a4d8

From:
https://stats.stackexchange.com/questions/159325/what-fast-algorithms-exist-for-computing-truncated-svd

"All reasonable programming languages and statistic packages (Matlab, R, Python
numpy, you name it) use the same Fortran libraries to perform
eigen/singular-value decompositions. These are LAPACK and ARPACK. ARPACK stands
for ARnoldi PACKage, and it's all about Arnoldi/Lanczos iterations. E.g. in
Matlab there are two functions for SVD: svd performs full decomposition via
LAPACK, and svds computes a given number of singular vectors via ARPACK and it
is actually just a wrapper for an eigs call on the "square-ized" matrix."

[jr] Re: bounding box calculator [2354 days 5 hours and 13 minutes ago]

Sun, 3 Nov 2019 15:45:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> > >> ... I wrote a macro which "scans" an object's BB ...
> > > find attached an updated version of 'Bounder'.
>
> So - those are pretty impressive differences between what POV-Ray does and what
> you trim it down to!  :O

agree.  for the Boy's Surface which got me going, the BB went from 11^3 units to
8.2^3, a reduction of well over 50%.

> The methods I suggested are probably too complex to see any implementation any
> time soon, but maybe if someone who reads and translates c++ or other languages
> into SDL faster (and more accurately) than I can, converts a script or two -
> then it would be a powerful tool for this as well as point clouds and other
> tasks.
> I doubt they'd be included into source - but I can dream a little.

as I wrote, I'm game for collaboration.  if you can express the spherical
bounding you're thinking off as "pseudo code" at least, I'm sure we could work
on something.

> I'm curious about how your BB compares to the native one aside from just size.
> Does it shift?
> Does the center move?  Is the space on either side equal for all 3 axes?
> Presumably your bounding box is TIGHT - if you difference away an inverse box,
> do you get points of overlap / coincident surfaces?
> I'm just wondering if you ought to include a tiny buffer of 2x10E-6 or whatever
> the safe distance is on either side, depending on usage.

the algorithm goes something like this, for each axis:
  - using the resolution, work out the required axis scan increments.
  - work along the scan axis until you hit the object:
    - scan the "face" looking +axis.  if no inside() test succeeded, remember
      that face as outside.
    - scan the "face" looking -axis.  as above.

the advantage is that the last stored coords are always outside of the object.
the art, I guess, will be finding the lowest resolution "good" for the object.
(low res like for the Boy's Surface wouldn't work for, say, a model of a sea
urchin, where one would presumably miss many of the spikes)

> Maybe have a switch in the macro call to omit or include that buffer space.

the 'Bounder' is only meant to give you (the user) guide figures, by up to which
you can tighten the BB if useful.

> Perhaps an interesting addition would be to add an animation .ini file that
> rotates the CSG object around an axis by some fraction of 45 degrees and then
> does the analysis - to see if the _AA_BB gets any smaller.

that's an interesting thought, re-orienting the object.  need to think about
that.

> Pretty nice work, and a striking demonstration of how much empty space an
> automatically generated bounding box can have.
> I knew there was some, but:   WOW.

yeah, Thomas's "reference"-style image did that for me too.  :-)

> I can see this being really useful for BB dependent operations like scanning
> with trace (), and probably a few others that I can't clearly envision at the
> moment.  Basically anywhere that a lot of ray-object intersections need to be
> tested.

gut feeling: scenes with a number of CSG shapes with "difficult" materials, like
glass, will benefit.  also, after a first glance, 'blob' shapes too look like
good candidates.

> This is solid.

merci bien.

regards, jr.

[Bald Eagle] Re: bounding box calculator [2354 days 6 hours and 8 minutes ago]

Sun, 3 Nov 2019 14:50:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:

> >> ... I wrote a macro which "scans" an object's BB ...
> >
> > find attached an updated version of 'Bounder'.

So - those are pretty impressive differences between what POV-Ray does and what
you trim it down to!  :O

The methods I suggested are probably too complex to see any implementation any
time soon, but maybe if someone who reads and translates c++ or other languages
into SDL faster (and more accurately) than I can, converts a script or two -
then it would be a powerful tool for this as well as point clouds and other
tasks.
I doubt they'd be included into source - but I can dream a little.

I'm curious about how your BB compares to the native one aside from just size.
Does it shift?
Does the center move?  Is the space on either side equal for all 3 axes?
Presumably your bounding box is TIGHT - if you difference away an inverse box,
do you get points of overlap / coincident surfaces?
I'm just wondering if you ought to include a tiny buffer of 2x10E-6 or whatever
the safe distance is on either side, depending on usage.

Maybe have a switch in the macro call to omit or include that buffer space.

Perhaps an interesting addition would be to add an animation .ini file that
rotates the CSG object around an axis by some fraction of 45 degrees and then
does the analysis - to see if the _AA_BB gets any smaller.

Pretty nice work, and a striking demonstration of how much empty space an
automatically generated bounding box can have.
I knew there was some, but:   WOW.

I can see this being really useful for BB dependent operations like scanning
with trace (), and probably a few others that I can't clearly envision at the
moment.  Basically anywhere that a lot of ray-object intersections need to be
tested.

This is solid.

[jr] Re: bounding box calculator [2354 days 6 hours and 58 minutes ago]

Sun, 3 Nov 2019 14:00:02 GMT

hi,

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 29/10/2019 om 15:09 schreef jr:
> > "jr" <cre### [at] gmailcom> wrote:
> >> ... I wrote a macro which "scans" an object's BB ...
> > find attached an updated version of 'Bounder'.
> > ...
> I suggest you change the wording in line 125, from:
> bndr_emit3V("object aligned (BB) max",dims_,6)
> into:
> bndr_emit3V("object aligned (BB) dimension",dims_,6)
> I suppose that was an overlook ;-)

yes, another one.  :-)  thanks.  after some thought I've changed it to "BB
aligned dimensions".  also, I've removed the parentheses in the lines above in
output, and the dashed line above the 'difference' lines.  I shall wait a few
days before posting a final version, in case other improvements get suggested.

regards, jr.

[Thomas de Groot] Re: bounding box calculator [2354 days 12 hours and 25 minutes ago]

Sun, 3 Nov 2019 08:33:38 GMT

Op 29/10/2019 om 15:09 schreef jr:
> "jr" <cre### [at] gmailcom> wrote:
>> ... I wrote a macro which "scans" an object's BB ...
> 
> find attached an updated version of 'Bounder'.
> 
> the changes are largely cosmetic, I've tried to make the output less confusing,
> and now refer to "inside() calls" instead of "probes" etc.  under the hood I
> managed to tighten things up a bit, removing a few variables and ..
> embarrassments.
> 

I suggest you change the wording in line 125, from:

bndr_emit3V("object aligned (BB) max",dims_,6)

into:

bndr_emit3V("object aligned (BB) dimension",dims_,6)

I suppose that was an overlook ;-)

-- 
Thomas

[jr] Re: bounding box calculator [2359 days 6 hours and 43 minutes ago]

Tue, 29 Oct 2019 14:15:01 GMT

"jr" <cre### [at] gmailcom> wrote:
> ... I wrote a macro which "scans" an object's BB ...

find attached an updated version of 'Bounder'.

the changes are largely cosmetic, I've tried to make the output less confusing,
and now refer to "inside() calls" instead of "probes" etc.  under the hood I
managed to tighten things up a bit, removing a few variables and ..
embarrassments.


enjoy, jr.

[jr] Re: bounding box calculator [2360 days 6 hours and 48 minutes ago]

Mon, 28 Oct 2019 14:10:01 GMT

hi,

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 27/10/2019 om 16:00 schreef jr:
> > ... a macro which ...
>
> Thanks! I am certainly going to play with this useful little toy.

thank you for giving it a try.  since it is a WIP, feedback on the .. user
"experience", problems etc will be valuable.

> I second Bald Eagle's suggestion about additional wireframes. I am a
> visual guy, and such things would help me no end.

that makes three if us.  :-)  blame POV-Ray (really, I mean it).  so I use a "X
Windows" environment, and here's provision for the following: I write a small UI
utility 'A' which can make use of the abilities of program 'B', so in 'A' I
create an empty frame (window) and when I run 'B' I tell it btw, here's a handle
to a window, please display yourself in that, and voila.  alas, the 3.6.x
versions of POV-Ray were the last "good X Windows citizens", since then it has
yoked itself to the SDL, a multimedia+gaming "sub-system", which doesn't play by
the same rules.  </rant>

however, I'd be happy to cooperate on solutions, if you (and or Bald Eagle) can
see a way to utilise the 'Bounder' output.

regards, jr.

[Thomas de Groot] Re: bounding box calculator [2360 days 12 hours and 38 minutes ago]

Mon, 28 Oct 2019 08:20:10 GMT

Op 27/10/2019 om 16:00 schreef jr:
> as part of some stuff I'm playing with, I noticed that the bounding box of the
> "Boy's Surface"[1] contains a lot of .. air.:-)   after reading up on things, I
> wrote a macro which "scans" an object's BB to find the actual dimensions (using
> 'inside()' tests), and print out information about how much "slack" is found[2]
> between object and bounding box face(s).
> 

Thanks! I am certainly going to play with this useful little toy. I 
second Bald Eagle's suggestion about additional wireframes. I am a 
visual guy, and such things would help me no end.

-- 
Thomas

[jr] Re: bounding box calculator [2360 days 21 hours and 53 minutes ago]

Sun, 27 Oct 2019 23:05:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > I've tested the code with a handful of different objects, and so far, so good.
> > perhaps someone else will find use(s) for it too.  it is a work in progress
> > though, and it would be nice if one or two wanted to be "guinea pigs", beta
> > test, and help find bugs/problems, suggest improvements.
>
> Sounds nice.

ah.  'useful' is the adjective I was [fw]ishing for.  ;-)

> ...
> First, maybe add the option of making two wireframe AA-BB's - the original, and
> the optimized so that the result can be seen in a render.

future stuff, perhaps.  :-)  the idea is simply to get guide figures to tighten
the bounds if wanted/necessary.

> Second - this is dealing with axis-aligned bounding boxes, which immediately
> brings up a million questions about what if I have a long, narrow box that's at
> 45 degrees to 2 axes .... is there some way to optimize the orientation of the
> object itself.

no.  the object is where it is.  a copy of the object is aligned to origin to
make the calculations .. bearable.  (up to) the diff figures can be then be
applied to the original.

"optimise the orientation" in which way?  not sure I understand.

> Especially if you try to apply this to an infinitely long cylinder, or plane,
> or....

yeah.  as I wrote, the macro uses 'inside()' to do the probing, with all that
implies.  in the end though one has to trust the user to know not to drive
screws with a hammer.

> ...
> ;)  Well, - what if we try to calculate a bounding _sphere_ ...

too advanced for me.  (as are your references in the other two follow-ups I
read)

> ...

regards ,jr.

[Bald Eagle] Re: bounding box calculator [2360 days 22 hours and 48 minutes ago]

Sun, 27 Oct 2019 22:10:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:

> we squish that sphere into a spheroid or ellipsoid?
> Graph those results.   Look at them.   I'm sure they'll say something.
> Just like the trace level on the NMR, we'd be looking for a global _minimum_ on
> each of the axes of the ellipsoid, that tightly girdle the shape.
> Then you'd have 3 axes of the ellipsoid,

Sounds great, Bill.
Some folks already did that, like 30 years ago...
Good job...

http://geomalgorithms.com/a08-_containers.html
"Nevertheless, especially in higher dimensions, the bounding ellipsoid is
superior to the minimal cuboid in many ways. It is unique, whereas the minimal
cuboid is not. There is a reasonable algorithm to implement it. And it is a good
approximation of the object it contains, much better than the minimal cuboid."

https://www.ics.uci.edu/~eppstein/junkyard/rcg.html

https://inf.ethz.ch/personal/emo/PublFiles/SmallEnclDisk_LNCS555_91.pdf

[Bald Eagle] Re: bounding box calculator [2360 days 23 hours and 43 minutes ago]

Sun, 27 Oct 2019 21:15:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:

> I always get the feeling that we might be trying to reinvent some wheel that may
> exist - somewhere, out there -

Like this:

https://www.geometrictools.com/Documentation/MinimumVolumeBox.pdf

from:

https://www.geometrictools.com/Source/ComputationalGeometry.html

[Bald Eagle] Re: bounding box calculator [2361 days and 23 minutes ago]

Sun, 27 Oct 2019 20:35:06 GMT

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

> I've tested the code with a handful of different objects, and so far, so good.
> perhaps someone else will find use(s) for it too.  it is a work in progress
> though, and it would be nice if one or two wanted to be "guinea pigs", beta
> test, and help find bugs/problems, suggest improvements.

Sounds nice.
It brings to mind some of the stuff I've played with concerning isosurfaces,
parametrics, creating meshes from objects in SDL, and working with the camera
view frustum.

First, maybe add the option of making two wireframe AA-BB's - the original, and
the optimized so that the result can be seen in a render.

Second - this is dealing with axis-aligned bounding boxes, which immediately
brings up a million questions about what if I have a long, narrow box that's at
45 degrees to 2 axes .... is there some way to optimize the orientation of the
object itself.
Especially if you try to apply this to an infinitely long cylinder, or plane,
or....

I always get the feeling that we might be trying to reinvent some wheel that may
exist - somewhere, out there - in RenderMan or Blender, or Grasshopper, or Maya,
or....

I used to shim nuclear magnetic resonance spectrometers to get a good clean
spectrum and a high signal-to-noise ratio.  But there were lots of knobs for
strange "axes" of the magnetic field, and we only had a "trace" signal that went
up or down.
(28 shims available, which are on-axis: Z1, Z2, Z3, Z4, Z5, Z6 and off-axis: X,
Y, XZ, YZ, XZ2, YZ2, XZ3, YZ3, XZ4, YZ4, X2-Y2, XY, (X2-Y2)Z, XYZ, (X2-Y2)Z2,
XYZ2, (X2-Y2)Z3, XYZ3, X3, Y3, X3Z, Y3Z
So we were flying blind around this N-dimensional field, and you had to stay
aware of the fact that just because the signal went up didn't mean for sure that
the shim settings were getting better - because it might just be a local maximum
that wasn't as high as the global maximum, and you might want to traverse a
region in a local minimum in order to get over to that global maximum - so
sometimes a weaker signal was good - in the short run.

"So what, Bill, you incoherent maniac?"

;)  Well, - what if we try to calculate a bounding _sphere_ from a set of
trace() results, and then run another series of traces or insidedness tests when
we squish that sphere into a spheroid or ellipsoid?
Graph those results.   Look at them.   I'm sure they'll say something.
Just like the trace level on the NMR, we'd be looking for a global _minimum_ on
each of the axes of the ellipsoid, that tightly girdle the shape.
Then you'd have 3 axes of the ellipsoid, and could orient those axes to the
global axes, and THEN do the AABB.

I really need to go through things like the Graphics Gems series, (and IIRC
there is a GPU Gems series as well,) that may have some great algorithms that we
can use.

[jr] bounding box calculator [2361 days 5 hours and 53 minutes ago]

Sun, 27 Oct 2019 15:05:01 GMT

hi,

as part of some stuff I'm playing with, I noticed that the bounding box of the
"Boy's Surface"[1] contains a lot of .. air.  :-)  after reading up on things, I
wrote a macro which "scans" an object's BB to find the actual dimensions (using
'inside()' tests), and print out information about how much "slack" is found[2]
between object and bounding box face(s).

[1]
<http://news.povray.org/povray.general/thread/%3Cweb.5b1bb8bbb1f83992458c7afe0%40news.povray.org%3E/>

[2] v basic still.  only distinguishes three scenarios: up to 1% space all
around, up to 5%, and over 5%.

I've tested the code with a handful of different objects, and so far, so good.
perhaps someone else will find use(s) for it too.  it is a work in progress
though, and it would be nice if one or two wanted to be "guinea pigs", beta
test, and help find bugs/problems, suggest improvements.

there is no documentation apart from a few header lines in the .inc, but the
macro is easy to use:

  macro Bounder(object, optional resolution)

where object is some object identifier, and the resolution an integer, or a
3-vector of ints, giving the number of "probes" per POV unit.

the simplest usage example is something like:
-----<snip>-----
#version 3.8;
global_settings {...}
#declare O = cylinder {...};
#include "bounder.inc"
Bounder(O,)
-----<snip>-----

uses the default resolution <50,50,50>.

the cut'n'paste stuff below shows the before and after for the 'boy-file.pov'
(with minimal adaptations, and renamed), with timings.  the difference is that
for the second run I'd added a 'clipped_by {box {}}' calculated from the values
in the "diff" lines, and a 'bounded_by {clipped_by}', as suggested in the docs.


enjoy, jr.

-----<snip>-----
the 'povparse' command is a BASH alias, shown here in case it's of interest to a
Linux user, useful when only the '#debug' output matters:
  alias povparse='nice -n 19 povray -w32 -h32 -D -F -GS -GR +i'


Script started on Sun 27 Oct 2019 12:16:05 GMT
jr@crow:1:bounder$ time povparse bta.pov
Persistence of Vision(tm) Ray Tracer Version 3.8.0-alpha.10013324.unofficial
  ...
==== [Parsing...] ==========================================================
----------[Bounder info]------------------------------------------------
  resolutions (per POV unit): <20, 20, 20>
     object "as is" (BB) min: <-6.000000, -6.000000, -6.000000>
     object "as is" (BB) max: <5.000000, 5.000000, 5.000000>
     object aligned (BB) max: <11.000000, 11.000000, 11.000000>
    axis 'X' scan resolution: 220
             probes per face: 48400
         scan axis increment: 0.05000000
          face col increment: 0.05000000
          face row increment: 0.05000000
                           -: ...scanning...
Parsing 140263K tokens
              total # probes: 3000800
    axis 'Y' scan resolution: 220
             probes per face: 48400
         scan axis increment: 0.05000000
          face col increment: 0.05000000
          face row increment: 0.05000000
                           -: ...scanning...
Parsing 289350K tokens
              total # probes: 3049200
    axis 'Z' scan resolution: 220
             probes per face: 48400
         scan axis increment: 0.05000000
          face col increment: 0.05000000
          face row increment: 0.05000000
                           -: ...scanning...
Parsing 432765K tokens
              total # probes: 3000800
    --------------------
            diff lower bound: 1.95000000,2.00000000,1.95000000
            diff upper bound: 0.95000000,0.95000000,0.95000000
  object bounding box has at least 5% "slack".
------------------------------------------------------------------------
==== [Rendering...] ========================================================
Rendered 1024 of 1024 pixels (100%)
POV-Ray finished

real 1m37.487s
user 1m36.884s
sys 0m0.041s


Script started on Sun 27 Oct 2019 12:18:31 GMT
jr@crow:4:bounder$ time povparse bt2.pov
Persistence of Vision(tm) Ray Tracer Version 3.8.0-alpha.10013324.unofficial
   ...
==== [Parsing...] ==========================================================
----------[Bounder info]------------------------------------------------
  resolutions (per POV unit): <20, 20, 20>
     object "as is" (BB) min: <-4.100000, -4.100000, -4.100000>
     object "as is" (BB) max: <4.100000, 4.100000, 4.100000>
     object aligned (BB) max: <8.200000, 8.200000, 8.200000>
    axis 'X' scan resolution: 164
             probes per face: 26896
         scan axis increment: 0.05000000
          face col increment: 0.05000000
          face row increment: 0.05000000
                           -: ...scanning...
Parsing 4616K tokens
              total # probes: 161376
    axis 'Y' scan resolution: 164
             probes per face: 26896
         scan axis increment: 0.05000000
          face col increment: 0.05000000
          face row increment: 0.05000000
                           -: ...scanning...
Parsing 9246K tokensParsing 13950K tokens
              total # probes: 161376
    axis 'Z' scan resolution: 164
             probes per face: 26896
         scan axis increment: 0.05000000
          face col increment: 0.05000000
          face row increment: 0.05000000
                           -: ...scanning...
Parsing 18627K tokensParsing 23261K tokens
              total # probes: 161376
    --------------------
            diff lower bound: 0.05000000,0.05000000,0.05000000
            diff upper bound: 0.05000000,0.05000000,0.05000000
  object bounding box is (near) optimal.
------------------------------------------------------------------------
==== [Rendering...] ========================================================
Rendered 1024 of 1024 pixels (100%)
POV-Ray finished

real 0m5.896s
user 0m5.236s
sys 0m0.006s

[jr] features suggestion (Bald Eagle) [2392 days 23 hours and 48 minutes ago]

Wed, 25 Sep 2019 21:10:06 GMT

[Bald Eagle] Re: nice knots [2396 days 22 hours and 38 minutes ago]

Sat, 21 Sep 2019 22:20:00 GMT

dick balaska <dic### [at] buckosoftcom> wrote:

> Try
> http://www.oocities.org/ccolefax/spline/index.html

Nope.   Nonexistent file.

Here:
http://knotilus.math.uwo.ca/doc/downloadtypes.html

[dick balaska] Re: nice knots [2397 days and 10 minutes ago]

Sat, 21 Sep 2019 20:48:43 GMT

On 9/21/19 8:48 AM, Bald Eagle wrote:
> Very cool.
> 
> Where does one find "spline.mcr" ?
> 

Awesome knots!

Try
http://www.oocities.org/ccolefax/spline/index.html

-- 
dik
Rendered 1024 of 921600 pixels (0%)

[Bald Eagle] Re: nice knots [2397 days 8 hours and 8 minutes ago]

Sat, 21 Sep 2019 12:50:01 GMT

Very cool.

Where does one find "spline.mcr" ?

[Norbert Kern] nice knots [2398 days 5 hours and 8 minutes ago]

Fri, 20 Sep 2019 15:50:01 GMT

// http://knotilus.math.uwo.ca/gallery/

#version 3.7;

#declare RAD = 4;

global_settings {
        #declare a_g = 2.2;
        assumed_gamma a_g
        max_trace_level 5
        noise_generator 2
        #if(RAD > 0)
                radiosity {
                        pretrace_start 0.08
                        pretrace_end 0.04/RAD
                        count 30*RAD
                        nearest_count min (20, RAD)
                        error_bound 2/RAD
                        low_error_factor 0.5
                        recursion_limit 1
                        gray_threshold 0
                        minimum_reuse 0.015
                        brightness 1
                        adc_bailout 0.005
                        normal on
                        media on
                }
        #end
}

#include "stdinc.inc"

#declare fac = 1;

sky_sphere {
        pigment {color rgb <0.5,0.5,0.5>}
        pigment {
                average
                pigment_map {
                        [1      function {max (min (y, 1), 0)}
                                color_map {
                                        [0      rgb fac*2.35]
                                        [0.96   rgb fac*4.5]
                                        [1      rgb fac*13.5]
                                }
                        ]
                        [1      function {max (min (y, 1), 0)}
                                turbulence 0.2
                                color_map {
                                        [0      rgbt 1]
                                        [0.5    rgbt
<fac*0.385,fac*0.77,fac*1.1,1>]
                                }
                                rotate z*-45
                        ]
                }
        }
        rotate <60,0,0>
}

light_source {
        <0, 300, -500>
        color rgb <1,1,1>
        area_light <80, 0, 0>, <0, 80, 0>, 10, 10 adaptive 0 jitter circular
orient
}

camera {
        location <0, 0, -550>
        look_at <-70, 0, 0>
        angle 64*image_width/image_height*0.7
        right x*16/9
}

// knot material
________________________________________________________________________________

// Norbert Kern  varnish test
http://news.povray.org/povray.binaries.images/message/%3C3d9d5b1b%40news.povray.org%3E/#%3C3d9d5b1b%40news.povray.org%3
E

#macro varnish (colv)

#declare iric = 30;         // determines the color variance (0 = full variance;
60 = all colors)
#declare ranc = 0.3;         // determines the decrease in color (1 = no
decrease; 0 = black at slope 0.5)
#declare RGBc = colv;           // main color
#declare HSLc = CRGB2HSL (RGBc);
#declare col1 = RGBc;
#declare col2 = CHSL2RGB (<HSLc.x-iric*0.5,HSLc.y,HSLc.z>);
#declare col3 = CHSL2RGB (<HSLc.x-iric*1,HSLc.y,HSLc.z>);
#declare col4 = CHSL2RGB (<HSLc.x-iric*1.5,HSLc.y,HSLc.z>);
#declare col5 = CHSL2RGB (<HSLc.x-iric*2,HSLc.y,HSLc.z>);
#declare col6 = CHSL2RGB (<HSLc.x-iric*2.5,HSLc.y,HSLc.z>);
#declare col7 = CHSL2RGB (<HSLc.x-iric*3,HSLc.y,HSLc.z>);
#declare col8 = CHSL2RGB (<HSLc.x-iric*3.5,HSLc.y,HSLc.z>);
#declare col9 = CHSL2RGB (<HSLc.x-iric*4,HSLc.y,HSLc.z>);
#declare col10 = CHSL2RGB (<HSLc.x-iric*4.5,HSLc.y,HSLc.z>);
#declare col11 = CHSL2RGB (<HSLc.x-iric*5,HSLc.y,HSLc.z>);

#declare fMetallic = 0.7;
#declare fNoise = 0.5;
#declare fGlitter = 2;

material {
 texture {
  pigment {
   aoi
   color_map {
    [0      rgb col1]
    [0.05   rgb col2*(1-0.1*(1-ranc))]
    [0.1    rgb col3*(1-0.2*(1-ranc))]
    [0.15   rgb col4*(1-0.3*(1-ranc))]
    [0.2    rgb col5*(1-0.4*(1-ranc))]
    [0.25   rgb col6*(1-0.5*(1-ranc))]
    [0.3    rgb col7*(1-0.6*(1-ranc))]
    [0.35   rgb col8*(1-0.7*(1-ranc))]
    [0.4    rgb col9*(1-0.8*(1-ranc))]
    [0.45   rgb col10*(1-0.9*(1-ranc))]
    [0.5    rgb col11*ranc]
    [0.55   rgb col10*(1-0.9*(1-ranc))]
    [0.6    rgb col9*(1-0.8*(1-ranc))]
    [0.65   rgb col8*(1-0.7*(1-ranc))]
    [0.7    rgb col7*(1-0.6*(1-ranc))]
    [0.75   rgb col6*(1-0.5*(1-ranc))]
    [0.8    rgb col5*(1-0.4*(1-ranc))]
    [0.85   rgb col4*(1-0.3*(1-ranc))]
    [0.9    rgb col3*(1-0.2*(1-ranc))]
    [0.95   rgb col2*(1-0.1*(1-ranc))]
    [1      rgb col1]
   }
  }
  finish {
   diffuse (1-fMetallic)*4/3
   specular fMetallic
   roughness 0.1
   metallic 1
  }
  normal {granite fNoise*0.1 scale 0.01}
 }
 texture {
  pigment {color rgbt 1}
  finish {diffuse 0.8 specular fGlitter roughness 0.005}
  normal {granite 1 scale 0.01}
 }
 texture {
  pigment {color rgbt 1}
  finish {
   diffuse 0.8
   reflection {0.08, 1 falloff 5 metallic 0.5}
   conserve_energy
   specular 1
   roughness 0.001
  }
 }
 interior {ior 1.5}
 scale 0.3
}

#end

// knot
________________________________________________________________________________

#include "spline.mcr"

// change this value to increase the z-offset at the crossings
#declare oset = 0.75;

#declare component0 =
create_spline (
        array [25] {
                <77.8557,96.1197, -10 *oset>, <74.1391,112.493, -10 *oset>,
<72.7938,129.558, -3.19175 *oset>,
                <77.528,145.682, 0 *oset>, <83.0397,164.454, 3.71593 *oset>,
<96.2288,180.032, 10 *oset>,
                <113.878,188.47, 10*oset>, <151.96,206.676, 10*oset>,
<196.731,189.867, 3.82119 *oset>,
                <221.758,154.583, 0 *oset>, <247.5,118.291, -3.9304 *oset>,
<247.335,68.7455, -10 *oset>,
                <214.347,41.4865, -10 *oset>, <202.359,31.5802, -10 *oset>,
<187.195,26.6658, -3.76182 *oset>,
                <171.681,25.6033, 0 *oset>, <158.975,24.7331, 3.08099 *oset>,
<146.234,26.431, 10 *oset>,
                <134.132,30.3952, 10*oset>, <119.646,35.1401, 10*oset>,
<106.28,43.0923, 3.38143 *oset>,
                <96.5024,54.792, 0 *oset>, <86.6666,66.5613, -3.40157 *oset>,
<81.2479,81.1754, -10 *oset>,
                <77.8557,96.1197, -10.0001 *oset>
        },
        create_bezier_spline
)

#declare link_object = torus {1, 0.2 scale <3,1,1> varnish (<0.2,0.36,0.85>)}

link_spline (component0, spline_step_size (7) + spline_step_twist (36))

#declare component1 =
create_spline (
        array [49] {
                <77.8557,96.1197, 10*oset>, <87.5618,101.294, 10*oset>,
<98.6654,102.613, 3.18496 *oset>,
                <109.613,103.47, 0 *oset>, <121.876,104.43, -3.56775 *oset>,
<134.347,104.864, -10 *oset>,
                <146.137,101.295, -10 *oset>, <159.492,97.2517, -10 *oset>,
<170.663,88.5039, -3.06995 *oset>,
                <181.108,79.2831, 0 *oset>, <193.76,68.114, 3.71861 *oset>,
<205.722,56.009, 10 *oset>,
                <214.347,41.4865, 10*oset>, <238.035,1.60241, 10*oset>,
<234.113,-48.2384, 3.70213 *oset>,
                <209.153,-87.6545, 0 *oset>, <185.58,-124.878, -3.49624 *oset>,
<145.421,-149.222, -10 *oset>,
                <101.612,-147.258, -10 *oset>, <82.2008,-146.388, -10 *oset>,
<63.6266,-140.09, -3.60792 *oset>,
                <45.0815,-134.379, 0 *oset>, <28.9954,-129.425, 3.12955 *oset>,
<12.5349,-124.761, 10 *oset>,
                <-1.12024,-114.865, 10*oset>, <-11.7523,-107.16, 10*oset>,
<-20.0407,-96.7125, 3.73509 *oset>,
                <-25.6576,-84.8465, 0 *oset>, <-30.2944,-75.0509, -3.08341
*oset>, <-33.0353,-64.4346, -10 *oset>,
                <-33.1842,-53.5955, -10 *oset>, <-33.3522,-41.3692, -10 *oset>,
<-30.2002,-29.2687, -3.52143 *oset>,
                <-23.4307,-19.085, 0 *oset>, <-17.1863,-9.69115, 3.24829 *oset>,
<-8.26351,-2.57213, 10 *oset>,
                <-0.00928933,5.08848, 10*oset>, <7.59886,12.1495, 10*oset>,
<14.6916,19.7368, 3.37262 *oset>,
                <21.6545,27.4336, 0 *oset>, <28.4678,34.965, -3.30016 *oset>,
<35.1728,42.6205, -10 *oset>,
                <40.8841,51.0217, -10 *oset>, <46.4691,59.2372, -10 *oset>,
<51.0539,68.0968, -3.3811 *oset>,
                <56.7782,76.2169, 0 *oset>, <62.4216,84.2223, 3.33329 *oset>,
<69.2054,91.5078, 10 *oset>,
                <77.8557,96.1197, 10.0001 *oset>
        },
        create_bezier_spline
)

#declare link_object = torus {1, 0.2 scale <3,1,1> varnish (<0.2,0.36,0.85>)}

link_spline (component1, spline_step_size (7) + spline_step_twist (40))

#declare component2 =
create_spline (
        array [61] {
                <113.878,188.47, -10 *oset>, <123.807,175.183, -10 *oset>,
<130.504,159.886, -3.55282 *oset>,
                <136.098,144.284, 0 *oset>, <141.089,130.365, 3.16975 *oset>,
<145.251,116.066, 10 *oset>,
                <146.137,101.295, 10*oset>, <146.878,88.9494, 10*oset>,
<145.303,76.6201, 3.43004 *oset>,
                <142.72,64.5309, 0 *oset>, <140.269,53.0542, -3.25623 *oset>,
<136.915,41.7952, -10 *oset>,
                <134.132,30.3952, -10 *oset>, <131.278,18.7043, -10 *oset>,
<128.975,6.7378, -3.4468 *oset>,
                <123.263,-3.87599, 0 *oset>, <117.818,-13.9955, 3.2863 *oset>,
<109.619,-22.2607, 10 *oset>,
                <100.354,-29.0489, 10*oset>, <90.1408,-36.5326, 10*oset>,
<78.7279,-42.1874, 3.45843 *oset>,
                <66.7263,-46.2161, 0 *oset>, <55.4753,-49.9928, -3.24214 *oset>,
<43.8075,-52.3103, -10 *oset>,
                <32.0563,-53.9513, -10 *oset>, <21.2378,-55.4621, -10 *oset>,
<10.3388,-56.4022, -3.33868 *oset>,
                <-0.585665,-56.3405, 0 *oset>, <-11.5049,-56.2788, 3.33705
*oset>, <-22.3871,-55.2168, 10 *oset>,
                <-33.1842,-53.5955, 10*oset>, <-44.9309,-51.8316, 10*oset>,
<-56.5906,-49.4022, 3.24623 *oset>,
                <-67.8059,-45.4799, 0 *oset>, <-79.7419,-41.3056, -3.45484
*oset>, <-91.0541,-35.4782, -10 *oset>,
                <-101.116,-27.816, -10 *oset>, <-110.246,-20.8632, -10 *oset>,
<-118.269,-12.4251, -3.28427 *oset>,
                <-123.382,-2.14349, 0 *oset>, <-128.757,8.6644, 3.45238 *oset>,
<-130.529,20.7531, 10 *oset>,
                <-133.044,32.5378, 10*oset>, <-135.473,43.9159, 10*oset>,
<-138.64,55.1284, 3.25493 *oset>,
                <-140.85,66.5518, 0 *oset>, <-143.179,78.5938, -3.4312 *oset>,
<-144.438,90.858, -10 *oset>,
                <-143.5,103.092, -10 *oset>, <-142.371,117.827, -10 *oset>,
<-138.1,132.067, -3.16766 *oset>,
                <-132.927,145.899, 0 *oset>, <-127.12,161.425, 3.55543 *oset>,
<-120.12,176.586, 10 *oset>,
                <-109.972,189.707, 10*oset>, <-83.5984,223.806, 10*oset>,
<-41.0389,239.9, 3.5218 *oset>,
                <2.22529,239.723, 0 *oset>, <45.5442,239.545, -3.52626 *oset>,
<88.0483,223.035, -10 *oset>,
                <113.878,188.47, -10.0001 *oset>
        },
        create_bezier_spline
)

#declare link_object = torus {1, 0.2 scale <3,1,1> varnish (<0.2,0.36,0.85>)}

link_spline (component2, spline_step_size (7) + spline_step_twist (52))

#declare component3 =
create_spline (
        array [37] {
                <101.612,-147.258, 10*oset>, <109.423,-126.804, 10*oset>,
<110.939,-104.691, 3.68731 *oset>,
                <109.79,-82.8451, 0 *oset>, <108.83,-64.5874, -3.0816 *oset>,
<106.031,-46.4334, -10 *oset>,
                <100.354,-29.0489, -10 *oset>, <94.8526,-12.1985, -10 *oset>,
<86.7181,3.69139, -3.51252 *oset>,
                <75.9835,17.7993, 0 *oset>, <66.1639,30.7046, 3.21313 *oset>,
<54.3096,41.9262, 10 *oset>,
                <40.8841,51.0217, 10*oset>, <28.715,59.2661, 10*oset>,
<15.0796,65.7486, 3.41039 *oset>,
                <0.372704,65.803, 0 *oset>, <-14.3301,65.8575, -3.40945 *oset>,
<-28.0068,59.4791, -10 *oset>,
                <-40.2697,51.3838, -10 *oset>, <-53.8477,42.4203, -10 *oset>,
<-65.9232,31.362, -3.2192 *oset>,
                <-75.9921,18.5817, 0 *oset>, <-86.9542,4.66759, 3.50481 *oset>,
<-95.3659,-11.063, 10 *oset>,
                <-101.116,-27.816, 10*oset>, <-107.038,-45.071, 10*oset>,
<-110.054,-63.147, 3.08659 *oset>,
                <-111.225,-81.3474, 0 *oset>, <-112.62,-103.047, -3.68007
*oset>, <-111.364,-125.037, -10 *oset>,
                <-103.905,-145.481, -10 *oset>, <-88.0939,-188.819, -10 *oset>,
<-47.8599,-218.765, -3.65022 *oset>,
                <-1.87885,-219.232, 0 *oset>, <44.2051,-219.7, 3.65839 *oset>,
<85.1206,-190.445, 10 *oset>,
                <101.612,-147.258, 10.0001 *oset>
        },
        create_bezier_spline
)

#declare link_object = torus {1, 0.2 scale <3,1,1> varnish (<0.2,0.36,0.85>)}

link_spline (component3, spline_step_size (7) + spline_step_twist (44))

#declare component4 =
create_spline (
        array [49] {
                <-1.12024,-114.865, -10 *oset>, <9.66283,-107.308, -10 *oset>,
<18.1424,-96.9663, -3.73474 *oset>,
                <23.9713,-85.1614, 0 *oset>, <28.7834,-75.4156, 3.08329 *oset>,
<31.7111,-64.8173, 10 *oset>,
                <32.0563,-53.9513, 10*oset>, <32.4443,-41.7411, 10*oset>,
<29.5398,-29.5878, 3.52905 *oset>,
                <22.9404,-19.3061, 0 *oset>, <16.877,-9.85952, -3.24243 *oset>,
<8.08978,-2.65665, -10 *oset>,
                <-0.00928933,5.08848, -10 *oset>, <-7.48292,12.2355, -10 *oset>,
<-14.4219,19.9113, -3.3682 *oset>,
                <-21.2794,27.6501, 0 *oset>, <-28.0069,35.2423, 3.3044 *oset>,
<-34.6747,42.9184, 10 *oset>,
                <-40.2697,51.3838, 10*oset>, <-45.699,59.5985, 10*oset>,
<-50.0603,68.4744, 3.38032 *oset>,
                <-55.5535,76.647, 0 *oset>, <-60.9722,84.7087, -3.33446 *oset>,
<-67.5303,92.0918, -10 *oset>,
                <-76.0163,96.8357, -10 *oset>, <-85.5545,102.168, -10 *oset>,
<-96.568,103.648, -3.19502 *oset>,
                <-107.426,104.698, 0 *oset>, <-119.517,105.867, 3.55798 *oset>,
<-131.838,106.561, 10 *oset>,
                <-143.5,103.092, 10*oset>, <-156.508,99.2224, 10*oset>,
<-167.315,90.6167, 3.07085 *oset>,
                <-177.424,81.5946, 0 *oset>, <-189.661,70.6735, -3.71719 *oset>,
<-201.258,58.9055, -10 *oset>,
                <-209.85,44.9193, -10 *oset>, <-233.965,5.65958, -10 *oset>,
<-232.055,-43.7895, -3.70068 *oset>,
                <-208.634,-83.6842, 0 *oset>, <-186.531,-121.335, 3.49251
*oset>, <-147.336,-146.542, 10 *oset>,
                <-103.905,-145.481, 10*oset>, <-84.6316,-145.011, 10*oset>,
<-66.0975,-139.065, 3.5929 *oset>,
                <-47.6141,-133.679, 0 *oset>, <-31.4541,-128.97, -3.14126
*oset>, <-14.9301,-124.544, -10 *oset>,
                <-1.12024,-114.865, -10.0001 *oset>
        },
        create_bezier_spline
)

#declare link_object = torus {1, 0.2 scale <3,1,1> varnish (<0.2,0.36,0.85>)}

link_spline (component4, spline_step_size (7) + spline_step_twist (40))

#declare component5 =
create_spline (
        array [25] {
                <-133.044,32.5378, -10 *oset>, <-118.579,36.8582, -10 *oset>,
<-105.222,44.5443, -3.3711 *oset>,
                <-95.3443,55.9666, 0 *oset>, <-85.3423,67.5333, 3.41371 *oset>,
<-79.6965,82.0083, 10 *oset>,
                <-76.0163,96.8357, 10*oset>, <-71.9702,113.138, 10*oset>,
<-70.2301,130.174, 3.19862 *oset>,
                <-74.6149,146.403, 0 *oset>, <-79.7,165.224, -3.70952 *oset>,
<-92.5119,181.04, -10 *oset>,
                <-109.972,189.707, -10 *oset>, <-147.415,208.292, -10 *oset>,
<-191.983,191.964, -3.82635 *oset>,
                <-216.903,157.06, 0 *oset>, <-242.5,121.209, 3.93028 *oset>,
<-242.384,72.1495, 10 *oset>,
                <-209.85,44.9193, 10*oset>, <-198.416,35.3499, 10*oset>,
<-184.003,30.3445, 3.75867 *oset>,
                <-169.162,28.9381, 0 *oset>, <-157.005,27.7861, -3.07899 *oset>,
<-144.745,29.0433, -10 *oset>,
                <-133.044,32.5378, -10.0001 *oset>
        },
        create_bezier_spline
)

#declare link_object = torus {1, 0.2 scale <3,1,1> varnish (<0.2,0.36,0.85>)}

link_spline (component5, spline_step_size (7) + spline_step_twist (36))

// wall
________________________________________________________________________________

// Jonathan Hunt  pebbles
http://news.povray.org/povray.text.scene-files/message/%3C48d158e3%241%40news.povray.org%3E/#%3C48d158e3%241%40news.pov
ray.org%3E

#macro pebbles (srand)

#declare stogam = 2.2*1.4;
#declare stodiff = 1.1;

#declare stora = seed (srand*4);

#declare PebbleNormalAndFinish =
texture {
 //normal {bumps 0.2 scale 0.005}
 finish {diffuse 0.6 ambient 0 /*specular 0.3 roughness 0.003*/}
}

#declare PebblePatternCount = 6;
#declare PebblePatterns = array [PebblePatternCount]

// A selection of base patterns for the pebbles.

#declare PebblePatterns [0] =
pigment {
 wrinkles
 scale 0.02
 noise_generator 2
}

#declare PebblePatterns [1] =
pigment {
 bozo
 turbulence 2.0
 scale 0.05
 noise_generator 2
}

#declare PebblePatterns [2] =
pigment {
 bozo
 turbulence 4.0
 scale 0.1
 noise_generator 3
}

#declare PebblePatterns [3] =
pigment {
 wrinkles
 turbulence 1.0
 scale 0.05
}

#declare PebblePatterns [4] =
pigment {
 granite
 turbulence 0.2
 scale 0.15
}

#declare PebblePatterns [5] =
pigment {
 granite
 scale 0.6
 turbulence 2
}

#declare PebblecolorCount = 15;
#declare Pebblecolors = array [PebblecolorCount]

// A selection of different color schemes for the pebbles.

#declare Pebblecolors [0] =
color_map {
 [0                              rgb <pow (0.7+(rand
(stora)-0.5)*0.05,stogam)*stodiff,pow (0.7+(rand
(stora)-0.5)*0.05,stogam)*stodiff,pow (0.7+(rand
(stora)-0.5)*0.05,stogam)*stodiff>]
 [0.7+(rand (stora)-0.5)*0.15    rgb <pow (0.8+(rand
(stora)-0.5)*0.05,stogam)*stodiff,pow (0.8+(rand
(stora)-0.5)*0.05,stogam)*stodiff,pow (0.8+(rand
(stora)-0.5)*0.05,stogam)*stodiff>]
 [1                              rgb <1,1,1>]
}
#declare Pebblecolors [1] =
color_map {
 [0                              rgb <pow (0.5+(rand
(stora)-0.5)*0.05,stogam)*stodiff,pow (0.5+(rand
(stora)-0.5)*0.05,stogam)*stodiff,pow (0.5+(rand
(stora)-0.5)*0.05,stogam)*stodiff>]
 [0.3+(rand (stora)-0.5)*0.15    rgb <pow (0.9+(rand
(stora)-0.5)*0.05,stogam)*stodiff,pow (0.9+(rand
(stora)-0.5)*0.05,stogam)*stodiff,pow (0.9+(rand
(stora)-0.5)*0.05,stogam)*stodiff>]
 [0.8+(rand (stora)-0.5)*0.15    rgb <1,1,1>]
 [1                              rgb <1,1,pow (0.5+(rand
(stora)-0.5)*0.05,stogam)*stodiff>]
}
#declare Pebblecolors [2] =
color_map {
 [0                              rgb <pow (0.4+(rand
(stora)-0.5)*0.05,stogam)*stodiff,pow (0.4+(rand
(stora)-0.5)*0.05,stogam)*stodiff,pow (0.6+(rand
(stora)-0.5)*0.05,stogam)*stodiff>]
 [0.2+(rand (stora)-0.5)*0.15    rgb <1,1,1>]
 [0.7+(rand (stora)-0.5)*0.15    rgb <pow (0.9+(rand
(stora)-0.5)*0.05,stogam)*stodiff,pow (0.9+(rand
(stora)-0.5)*0.05,stogam)*stodiff,1>]
 [1                              rgb <pow (0.8+(rand

[ remainder of message truncated in this digest view due to length ]

[Mike Horvath] Re: Updated screen.inc [2485 days 10 hours and 54 minutes ago]

Tue, 25 Jun 2019 10:04:17 GMT

Made some minor tweaks, and updated the documentation. These are 
probably the last changes I will make unless there is feedback.


Michael

[Mike Horvath] Re: Updated screen.inc [2485 days 13 hours and 21 minutes ago]

Tue, 25 Jun 2019 07:37:32 GMT

Oops, I forgot to trim some test code that causes experimental behavior. 
I have attached the unaffected code to this post.


Michael

[Mike Horvath] Re: Updated screen.inc [2485 days 13 hours and 24 minutes ago]

Tue, 25 Jun 2019 07:34:33 GMT

On 6/25/2019 3:32 AM, Mike Horvath wrote:
> Some small tweaks, as well as some notes.
> 
> NOTES (MJH)
> * Camera_Angle and Camera_Zoom are ignored by Mode 2.
> * Outputted Camera_Look_At is incorrect with Mode 2 when orthographic
>  Â  projection is disabled. Not sure this can be fixed.
> * In my opinion, Set_Camera_Angle and Set_Camera_Zoom should disregard
>  Â  Camera_Aspect_Ratio. Instead, Camera_Aspect_Ratio should be handled
>  Â  at other points in the code. However, altering this behavior could
>  Â  affect old scenes.

Additional note:

Is it even possible to determine the look_at point when you are using 
location, direction, right, and up and perspective projection?


Michael

[Mike Horvath] Re: Updated screen.inc [2485 days 13 hours and 26 minutes ago]

Tue, 25 Jun 2019 07:32:00 GMT

Some small tweaks, as well as some notes.

NOTES (MJH)
* Camera_Angle and Camera_Zoom are ignored by Mode 2.
* Outputted Camera_Look_At is incorrect with Mode 2 when orthographic
   projection is disabled. Not sure this can be fixed.
* In my opinion, Set_Camera_Angle and Set_Camera_Zoom should disregard
   Camera_Aspect_Ratio. Instead, Camera_Aspect_Ratio should be handled
   at other points in the code. However, altering this behavior could
   affect old scenes.

[Mike Horvath] Re: Updated screen.inc [2486 days 18 hours and 18 minutes ago]

Mon, 24 Jun 2019 02:40:00 GMT

I discovered a lot of bugs that I didn't notice before.

These updated versions may work better. There are new test cases in the 
demo scene. Let me know if they're not working.


Michael

[Mike Horvath] Re: Brick wall and spotlights [2512 days 13 hours and 31 minutes ago]

Wed, 29 May 2019 07:26:57 GMT

On 5/28/2019 9:28 PM, Bald Eagle wrote:
> I made one with prism bricks with a normal, over a plane with a normal.
> I left the 2 points bracketing each [implied] corner unperturbed, but that's
> easily changed.
> 
> 
> 3.562 seconds
> 


This is what I am using currently. I will keep poking around over the 
next few days.


Michael

[Bald Eagle] Re: Brick wall and spotlights [2512 days 19 hours and 28 minutes ago]

Wed, 29 May 2019 01:30:01 GMT

I made one with prism bricks with a normal, over a plane with a normal.
I left the 2 points bracketing each [implied] corner unperturbed, but that's
easily changed.


3.562 seconds

[Bald Eagle] Re: Brick wall and spotlights [2512 days 23 hours and 13 minutes ago]

Tue, 28 May 2019 21:45:00 GMT

Mike Horvath <mik### [at] gmailcom> wrote:
> Here is my wall so far. I like the fact that the bricks are irregular.
> However, the edges of each brick is still too sharp. If I could soften
> the edges and corners, that would be great.
>
>
> Michael

Well, if you want them more irregular, your f_wrinkles value needs to get
multiplied - 1.2 - 2 looks good.

Or you could use a round_box object for the bricks and subtract a single
translated wavy isosurface from its face and edges.
That would probably be MUCH faster than calculating all those isosurfaces.
Creating a mesh or a heightfield to do it would be faster still.

[Mike Horvath] Brick wall and spotlights [2513 days 2 hours and 53 minutes ago]

Tue, 28 May 2019 18:05:26 GMT

Here is my wall so far. I like the fact that the bricks are irregular. 
However, the edges of each brick is still too sharp. If I could soften 
the edges and corners, that would be great.


Michael

[gregjohn] Re: Help with converting electron scattering CAS... [2539 days 6 hours and 13 minutes ago]

Thu, 2 May 2019 14:45:00 GMT

Thanks all for the consideration. The "fifth" variable is interesting because
it's the energy, and one can see it decrease with increasing collisions... That
could be an interesting color parameter.

[Bald Eagle] Re: Help with converting electron scattering CAS... [2539 days 18 hours and 33 minutes ago]

Thu, 2 May 2019 02:25:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:

> I see what I can do, unless you beat me to it  ;)

It took me a while to struggle with some of the syntax in LibreOffice, and
puzzle out how to pair INDIRECT() with ADDRESS() so I could specify a cell
range, but I think it should work.
Just needs a minor tweak to make it fully automated (hopefully I'll do that
tomorrow)

Your sample data set gets transformed into and array made of 400 other arrays,
the largest of which has 36 elements.

I sent you an email.  :)

[Bald Eagle] Re: Help with converting electron scattering CAS... [2539 days 23 hours and 13 minutes ago]

Wed, 1 May 2019 21:45:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:

> Seems to me you can write a macro to parse your text file.

And of course, since POV-Ray can't determine the cast/type of the variable, you
can't parse data that you don't know exactly what format the variables are - and
so you need to know how many records to read.....
So ignore that.

> (Can you change it a CSV format?  Maybe with Excel / LibreOffice, etc.?)

I think I might have a way to process the data in LibreOffice/OpenOffice to
generate an include file with the formatted arrays.

But that might take a while since it's been months since I've looked at my
ridiculously complicated spreadsheet from my last job....

So the new plan is to use a 3rd party tool (commercial, or hand-written
C++/C#/whatever) to just strip out anything but the numeric data lines, and make
arrays of all the data sets.

I see what I can do, unless you beat me to it  ;)

[Bald Eagle] Re: Help with converting electron scattering CAS... [2540 days 1 hour and 38 minutes ago]

Wed, 1 May 2019 19:20:01 GMT

"gregjohn" <pte### [at] yahoocom> wrote:
> Hi. I have a dozen of these files, which are the output of the CASINO program
> for the simulation of electron scattering in a solid of SiO2.  These can be very
> beautiful (see images at https://www.google.com/search?q=casino+electron ), but
> the paths are often rendered in ugly, one-pixel-wide trails.
>
> I want to render in povray, turning each Trajectory into a spline or a series of
> cylinders. Once I get a series of arrays defined properly in povray SDL, I'm
> good to go.  I believe I have the skills to use Notepad++ to make most of the
> modifications, then do some typing by hand per trajectory. But the problem is
> there are 200 trajectories, each with a different number of segments, and I have
> a dozen files.  Also, this low energy simulation only has about 20 points. Some
> of the high energy ones have over 300!
>
> Any tips? (Feel free to use this file any way you see fit).
>
> Hello! The email I use everyday, for old povray friends, is this
> use### [at] gmailcom

Seems to me you can write a macro to parse your text file.
(Can you change it a CSV format?  Maybe with Excel / LibreOffice, etc.?)

Set a counter to 0
Skip the first "Trajectory" and then every time after, increment a counter.

Once you hit "Energy", you start building your array with 5 dimensions.
Use the counter in a macro call that adds a data set to the array.
Stop when you hit
"-----------------------------------------------------------------"

Add that trajectory array to a master array.

Now you have an array of arrays that you can step through, interpolate a spline
for a sphere sweep, instantiate the sphere sweep, and cycle through until all
the trajectories are "plotted".

[gregjohn] Help with converting electron scattering CASINO ... [2540 days 5 hours and 33 minutes ago]

Wed, 1 May 2019 15:25:00 GMT

Hi. I have a dozen of these files, which are the output of the CASINO program
for the simulation of electron scattering in a solid of SiO2.  These can be very
beautiful (see images at https://www.google.com/search?q=casino+electron ), but
the paths are often rendered in ugly, one-pixel-wide trails.

I want to render in povray, turning each Trajectory into a spline or a series of
cylinders. Once I get a series of arrays defined properly in povray SDL, I'm
good to go.  I believe I have the skills to use Notepad++ to make most of the
modifications, then do some typing by hand per trajectory. But the problem is
there are 200 trajectories, each with a different number of segments, and I have
a dozen files.  Also, this low energy simulation only has about 20 points. Some
of the high energy ones have over 300!

Any tips? (Feel free to use this file any way you see fit).

Hello! The email I use everyday, for old povray friends, is this
use### [at] gmailcom

[MichaelJF] Painting a Blob [2690 days 2 hours and 30 minutes ago]

Sun, 2 Dec 2018 18:28:23 GMT

Hi to the crowd,

here is an idea and the corresponding code, how one can convert an image 
to a blob. I needed the Eye of Horus for an old idea I reinvestigate 
now. I have forgotten that I solved this image to blob riddle two years 
ago. But may be the one or other here is still interessted in this issue.

I used the image one can find at the English Wikipedia under the topic 
"Eye of Horus", loaded it in the GIMP and painted a little bit at an 
additional layer to mark the different materials. White for the 
background, red for the reddish material and so on. I saved the result 
in the image "gold.jpg" (see attached archive). Then I did the same to 
have some elevations in the resulting blob ("Erhoehungen.png"). Finally 
I scanned both images within POV using the eval_pigment function to 
construct the blob. This took a (little) while, so I saved the resulting 
blob in an include-file (not included in the archive, you have to run 
the POV-file to create it).

Best regards
Michael

[jr] Re: queues [2693 days 17 hours and 43 minutes ago]

Thu, 29 Nov 2018 03:15:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> the 'queues.inc' file is standalone.  the usage of the macros is documented in
> the 'queues.html' page.  the archive also includes two (simple) demo scenes.

the documentation contained a cut and paste error which made reference to an old
variable name, now corrected.  see attached.

enjoy, jr.

[jr] queues [2716 days 3 hours and 3 minutes ago]

Tue, 6 Nov 2018 17:55:06 GMT

hi,

the new in version 3.8 features have made it easier to implement some "standard"
data structures, so here's my version of a couple of queue types:
a conventional first in - first out (FIFO) type and a last in - first out
(LIFO/stack).

the 'queues.inc' file is standalone.  the usage of the macros is documented in
the 'queues.html' page.  the archive also includes two (simple) demo scenes.

feedback on both the '.inc' and the '.html' is wanted, and welcome, as are
criticisms, tips, etc to make "the package" better.


enjoy, jr.

[Thomas de Groot] Re: Mika Diamond [2755 days 14 hours and 21 minutes ago]

Fri, 28 Sep 2018 06:37:36 GMT

On 28-9-2018 5:46, Dan wrote:
> And yet another diamond... Not fully parameterized yet.  Don't change the
> diameter just scale it.

It took 14 years to grow? ;-)

-- 
Thomas

[Dan] Re: Mika Diamond [2755 days 17 hours and 8 minutes ago]

Fri, 28 Sep 2018 03:50:00 GMT

And yet another diamond... Not fully parameterized yet.  Don't change the
diameter just scale it.
#declare Diamond_Diameter = 2.0;
#declare Diamond =
difference {
// body
 cylinder {  <0,0,0>, <0,2,0>, Diamond_Diameter/2 }
//kite facets
#for (kiteangle,0,315,45)
  box { <-5.00, 0.00, -5.00>,< 5.00, 1.00, 5.00> rotate<0,0,34>
translate<-.54*Diamond_Diameter/2,2,0> rotate<0,kiteangle,0>     }
#end
// star facets
#for (starangle,22.5,360,45)
  box { <-5.00, 0.00, -5.00>,< 5.00, 1.00, 5.00> rotate<0,0,17>
translate<-.4989*Diamond_Diameter/2,2,0> rotate<0,starangle,0>    }
#end
// Upper Girdle Facets
#for (girdleangle,11.25,360,22.5)
  box { <-5.00, 0.00, -5.00>,< 5.00, 1.00, 5.00> rotate<0,0,38.37>
translate<-.589*Diamond_Diameter/2,2,0> rotate<0,girdleangle,0>    }
#end
//Pavilion main facets
#for (pavilionangle,0,360,45)
  box { <-5.00, -1.00, -5.00>,< 5.00, 0.00, 5.00> rotate<0,0,(-40.6)>
translate<.963*Diamond_Diameter/2,-.05,0> rotate<0,pavilionangle,0>    }
#end
//Lower Girdle Facets
#for (girdleangle,11.25,360,22.5)
  box { <-5.00, -1.00, -5.00>,< 5.00, 0.00, 5.00> rotate<0,0,-(40.6+4.37)>
translate<-1.2985*Diamond_Diameter/2,1.95,0> rotate<0,girdleangle,0>    }
#end
//Girdle Trim Facets
#for (girdleangle,11.25,360,22.5)
  box { <-5.00, -1.00, -5.00>,< 0.00, 2.00, 5.00> rotate<0,0,0>
translate<-0.98*Diamond_Diameter/2,0,0> rotate<0,girdleangle,0>    }
#end
}