povray.binaries.animations message digest

[Clarence1898] Re: Orrery WIP [19 days 17 hours and 59 minutes ago]

Tue, 17 Mar 2026 21:20:00 GMT

"Clarence1898" <dle### [at] comcastnet> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > "Clarence1898" <dle### [at] comcastnet> wrote:
> > > This is a project I started over 20 years ago by modeling an orrery.
> >
> > And you're still at it!  Good work.
> >
> > It's been a long time since I've seen one of these classic animations.
> >
> > >Then had
> > > to figure out a scene to put it in.  This is what I finally came up with.  Turn
> > > looping on in your player.  I would get stuck on it, or real life interrupted,
> > > put aside for a few years then repeat.  I'm not very happy with the clouds the
> > > camera flies through, not enough turbulence.
> >
> > Clouds are notoriously difficult.
> >
> > >There is also some flickering I
> > > haven't been able to get rid of.
> >
> > I didn't really notice anything, so it must be a very small problem.
> >
> > >The camera has a couple of abrupt moves I need
> > > to smooth out.
> >
> > When you're about to make a sharp turn, slow down the camera dramatically.
> > Look into "smoothing functions" to get the sort of thing you want.
> >
> > >I do plan to add more objects to the scene.  Any comments or
> > > suggestions would be welcome.
> >
> > I like the island a LOT.
> > The house, the working lighthouse (make the light MUCH brighter), the ceiling
> > fan, the periodic table, the stencil on the desk....
> >
> > The orrery sun could be a bit brighter/yellower.
> >
> > I like the checkered bed.  Perhaps a silvery pillow would be a nice "easter egg"
> > nod to the RSOCP.  It's always fun to sneak some classic POV-Ray / computer
> > graphics models, or someone else's POV-Ray model/effect into a scene.
> >
> > If you hit any more stumbling blocks, don't be afraid to ask for ideas or
> > solutions.  Set your goal on the finish line!
> >
> > - BE
>
> Thank you for the suggestions.  I made a few changes and reposted a new
> animation.  The flickering is much more noticeable at higher resolutions, I
> rendered the animation at 1280x720 then reduced it to 640x360 to get the size
> down for posting.  The planet maps came from a NASA web site, I picked a new sun
> that is brighter and yellower.  It does look better.  The checkered bed was a
> nod to the RSOCP, but the pillow reflects the creme colored walls not the bed
> and it almost looks translucent not reflective.  At the time I created the
> lighthouse I didn't know the color rgb values could be greater than 1.0.  I
> increased the value and it looks much better.  I wrote a program to generate the
> island,  started with a pyramid and recursively divided the faces into smaller
> triangles and translating the vertices a random amount up or down and then
> created a mesh2 object.  I then populated the island with 24000 trees and 32000
> bushes that were created by Arbaro 2.0.  Now I need to work on the camera
> transitions.

In trying to reduce the flicker, I rendered at 3840x2160 then scaled it down to
640x360.  It didn't eliminate all the flickering but did reduce it a lot.  That
cut the size down from 42MB to a more reasonable 3.4MB.  I was also able to
smooth the transition when the camera entered earth orbit.  Still not completely
happy with it, but I think its looking better.

[m@b] Re: Orrery WIP [28 days 12 hours and 29 minutes ago]

Mon, 9 Mar 2026 02:50:00 GMT

> > Very nice. I did an orrery some time ago:
> > <https://www.youtube.com/watch?v=GyqQolOK_qI>
> >
> > I remember one of the first scenes I animated was a lighthouse (using Polyray)
> > way back when :-)
> >
> > m@b
>
> Very nice.  I particularly like the way you morphed the planets into the orrery.
> Impressive.

Thanks :-)

[Clarence1898] Re: Orrery WIP [31 days 11 hours and 54 minutes ago]

Fri, 6 Mar 2026 03:25:00 GMT

"m@b" <nomail@nomail> wrote:
> "Clarence1898" <dle### [at] comcastnet> wrote:
> > This is a project I started over 20 years ago by modeling an orrery.  Then had
> > to figure out a scene to put it in.  This is what I finally came up with.  Turn
> > looping on in your player.  I would get stuck on it, or real life interrupted,
> > put aside for a few years then repeat.  I'm not very happy with the clouds the
> > camera flies through, not enough turbulence.  There is also some flickering I
> > haven't been able to get rid of.  The camera has a couple of abrupt moves I need
> > to smooth out.  I do plan to add more objects to the scene.  Any comments or
> > suggestions would be welcome.
>
> Very nice. I did an orrery some time ago:
> <https://www.youtube.com/watch?v=GyqQolOK_qI>
>
> I remember one of the first scenes I animated was a lighthouse (using Polyray)
> way back when :-)
>
> m@b

Very nice.  I particularly like the way you morphed the planets into the orrery.
Impressive.

[m@b] Re: Orrery WIP [31 days 13 hours and 4 minutes ago]

Fri, 6 Mar 2026 02:15:00 GMT

"Clarence1898" <dle### [at] comcastnet> wrote:
> This is a project I started over 20 years ago by modeling an orrery.  Then had
> to figure out a scene to put it in.  This is what I finally came up with.  Turn
> looping on in your player.  I would get stuck on it, or real life interrupted,
> put aside for a few years then repeat.  I'm not very happy with the clouds the
> camera flies through, not enough turbulence.  There is also some flickering I
> haven't been able to get rid of.  The camera has a couple of abrupt moves I need
> to smooth out.  I do plan to add more objects to the scene.  Any comments or
> suggestions would be welcome.

Very nice. I did an orrery some time ago:
<https://www.youtube.com/watch?v=GyqQolOK_qI>

I remember one of the first scenes I animated was a lighthouse (using Polyray)
way back when :-)

m@b

[Clarence1898] Re: Orrery WIP [31 days 16 hours and 24 minutes ago]

Thu, 5 Mar 2026 22:55:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Clarence1898" <dle### [at] comcastnet> wrote:
> > This is a project I started over 20 years ago by modeling an orrery.
>
> And you're still at it!  Good work.
>
> It's been a long time since I've seen one of these classic animations.
>
> >Then had
> > to figure out a scene to put it in.  This is what I finally came up with.  Turn
> > looping on in your player.  I would get stuck on it, or real life interrupted,
> > put aside for a few years then repeat.  I'm not very happy with the clouds the
> > camera flies through, not enough turbulence.
>
> Clouds are notoriously difficult.
>
> >There is also some flickering I
> > haven't been able to get rid of.
>
> I didn't really notice anything, so it must be a very small problem.
>
> >The camera has a couple of abrupt moves I need
> > to smooth out.
>
> When you're about to make a sharp turn, slow down the camera dramatically.
> Look into "smoothing functions" to get the sort of thing you want.
>
> >I do plan to add more objects to the scene.  Any comments or
> > suggestions would be welcome.
>
> I like the island a LOT.
> The house, the working lighthouse (make the light MUCH brighter), the ceiling
> fan, the periodic table, the stencil on the desk....
>
> The orrery sun could be a bit brighter/yellower.
>
> I like the checkered bed.  Perhaps a silvery pillow would be a nice "easter egg"
> nod to the RSOCP.  It's always fun to sneak some classic POV-Ray / computer
> graphics models, or someone else's POV-Ray model/effect into a scene.
>
> If you hit any more stumbling blocks, don't be afraid to ask for ideas or
> solutions.  Set your goal on the finish line!
>
> - BE

Thank you for the suggestions.  I made a few changes and reposted a new
animation.  The flickering is much more noticeable at higher resolutions, I
rendered the animation at 1280x720 then reduced it to 640x360 to get the size
down for posting.  The planet maps came from a NASA web site, I picked a new sun
that is brighter and yellower.  It does look better.  The checkered bed was a
nod to the RSOCP, but the pillow reflects the creme colored walls not the bed
and it almost looks translucent not reflective.  At the time I created the
lighthouse I didn't know the color rgb values could be greater than 1.0.  I
increased the value and it looks much better.  I wrote a program to generate the
island,  started with a pyramid and recursively divided the faces into smaller
triangles and translating the vertices a random amount up or down and then
created a mesh2 object.  I then populated the island with 24000 trees and 32000
bushes that were created by Arbaro 2.0.  Now I need to work on the camera
transitions.

[Bald Eagle] Re: Orrery WIP [32 days 1 hour and 9 minutes ago]

Thu, 5 Mar 2026 14:10:00 GMT

"Clarence1898" <dle### [at] comcastnet> wrote:
> This is a project I started over 20 years ago by modeling an orrery.

And you're still at it!  Good work.

It's been a long time since I've seen one of these classic animations.

>Then had
> to figure out a scene to put it in.  This is what I finally came up with.  Turn
> looping on in your player.  I would get stuck on it, or real life interrupted,
> put aside for a few years then repeat.  I'm not very happy with the clouds the
> camera flies through, not enough turbulence.

Clouds are notoriously difficult.

>There is also some flickering I
> haven't been able to get rid of.

I didn't really notice anything, so it must be a very small problem.

>The camera has a couple of abrupt moves I need
> to smooth out.

When you're about to make a sharp turn, slow down the camera dramatically.
Look into "smoothing functions" to get the sort of thing you want.

>I do plan to add more objects to the scene.  Any comments or
> suggestions would be welcome.

I like the island a LOT.
The house, the working lighthouse (make the light MUCH brighter), the ceiling
fan, the periodic table, the stencil on the desk....

The orrery sun could be a bit brighter/yellower.

I like the checkered bed.  Perhaps a silvery pillow would be a nice "easter egg"
nod to the RSOCP.  It's always fun to sneak some classic POV-Ray / computer
graphics models, or someone else's POV-Ray model/effect into a scene.

If you hit any more stumbling blocks, don't be afraid to ask for ideas or
solutions.  Set your goal on the finish line!

- BE

[jr] Re: Orrery WIP (with mp4) [32 days 6 hours and 59 minutes ago]

Thu, 5 Mar 2026 08:20:00 GMT

hi,

"Clarence1898" <dle### [at] comcastnet> wrote:
> somehow my attachment is missing.  Try it again.

wow, quite the study.. :-)  very nice.


regards, jr.

[Clarence1898] Orrery WIP (with mp4) [32 days 16 hours and 29 minutes ago]

Wed, 4 Mar 2026 22:50:00 GMT

somehow my attachment is missing.  Try it again.

[Clarence1898] Orrery WIP [32 days 17 hours and 34 minutes ago]

Wed, 4 Mar 2026 21:45:00 GMT

This is a project I started over 20 years ago by modeling an orrery.  Then had
to figure out a scene to put it in.  This is what I finally came up with.  Turn
looping on in your player.  I would get stuck on it, or real life interrupted,
put aside for a few years then repeat.  I'm not very happy with the clouds the
camera flies through, not enough turbulence.  There is also some flickering I
haven't been able to get rid of.  The camera has a couple of abrupt moves I need
to smooth out.  I do plan to add more objects to the scene.  Any comments or
suggestions would be welcome.

[Bald Eagle] Re: Solar System [60 days 23 hours and 19 minutes ago]

Wed, 4 Feb 2026 16:00:00 GMT

"Maetes" <nomail@nomail> wrote:

> Nice animation, but I don't really understand, what is happening in the
> animation. Where ist Earth, where Jupiter, what changes over time?

All of the planets are pictured stationary in their orbits
(I suppose I did that for simplicity at the time)
All of the white objects are the 655,000+ "minor planets" in the asteroid belt
getting animated over the span of 1 year

- BE

[Maetes] Re: Solar System [61 days 5 hours and 4 minutes ago]

Wed, 4 Feb 2026 10:15:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Further work:
>
> Over the weekend I worked out the REAL way to do orbital inclinations, and
> processed the data for ~655,000 minor plants from:
> http://www.minorplanetcenter.net/iau/MPCORB.html
>
> You can clearly see why it's called the asteroid BELT.  :O

Nice animation, but I don't really understand, what is happening in the
animation. Where ist Earth, where Jupiter, what changes over time?

ma

[Ton] Re: Starfield-Animations - WIP [64 days 6 hours and 14 minutes ago]

Sun, 1 Feb 2026 09:05:00 GMT

"Maetes" <nomail@nomail> wrote:
> I've finally found some time to work on my old star field animations.
> They are far from what I would like them to be, but at least they are colorful
> now!
>
> 4 Videos, 2  normal and 2 stereo, and some more informations:
> https://www.maetes.com/en/blog/our-stellar-red-neighborhood
>
> One animation shows stars and so-called brown dwarfs within a radius of 20 light
> years (see example image), the second one in 100 light years.
>
> Have a nice day,
> M

Hallo Maetes

an interesting way of star-gazing.

Cheers
Ton

[Maetes] Starfield-Animations - WIP [66 days and 39 minutes ago]

Fri, 30 Jan 2026 14:40:00 GMT

I've finally found some time to work on my old star field animations.
They are far from what I would like them to be, but at least they are colorful
now!

4 Videos, 2  normal and 2 stereo, and some more informations:
https://www.maetes.com/en/blog/our-stellar-red-neighborhood

One animation shows stars and so-called brown dwarfs within a radius of 20 light
years (see example image), the second one in 100 light years.

Have a nice day,
M

[jr] Re: Starfield animations from 2018 [110 days and 24 minutes ago]

Wed, 17 Dec 2025 14:55:00 GMT

hi,

"Maetes" <nomail@nomail> wrote:
> Hi folks,
>
> I uploaded a few star field animations that I already made in 2018.
> With my new databases I will bring them up to date in time.
>
> https://www.maetes.com/en/astro-3d/starfield-animations-from-2018
>
> ma

v nice (even w/out glasses :-)).  thank you.


regards, jr.

[Maetes] Re: Starfield animations from 2018 [111 days 14 hours and 44 minutes ago]

Tue, 16 Dec 2025 00:35:00 GMT

"Leroy" <whe### [at] gmailcom> wrote:
> Another Great job! I like the 3d videos! Where did I put my Glasses?
>

Search them!
The first one in 3D looks really cool.
I could look at it for minutes and longer :)

ma

[Bald Eagle] Re: Povray Island [111 days 14 hours and 54 minutes ago]

Tue, 16 Dec 2025 00:25:00 GMT

"Maetes" <nomail@nomail> wrote:
> In the summer of 2025, I tried to build a macro collection that creates islands
> with vegetation and all kinds of things. I didn't finish it, but made a nice
> video with a fly-through.
>
> https://www.maetes.com/en/blog/povray-island-and-air-lohmueller
>
> Ma

That reminds me of Sebastian Lague's little flying game

https://www.youtube.com/watch?v=sLqXFF8mlEU

[Leroy] Re: Starfield animations from 2018 [111 days 15 hours and 4 minutes ago]

Tue, 16 Dec 2025 00:15:00 GMT

"Maetes" <nomail@nomail> wrote:
> Hi folks,
>
> I uploaded a few star field animations that I already made in 2018.
> With my new databases I will bring them up to date in time.
>
> https://www.maetes.com/en/astro-3d/starfield-animations-from-2018
>
> ma

Another Great job! I like the 3d videos! Where did I put my Glasses?

Have Fun!

[Leroy] Re: Povray Island [111 days 15 hours and 14 minutes ago]

Tue, 16 Dec 2025 00:05:00 GMT

"Maetes" <nomail@nomail> wrote:
> In the summer of 2025, I tried to build a macro collection that creates islands
> with vegetation and all kinds of things. I didn't finish it, but made a nice
> video with a fly-through.
>
> https://www.maetes.com/en/blog/povray-island-and-air-lohmueller
>
> Ma

Very nice! Reminds me of a fly over I did years ago. I had one Island and my
plane was a jet.(so I didn't have to animate the propellers)

Have Fun!

[Maetes] Povray Island [111 days 23 hours and 4 minutes ago]

Mon, 15 Dec 2025 16:15:00 GMT

In the summer of 2025, I tried to build a macro collection that creates islands
with vegetation and all kinds of things. I didn't finish it, but made a nice
video with a fly-through.

https://www.maetes.com/en/blog/povray-island-and-air-lohmueller

Ma

[Maetes] Starfield animations from 2018 [111 days 23 hours and 9 minutes ago]

Mon, 15 Dec 2025 16:10:00 GMT

Hi folks,

I uploaded a few star field animations that I already made in 2018.
With my new databases I will bring them up to date in time.

https://www.maetes.com/en/astro-3d/starfield-animations-from-2018

ma

[Bald Eagle] Re: shuttle [135 days 21 hours and 54 minutes ago]

Fri, 21 Nov 2025 17:25:00 GMT

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

> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > ...
> > It just occurred to me that we can probably use the user-defined mesh camera to
> > do it all in the first pass.

Scratch that,
using the _mesh projection_ would be a giant pain my sphere {}s.

HOWEVER,
using the user-defined function camera
("User defined projection")
would probably allow one to map out the portions of the screen as an
image/diagram
and then use eval_pigment in a function to control the location and direction of
the camera at each pixel.

> that is an interesting idea.  I can tidy-up and post the code if you're minded
> to pursue it.

I think I can just use something like a cubic pattern and different colored
faces to get everything working.
Then it would just be a plug-n-play kind of setup, if I wrote the scene code for
a fairly general case.

- bw

[jr] Re: shuttle [135 days 22 hours and 34 minutes ago]

Fri, 21 Nov 2025 16:45:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> ...
> It just occurred to me that we can probably use the user-defined mesh camera to
> do it all in the first pass.

that is an interesting idea.  I can tidy-up and post the code if you're minded
to pursue it.


regards, jr.

[Bald Eagle] Re: shuttle [136 days and 19 minutes ago]

Fri, 21 Nov 2025 15:00:00 GMT

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

> > I would imagine one could create a 5th animation scene to use the image maps
> > from the first 4, but imagemagick was probably 1000 times faster.
>
> that would have been "the fallback", had I not "lucked out" with the ImageMagick
> tools.


It just occurred to me that we can probably use the user-defined mesh camera to
do it all in the first pass.

- bw

[jr] Re: shuttle [136 days 7 hours and 14 minutes ago]

Fri, 21 Nov 2025 08:05:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> ...
> blue
> green
> red
> metallic cube & sphere

"tut, tut.."

> Nice twist :)

thanks.  (yes, all "that pain" for one little thing :-))

> Presumably you had a system for filenames for each of the panes?

yes, o/wise it'd be real work </grin>.  I have a single scene file (plus .inc)
and four ini files, one "run_" per camera;  frame/file names were
'*_[1234]_*.png'. also two "one-liner" shell scripts, to assemble the frames and
to convert to mp4.

> I would imagine one could create a 5th animation scene to use the image maps
> from the first 4, but imagemagick was probably 1000 times faster.

that would have been "the fallback", had I not "lucked out" with the ImageMagick
tools.

regards, jr.

[Bald Eagle] Re: shuttle [136 days 18 hours and 29 minutes ago]

Thu, 20 Nov 2025 20:50:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> a simple, short animation of a sphere (~25M, ~29secs), plays full-screen.
>
> <drive.google.com/file/d/107xFAgCi1m7Ng-bVsemPRr_5K_V7lCRw/view?usp=sharing>
>
>
> enjoy, jr.

blue
green
red
metallic cube & sphere

Nice twist :)

Presumably you had a system for filenames for each of the panes?

I would imagine one could create a 5th animation scene to use the image maps
from the first 4, but imagemagick was probably 1000 times faster.

- bw

[jr] Re: shuttle [137 days 22 hours and 34 minutes ago]

Wed, 19 Nov 2025 16:45:00 GMT

hi,

yesbird wrote:
> On 19/11/2025 16:08, jr wrote:
> > ...
> Interesting idea to show object from 4 points simultaneously, how did
> you combined the views ?

"magick" </grin>.  literally, the name of the command installed (on Slackware)
as part of the ImageMagick tools.  it allows one to place images (in layers) on
a "canvas" and "flatten" those in an output image.  will send an example later.

> Also reminds me a paintings of Kazimir Malevich ).

thank you. (Google and Wikipedia show many interesting paintings)

regards, jr.

[yesbird] Re: shuttle [137 days 23 hours and 22 minutes ago]

Wed, 19 Nov 2025 15:56:28 GMT

On 19/11/2025 16:08, jr wrote:
> hi,
> a simple, short animation of a sphere (~25M, ~29secs), plays full-screen.
> <drive.google.com/file/d/107xFAgCi1m7Ng-bVsemPRr_5K_V7lCRw/view?usp=sharing>
> enjoy, jr.
> 

Interesting idea to show object from 4 points simultaneously, how did
you combined the views ? Also reminds me a paintings of Kazimir
Malevich ).
--
YB

[jr] shuttle [138 days 2 hours and 9 minutes ago]

Wed, 19 Nov 2025 13:10:00 GMT

hi,

a simple, short animation of a sphere (~25M, ~29secs), plays full-screen.

<drive.google.com/file/d/107xFAgCi1m7Ng-bVsemPRr_5K_V7lCRw/view?usp=sharing>


enjoy, jr.

[Alain Martel] Re: Non-circular gear [172 days 19 hours and 6 minutes ago]

Wed, 15 Oct 2025 20:12:30 GMT

Le 2025-10-15 Ã  15:35, MichaelJF a Ã©critÂ :
> Am 15.10.25 um 18:23 schrieb spigor:
>> A non-circular gear animation I created about 20 years ago using POV-Ray.
> 
> Beautiful and fascinating animation! But is there a practical technical 
> application for this gearbox?
> 
> Best regards
> Mihael

Don't know about that specific shape, but, yes, there are. Some all 
mechanical stamping presses use that kind of gears. They are often 
phased out to use electronically controlled hydraulic presses.

[MichaelJF] Re: Non-circular gear [172 days 19 hours and 43 minutes ago]

Wed, 15 Oct 2025 19:35:47 GMT

Am 15.10.25 um 18:23 schrieb spigor:
> A non-circular gear animation I created about 20 years ago using POV-Ray.

Beautiful and fascinating animation! But is there a practical technical 
application for this gearbox?

Best regards
Mihael

[spigor] Non-circular gear [172 days 22 hours and 54 minutes ago]

Wed, 15 Oct 2025 16:25:00 GMT

A non-circular gear animation I created about 20 years ago using POV-Ray.

[Alain Martel] Re: Robot Lightning Chess [182 days 2 hours and 50 minutes ago]

Mon, 6 Oct 2025 12:29:15 GMT

Le 2025-10-05 Ã  20:04, Clarence1898 a Ã©critÂ :
> "Kenneth" <kdw### [at] gmailcom> wrote:
>> "Clarence1898" <dle### [at] comcastnet> wrote:
>>> "Maetes" <nomail@nomail> wrote:
>>>
>>> Still I would like to know how everyone does their rendering.
>>
>> [running Windows 10]
>>
>> Hi!
>>
>> I have been rendering POV-ray animations for many years, all the way back to
>> Windows 98 days, when machines had only single cores. Now I have a Corei7
>> machine with 8 cores/16 threads. (Quite an improvement, ha.)
>>
>> To be honest, I was not even aware that multiple instances of the app could be
>> run *successfully*...that is, with an overall speed improvement for a scene or
>> an animation...since it has always been my understanding that even a single
>> instance of POV-ray uses most of the resources of the entire machine for
>> rendering. At least, that's the way it used to be on my various single-core
>> machines through the years. (And AFAIU, initially *parsing* a scene uses only
>> one thread, regardless of how many threads are available.)
>>
>> But the faster results of your multi-instance use are a real surprise! I will
>> have to give that a try, to see what the speed improvement might be for my own
>> animations.
>>
>> There remains a question, though: When running multiple instances of the app on
>> multi core/multi thread machines, does each instance's scene parsing use it's
>> *own* single thread to do so? I.e., with 3 instances running (for example), are
>> there now 3 threads dedicated to parsing the (3) scenes? Or just one thread as
>> is typical-- split up between the 3 instances?
> 
> When I started using multiprocessors I noticed the performance advantage of
> multiple instances, but it was on a much smaller scale.  It was only with more
> and faster processors that it became noticeable.  With my first quad-core system
> the difference was about 15% improvement.  With a 20 cpu i9 the difference is up
> to 60%.  For more complex scenes the smaller the difference, but still
> noticeable.
> 
> As I understand it, each instance is completely independent from the others.
> Each instance will have its own threads.
> 
> 

When using POV-Ray version 3.6 and earlier, you couldn't use more than a 
single core/thread. So, back then, using several instances was the only 
way to use all of your cores on a multi-core system.
The main feature of version 3.7, and the reason it was developed, is the 
ability to use all the cores of modern CPUs.

[jr] Re: Robot Lightning Chess [182 days 4 hours and 44 minutes ago]

Mon, 6 Oct 2025 10:35:00 GMT

hi,

"Clarence1898" <dle### [at] comcastnet> wrote:
> ...  Still I would like to know how everyone does their rendering.

I have an "elderly" i5 dedicated to renders.  I have not tried running multiple
instances[*] but like your time-savings observations.

[*] played briefly, some years ago, with multiple version 3.6, even tried to get
3.5 to build/run :-).

and thanks for including the ffmpeg command-line too when you posted robot1
(3.4M is small).


regards, jr.

[yesbird] Klein bottle surface produced by MathView [182 days 15 hours and 2 minutes ago]

Mon, 6 Oct 2025 00:16:20 GMT

This is animation of Klein bottle surface, produced by MathView:
https://mathview.yesbird.online

Details at: povray.binaries.utilities.
-- 
YB

[Clarence1898] Re: Robot Lightning Chess [182 days 15 hours and 9 minutes ago]

Mon, 6 Oct 2025 00:10:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Clarence1898" <dle### [at] comcastnet> wrote:
> > "Maetes" <nomail@nomail> wrote:
> >
> > Still I would like to know how everyone does their rendering.
>
> [running Windows 10]
>
> Hi!
>
> I have been rendering POV-ray animations for many years, all the way back to
> Windows 98 days, when machines had only single cores. Now I have a Corei7
> machine with 8 cores/16 threads. (Quite an improvement, ha.)
>
> To be honest, I was not even aware that multiple instances of the app could be
> run *successfully*...that is, with an overall speed improvement for a scene or
> an animation...since it has always been my understanding that even a single
> instance of POV-ray uses most of the resources of the entire machine for
> rendering. At least, that's the way it used to be on my various single-core
> machines through the years. (And AFAIU, initially *parsing* a scene uses only
> one thread, regardless of how many threads are available.)
>
> But the faster results of your multi-instance use are a real surprise! I will
> have to give that a try, to see what the speed improvement might be for my own
> animations.
>
> There remains a question, though: When running multiple instances of the app on
> multi core/multi thread machines, does each instance's scene parsing use it's
> *own* single thread to do so? I.e., with 3 instances running (for example), are
> there now 3 threads dedicated to parsing the (3) scenes? Or just one thread as
> is typical-- split up between the 3 instances?

When I started using multiprocessors I noticed the performance advantage of
multiple instances, but it was on a much smaller scale.  It was only with more
and faster processors that it became noticeable.  With my first quad-core system
the difference was about 15% improvement.  With a 20 cpu i9 the difference is up
to 60%.  For more complex scenes the smaller the difference, but still
noticeable.

As I understand it, each instance is completely independent from the others.
Each instance will have its own threads.

[Clarence1898] Re: Robot Lightning Chess [182 days 15 hours and 54 minutes ago]

Sun, 5 Oct 2025 23:25:00 GMT

"Maetes" <nomail@nomail> wrote:
> "Clarence1898" <dle### [at] comcastnet> wrote:
> >  Still I would like
> > to know how everyone does their rendering.
>
> I use Raspberry Pis for it.
> One is my standard computer for all days work, and another I turn on when I have
> long movies to render.
> Connection via SSH or virtual desktop.
> That they need 1 or 2 days for a 2000 frames HD Moon- or Mars-Video doesnt
> matter to me.
>
> Pis are cheap, small, silent, energy-efficient.
> And when there is nothing to render, you can use it as Media-Server or anything
> else.
>
> ma

Yes the Pi is a very nice machine.  I run Hercules, an IBM mainframe emulator on
a pi 5.  More ram, aux storage, and faster than the 3081 I worked on in the
1980's.

[Kenneth] Re: Robot Lightning Chess [182 days 17 hours and 9 minutes ago]

Sun, 5 Oct 2025 22:10:00 GMT

"Clarence1898" <dle### [at] comcastnet> wrote:
> "Maetes" <nomail@nomail> wrote:
>
> Still I would like to know how everyone does their rendering.

[running Windows 10]

Hi!

I have been rendering POV-ray animations for many years, all the way back to
Windows 98 days, when machines had only single cores. Now I have a Corei7
machine with 8 cores/16 threads. (Quite an improvement, ha.)

To be honest, I was not even aware that multiple instances of the app could be
run *successfully*...that is, with an overall speed improvement for a scene or
an animation...since it has always been my understanding that even a single
instance of POV-ray uses most of the resources of the entire machine for
rendering. At least, that's the way it used to be on my various single-core
machines through the years. (And AFAIU, initially *parsing* a scene uses only
one thread, regardless of how many threads are available.)

But the faster results of your multi-instance use are a real surprise! I will
have to give that a try, to see what the speed improvement might be for my own
animations.

There remains a question, though: When running multiple instances of the app on
multi core/multi thread machines, does each instance's scene parsing use it's
*own* single thread to do so? I.e., with 3 instances running (for example), are
there now 3 threads dedicated to parsing the (3) scenes? Or just one thread as
is typical-- split up between the 3 instances?

[Maetes] Re: Robot Lightning Chess [182 days 17 hours and 39 minutes ago]

Sun, 5 Oct 2025 21:40:00 GMT

"Clarence1898" <dle### [at] comcastnet> wrote:
>  Still I would like
> to know how everyone does their rendering.

I use Raspberry Pis for it.
One is my standard computer for all days work, and another I turn on when I have
long movies to render.
Connection via SSH or virtual desktop.
That they need 1 or 2 days for a 2000 frames HD Moon- or Mars-Video doesnt
matter to me.

Pis are cheap, small, silent, energy-efficient.
And when there is nothing to render, you can use it as Media-Server or anything
else.

ma

[Clarence1898] Re: Robot Lightning Chess [182 days 17 hours and 54 minutes ago]

Sun, 5 Oct 2025 21:25:00 GMT

"Leroy" <whe### [at] gmailcom> wrote:
> "Clarence1898" <dle### [at] comcastnet> wrote:
> > Going through an old archive I found this animation I wrote 20 years ago.  I
> > wanted to make a few additions but couldn't believe the code I wrote.  Decided I
> > could do a better job 2nd time around.  The rewrite isn't finished yet so still
> > a work in progress.
>
> I'm like you going though my old archives. Have you found any code that you say
> to yourself 'Did I really write that!?'.
>
> I like the animation after I got it to play. I down loaded it and tried window
> media player, it came up with screen 'needs a new codex 99 cents'
> Where did the game come from? A while back I was testing ways to position pieces
> on the chess board and taken pieces placed around it. I got online and found a
> lots of tournament games (which I didn't bookmark their locations)
>
> Have Fun!

I have looked at my old code so many times and thought what was I on when I
wrote that.   Not only my personal code but code I got paid for.   The games I
used came from chessgames.com 1000 Best Short Games here:

https://www.chessgames.com/perl/chesscollection?cid=1034766

I used the short games to keep the video size below 5000K.

I always have fun.

[Leroy] Re: Robot Lightning Chess [182 days 20 hours and 49 minutes ago]

Sun, 5 Oct 2025 18:30:00 GMT

"Clarence1898" <dle### [at] comcastnet> wrote:
> Going through an old archive I found this animation I wrote 20 years ago.  I
> wanted to make a few additions but couldn't believe the code I wrote.  Decided I
> could do a better job 2nd time around.  The rewrite isn't finished yet so still
> a work in progress.

I'm like you going though my old archives. Have you found any code that you say
to yourself 'Did I really write that!?'.

I like the animation after I got it to play. I down loaded it and tried window
media player, it came up with screen 'needs a new codex 99 cents'
Where did the game come from? A while back I was testing ways to position pieces
on the chess board and taken pieces placed around it. I got online and found a
lots of tournament games (which I didn't bookmark their locations)

Have Fun!

[Clarence1898] Re: Robot Lightning Chess [183 days 1 hour and 49 minutes ago]

Sun, 5 Oct 2025 13:30:01 GMT

"Maetes" <nomail@nomail> wrote:
> "Clarence1898" <dle### [at] comcastnet> wrote:
> > Going through an old archive I found this animation I wrote 20 years ago.
>
>
> Looks really really cool :)
> Cant wait to see Version 2.0
>
> Ma

This is the reason I made the change, so I could run multiple games at the same
time.   I think it is a bit amusing watching the robots bob up and down.  I have
a question about how everyone else renders animations.  I wrote the original
scene in 2003, probably on a pentium cpu using povray 3.5.  It was terribly
slow.  When I got another pc, I wrote a program to render frames on both pc's.
When I upgraded to pc's with multiple cpus I changed the program to use multiple
instances of povray on each pc.  With 3.7 I changed the program to use the work
thread option,  but I found that using multiple instances of povray still gave
me better throughput.  Four years ago after recovering from covid, I splurged
and  purchased an intel I9 10900k pc with 10 cores and 20 logical processors.  I
know it sounds ridiculous but running 20 instances of povray was 4 times faster
than running 1 instance with 20 threads.  Individual elapsed times were slower
but total throughput was 4 times as many frames per minute.  I know that this is
low resolution (720x400) and a very simple scene so I tested several
resolutions: 1920x1080 was twice as fast, 3840x2160 was still 60% faster.  I'm
sure more complicated scenes would decrease the difference.  Still I would like
to know how everyone does their rendering.

[Clarence1898] Re: Robot Lightning Chess [183 days 2 hours and 24 minutes ago]

Sun, 5 Oct 2025 12:55:01 GMT

"Maetes" <nomail@nomail> wrote:
> Few ideas:
> let the robots sometimes think a while.
> or let them stop before grabbing, and choose another move.
> and move the camera, maybe slowly aroud the scene, but always a tiny bit.
>
> ma

I like that idea,  moving the camera will be simple.  Changing its mind will be
a bit more difficult.

[Clarence1898] Re: Robot Lightning Chess [183 days 2 hours and 24 minutes ago]

Sun, 5 Oct 2025 12:55:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> I tried to play this with VLC, and just got a black screen.
> Windows Media Player wouldn't even play it.
>
> However VLC has been acting strangely over the past 2 days.
>
> First, when I opened a sound file, there was no VLC interface on the desktop -
> but it was playing the sound in the background.   I had to kill the process to
> close it.
>
> Then when i tried to play your video, When I closed VLC and tried to delete the
> mp4, Win said that it was still open in VLC - and yep, there was a process still
> open in the background that I had to end.
>
> - BE

I used ffmpeg to encode the video.  Here is the command:

ffmpeg -i Robot1%04d.png -c:v libx265 -pix_fmt yuv420p Robot1.mp4

On windows 10 and 11 I use Media Player, on linux VLC.  Everything works fine.

[Cousin Ricky] Re: Robot Lightning Chess [183 days 11 hours and 6 minutes ago]

Sun, 5 Oct 2025 04:12:40 GMT

On 2025-10-04 16:26 (-4), Bald Eagle wrote:
> I tried to play this with VLC, and just got a black screen.
> Windows Media Player wouldn't even play it.

It played fine for me, right in the browser, even with my flaky hardware
and spotty Internet:
Firefox 140.3.0esr (64 bit)
openSUSE Leap 15.6 GNU/Linux

[Kenneth] Re: Robot Lightning Chess [183 days 15 hours and 39 minutes ago]

Sat, 4 Oct 2025 23:40:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> I tried to play this with VLC, and just got a black screen.
> Windows Media Player wouldn't even play it.
>

[running Windows 10]
The download plays OK for me in VLC (my older version, 3.0.20), Irfanview, and
W.M.P.

[Bald Eagle] Re: Robot Lightning Chess [183 days 18 hours and 29 minutes ago]

Sat, 4 Oct 2025 20:50:00 GMT

"Maetes" <nomail@nomail> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > I tried to play this with VLC, and just got a black screen.
> > Windows Media Player wouldn't even play it.

> Win or LX?

Both Windows.
I haven't switched the laptop over to the linux dual-boot partition try try
there

[Maetes] Re: Robot Lightning Chess [183 days 18 hours and 34 minutes ago]

Sat, 4 Oct 2025 20:45:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> I tried to play this with VLC, and just got a black screen.
> Windows Media Player wouldn't even play it.
> ...


Win or LX?

m

[Bald Eagle] Re: Robot Lightning Chess [183 days 18 hours and 49 minutes ago]

Sat, 4 Oct 2025 20:30:00 GMT

I tried to play this with VLC, and just got a black screen.
Windows Media Player wouldn't even play it.

However VLC has been acting strangely over the past 2 days.

First, when I opened a sound file, there was no VLC interface on the desktop -
but it was playing the sound in the background.   I had to kill the process to
close it.

Then when i tried to play your video, When I closed VLC and tried to delete the
mp4, Win said that it was still open in VLC - and yep, there was a process still
open in the background that I had to end.

- BE

[Maetes] Re: Robot Lightning Chess [183 days 19 hours and 4 minutes ago]

Sat, 4 Oct 2025 20:15:00 GMT

Few ideas:
let the robots sometimes think a while.
or let them stop before grabbing, and choose another move.
and move the camera, maybe slowly aroud the scene, but always a tiny bit.

ma

[Maetes] Re: Robot Lightning Chess [183 days 19 hours and 9 minutes ago]

Sat, 4 Oct 2025 20:10:00 GMT

"Clarence1898" <dle### [at] comcastnet> wrote:
> Going through an old archive I found this animation I wrote 20 years ago.


Looks really really cool :)
Cant wait to see Version 2.0

Ma

[Clarence1898] Robot Lightning Chess [183 days 20 hours and 44 minutes ago]

Sat, 4 Oct 2025 18:35:00 GMT

Going through an old archive I found this animation I wrote 20 years ago.  I
wanted to make a few additions but couldn't believe the code I wrote.  Decided I
could do a better job 2nd time around.  The rewrite isn't finished yet so still
a work in progress.

[Maetes] Re: Update to my first POV animation [262 days 6 hours and 34 minutes ago]

Fri, 18 Jul 2025 08:45:00 GMT

Whow, looks cool!
Some kind of realistic.
I'm curious about the next version.

I have never created indoor-animations :)

If you need some furniture:
https://www.f-lohmueller.de/pov_tut/objects/obj_220e.htm

Ma

[Cousin Ricky] Update to my first POV animation [262 days 14 hours and 54 minutes ago]

Fri, 18 Jul 2025 00:24:23 GMT

The metal textures are improved, using micronormal blurred reflection
rather than partial diffuse reflection, as the first version did.

The floor uses finish-level Fresnel, which was unavailable in POV-Ray
3.5.  I had long suspected a problem with POV-Ray's Fresnel reflection,
but couldn't confirm my suspicion until clipka posted "Another tweak
towards realism" to p.b.i in February 2013.  Since then, I have found a
workaround for older POV-Ray versions, but it wasn't something I could
reliably come up with prior to having a realistic Fresnel implementation
to compare it with.  (See the "Moving indoors" thread from August 2021
in p.b.i for my workaround.)

The fade distance on the light source is very much shortened, making it
much closer to true inverse squared attenuation.  (True inverse squared
attenuation is not used, due to a photon mapping bug in 3.8 beta.)  I
also changed the lamp globe from clear glass to frosted.

I rendered each frame to EXR and post-processed them for iris
diffraction.  I eliminated highlights on the floor and metallic
surfaces, relying entirely on the post-processing for light blooming
effects.

[Josh English] Re: Wave Function Collapse Animation [271 days 10 hours and 29 minutes ago]

Wed, 9 Jul 2025 04:49:26 GMT

On 7/8/2025 10:25 AM, Bald Eagle wrote:

> 
> https://github.com/mxgmn/WaveFunctionCollapse
> 
> https://robertheaton.com/2018/12/17/wavefunction-collapse-algorithm/
> 
> https://github.com/CodingTrain/Wave-Function-Collapse
> 
> Plus lots more links.

Thank you. I spent some time refactoring the code to get the macros in 
sections in the main include file so I could sort of trace what is going 
on in the whole process.

> 
> This is definitely something to develop for general use!

I'm probably committing the sin of overgeneralizing the code right now 
because I want to also try this with hexagons and eventually cubes.

> 
> Glad you're still at it Josh - from the days of the POVcyclopedia to now.  :)
> 
> - BW
> 

I'm surprised anyone remembers that project. I found the original html 
and it still had the webring links in.

All that's left is on my homepage: https://joshuarenglish.com/povray/

Uncle Josh

[Bald Eagle] Re: Wave Function Collapse Animation [271 days 21 hours and 49 minutes ago]

Tue, 8 Jul 2025 17:30:00 GMT

Josh English <Jos### [at] joshuarenglishcom> wrote:
> On 7/5/2025 10:51 PM, William F Pokorny wrote:
>
> >
> > I have only the vaguest notion of what your doing here, but it's a cool
> > animation! :-)
> >
> > Bill P.
>
> Same here, my friend.
>
> Same here.
>
> Josh

https://github.com/mxgmn/WaveFunctionCollapse

https://robertheaton.com/2018/12/17/wavefunction-collapse-algorithm/

https://github.com/CodingTrain/Wave-Function-Collapse

Plus lots more links.

This is definitely something to develop for general use!

I have been tied with this and that for a while, but would love to see continued
development of this, both as a reminder for me to work on this, and so that we
can have a collaborative effort to really explore the potential of what we can
do with this in SDL.

Glad you're still at it Josh - from the days of the POVcyclopedia to now.  :)

- BW

[Josh English] Re: Wave Function Collapse Animation [273 days 19 hours and 36 minutes ago]

Sun, 6 Jul 2025 19:42:33 GMT

On 7/5/2025 10:51 PM, William F Pokorny wrote:

> 
> I have only the vaguest notion of what your doing here, but it's a cool 
> animation! :-)
> 
> Bill P.

Same here, my friend.

Same here.

Josh

[William F Pokorny] Re: Wave Function Collapse Animation [274 days 9 hours and 27 minutes ago]

Sun, 6 Jul 2025 05:51:41 GMT

On 7/4/25 23:15, Josh English wrote:
> This was a bear. Since the algorithm relies on a random state that can't 
> be preserved between frames, the only solution I found was a script that 
> generated all the possibilities at every turn of the solve and a second 
> script that read them all and created the frames. That's 2 text files 
> and a frame for every step of the algorithm.
> 
> But I have it working and I've ironed out the bugs I have found.
> 
> Uncle Josh

I have only the vaguest notion of what your doing here, but it's a cool 
animation! :-)

Bill P.

[Josh English] Wave Function Collapse Animation [275 days 12 hours and 4 minutes ago]

Sat, 5 Jul 2025 03:15:06 GMT

This was a bear. Since the algorithm relies on a random state that can't 
be preserved between frames, the only solution I found was a script that 
generated all the possibilities at every turn of the solve and a second 
script that read them all and created the frames. That's 2 text files 
and a frame for every step of the algorithm.

But I have it working and I've ironed out the bugs I have found.

Uncle Josh

[jr] Re: Charles C 2007 [279 days 3 hours and 19 minutes ago]

Tue, 1 Jul 2025 12:00:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> ...
> I spent 5h in a crawlspace yesterday jacking up a floor and installing 16-foot
> beams.  Bet you're envious and sad you missed out. :P

damn, you can bet I am!  ;-)

> ...
> I have noticed that a lot can be done with ffmpeg - you can adjust the speed,
> file size, and all sorts of things.

pray tell..  my use of 'ffmpeg' is basic ('-q:v N' mostly :-)), and I only found
out the other day that it will accept file names with shell wildcards when given
a '-pattern_type' option.

> Yes, I figured the code would have to be "adjusted" to make it loop, and of
> course it might be challenging to get it do so in a visually smooth manner

agree, no easy way.

regards, jr.

[Bald Eagle] Re: Charles C 2007 [280 days 1 hour and 9 minutes ago]

Mon, 30 Jun 2025 14:10:00 GMT

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

> thank you.  will send an email, later today or tomorrow.

Hope to get a chance to look at that today/tomorrow.
I spent 5h in a crawlspace yesterday jacking up a floor and installing 16-foot
beams.  Bet you're envious and sad you missed out. :P

> I too would have liked (much) slower "movement", the problem is the #frames
> resulting; currently using 12th of degrees (Y rotation), wanted 16th or better
> :-).  btw, "looping" would require changing the code, no loop/repeat as written.

I have noticed that a lot can be done with ffmpeg - you can adjust the speed,
file size, and all sorts of things.

Yes, I figured the code would have to be "adjusted" to make it loop, and of
course it might be challenging to get it do so in a visually smooth manner.

- BW

[jr] Re: Charles C 2007 [281 days 9 hours and 39 minutes ago]

Sun, 29 Jun 2025 05:40:00 GMT

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

enjoy, jr.

[jr] Re: Charles C 2007 [281 days 9 hours and 44 minutes ago]

Sun, 29 Jun 2025 05:35:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > the link below is the result of my "fiddling" with his code,
> This looks great - hopefully I will get a chance to look that code over and see
> what else can be done with it!  :)

thank you.  will send an email, later today or tomorrow.

> > (at least one person finds it too long </grin>)
> I'm wondering if it were a slower speed, to yield a gentle, swirling motion - if
> a nice long (and/or looping) animation would just be some cool eye-candy for an
> inactive screen.

I too would have liked (much) slower "movement", the problem is the #frames
resulting; currently using 12th of degrees (Y rotation), wanted 16th or better
:-).  btw, "looping" would require changing the code, no loop/repeat as written.

regards, jr.

[Bald Eagle] Re: Charles C 2007 [282 days 21 hours and 49 minutes ago]

Fri, 27 Jun 2025 17:30:00 GMT

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

> the link below is the result of my "fiddling" with his code,

This looks great - hopefully I will get a chance to look that code over and see
what else can be done with it!  :)

> (at least one person finds it too long </grin>)

I'm wondering if it were a slower speed, to yield a gentle, swirling motion - if
a nice long (and/or looping) animation would just be some cool eye-candy for an
inactive screen.

- BW

[jr] Charles C 2007 [284 days 1 hour and 39 minutes ago]

Thu, 26 Jun 2025 13:40:00 GMT

hi,

sometime early 2007 "Charles C" posted code, which included the
'psychedelic_scrambler.pov' scene; good name I think, irresistable :-), file
attached.  the link below is the result of my "fiddling" with his code, rendered
courtesy of Yesbird's online service[*] which I currently cannot connect to.

<drive.google.com/file/d/147ThSLBZ6Ro5EIhYSJqEGdunzIVbJHI4/view?usp=sharing>
(at least one person finds it too long </grin>)

[*] <https://povlab.online>


enjoy, jr.

[Maetes] Re: Tussi - Flight No. 2 [292 days 16 hours and 44 minutes ago]

Tue, 17 Jun 2025 22:35:00 GMT

"Mr" <m******r******at_hotmail_dot_fr> wrote:
> The cloud on the right , I suppose has the highest quality settings and render
> time? It looks much better ... But if the one directly on its left is much
> faster, it is still quite an acceptable result ! Maybe there is a bug, but we
> see the bounding sphere with a darker shade... This may be a problem. have you
> played with RGBF vs RGBT vs RGBFT for colors? also if you use both a scattering
> and absorption, maybe using just one of those would suppress the issue?

Its a test-enviroment only.

The clouds differ in certain parameters and the random numbers used.
With this I want to find out which settings looks good.

For the right two, this are some parameters:
transmit: 0.9; turbulence: 0.5; scattering: 10
transmit: 0.9; turbulence: 0.8; scattering: 20

The sphere around is intentional.
If you make the media inside the sphere to big, the cloud gets cutted and that
look not good. Its a simple transmit I have to increase from 0.9 to 1.

Haven't finished it yet, it's still under development.
Has something else come up again :)

Ma

[Mr] Re: Tussi - Flight No. 2 [293 days 7 hours and 29 minutes ago]

Tue, 17 Jun 2025 07:50:00 GMT

"Maetes" <nomail@nomail> wrote:
> "Mr" <m******r******at_hotmail_dot_fr> wrote:
> > Here's some nitpicking:
> > * It feels your materials for lateral propulsion (whiter ones) are not emissive,
> > nor fading too transparency enough, too flat opaque.
>
> You're absolutely right. However, I usually tackle the ugliest detail first. If
> you compare Movie 1 and Movie 2, you'll see that the flame of the main engine
> was even uglier.
> See:
> https://www.maetes.com/en/povray-os/ma_tussi#flight-1
>
> For the boosters I think of something completely different, thick fat smoke
> plume, a lot of work :(
>
>
> > *Your  solar panels materials are too ambient/emissive, reminding LCD screens
> > use fresnel and albedo with conserve_energy wherever possible... one specificity
> > with solar panels if they are modeled as simple geometries, should have very
> > (maximal) complex texture:
> > I would use a finish map trick (two textures with different finishes, in the
> > entries of a texture_map factored by a (cell/contrasted leopard) pattern with a
> > recusion level if possible to do the less regular, much smaller sparky freckles.
> > use this pattern to separate cells and freckles of higher reflectivity from
> > their intervals. halving that reflectivity within cells but bearing both a phong
> > *and* a specular with each half of that value, to indicate a layered
> > transparency but use irisdescence to indicate metallic reflectivity (very low
> > turbulence) in the cells finish use metallic keyword for specularities to have
> > another layer with metallic colored spec/reflections and each phong/specular
> > should have different size/roughness.
>
> Same problem, ugliest parts first.
> I quickly conjured up the solar cells and put more emphasis on the movements.
>
> Textures and details are my biggest weakness anyway. It's just very tedious in
> Povray to change a texture a bit, render, see what has happened, change again,
> look... Wish there was a better way, or a tool.
>
>
> > * I think for landing you need a very tiny slight vibration or shake both of the
> > camera and the ship (its solar panels could even buldge slightly with  respect
> > to main frame, currenly, everything is too clean to give any sense of weight and
> > the miracle of lifting/damping it.
>
> Yes, its on my list.
> Its to clean and smooth, will work on it.
>
>
> > * The cloud cover should use scattering(only) media, its the very situation
> > where you need them to look good as seen from afar and crossed through.
> > https://www.geocities.ws/evilsnack/tut01.htm
> >
https://news.povray.org/povray.binaries.images/thread/%3Cweb.4dad7d3b9549be2894d713cc0%40news.povray.org%3E/
> >
https://news.povray.org/povray.binaries.images/thread/%3C4d5df00c%40news.povray.org%3E/
>
> Thanks for the links! Especially the first one, the tutorial is very helpful.
> You will hardly believe it, but I have tried clouds in the last few days, see
> result in the picture. Several clouds in side view and from above, with slight
> changes.
>
>
> > *(sorry I forgot a point, but I'm sure the next iterations will refocus :-P )
>
> You forgot about 100 points :)
> I have so many ideas what to do.
> I could work on it for the next years.
>
> Ma

The cloud on the right , I suppose has the highest quality settings and render
time? It looks much better ... But if the one directly on its left is much
faster, it is still quite an acceptable result ! Maybe there is a bug, but we
see the bounding sphere with a darker shade... This may be a problem. have you
played with RGBF vs RGBT vs RGBFT for colors? also if you use both a scattering
and absorption, maybe using just one of those would suppress the issue?

[Maetes] Re: Tussi - Flight No. 2 [302 days 2 hours and 49 minutes ago]

Sun, 8 Jun 2025 12:30:00 GMT

"Mr" <m******r******at_hotmail_dot_fr> wrote:
> * The cloud cover should use scattering(only) media, its the very situation
> where you need them to look good as seen from afar and crossed through.
> https://www.geocities.ws/evilsnack/tut01.htm

Thanks again for the link.
I haven't tested the clouds so far, but there is a rock generator on the page.
It randomly creates meshes for handsome, non-round rocks, with which I have made
my moon surface a bit prettier.
https://www.geocities.ws/evilsnack/inc.htm

The stones in the picture are all of one mesh, just different sizes and rotates.
My lunar surface is not perfect, but out of the Ugly-Top-3.

Have a nice day,
Ma

[Maetes] Re: Tussi - Flight No. 2 [303 days 5 hours and 39 minutes ago]

Sat, 7 Jun 2025 09:40:00 GMT

"Mr" <m******r******at_hotmail_dot_fr> wrote:
> Here's some nitpicking:
> * It feels your materials for lateral propulsion (whiter ones) are not emissive,
> nor fading too transparency enough, too flat opaque.

You're absolutely right. However, I usually tackle the ugliest detail first. If
you compare Movie 1 and Movie 2, you'll see that the flame of the main engine
was even uglier.
See:
https://www.maetes.com/en/povray-os/ma_tussi#flight-1

For the boosters I think of something completely different, thick fat smoke
plume, a lot of work :(

> *Your  solar panels materials are too ambient/emissive, reminding LCD screens
> use fresnel and albedo with conserve_energy wherever possible... one specificity
> with solar panels if they are modeled as simple geometries, should have very
> (maximal) complex texture:
> I would use a finish map trick (two textures with different finishes, in the
> entries of a texture_map factored by a (cell/contrasted leopard) pattern with a
> recusion level if possible to do the less regular, much smaller sparky freckles.
> use this pattern to separate cells and freckles of higher reflectivity from
> their intervals. halving that reflectivity within cells but bearing both a phong
> *and* a specular with each half of that value, to indicate a layered
> transparency but use irisdescence to indicate metallic reflectivity (very low
> turbulence) in the cells finish use metallic keyword for specularities to have
> another layer with metallic colored spec/reflections and each phong/specular
> should have different size/roughness.

Same problem, ugliest parts first.
I quickly conjured up the solar cells and put more emphasis on the movements.

Textures and details are my biggest weakness anyway. It's just very tedious in
Povray to change a texture a bit, render, see what has happened, change again,
look... Wish there was a better way, or a tool.

> * I think for landing you need a very tiny slight vibration or shake both of the
> camera and the ship (its solar panels could even buldge slightly with  respect
> to main frame, currenly, everything is too clean to give any sense of weight and
> the miracle of lifting/damping it.

Yes, its on my list.
Its to clean and smooth, will work on it.

> * The cloud cover should use scattering(only) media, its the very situation
> where you need them to look good as seen from afar and crossed through.
> https://www.geocities.ws/evilsnack/tut01.htm
>
https://news.povray.org/povray.binaries.images/thread/%3Cweb.4dad7d3b9549be2894d713cc0%40news.povray.org%3E/
>
https://news.povray.org/povray.binaries.images/thread/%3C4d5df00c%40news.povray.org%3E/

Thanks for the links! Especially the first one, the tutorial is very helpful.
You will hardly believe it, but I have tried clouds in the last few days, see
result in the picture. Several clouds in side view and from above, with slight
changes.

> *(sorry I forgot a point, but I'm sure the next iterations will refocus :-P )

You forgot about 100 points :)
I have so many ideas what to do.
I could work on it for the next years.

Ma

[Maetes] Re: Tussi - Flight No. 2 [303 days 6 hours and 14 minutes ago]

Sat, 7 Jun 2025 09:05:00 GMT

> Yadgar=22_Bleimann?= <yaz### [at] gmxde> wrote:
> On 27.04.25 10:01, Maetes wrote:
>
> > Stands for Tiny Ugly Science Satellite (and) Impactor.
>
> O.k., that's obvious!

Isn't it?

> What about attaching a Colognian Space Agency
> plate containing the "crowns and flames" coat-of-arms to its hull?

That's a really fantastic idea! I thought it was silly to put a NASA or ESA
sticker on it, but something with Cologne would be a great thing.
That's what I keep in mind for my launch vehicle - Vulture 9.

> Wiesu heiss dat Dingen dann Tussi? Usssinn deit dat Dingen wie en
> Muelltonn foer zom Mohnd zo fleje... is die Queen vun dr Ihrestross jetzt
> bei dr NASA? Leck misch in dr Taesch...

Ne koelsche Jung immen Povray-Forum, isch waerd jeck!
Koennemer jlatt ne koelner Povray-Symposium abhalde.
Jross zeroeck!

NIE MEEEEEHR ZWEITE LIGA!
Prost
Ma

PS: Wie hast du es geschafft, hier Umlaute reinzubringen?
Musste die aller per Hand ersetzen. Zeilen mit Umlauten wurden einfach
geloescht.

[Jörg "Yadgar" Bleimann] Re: Tussi - Flight No. 2 [303 days 21 hours and 34 minutes ago]

Fri, 6 Jun 2025 17:44:28 GMT

Hi(gh)!

On 27.04.25 10:01, Maetes wrote:

> Stands for Tiny Ugly Science Satellite (and) Impactor.

O.k., that's obvious! What about attaching a Colognian Space Agency 
plate containing the "crowns and flames" coat-of-arms to its hull?

See you in Khyberspace!

Yadgar

-- 
VBI BENE, IBI BACTRIA!

[Jörg "Yadgar" Bleimann] Re: Tussi - Flight No. 2 [303 days 21 hours and 38 minutes ago]

Fri, 6 Jun 2025 17:40:18 GMT

On 26.04.25 23:10, Maetes wrote:
> I love Povray animations.
> 
> https://www.maetes.com/en/blog/tussi_flight_number_2_povray
> 
> I have given a year-old film various upgrades.
> Far from perfect, but looks much nicer.
> 
> Does anyone have ideas or half-finished scripts for:
> - Earth surface
> - Moon surface
> - Cloudcover (during launch)
> ?
> 
> Have a nice day (sunny and warm days ahead in Cologne/Germany)
> Martin
> 
> https://bsky.app/profile/martinseydler.bsky.social

Wiesu heiÃŸ dat Dingen dann Tussi? Usssinn deit dat Dingen wie en 
MÃ¼lltonn fÃ¶r zom Mohnd zo fleje... is die Queen vun dr
IhrestroÃŸ jetzt 
bei dr NASA? Leck misch in dr TÃ¤sch...

Ã„wwer lauwÃ¤rm *rÃ¼lps*!

Jattgahr, dÃ¤ kÃ¶lsche Krat!

-- 
VBI BENE, IBI BACTRIA!

[Mr] Re: Tussi - Flight No. 2 [304 days 7 hours and 14 minutes ago]

Fri, 6 Jun 2025 08:05:00 GMT

"Maetes" <nomail@nomail> wrote:
> I love Povray animations.

You know what, we can feel your joy through the result it's motivational to
watch, and not only because of the music !
The colors of the space and planets may well be spot on.

> Does anyone have ideas or half-finished scripts for:
> - Earth surface
> - Moon surface
> - Cloudcover (during launch)

Here's some nitpicking:
* It feels your materials for lateral propulsion (whiter ones) are not emissive,
nor fading too transparency enough, too flat opaque.

*Your  solar panels materials are too ambient/emissive, reminding LCD screens
use fresnel and albedo with conserve_energy wherever possible... one specificity
with solar panels if they are modeled as simple geometries, should have very
(maximal) complex texture:
I would use a finish map trick (two textures with different finishes, in the
entries of a texture_map factored by a (cell/contrasted leopard) pattern with a
recusion level if possible to do the less regular, much smaller sparky freckles.
use this pattern to separate cells and freckles of higher reflectivity from
their intervals. halving that reflectivity within cells but bearing both a phong
*and* a specular with each half of that value, to indicate a layered
transparency but use irisdescence to indicate metallic reflectivity (very low
turbulence) in the cells finish use metallic keyword for specularities to have
another layer with metallic colored spec/reflections and each phong/specular
should have different size/roughness.

* I think for landing you need a very tiny slight vibration or shake both of the
camera and the ship (its solar panels could even buldge slightly with  respect
to main frame, currenly, everything is too clean to give any sense of weight and
the miracle of lifting/damping it.

* The cloud cover should use scattering(only) media, its the very situation
where you need them to look good as seen from afar and crossed through.
https://www.geocities.ws/evilsnack/tut01.htm
https://news.povray.org/povray.binaries.images/thread/%3Cweb.4dad7d3b9549be2894d713cc0%40news.povray.org%3E/
https://news.povray.org/povray.binaries.images/thread/%3C4d5df00c%40news.povray.org%3E/

*(sorry I forgot a point, but I'm sure the next iterations will refocus :-P )

[Maetes] Re: Tussi - Flight No. 2 [334 days 5 hours and 49 minutes ago]

Wed, 7 May 2025 09:30:00 GMT

"Leroy" <whe### [at] gmailcom> wrote:
> Thanks! Download it already. The reason I didn't put those cords in was probably
> time. I made that for a contest. I other thing to worry about and it looked
> good.

No problem, I know the time required only too well. I saw the small mistakes and
just HAD to fix them. But it was a nice division of labor, I think.

I stopped when I was thinking about an unfolding process, and that would cost me
days again :)

ma

[Leroy] Re: Tussi - Flight No. 2 [334 days 15 hours and 59 minutes ago]

Tue, 6 May 2025 23:20:00 GMT

"Maetes" <nomail@nomail> wrote:
> "Maetes" <nomail@nomail> wrote:
> > Will send you the code when ready.
>
> Here the code for now.
> Maybe I will do some more in the next days.
>
> Gr
> Ma

Thanks! Download it already. The reason I didn't put those cords in was probably
time. I made that for a contest. I other thing to worry about and it looked
good.

[Maetes] Re: Tussi - Flight No. 2 [335 days 1 hour and 19 minutes ago]

Tue, 6 May 2025 14:00:00 GMT

"Maetes" <nomail@nomail> wrote:
> Will send you the code when ready.

Here the code for now.
Maybe I will do some more in the next days.

Gr
Ma

[Maetes] Re: Tussi - Flight No. 2 [335 days 15 hours and 24 minutes ago]

Mon, 5 May 2025 23:55:00 GMT

"Leroy" <whe### [at] gmailcom> wrote:
> And don't worry about the skull. One day when less expected, Wham it'll come to
> you.

I worked far longer than week on the robot AND THAT DID NOT HAPPEN !!!

- - -

Parachute successfully opened!

I fixed some small errors (missing cords in the gap, ...) and will make it more
variable in the next days, but so far the chute looks cute :)

Will send you the code when ready.

Thanks for that.
To build that from scratch would cost much more time.

Ma

[Leroy] Re: Tussi - Flight No. 2 [336 days 19 hours and 54 minutes ago]

Sun, 4 May 2025 19:25:00 GMT

"Maetes" <nomail@nomail> wrote:
>
> And the damn skull, I hadn't even touched it yet.
>
> And... and... AND...
>

Not a bad bot. You could make an army of them!
And don't worry about the skull. One day when less expected, Wham it'll come to
you.

>
> The parachute would be cool, but please please don't waste hours and days. Maybe
> I won't use it or only in x months. If it's easy to extract - great, if not,
> don't do it.

It was very easy and small. Here it is:

 #declare PPig=pigment{radial color_map{[0 Black][.1 Tan]
                    [.3 rgb<.9,.9,.85>][.6 rgb<.9,.8,.85>]
                    [.9 Tan][1 Black]}
                    frequency 20}
 #declare Para= union{sphere{0,4 translate y*2
                    clipped_by{ box {<-4.1,4.4,-4.1>,<4.1,5.9,4.1>}}}
                    sphere{0,4 translate y*2
                    clipped_by{ box {<-4.1,3.5,-4.1>,<4.1,2,4.1>}}}
                    cone{y*2,4,-y*.25,3.9 open}
                    }
#declare ParaChute=
 union{
  object{Para pigment{PPig} translate y*50}
  sphere{0,1 scale<1,.25,1> translate y*25 pigment{rgb<.25,.15,.25>}}

 //cords
   #declare Cnt = 0;
  #while (Cnt < 360)
   cylinder{0,<4,20,0>,.05 rotate y*Cnt pigment{Tan*.5} translate y*30}
  #declare Cnt = Cnt+20;
  #end
   cone{y*25,.15,y*31,.2 pigment{rgb 0}}//short link
   cylinder{0,y*30,.15 pigment{rgb 0}}//long link
 }

Straight from the code, It is fairly long 50 or so POV units.

Have Fun!

[jr] Re: Tussi - Flight No. 2 [337 days 1 hour and 39 minutes ago]

Sun, 4 May 2025 13:40:00 GMT

hi,

"Maetes" <nomail@nomail> wrote:
> "Leroy" <whe### [at] gmailcom> wrote:
> >  The robot ...
> And the damn skull, I hadn't even touched it yet.
> And... and... AND...

"bonus" for a good name, _v_ nice.


regards, jr.

[Maetes] Re: Tussi - Flight No. 2 [337 days 3 hours and 39 minutes ago]

Sun, 4 May 2025 11:40:00 GMT

"Leroy" <whe### [at] gmailcom> wrote:
>  The robot was one of the my first. I was still trying to set up the frame to
> frame pose animation and get things organize. A Robot is a complicated object.
> And to get one moving even more complicated.
>  There's about 60 variables to make a robot. So I cut a robot into 3 parts
> Body,Face,Hands. Each of these have their own pose files and object files. The
> object file would take the pose variables and make the part.
>  I better watch it or I'll write a whole page of nothing but how to build and
> animate robots. To make a long story longer. I have to say I have a Robot
> Factory now that can combine different bodies,heads and hands into a BOT and
> then animate it. But I'm never satisfied I keep adding on to it.

I solved so many really tricky problems one after the other, only to find that I
hadn't even done a quarter of the way.

It started with from where to where build it up. This affects how it behaves in
not-standing positions (e.g. leaning to the side, jumping,...) and how he can be
controlled.

And then, of course, the appearance, how the individual parts can be human-like.

And the damn skull, I hadn't even touched it yet.

And... and... AND...

>  As for the code It's on my other computer and it's isolated. That is I need to
> load stuff to a flash drive to get to this computer. The code large & might call
> somethings long gone. I haven't rerun it all. But what I did stopped. But the
> parachute show be easy to get. Just how much do ya want?

The parachute would be cool, but please please don't waste hours and days. Maybe
I won't use it or only in x months. If it's easy to extract - great, if not,
don't do it.

Gr
Ma

[Leroy] Re: Tussi - Flight No. 2 [337 days 20 hours and 54 minutes ago]

Sat, 3 May 2025 18:25:00 GMT

"Maetes" <nomail@nomail> wrote:
> "js" wrote:
> I knew the video!
> Have seen it month or even years before.
> From 2005? How long did you render ... a week?
> Nice work.

You're Right about the date. A few years latter I add the audio. The render time
was about 34 hours, not counting putting it all together into a mpg. I found the
code for IT with no problem (well I did forget the name it was saved under).
Likely some time in the pass I put all my animations in a folder on my XP.

>
> I have also tried my hand at a humanoid robot, but the work did not stop and did
> not stop. But I would love to have one, or even a human figure. Wouldn't have to
> be lifelike. Better a little comic than badly realistic.

 The robot was one of the my first. I was still trying to set up the frame to
frame pose animation and get things organize. A Robot is a complicated object.
And to get one moving even more complicated.
 There's about 60 variables to make a robot. So I cut a robot into 3 parts
Body,Face,Hands. Each of these have their own pose files and object files. The
object file would take the pose variables and make the part.
 I better watch it or I'll write a whole page of nothing but how to build and
animate robots. To make a long story longer. I have to say I have a Robot
Factory now that can combine different bodies,heads and hands into a BOT and
then animate it. But I'm never satisfied I keep adding on to it.

>
> If it's not too much work, see if you can find the code. I, on the other hand,
> cannot promise that I will use any of it in the near future, so don't hurry. You
> won't believe it, I like the parachute, I might need it soon :)
>

 As for the code It's on my other computer and it's isolated. That is I need to
load stuff to a flash drive to get to this computer. The code large & might call
somethings long gone. I haven't rerun it all. But what I did stopped. But the
parachute show be easy to get. Just how much do ya want?

> We Povrayers should exchange or provide much more code anyway, there are so few
> of us.

I thought we ruled the world!

[Maetes] Re: Tussi - Flight No. 2 [339 days 17 hours and 19 minutes ago]

Thu, 1 May 2025 22:00:00 GMT

"js" wrote:
> I look forward to further work by you.

You will hear from me! (Schwarzenegger-voice)

"Leroy" <whe### [at] gmailcom> wrote:
>
> The Mars video I made is on my website http://leroyw.byethost15.com
> It's under 'Videos' name 'Exploring Mars'(of course)

I knew the video!
Have seen it month or even years before.
From 2005? How long did you render ... a week?
Nice work.

I have also tried my hand at a humanoid robot, but the work did not stop and did
not stop. But I would love to have one, or even a human figure. Wouldn't have to
be lifelike. Better a little comic than badly realistic.

If it's not too much work, see if you can find the code. I, on the other hand,
cannot promise that I will use any of it in the near future, so don't hurry. You
won't believe it, I like the parachute, I might need it soon :)

We Povrayers should exchange or provide much more code anyway, there are so few
of us.

Gr
Ma

[Leroy] Re: Tussi - Flight No. 2 [342 days 17 hours and 34 minutes ago]

Mon, 28 Apr 2025 21:45:00 GMT

"Maetes" <nomail@nomail> wrote:
> "Leroy" <whe### [at] gmailcom> wrote:
>
> > Here's a place I used for the bump map of the moon!
> >
> > http://planetpixelemporium.com/earth8081.html
> >
>
>
> Sorry Leroy, I misunderstood your answer or you misunderstood my request.
>
> I need nice environments for take-off and landing. In the case of the moon,
> something with gentle hills, which should also look like a lunar landscape in
> terms of coloring. I haven't been able to do it properly so far.
>
> Even an attempt to use the global maps for this only cost me hours of time.
>
> I have enough sources for views from orbit. Moon and Mars with horizontal
> resolutions > 16,000 pixels.
>
> Ma

I understood what you wanted to Land and maybe take off from the moon. I landed
on mars awhile back. What I did is take just a part the 'bump_map' that I needed
and turn it into an height_field and then use the matching part of an
'image_map' for the pigment. I thought the Web address I gave you had both.

The Mars video I made is on my website http://leroyw.byethost15.com
It's under 'Videos' name 'Exploring Mars'(of course)

I wish I could tell how it was all done but it was a looooooooog time ago and
I've sleep since then. If you need the code I can look it up.

Have Fun!

[jr] Re: Tussi - Flight No. 2 [342 days 22 hours and 59 minutes ago]

Mon, 28 Apr 2025 16:20:00 GMT

hi,

"Maetes" <nomail@nomail> wrote:
> ...
> Acronyms are very important in the space-industry.
> Do you KRUSTY? Or DUFF?

when I read "DUFF", I "saw" Homer & Barney raising their cans </grin>.
(and no, hadn't known either acronym before)

> In german language "Tussi" means something like "underfunded diva". Fits
> perfectly, because working with the space probe is sometimes really annoying.
>
> If I didn't have burnout in my bones and could use the time better, I would
> create entire comic animations. I have a lot of ideas, let's see how far I get.

typo cosmic I guess.  a recent Quanta article had what looked like a usable map
of Io.
<www.quantamagazine.org/whats-going-on-inside-io-jupiters-volcanic-moon-20250425/>

I look forward to further work by you.

regards, jr.

[Maetes] Re: Tussi - Flight No. 2 [343 days 17 hours and 4 minutes ago]

Sun, 27 Apr 2025 22:15:00 GMT

"Leroy" <whe### [at] gmailcom> wrote:

> Here's a place I used for the bump map of the moon!
>
> http://planetpixelemporium.com/earth8081.html
>

Sorry Leroy, I misunderstood your answer or you misunderstood my request.

I need nice environments for take-off and landing. In the case of the moon,
something with gentle hills, which should also look like a lunar landscape in
terms of coloring. I haven't been able to do it properly so far.

Even an attempt to use the global maps for this only cost me hours of time.

I have enough sources for views from orbit. Moon and Mars with horizontal
resolutions > 16,000 pixels.

Ma

[Maetes] Re: Tussi - Flight No. 2 [343 days 17 hours and 9 minutes ago]

Sun, 27 Apr 2025 22:10:00 GMT

"Leroy" <whe### [at] gmailcom> wrote:
> Here's a place I used for the bump map of the moon!
> http://planetpixelemporium.com/earth8081.html
> P.S You have a Nice video!

Thanks.
His Earth looks really good.
One of my (many) next projects :(
Sources for moon-maps I have (USGS).
But the complete pluto-maps are new to me.

"JR" wrote:
> thank you for expanding the acronym.

Acronyms are very important in the space-industry.
Do you KRUSTY? Or DUFF?
https://en.wikipedia.org/wiki/Kilopower

In german language "Tussi" means something like "underfunded diva". Fits
perfectly, because working with the space probe is sometimes really annoying.

If I didn't have burnout in my bones and could use the time better, I would
create entire comic animations. I have a lot of ideas, let's see how far I get.

The Animation below shows Cif - Camera Installation Front.
Yes, I know, there is still a long way to go.

Nice evening,
Martin

[Leroy] Re: Tussi - Flight No. 2 [343 days 22 hours and 29 minutes ago]

Sun, 27 Apr 2025 16:50:00 GMT

"Maetes" <nomail@nomail> wrote:
> I love Povray animations.
>
> https://www.maetes.com/en/blog/tussi_flight_number_2_povray
>
> I have given a year-old film various upgrades.
> Far from perfect, but looks much nicer.
>
> Does anyone have ideas or half-finished scripts for:
> - Earth surface
> - Moon surface
> - Cloudcover (during launch)
> ?
>
> Have a nice day (sunny and warm days ahead in Cologne/Germany)
> Martin
>
> https://bsky.app/profile/martinseydler.bsky.social

Here's a place I used for the bump map of the moon!

http://planetpixelemporium.com/earth8081.html

Have fun!

P.S You have a Nice video!

[jr] Re: Tussi - Flight No. 2 [343 days 23 hours and 49 minutes ago]

Sun, 27 Apr 2025 15:30:00 GMT

hi,

"Maetes" <nomail@nomail> wrote:
> ...
> You're totally wrong:

has happened before.. </grin>


> Stands for Tiny Ugly Science Satellite (and) Impactor.

thank you for expanding the acronym.


> The ANIMATION / VIDEO you can be found on the Website !!!!!
> ...
> Here ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

got it ;-).


regards, jr.

[Maetes] Re: Tussi - Flight No. 2 [344 days 7 hours and 14 minutes ago]

Sun, 27 Apr 2025 08:05:00 GMT

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

> question - why "Tussi" ?  (a not-quite girlfriend, iirc)
>
> regards, jr.

You're totally wrong:
Stands for Tiny Ugly Science Satellite (and) Impactor.

The ANIMATION / VIDEO you can be found on the Website !!!!!

https://www.maetes.com/en/blog/tussi_flight_number_2_povray

Here ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

ma

[jr] Re: Tussi - Flight No. 2 [344 days 8 hours and 49 minutes ago]

Sun, 27 Apr 2025 06:30:00 GMT

hi,

"Maetes" <nomail@nomail> wrote:
> I love Povray animations.
> ...
> Have a nice day (sunny and warm days ahead in Cologne/Germany)
> Martin

thanks, and enjoy the rest of your weekend.  I (very much) like the still you
posted.

question - why "Tussi" ?  (a not-quite girlfriend, iirc)

regards, jr.

[Maetes] Tussi - Flight No. 2 [344 days 18 hours and 4 minutes ago]

Sat, 26 Apr 2025 21:15:00 GMT

I love Povray animations.

https://www.maetes.com/en/blog/tussi_flight_number_2_povray

I have given a year-old film various upgrades.
Far from perfect, but looks much nicer.

Does anyone have ideas or half-finished scripts for:
- Earth surface
- Moon surface
- Cloudcover (during launch)
?

Have a nice day (sunny and warm days ahead in Cologne/Germany)
Martin

https://bsky.app/profile/martinseydler.bsky.social

[Bald Eagle] Re: Some bivariate slices of rational Bezier tri... [367 days 2 hours and 54 minutes ago]

Fri, 4 Apr 2025 12:25:00 GMT

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
https://en.wikipedia.org/wiki/Dupin_cyclide#Dupin_cyclides_and_geometric_inversions
>
> That's some interesting transforms.
>
> It would be an interesting exercise to experiment with them.

I think you get a lot of bang for your buck.
Check out the "Pappus Chain" thread.

> > So you could start with a cylinder, invert it into a torus, and then re-invert
> > it into a cone.  :D  Invert it again into a Dupin cyclide, and then you could
> > invert a final time back to the original cylinder and have QUITE the cyclic
> > animation!

> I'm not sure if I'm able to follow your line of thinking - sorry.

If you follow the diagrams, you'll see that the inversion sphere is a kind of
geometric mirror. And depending upon how the shape and sphere are oriented to
one another, you can get different results.  It's quite the "fun house" mirror.

So my thought was:

A Dupin cyclide can be obtained by inversion of either a ring torus, a cylinder,
or a cone.
Start with a ring torus and invert it to a Dupin cyclide through the appropriate
inversion sphere.
But now, since a Dupin cyclide can be inverted to a cylinder, invert it through
a different sphere to get the cylinder.
Then invert it back to a different Dupin cyclide with yet another inversion
sphere,
and then invert it to a cone with another sphere.
That can be inverted to a Dupin cyclide again,
which can be inverted to the original ring torus.

The real trick is to calculate the parameters of the shapes and the inversion
sphere to get the desired shapes upon each new inversion.

> You can hold any of u, v and w constant and then vary the remaining
> ones with code or by the clock. The result could be a point, a curve,
> a patch or a kind of "solid".

OK, I think I had plain vanilla Bezier surfaces in my mind when you were working
with rational (weighted) Bezier patches.

I will now return you to your regularly scheduled programming.  :)

- BW

[Tor Olav Kristensen] Re: Some bivariate slices of rational Bezier tri... [367 days 15 hours and 14 minutes ago]

Fri, 4 Apr 2025 00:05:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
>
> > > Have you thought about geometrically inverting the patches to become a cylinder
> > > or a cone?  :D
> >
> > I'm not sure what you mean by "inverting the patches".
> >
> > I have not yet made cones with Bezier patches. But I have made
> > cylinders. This document shows an example:
> >
> >
https://github.com/t-o-k/Maxima-bezier/blob/main/cylinder_made_with_4_rational_bezier_surfaces_3d.pdf
>
> https://en.wikipedia.org/wiki/Dupin_cyclide#Dupin_cyclides_and_geometric_inversions

That's some interesting transforms.

It would be an interesting exercise to experiment with them.


> So you could start with a cylinder, invert it into a torus, and then re-invert
> it into a cone.  :D  Invert it again into a Dupin cyclide, and then you could
> invert a final time back to the original cylinder and have QUITE the cyclic
> animation!
>
> > The attached image shows the 3x3x3 = 3x9 = 27 control points for
> > two of the patches in the animation. Note that the patches do
> > not get very close to the 9 cyan "intermediate" control points.
>
> Ah yes - that makes it much clearer.
>
> Though if you're interpolating between control grids composed of u,w
> coordinates, via splines controlled by u, then technically u and w are
> parametric equations in u even not explicitly written that way.   Right? (?)

I'm not sure if I'm able to follow your line of thinking - sorry.

You can hold any of u, v and w constant and then vary the remaining
ones with code or by the clock. The result could be a point, a curve,
a patch or a kind of "solid".

E.g.:
If you let u be a constant, let v be controlled by the clock - and
vary w with some code, then a bicubic Bezier curve that wiggles
around within the 3x3x3 grid can be shown (in an animation).


> Beautiful work as always.
> I always enjoy the ballet of the math and graphics, and admire and appreciate
> the skill and discipline to make it all happen.
>
> I'm glad you had the free time to put this one together.  :)

Thank you very much Bill!

    =)

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

[Bald Eagle] Re: Some bivariate slices of rational Bezier tri... [375 days 15 hours and 34 minutes ago]

Wed, 26 Mar 2025 23:45:00 GMT

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:

> > Have you thought about geometrically inverting the patches to become a cylinder
> > or a cone?  :D
>
> I'm not sure what you mean by "inverting the patches".
>
> I have not yet made cones with Bezier patches. But I have made
> cylinders. This document shows an example:
>
>
https://github.com/t-o-k/Maxima-bezier/blob/main/cylinder_made_with_4_rational_bezier_surfaces_3d.pdf

https://en.wikipedia.org/wiki/Dupin_cyclide#Dupin_cyclides_and_geometric_inversions

So you could start with a cylinder, invert it into a torus, and then re-invert
it into a cone.  :D  Invert it again into a Dupin cyclide, and then you could
invert a final time back to the original cylinder and have QUITE the cyclic
animation!

> The attached image shows the 3x3x3 = 3x9 = 27 control points for
> two of the patches in the animation. Note that the patches do
> not get very close to the 9 cyan "intermediate" control points.

Ah yes - that makes it much clearer.

Though if you're interpolating between control grids composed of u,w
coordinates, via splines controlled by u, then technically u and w are
parametric equations in u even not explicitly written that way.   Right? (?)

Beautiful work as always.
I always enjoy the ballet of the math and graphics, and admire and appreciate
the skill and discipline to make it all happen.

I'm glad you had the free time to put this one together.  :)

- BW

[Tor Olav Kristensen] Re: Some bivariate slices of rational Bezier tri... [375 days 15 hours and 59 minutes ago]

Wed, 26 Mar 2025 23:20:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 3/26/25 07:48, Tor Olav Kristensen wrote:
> > Here all the boxes are drawn "within" a quadrivariate (u, v, w, t), where the
> > animation clock controls the t parameter.
>
> I like it! Cool.

Thank you Bill!

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

[Tor Olav Kristensen] Re: Some bivariate slices of rational Bezier tri... [375 days 15 hours and 59 minutes ago]

Wed, 26 Mar 2025 23:20:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Hi TOK,
> I'll have to wait until I'm home to access dataduppedings.no/
>
> But in the meantime,
>
> > The attached animation shows 5 x 3 = 15 animated bivariate patches.
> > Each patch is drawn "within" a trivariate (u, v, w) whose control grid consists
> > of 3x3x3 = 27 points.
>
> So, they are quadratic Bezier surfaces?

Yes, rational quadratic Bezier surfaces.


> > Each patch is drawn by varying both the v and w parameters of the trivariate
> > from 0.0 to 1.0, while the animation clock, running from 0.0 to 1.0, is
> > controlling the u parameter.
>
> and then the u parameter gets interpolated between its 3 control points along an
> "orthogonal" quadratic Bezier spline.  And I'm assuming that v and w are
> parametric equations of u.

The corners of the patches are influenced by 3 points only - and
the edges of the patches are influenced by 9 points.

But elsewhere in the patches all 27 control points are used in the
calculations (if I have understood this correctly).

And v and w are not parametric equations of u.

Here's some untested and non optimal code that shows the roles of
u, v and w:

#declare QuadraticBlendFns =
    array[3] {
        function(s) { (1 - s)*(1 - s) },
        function(s) { (1 - s)*s },
        function(s) { s*s }
    }
;

#macro TrivariateQuadraticBezierFunction(CC)

    function(_u, _v, _w) {
        0.0
        #for (K, 0, 2)
            #for (J, 0, 2)
                #for (I, 0, 2)
                    +
                    QuadraticBlendFns[I](_u)
                    *
                    QuadraticBlendFns[J](_v)
                    *
                    QuadraticBlendFns[K](_w)
                    *
                    CC[I][J][K]
                #end // for
            #end // for
        #end // for
    }

#end // macro TrivariateQuadraticBezierFunction


> That's pretty cool.

Thank you =)


> Have you thought about geometrically inverting the patches to become a cylinder
> or a cone?  :D

I'm not sure what you mean by "inverting the patches".

I have not yet made cones with Bezier patches. But I have made
cylinders. This document shows an example:

https://github.com/t-o-k/Maxima-bezier/blob/main/cylinder_made_with_4_rational_bezier_surfaces_3d.pdf

Here's some more untested code that shows how to use the clock
to "slice" the trivariate functions into bivariate functions.

XX, YY and ZZ are 3x3x3 arrays with the X, Y and coordinates
of the 3x3x3 control points.

#declare TrivariateFnX = TrivariateQuadraticBezierFunction(XX);
#declare TrivariateFnY = TrivariateQuadraticBezierFunction(YY);
#declare TrivariateFnZ = TrivariateQuadraticBezierFunction(ZZ);

#declare U = clock;

#declare BivariateFnX = function(_v, _w) { TrivariateFnX(U, _v, _w) };
#declare BivariateFnY = function(_v, _w) { TrivariateFnY(U, _v, _w) };
#declare BivariateFnZ = function(_v, _w) { TrivariateFnZ(U, _v, _w) };

#declare dV = 1/100;
#declare dW = 1/100;

#declare AnimatedMesh =
    mesh {
        #declare W0 = 0.0;
        #for (K, 1, 100)
            #declare W1 = W0 + dW;
            #declare V0 = 0.0;
            #for (J, 1, 100)
                #declare V1 = V0 + dV;
                #declare p00 =
                    <
                        BivariateFnX(V0, W0),
                        BivariateFnY(V0, W0),
                        BivariateFnZ(V0, W0)
                    >
                ;
                #declare p01 =
                    <
                        BivariateFnX(V0, W1),
                        BivariateFnY(V0, W1),
                        BivariateFnZ(V0, W1)
                    >
                ;
                #declare p10 =
                    <
                        BivariateFnX(V1, W0),
                        BivariateFnY(V1, W0),
                        BivariateFnZ(V1, W0)
                    >
                ;
                #declare p11 =
                    <
                        BivariateFnX(V1, W1),
                        BivariateFnY(V1, W1),
                        BivariateFnZ(V1, W1)
                    >
                ;
                triangle { p00, p10, p11 }
                triangle { p11, p01, p00 }
                #declare V0 = V1;
            #end // for
            #declare W0 = W1;
        #end // for
    }

The attached image shows the 3x3x3 = 3x9 = 27 control points for
two of the patches in the animation. Note that the patches do
not get very close to the 9 cyan "intermediate" control points.

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

[William F Pokorny] Re: Some bivariate slices of rational Bezier tri... [376 days and 34 minutes ago]

Wed, 26 Mar 2025 14:45:14 GMT

On 3/26/25 07:48, Tor Olav Kristensen wrote:
> Here all the boxes are drawn "within" a quadrivariate (u, v, w, t), where the
> animation clock controls the t parameter.

I like it! Cool.

Bill P.

[Bald Eagle] Re: Some bivariate slices of rational Bezier tri... [376 days and 49 minutes ago]

Wed, 26 Mar 2025 14:30:00 GMT

Hi TOK,
I'll have to wait until I'm home to access dataduppedings.no/

But in the meantime,

> The attached animation shows 5 x 3 = 15 animated bivariate patches.
> Each patch is drawn "within" a trivariate (u, v, w) whose control grid consists
> of 3x3x3 = 27 points.

So, they are quadratic Bezier surfaces?

> Each patch is drawn by varying both the v and w parameters of the trivariate
> from 0.0 to 1.0, while the animation clock, running from 0.0 to 1.0, is
> controlling the u parameter.

and then the u parameter gets interpolated between its 3 control points along an
"orthogonal" quadratic Bezier spline.  And I'm assuming that v and w are
parametric equations of u.



That's pretty cool.

Have you thought about geometrically inverting the patches to become a cylinder
or a cone?  :D


- BW

[Tor Olav Kristensen] Some bivariate slices of rational Bezier trivari... [376 days 3 hours and 29 minutes ago]

Wed, 26 Mar 2025 11:50:00 GMT

Hi

The attached animation shows 5 x 3 = 15 animated bivariate patches.
Each patch is drawn "within" a trivariate (u, v, w) whose control grid consists
of 3x3x3 = 27 points.

Each patch is drawn by varying both the v and w parameters of the trivariate
from 0.0 to 1.0, while the animation clock, running from 0.0 to 1.0, is
controlling the u parameter.

This is analogous to what happens in this animation:
https://dataduppedings.no/subcube/POV-Ray/NURBS-Quadrivariate_Deformation.mpg

Here all the boxes are drawn "within" a quadrivariate (u, v, w, t), where the
animation clock controls the t parameter.

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

[William F Pokorny] Re: Test text animation for upcoming yuqk R19 [379 days 1 hour and 51 minutes ago]

Sun, 23 Mar 2025 13:27:32 GMT

On 3/22/25 12:23, Alain Martel wrote:
> That's some great improvement.

Thanks!

Bill P.

[Alain Martel] Re: Test text animation for upcoming yuqk R19 [379 days 22 hours and 56 minutes ago]

Sat, 22 Mar 2025 16:23:12 GMT

Le 2025-03-22 Ã  07:56, William F Pokorny a Ã©critÂ :
> Attached a test animation which makes use of updates and fixes to the 
> text{} object in the upcoming R19 release of yuqk.
> 
> On the top, the traditional union{} of individual characters internally 
> created with text{}. On the bottom a new, optional, alternate merge{} 
> representation of the characters in the text{} string.
> 
> Also using the offset vector to start with all the characters 
> overlapping; after which using the animation clock to space them out 
> more normally with updates to the x component of the offset vector. A 
> fix for the z component of the offset vector necessary too, to avoid 
> coincident surfaces.
> 
> Bill P.

That's some great improvement.

[William F Pokorny] Test text animation for upcoming yuqk R19 [380 days 3 hours and 22 minutes ago]

Sat, 22 Mar 2025 11:56:50 GMT

Attached a test animation which makes use of updates and fixes to the 
text{} object in the upcoming R19 release of yuqk.

On the top, the traditional union{} of individual characters internally 
created with text{}. On the bottom a new, optional, alternate merge{} 
representation of the characters in the text{} string.

Also using the offset vector to start with all the characters 
overlapping; after which using the animation clock to space them out 
more normally with updates to the x component of the offset vector. A 
fix for the z component of the offset vector necessary too, to avoid 
coincident surfaces.

Bill P.

[yesbird] Re: Lidar data visualization in VR [381 days 2 hours and 6 minutes ago]

Fri, 21 Mar 2025 13:12:28 GMT

On 18/03/2025 22:08, yesbird wrote:
> This animation produced by rendering Paul Bourke's lidar
> visualization scene and published with VR support:
> https://povlab.yesbird.online/pb/lidar_video.html
> -- 
> YB
> 
Video now completed and contains 1201 frames (48.04 seconds)
in one direction.
--
YB

[yesbird] Lidar data visualization in VR [383 days 20 hours and 10 minutes ago]

Tue, 18 Mar 2025 19:08:22 GMT

This animation produced by rendering Paul Bourke's lidar
visualization scene and published with VR support:
https://povlab.yesbird.online/pb/lidar_video.html
--
YB

[jr] Re: Looking at font file content as mp4 [390 days 20 hours and 39 minutes ago]

Tue, 11 Mar 2025 18:40:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 3/10/25 10:02, jr wrote:
> > ran into trouble straightaway (sorry).  ...
> Ah, guessing you didn't run as an animation? (The +kff1311 at the top of
> the boolObjPlay.pov file)
>
> Me offering an excuse. :-) The scene should run frame 1 without using an
> animation setting. Change the line:
> ...

ok, got it, thanks.


regards, jr.

[William F Pokorny] Re: Looking at font file content as mp4 [391 days 5 hours and 3 minutes ago]

Tue, 11 Mar 2025 10:16:07 GMT

On 3/10/25 10:02, jr wrote:
> ran into trouble straightaway (sorry).  tried with a couple of different fonts
> and keep getting a (the same) negative character width ?  (see attached)  I can
> access the first 4 pages/1024 glyphs in the font ('streetsign.ttf') ok using a
> different scene.  using yuqk a5c25dda.

Ah, guessing you didn't run as an animation? (The +kff1311 at the top of 
the boolObjPlay.pov file)

Me offering an excuse. :-) The scene should run frame 1 without using an 
animation setting. Change the line:

#local I = (frame_number-1)*CharsPerPage;

to

#local I = max(0,frame_number-1)*CharsPerPage;

Bill P.

Aside: The 'frame_number' is set to zero, if not running an animation - 
or if you try to render only the first frame with '+kfi1 +kff1' (+kfi2 
+kff2 works as does rendering any single frame >2)(*).

(*) Yep. The '+kfi1 +kff1' flags not working for frame 1 is quirky. On 
my list to look at it some day. I'm afraid to just change behavior 
without thinking more about why things might be set up as they are...

Aside 2: Be forewarned. I did the character image comparisons with SDL 
so the entire animation takes many hours for typically sparse BMP font 
implementations.

[jr] Re: Looking at font file content as mp4 [392 days 1 hour and 14 minutes ago]

Mon, 10 Mar 2025 14:05:00 GMT

hi,

"jr" <cre### [at] gmailcom> wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> > My slightly cleaned up 'working files / code' attached. Unsure yet how
> > I'll include this code in the yuqk distribution.
> _thank_you_.  (tonight, I guess :-))

ran into trouble straightaway (sorry).  tried with a couple of different fonts
and keep getting a (the same) negative character width ?  (see attached)  I can
access the first 4 pages/1024 glyphs in the font ('streetsign.ttf') ok using a
different scene.  using yuqk a5c25dda.

regards, jr.

[jr] Re: Looking at font file content as mp4 [392 days 8 hours and 24 minutes ago]

Mon, 10 Mar 2025 06:55:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> My slightly cleaned up 'working files / code' attached. Unsure yet how
> I'll include this code in the yuqk distribution.
> ...
> Anyhow...

_thank_you_.  (tonight, I guess :-))

> ...other ways to query and present information about a font files.

in SDL.  the 'tabulated' macro comes with a shell script to view the first four
"pages" of glyphs, but would be easy "to monkey" to output an arbitrary set.
(fwiw)

regards, jr.

[Alain Martel] Re: Looking at font file content as mp4 [392 days 11 hours and 38 minutes ago]

Mon, 10 Mar 2025 03:40:23 GMT

Le 2025-03-08 Ã  21:26, William F Pokorny a Ã©critÂ :
> Partly due running down a bug in the text{} object; partly to test 
> yuqk's bool_object{} pattern with multiple objects (10 text{} objects 
> here); I've created animations of some mono font files.
> 
> With each font I rendered an animation at 50 characters per frame for 
> the entire Basic Multilingual Plane (BMP) of 2^16 possible characters. I 
> kept only those frames showing at least one supported character glyph 
> and I created an mp4 with those frame images at 1 per second.
> 
> The thought is maybe this is a good way to review what characters are 
> supported in a particular font alongside how POV-Ray is handling those 
> characters.
> 
> Attached is an animation of the hack-r font. It's a popular linux / unix 
> programmer's mono font.
> 
> Bill P.
> 
I once did something similar. The difference was that I had 256 
characters per frame and the character number was not clearly displayed. 
The columns where the hexadecimal unit, the line was the second digit, 
and the frame number for the third+ digit.

[William F Pokorny] Re: Looking at font file content as mp4 [392 days 20 hours and 37 minutes ago]

Sun, 9 Mar 2025 18:41:46 GMT

On 3/9/25 09:44, Bald Eagle wrote:
> Is there a significance to various parts of that plane?

https://en.wikipedia.org/wiki/Plane_(Unicode)

> Can you represent it like an RGB space so you can see the (valid) character
> density?  Maybe a pie chart?  Histogram?
> 
> Esp if you wanted to compare several font charts in the same render.

Yes, I expect other representations are possible. Ive not given it any 
detailed thought.

Many work and play with fonts. There are tools available which offer 
other ways to query and present information about a font files. In years 
past I've used a few of them - but other than ttfdump, my memory is 
failing me at the moment. :-)

Aside: I have on my list to make a go at creating polygon{} font-derived 
character objects somewhat automatically using the ttfdump output given 
yuqk's new potential pattern support for the polygon{} object, but we'll 
see.

Bill P.

[William F Pokorny] Re: Looking at font file content as mp4 [392 days 20 hours and 53 minutes ago]

Sun, 9 Mar 2025 18:25:35 GMT

On 3/9/25 05:25, jr wrote:
> ideally you'd post a scene file / ini combo too, where one only needs to change
> the name of the font.  (tia :-))

My slightly cleaned up 'working files / code' attached. Unsure yet how 
I'll include this code in the yuqk distribution.

Thinking aloud. There is in the posted 'Hack-Regular' and the 
'LiberationMono-Regular' a few character collapses of width not seen 
with 'UbuntuMono-R'. Also some character stand ins which differ between 
fonts - and it isn't clear to me why of these get used as they do.

The Ubuntu font is the only one which includes the 65533 character for 
code points beyond the BMP. It's interesting to me too how the fonts 
differ in the one-off characters they support.

Anyhow...

Bill P.

[Bald Eagle] Re: Looking at font file content as mp4 [393 days 1 hour and 34 minutes ago]

Sun, 9 Mar 2025 13:45:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

> With each font I rendered an animation at 50 characters per frame for
> the entire Basic Multilingual Plane (BMP) of 2^16 possible characters.

Is there a significance to various parts of that plane?
Can you represent it like an RGB space so you can see the (valid) character
density?  Maybe a pie chart?  Histogram?

Esp if you wanted to compare several font charts in the same render.

- BW

[jr] Re: Looking at font file content as mp4 [393 days 5 hours and 49 minutes ago]

Sun, 9 Mar 2025 09:30:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> Partly due running down a bug in the text{} object; partly to test
> yuqk's bool_object{} pattern with multiple objects (10 text{} objects
> here); I've created animations of some mono font files.
> ...
> The thought is maybe this is a good way to review what characters are
> supported in a particular font alongside how POV-Ray is handling those
> characters.

fwiw, agree.  I do like the "presentation".


> Attached is an animation of the hack-r font. It's a popular linux / unix
> programmer's mono font.

ideally you'd post a scene file / ini combo too, where one only needs to change
the name of the font.  (tia :-))


regards, jr.

[William F Pokorny] Looking at font file content as mp4 [393 days 12 hours and 52 minutes ago]

Sun, 9 Mar 2025 02:26:42 GMT

Partly due running down a bug in the text{} object; partly to test 
yuqk's bool_object{} pattern with multiple objects (10 text{} objects 
here); I've created animations of some mono font files.

With each font I rendered an animation at 50 characters per frame for 
the entire Basic Multilingual Plane (BMP) of 2^16 possible characters. I 
kept only those frames showing at least one supported character glyph 
and I created an mp4 with those frame images at 1 per second.

The thought is maybe this is a good way to review what characters are 
supported in a particular font alongside how POV-Ray is handling those 
characters.

Attached is an animation of the hack-r font. It's a popular linux / unix 
programmer's mono font.

Bill P.

[Bald Eagle] Re: Probably my POV first animation [396 days 14 hours and 4 minutes ago]

Thu, 6 Mar 2025 01:15:00 GMT

Mine was in 2013.
I was unemployed, and wanted to help out Pat Delany.

http://opensourcemachinetools.org/human-powered-generator-project-genny/

[Leroy] Re: Probably my POV first animation [396 days 15 hours and 14 minutes ago]

Thu, 6 Mar 2025 00:05:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
> (... Other than the ball.pov tutorial, that is.)
>
> I created this in January of 2004, but re-rendered it in 2022 after I
> discovered a better compression tool, cutting down the size by more than
> 60%.  I re-rendered it again just now when I decided than my 2022
> compression level was overkill. The attached file is 1/5 the size of the
> original render.
>
> Of course I am not satisfied with the metallic textures.  This was 2004.

Nice! My first animation is lost in time. What was that 'fmpg' in dos and with
Qbasic to make a mpg file. It took a couple of files beside the normal animation
image files. I remember a little about the code file, you picked when you use a
whole frame and when and how to interpret the next frame. My head hurts just
thinking about all the hours spent trying figure it out.

Have Fun!

[Cousin Ricky] Probably my POV first animation [397 days 12 hours and 50 minutes ago]

Wed, 5 Mar 2025 02:28:48 GMT

(... Other than the ball.pov tutorial, that is.)

I created this in January of 2004, but re-rendered it in 2022 after I
discovered a better compression tool, cutting down the size by more than
60%.  I re-rendered it again just now when I decided than my 2022
compression level was overkill. The attached file is 1/5 the size of the
original render.

Of course I am not satisfied with the metallic textures.  This was 2004.

[Josh English] Re: Playing with matrix transforms [400 days 21 hours and 2 minutes ago]

Sat, 1 Mar 2025 18:17:02 GMT

On 1/25/2025 6:47 AM, Kenneth wrote:
> 
> So I downloaded your video-- and it plays fine in*most* of my Windows 10 media
> players: VLC Media Player, SM Player, and even my old VirtualDub2. But it does
> not play in Windows' own Media Player (a black screen)-- and actually breaks
> Irfanview (the app hangs and has to be terminated via Windows Task Manager.)
> Irfanview will usually play just about any video that I throw at it, so its
> behavior in this case is very weird.
> 
> In VLC Media Player, I took a look at your first posted video's encoding
> statistics:
> 
> Codec: H264-MPEG-4 AVC (part 10) (avc1)
> Video Resolution: 450 X 450
> Buffer Dimensions: 464 X 482
> Decoded Format: Planar 4:4:4 YUV
> Color Primaries: ITU-R BT.709
> 
> I did some research (yet again!) about video encoding and codecs, because it is
> all so complicated to remember. Your video's stats are fairly standard stuff
> AFAIU-- except for the 4:4:4 chroma subsampling.  4:2:0 is the typical scheme
> for h.264; I use that myself. Take a look at Wikipedia's "h.264" page,
> particularly the subsection "Feature support in particular profiles". It appears
> that 4:4:4 is only supported in a particular high-end 'flavor' of h.264; perhaps
> that presents a problem for Firefox, and/or for Windows 10's built-in video
> codecs.

I'm late to reviewing this thread. I use ffmpeg on Windows 10 to make my 
animations.

ffmpeg -i <file_pattern> -c:v libx264 -strict -2 -preset slow -pix_fmt 
yuv420p -vf "scale=trunc(iw/2)*2:trunc(ih/2)*2" -f mp4 candle2.mp4

I think it's the -pix_fmt yuv420p that makes Windows Media Player like 
the file. It might by the -c:v libx264 that's doing it though. It's been 
a while and I don't remember.

Josh

[Bald Eagle] Re: Playing with matrix transforms [414 days 12 hours and 39 minutes ago]

Sun, 16 Feb 2025 02:40:00 GMT

OK, so I was diagramming this all out, and that got me to focus on the fact that
the text not only gets rotated, but MOVED.

That's because it's not rotating the text around the origin.
Just apply the following fix:


 object {
  Object
  translate -OL
  transform {Object_Transform}
  translate OL
 }
#end // end macro FaceCamera

[William F Pokorny] Testing bump_map and ii_offset. [414 days 21 hours and 58 minutes ago]

Sat, 15 Feb 2025 17:20:52 GMT

Attached is a derivative of one of my recent testing animations for the 
bump_map{} updates.

The set up is simple. It relies on one of two long undocumented features 
shipped with POV-Ray in 'offset' (called 'ii_offset' in the yuqk fork).

With it one can start an image outside of the usual <0,0> to <1,1> 
square image area variously mapped onto surfaces - and with 'ii_offset' 
slowly move the image through the unit square based upon the frame_number.

The essential bit of code is:

     ...
     #declare Nrml00 = normal {
         bump_map {
             "hmmI.png" gamma 1.0
             ii_interpolate   2
             ii_map_type      1
             ii_once
             #if     (frame_number>0 & frame_number<=150)
                 ii_offset <-1.1+(2.2/300)*frame_number,0>
             #elseif (frame_number>150 & frame_number<=300)
                 ii_offset <0,0>
             #else
                 ii_offset <-1.1+(2.2/300)*(frame_number-150),0>
             #end
         }
     }
     ...
     union {
         sphere { 0, 1
             pigment { rgb 1 }
             normal { Nrml00 bump_size +127 rotate +60*y}
         }
         sphere {
             <1,1,0>/sqrt(2), 0.02
             pigment {rgb <1,0,0> }
             rotate +60*y
         }
         #if (frame_number>150 & frame_number<=300)
             rotate <0,-(frame_number-150)/150*360,0>
         #end
     }

And when rendering add +kff450 to the command line.

Bill P.

Aside: The other long undocumented feature is 'repeat <2d vector>' or 
'ii_repeat' in the yuqk fork. With 'ii_repeat' one can both scale and 
repeat images within the 2D unit image space, but it's not used here.

[Bald Eagle] Re: Playing with matrix transforms [420 days and 59 minutes ago]

Mon, 10 Feb 2025 14:20:00 GMT

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

> So, I spent a bit of time working out how to do the "this object always faces
> the camera" thing,

And here's a bit more commentary to better explain how that works, and provide a
useful bit of code for future reference.

#macro FaceCamera (Object, CL)
 #local Min = min_extent (Object);
 #local Max = max_extent (Object);
 #local OL = Min + (Max-Min)/2;

 #declare CamL = CameraLocation;   // wherever you're putting it
 #declare CamD = vnormalize (OL-CamL);  // direction of camera view
  // One can alternately look at this as -Caml, translated to the object's
  // location by adding OL.  -CamL+OL = (OL-CamL)
 #declare CamR = vnormalize (vcross(y,CamD)); // to the right
  // The vector cross product gives a vector that is perpendicular to the two
  // given vectors.  If we're at the vertex (camera location) and we cross the
  // direction of view and the y-axis, we get a vector pointing out to the right
  // CamD and y are likely not perpendicular, so the resulting vcross is some
  // size != 1, so we normalize the size.
 #declare CamU = vnormalize (vcross(CamD,CamR)); // camera up
  // So now we have a view direction and a right vector, which are perpendicular
  // So we do another vector cross product, and get the new "up" vector
  // Which completes our new "frame of reference".
  // The tangent, normal, and binormal unit vectors, often called T, N, and B,
  // or collectively the Frenet–Serret frame (TNB frame or TNB basis)

  // So now when we take the old x, y, and z basis vectors or normal POV-space
  // and move them to align with the new TNB vectors, your object whose
  // orientation was based upon x, y, and z is now based upon the new
  // T, N, and B vectors.
  // Since default camera points at z, and default orientation of most objects
  // is in the xy plane, the object is now in the same relative orientation
  // to the camera in the new TNB frame, and so always faces the camera.
 #declare Object_Transform =
 transform {
  matrix <
  CamR.x, CamR.y, CamR.z,
  CamU.x, CamU.y, CamU.z,
  CamD.x, CamD.y, CamD.z,
      0,      0,      0
  >
 }

 object {
  Object
  transform {Object_Transform}
 }
#end // end macro FaceCamera

[Bald Eagle] Re: Playing with matrix transforms [420 days 3 hours and 19 minutes ago]

Mon, 10 Feb 2025 12:00:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> >
> > {Illusion.inc] is basically a different
> > way of applying an image_map to objects-- but from the camera's viewpoint, and
> > with a rather magical matrix manipulation that alters the 'depth perspective'
> > of the applied image.
> >
>
> It essentially applies the image_map as an 'orthographic' projection onto scene
> objects, devoid of perspective... which is quite different from a typical
> map_type 0 projection.

So, I spent a bit of time working out how to do the "this object always faces
the camera" thing, and it's essentially what gets done in screen.inc, minus the
final translation.

Compare that to Rune's "rather magical matrix manipulation" and you'll see that
it's basically the same thing.

So it looks to me that what's going on is, the image gets oriented to be
perpendicular to the camera / parallel to the image plane, and the divisions by
z in the image function are there to provide the appropriate scaling of the
image depending upon where it gets mapped to.

- BW

[Bald Eagle] Re: Playing with matrix transforms [426 days 17 hours and 9 minutes ago]

Mon, 3 Feb 2025 22:10:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> It is basically a different
> way of applying an image_map to objects-- but from the camera's viewpoint, and
> with a rather magical matrix manipulation that alters the 'depth perspective' of
> the applied image.

Yes, I get that part.

> Rune's matrix transform is quite mysterious (to me) because it uses the
> *camera's* settings, along with some math manipulations that are presently way
> over my head.

So, as best I can tell, he's simply done the kind of thing that's done in the
"make this object/text always face the camera"... with the matrix.

but the image_map is converted to a function that incorporates x/z and y/z which
also corrects for the projection matrix so that everything lines up no matter
how near or far.

I just haven;t had the time to figure out how to start applying his include to a
scene, so that I can reverse-engineer it enough to provide a didactic diagram
and explanation.

So if you have working code....   ;)

- BW

[Kenneth] Re: Playing with matrix transforms [426 days 17 hours and 34 minutes ago]

Mon, 3 Feb 2025 21:45:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> {Illusion.inc] is basically a different
> way of applying an image_map to objects-- but from the camera's viewpoint, and
> with a rather magical matrix manipulation that alters the 'depth perspective'
> of the applied image.
>

It essentially applies the image_map as an 'orthographic' projection onto scene
objects, devoid of perspective... which is quite different from a typical
map_type 0 projection.

[Kenneth] Re: Playing with matrix transforms [426 days 21 hours and 54 minutes ago]

Mon, 3 Feb 2025 17:25:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> > Rune's old 'illusion.inc' file is a prime example [of a complex matrix];
> > I use it a lot, but its workings are a mystery to me.
>
> I have never used it, and the instructions puzzle me.
> Perhaps if you could post a scene using it, and the intermediate render, then
> maybe I can have some idea how to use it and see how it works.
>

(Sorry for the delay, I was updating my own notes about illusion.inc and running
more test renders.)

Yeah, it was confusing to me as well when I first tried to use it-- mainly
because it is set up as a demonstration file rather than a basic include. And
the demonstration results are a bit confusing, IMO. It is basically a different
way of applying an image_map to objects-- but from the camera's viewpoint, and
with a rather magical matrix manipulation that alters the 'depth perspective' of
the applied image.

It is still available at
https://runevision.com/3d/include/

(Rune mentions that the download has a 2010 update by Sam Benge, which is
apparently no longer part of it; I checked recently.)

Back in 2013, I posted some preliminary info about how the include file works:
https://news.povray.org/povray.binaries.images/thread/%3Cweb.5106f53bd9b7ab13c2d977c20%40news.povray.org%3E/

I also posted a kind of explanatory animation at the time, but it is in
an older .avi video format:
https://news.povray.org/povray.binaries.animations/thread/%3Cweb.5106fb628df1613ec2d977c20%40news.povray.org%3E/?ttop=4
44658&toff=150

I should mention have been using my own simplified and slightly updated version
of the include file for years. I've had thoughts of posting it-- along with my
own set of instructions and a different demo-- but was worried that it might
infringe on Rune's original copyright notice from 2003. Although, I now see that
an update would probably be OK to post.

Rune's matrix transform is quite mysterious (to me) because it uses the
*camera's* settings, along with some math manipulations that are presently way
over my head.

[ingo] Re: Playing with matrix transforms [430 days and 9 minutes ago]

Fri, 31 Jan 2025 15:10:00 GMT

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

> I know that clipka was talking about trying to find as much common ground for
> all of the primitives as possible, so that we could have as few specialized
> objects/data structures as possible, so perhaps it would good to look at a lot
> of the spline/interpolation code as matrix-based.

There are a few fun things one can do with the matrix based spline calculations.
One can blend two spline matrices to a new spline, or over time morph from one
spline to an other spline type. But one needs access to POV-Ray's internals
then.

The whole spline matrices thing is covered here:

http://web.archive.org/web/20151002232205/http://home.comcast.net/~k9dci/site/?/page/Piecewise_Polynomial_Interpolation
/

Download the book PDF and the separate appendix.

ingo

[Bald Eagle] Re: Playing with matrix transforms [430 days and 54 minutes ago]

Fri, 31 Jan 2025 14:25:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

> Perhaps obvious the matrix play in this thread can act as a rotational
> interpolation.

Well now that we're going there - Bezier and other splines can all be
represented as matrix multiplications.

https://blog.demofox.org/2016/03/05/matrix-form-of-bezier-curves/

https://observablehq.com/@danburzo/the-matrix-form-of-some-common-cubic-splines

I know that clipka was talking about trying to find as much common ground for
all of the primitives as possible, so that we could have as few specialized
objects/data structures as possible, so perhaps it would good to look at a lot
of the spline/interpolation code as matrix-based.

We ought to have robust and versatile matrix methods available anyway.

Also, rotational matrices tie directly into complex numbers - so maybe there's a
way to roll that in there too.

- Bald "I want it all" Eagle

[William F Pokorny] Re: Playing with matrix transforms [430 days 2 hours and 21 minutes ago]

Fri, 31 Jan 2025 12:57:31 GMT

On 1/19/25 15:33, William F Pokorny wrote:
> Playing more with matrix transforms

Recently the idea of splines as interpolations was touched upon in the 
thread:

https://news.povray.org/povray.advanced-users/thread/%3Cweb.6797e39ce9acc1774cc51b5c25979125%40news.povray.org%3E/

Perhaps obvious the matrix play in this thread can act as a rotational 
interpolation.

Attached an animation and full scene file for the animation (for jr). It 
should run in v3.8 beta 2 too.

Bill P.

[Kenneth] Re: Playing with matrix transforms [433 days 23 hours and 29 minutes ago]

Mon, 27 Jan 2025 15:50:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 1/25/25 19:58, William F Pokorny wrote:
>
> > Next time I create an animation with ffmpeg, I'll try to get the 4:2:0
> > chroma sub-sampling.
>
> Alright. Found myself playing again today with a direct matrix transform
>  against yuqk's updated wrinkle pattern. The attached animation uses
> the sampling you suggested. Does it work in programs where failing before?
>

YES, this animation plays in all of my Windows media players, including
Irfanview. AND, it also plays in Firefox's 'preview'. Great work! Thanks for
taking the time to dig down into your settings for ffmpeg; very much
appreciated.

For this animation, my VLC Media Player does not report the particular 'chroma
subsampling' scheme that you used... but that seems to be its usual behavior
when encountering the 'typical' 4:2:0. So I guess the switch from 4:4:4 to 4:2:0
has solved the problem. That is interesting news! :-)

[William F Pokorny] Re: Playing with matrix transforms [434 days 1 hour and 38 minutes ago]

Mon, 27 Jan 2025 13:40:57 GMT

On 1/25/25 19:58, William F Pokorny wrote:
> Next time I create an animation with ffmpeg, I'll try to get the 4:2:0 
> chroma sub-sampling.

Alright. Found myself playing again today with a direct matrix transform 
  against yuqk's updated wrinkle pattern. The attached animation uses 
the sampling you suggested. Does it work in programs where failing before?

Bill P.

             matrix <
                 1.0, (frame_number-1)/60, 0.0,
                -(frame_number-1)/60, 1.0, 0.0,
                 0.0, 0.0, 1.0,
                 (frame_number-1)/57, (frame_number-1)/37, 0.0>

[Bald Eagle] Re: Playing with matrix transforms [434 days 19 hours and 54 minutes ago]

Sun, 26 Jan 2025 19:25:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
(Rune's old 'illusion.inc' file is a
> prime example; I use it a lot, but its workings are a mystery to me.)

I have never used it, and the instructions puzzle me.
Perhaps if you could post a scene using it, and the intermediate render, then
maybe I can have some idea how to use it and see how it works.

Also, this seems like the sort of perspective correction that Francois LE COAT
would know all about.

- BW

[William F Pokorny] Re: Playing with matrix transforms [434 days 23 hours and 50 minutes ago]

Sun, 26 Jan 2025 15:28:52 GMT

On 1/25/25 19:22, Tor Olav Kristensen wrote:
> For those of you that want to be able to do matrix calculations within POV-Ray,
> I have made a library that can do some of that.
> 
> It can be found here:
> 
> https://github.com/t-o-k/POV-Ray-matrices

Thank you for the reminder. I'd looked at what you have there before - 
but my memory failed me in moment.

While I was "thinking aloud" about what was happening with the checker 
rotation/shear 'stick poking' play, your package would have saved me a 
chunk of time.

I've added a link to your page from my yuqk matrix documentation text 
file - which I hope will help me remember.

Bill P.

[Kenneth] Re: Playing with matrix transforms [435 days 11 hours and 44 minutes ago]

Sun, 26 Jan 2025 03:35:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
> > That is also my usual method of playing with matrices, ha-- because I
> > still have a hard time understanding how they work and how to use them.
>
> A matrix is nothing more than a statement of the end position of each basis
> vector after the transformation.
> [clip]

Thanks for the useful info. Actually, the shearing ability of a matrix is one of
the (few) things that I do grasp. And William P's checkerboard rotation trick
has also been informative. But there are other more complex matrix transforms
that I have seen in newsgroup posts and include files that really baffle me, as
to how the 'magical' results are obtained. (Rune's old 'illusion.inc' file is a
prime example; I use it a lot, but its workings are a mystery to me.)

What I *need* to do is devote the time solely to learning the fundamentals-- and
without other POV-ray distractions. But that's difficult! Because there are
many *other* features that I only understand at a basic level...like
sophisticated functions! To truly learn all that I need to know, I could spend
25 hrs a day.

But every now and then, I have the urge to actually *render* something. ;-)

[William F Pokorny] Re: Playing with matrix transforms [435 days 14 hours and 21 minutes ago]

Sun, 26 Jan 2025 00:58:04 GMT

On 1/25/25 09:47, Kenneth wrote:
> I did some research (yet again!) about video encoding and codecs, because it is
> all so complicated to remember. Your video's stats are fairly standard stuff
> AFAIU-- except for the 4:4:4 chroma subsampling.  4:2:0 is the typical scheme
> for h.264; I use that myself. Take a look at Wikipedia's "h.264" page,
> particularly the subsection "Feature support in particular profiles". It appears
> that 4:4:4 is only supported in a particular high-end 'flavor' of h.264; perhaps
> that presents a problem for Firefox, and/or for Windows 10's built-in video
> codecs.
> 
> Or maybe you encoded the videos using 10-bit colors rather than the more
> standard 8-bit?

Hi Kenneth,

Excepting - maybe - the noise video where output grayscale and I 
remember trying the flag '-vf format=gray' to get a smaller mp4 file 
(made no difference), everything should be 8 bits because the png output 
is defaulting to 8 bits per channel.

Thank you for taking the time to investigate the problem you've seen 
with my ffmpeg encoded videos! I'm an amateur having encoded very few 
animations over the years - and I've posted fewer still.

I'd captured recommendations Dick Balaska made years ago for options 
(which included a '-pix_fmt yuv420p' setting), however, when I tried the 
command line late last year I kept getting errors I didn't understand.

Being lazy, I dropped back to a very simple command with a flag for 
frame rate, the input pattern for saved image frames and the output file 
name... Things seemed to work, so I went with ffmpeg's defaulting. :-) 

Next time I create an animation with ffmpeg, I'll try to get the 4:2:0 
chroma sub-sampling.

Bill P.

[Bald Eagle] Re: Playing with matrix transforms [435 days 14 hours and 49 minutes ago]

Sun, 26 Jan 2025 00:30:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:

> That is also my usual method of playing with matrices, ha-- because I still have
> a hard time understanding how they work and how to use them.

A matrix is nothing more than a statement of the end position of each basis
vector after the transformation.

For instance, when I do a shear along x, what I do is take "y" (<0, 1, 0>) and
shit it along the x-axis.  Maybe make it become <0.5, 1, 0>.

So matrix {
1, 0, 0,
0, 1, 0,
0, 0, 1,
0, 0, 0
}

becomes

matrix {
1, 0, 0,
0.5, 1, 0,
0, 0, 1,
0, 0, 0
}

Just think of the matrix operator as

matrix {
x,
y,
z,
translate <a, b, c>
}

and your matrix transform is

matrix {
new_x,
new_y,
new_z,
translate <a, b, c>
}

https://www.youtube.com/watch?v=kYB8IZa5AuE

https://www.f-lohmueller.de/pov_tut/trans/trans_000e.htm

[Tor Olav Kristensen] Re: Playing with matrix transforms [435 days 14 hours and 54 minutes ago]

Sun, 26 Jan 2025 00:25:00 GMT

For those of you that want to be able to do matrix calculations within POV-Ray,
I have made a library that can do some of that.

It can be found here:

https://github.com/t-o-k/POV-Ray-matrices
(NB: Some of the descriptions and examples are not finished yet.)

Below are some examples with this library that may be relevant to this thread.

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


// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

#version 3.7;  // Should also work in version 3.8

global_settings { assumed_gamma 1.0 }

#include "matrices.inc"

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

#declare No_Change_Transform = transform { }

#declare Rotate_Transform = transform { rotate 60*x }

#declare Shear_Transform =
    transform {
        matrix <
            1, 1, 0,
            0, 1, 0,
            0, 0, 1,
            0, 0, 0
        >
    }

#declare Translate_Transform = transform { translate <3, 1, 2> }

#declare Composite_Transform =
    transform {
        No_Change_Transform
        Rotate_Transform
        Shear_Transform
        Translate_Transform
    }

#debug "\nNo Change Transform:\n"
M_Print(M_FromTransform(No_Change_Transform))

#debug "\nRotate Transform:\n"
M_Print(M_FromTransform(Rotate_Transform))

#debug "\nShear Transform:\n"
M_Print(M_FromTransform(Shear_Transform))

#debug "\nTranslate Transform:\n"
M_Print(M_FromTransform(Translate_Transform))

#debug "\nComposite Transform:\n"
M_Print(M_FromTransform(Composite_Transform))

#debug "\n\n"

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

#declare No_Change_Matrix = M_Identity(4);

#declare Rotate_Matrix = M_Rotate3D_AroundX(radians(60));

#declare Shear_Matrix =
    array[4][4] {
        {  1.0,  1.0,  0.0,  0.0 },
        {  0.0,  1.0,  0.0,  0.0 },
        {  0.0,  0.0,  1.0,  0.0 },
        {  0.0,  0.0,  0.0,  1.0 }
    }
;

#declare Translate_Matrix = M_Translate3D(<3, 1, 2>);

#declare Composite_Matrix =
    M_Mult(
        M_Mult(
            M_Mult(
                No_Change_Matrix,
                Rotate_Matrix
            ),
            Shear_Matrix
        ),
        Translate_Matrix
    )
;

#debug "\nNo Change Matrix:\n"
M_Print(No_Change_Matrix)

#debug "\nRotate Matrix:\n"
M_Print(Rotate_Matrix)

#debug "\nShear Matrix:\n"
M_Print(Shear_Matrix)

#debug "\nTranslate Matrix:\n"
M_Print(Translate_Matrix)

#debug "\nComposite Matrix:\n"
M_Print(Composite_Matrix)

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

#debug "\n"
#error "No error, just finished"

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

[Kenneth] Re: Playing with matrix transforms [436 days and 29 minutes ago]

Sat, 25 Jan 2025 14:50:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> but I fully admit I'm just poking the matrix with a stick to
> see what happens. To some extent, I wonder about why it does what it
> does, but I care more about whether what it does might be useful.
>

That is also my usual method of playing with matrices, ha-- because I still have
a hard time understanding how they work and how to use them. I like your video
though; I need to experiment with your code example to see how I can break it!

------------
[In Windows 10]  I thought I should mention something: In the newsgroups'
standard web portal that I use, the Firefox 'previews' of your .mp4 videos do
not play -- with the message "Video cannot be played because the file is
corrupt." (which is not the case!) As a comparison: Josh's .mp4 animation in his
recent post  "Go home, RSOCP, yer drunk" plays fine in the Firefox preview.

So I downloaded your video-- and it plays fine in *most* of my Windows 10 media
players: VLC Media Player, SM Player, and even my old VirtualDub2. But it does
not play in Windows' own Media Player (a black screen)-- and actually breaks
Irfanview (the app hangs and has to be terminated via Windows Task Manager.)
Irfanview will usually play just about any video that I throw at it, so its
behavior in this case is very weird.

In VLC Media Player, I took a look at your first posted video's encoding
statistics:

Codec: H264-MPEG-4 AVC (part 10) (avc1)
Video Resolution: 450 X 450
Buffer Dimensions: 464 X 482
Decoded Format: Planar 4:4:4 YUV
Color Primaries: ITU-R BT.709

I did some research (yet again!) about video encoding and codecs, because it is
all so complicated to remember. Your video's stats are fairly standard stuff
AFAIU-- except for the 4:4:4 chroma subsampling.  4:2:0 is the typical scheme
for h.264; I use that myself. Take a look at Wikipedia's "h.264" page,
particularly the subsection "Feature support in particular profiles". It appears
that 4:4:4 is only supported in a particular high-end 'flavor' of h.264; perhaps
that presents a problem for Firefox, and/or for Windows 10's built-in video
codecs.

Or maybe you encoded the videos using 10-bit colors rather than the more
standard 8-bit?

I also did a search for possible Firefox problems regarding playback of
h.264 .mp4 files, but found nothing that would be helpful-- except for this
possibility:

"Yes, Firefox can play 4:4:4 videos, but only if your hardware and system
settings support it; this is because the capability to play 4:4:4 video depends
on your graphics card and the video codec used, not solely on the browser
itself."

(By the way: I had the same video-playback problems with your December 2024
post,
 "New f_dnoise(), modified f_dturbulence(). yuqk R17"
but forgot to mention it at the time.)

[jr] Re: Go home, RSOCP, yer drunk [437 days 4 hours and 14 minutes ago]

Fri, 24 Jan 2025 11:05:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
> > Good grief!  That's stronger than Bacardi 151, ...
> They stopped making it because we no longer have adults in the world who accept
> responsibility for their own behaviour.  Instead we have aged children asserting
> the false claim that they're adults.
> Then, when they hurt themselves with Big Boy drinks, they rush to blame anyone
> from themselves and seek to profit off of a corrupt judicial system, enabled by
> personal injury attorney with no moral compass (ambulance chasers).
> ...
> After all, they still manufacture and sell Everclear, which is not 151 proof,
> but 190 proof.

wow, nice, wondering now how eg pears compare "in Schnapps" vs in rum, might
need extra "botanicals" to flavour.

(and I liked reading how the 189-proof Everclear came about.  incidentally, the
brand name anagrams to "are clever" :-))


regards, jr.

[Bald Eagle] Re: Go home, RSOCP, yer drunk [437 days 22 hours and 24 minutes ago]

Thu, 23 Jan 2025 16:55:00 GMT

https://www.reddit.com/r/WTF/comments/1e5aga/man_sticks_hand_in_blender_theres_not_much_else/

You know what to do.  (Or not to do)

[Bald Eagle] Re: Go home, RSOCP, yer drunk [437 days 22 hours and 34 minutes ago]

Thu, 23 Jan 2025 16:45:00 GMT

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

> Good grief!  That's stronger than Bacardi 151, which they stopped making
> because it was basically a hazardous substance.

Ha!

They stopped making it because we no longer have adults in the world who accept
responsibility for their own behaviour.  Instead we have aged children asserting
the false claim that they're adults.
Then, when they hurt themselves with Big Boy drinks, they rush to blame anyone
from themselves and seek to profit off of a corrupt judicial system, enabled by
personal injury attorney with no moral compass (ambulance chasers).

Wikipedia:
Because of its high alcohol content, Bacardi 151 was particularly flammable
among liquors. For this reason it was often used as the ignition source for
"flaming shots"[3][4] and even for at-home pyrotechnic stunts.[5] The bottle
carried a warning label advising consumers, among other things, "do not use this
product for flaming dishes or other drinks." Bottles were also equipped with a
stainless steel flame arrester crimped onto the neck of the bottle to prevent
the rum inside the bottle from igniting. Nevertheless, Bacardi faced at least
two lawsuits from consumers who claimed to have been badly injured by the
product's flames.[6][7] While the company never issued a formal statement
regarding the product's discontinuation, it has been speculated that "it's a
pretty good guess that Bacardi got sick of being sued."[2]

After all, they still manufacture and sell Everclear, which is not 151 proof,
but 190 proof.

https://en.wikipedia.org/wiki/Everclear

We also have Red 40, hair dyes, gas pumps, aerosol carburetor cleaner, bleach,
sulfuric acid toilet bowl cleaner and muriatic acid, fireworks, lp gas,
automobiles, laser pointers, kitchen knives, acetaminophen, . . . it's nearly an
infinite list.

[Cousin Ricky] Re: Go home, RSOCP, yer drunk [437 days 23 hours and 52 minutes ago]

Thu, 23 Jan 2025 15:26:48 GMT

On 2025-01-21 01:10 (-4), MichaelJF wrote:
> Am 20.01.2025 um 21:45 schrieb Josh English:
>> On 1/19/2025 5:30 AM, jr wrote:
>>> +1. ('Strohrum' ?!Â  </grin>)
>>
>> I have to admit I don't know what Strohrum refers to. Sorry. I'm a bit
>> dense.
>>
>> Josh
> 
> Not quite my taste:
> 
> https://en.wikipedia.org/wiki/Stroh

Good grief!  That's stronger than Bacardi 151, which they stopped making
because it was basically a hazardous substance.

[William F Pokorny] Re: Playing with matrix transforms [439 days 16 hours and 18 minutes ago]

Tue, 21 Jan 2025 23:00:47 GMT

On 1/21/25 15:30, Bald Eagle wrote:
> The isosurface looks like a strange, but interesting result to me, because
> you're getting distortion of the square instead of the simple rotation like you
> do in the checker.
> It sort of looks like a camera iris - something to be pursued, I think.

Yes, I added a f_hypot(x,y) multiplier to the two 'rotation/shear terms' 
to create something more interesting than the square-frame rotating and 
shrinking.

Attaching two more mp4s. The one with the _BW.mp4 suffix removes that 
f_hypot() multiplier.

The one with the _SinCosHyp.mp4 suffix adds a sin() then cos() wrap of 
the f_hypot() multipliers. Done with the thought it might be 
interesting. :-)

Bill P.

[Bald Eagle] Re: Playing with matrix transforms [439 days 18 hours and 44 minutes ago]

Tue, 21 Jan 2025 20:35:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

> My original surprise at the result in the lower right image over in pbi
> came from setting up a matrix I knew was out of bounds for typical use.
> I didn't expect things to work like two separate shear matrices; I
> didn't know what would happen, but the result surprised me due how
> dramatically it whacked the checker pattern.

Now that I've reviewed it all, your initial result was due to making x-hat and
y-hat the same vector.  <1, 1, 0> Essentially collapsing 3d space into a plane.
Attempting to apply the inverse and getting a parse error therefore makes sense.

> The isosurface animation was itself another way to verify behavior.
> There is the usual pattern space to function space inversion. I
> un-inverted the rotation so it looked like the checker rotation. I left
> the scaling as is because scaling up of the function's coordinate space
> shrinks the isosurface result here - keeping the results in a fixed
> view/frame, so to speak.

The isosurface looks like a strange, but interesting result to me, because
you're getting distortion of the square instead of the simple rotation like you
do in the checker.
It sort of looks like a camera iris - something to be pursued, I think.

[William F Pokorny] Re: Playing with matrix transforms [439 days 20 hours and 30 minutes ago]

Tue, 21 Jan 2025 18:49:01 GMT

On 1/21/25 06:39, Bald Eagle wrote:
> 
> "Easiest" and fastest thing to do is stop speculating and crank out some
> numbers.
> 
> Have one shear matrix and another and apply them individually to a VECTOR, and
> spit out the result to #debug with vstr.
> 
> Then have POV-Ray sequentially apply the matrices and spit out the result.
> 
> Apply your matrix transforms to a "matrix" by matrix transforming your basic
> vectors x-hat, y-hat, and z-hat and stack the transform output in the #debug
> stream to see what matrix you're actually applying in both individual cases and
> your compound matrix transform case.
> 
> You can use the result vectors to plot spheres in a scene.
> Match them up with the corners of the checkerboard pattern.
> 
> If anything is mis-matched, it's probably not POV-Ray, but some matrix
> construction error.
> 
> Run all of the calculations with POV-Ray matrix transforms and vectors to check
> and verify your calculations in the above post.
> 
> - BW
> 

Hi Bill,

Your suggestions are reasonable ways we might better see what's 
happening. I suspect I've mislead you into thinking I believe something 
is amiss with how matrix transforms are working or with what I expect 
for a result.

My original surprise at the result in the lower right image over in pbi 
came from setting up a matrix I knew was out of bounds for typical use. 
I didn't expect things to work like two separate shear matrices; I 
didn't know what would happen, but the result surprised me due how 
dramatically it whacked the checker pattern.

I started to wonder what other useful direct matrix transformations 
there might be. The 'matrix form' posted about in this thread looks 
useful too, but I fully admit I'm just poking the matrix with a stick to 
see what happens. To some extent, I wonder about why it does what it 
does, but I care more about whether what it does might be useful.

The isosurface animation was itself another way to verify behavior. 
There is the usual pattern space to function space inversion. I 
un-inverted the rotation so it looked like the checker rotation. I left 
the scaling as is because scaling up of the function's coordinate space 
shrinks the isosurface result here - keeping the results in a fixed 
view/frame, so to speak.

I ran the animation out only to frame 50, but I did spot checks at 
frame_numbers 100 through 900 stepping by 100. An image of those renders 
is attached.

Bill P.

[Bald Eagle] Re: Playing with matrix transforms [440 days 3 hours and 39 minutes ago]

Tue, 21 Jan 2025 11:40:00 GMT

"Easiest" and fastest thing to do is stop speculating and crank out some
numbers.

Have one shear matrix and another and apply them individually to a VECTOR, and
spit out the result to #debug with vstr.

Then have POV-Ray sequentially apply the matrices and spit out the result.

Apply your matrix transforms to a "matrix" by matrix transforming your basic
vectors x-hat, y-hat, and z-hat and stack the transform output in the #debug
stream to see what matrix you're actually applying in both individual cases and
your compound matrix transform case.

You can use the result vectors to plot spheres in a scene.
Match them up with the corners of the checkerboard pattern.

If anything is mis-matched, it's probably not POV-Ray, but some matrix
construction error.

Run all of the calculations with POV-Ray matrix transforms and vectors to check
and verify your calculations in the above post.

- BW

[William F Pokorny] Re: Playing with matrix transforms [440 days 5 hours and 52 minutes ago]

Tue, 21 Jan 2025 09:26:59 GMT

On 1/20/25 15:44, Josh English wrote:
> Very cool. I'm very rusty on matrices. My guess is the smooth rotation 
> (I'm assuming the camera is not rotating at all here, or the plane, 
> other than what the matrix is doing) comes from the fact that the first 
> two groups of the transform matrix are orthogonal, so it rotates instead 
> of shears. The scaling happens because the first two "vectors" aren't 
> constrained to the unit vector.
> 
> Or did I misunderstand what you meant by "I don't 'really' understand 
> what's happening...' and just talk down to you by accident?

No worries. I'm a life long "never polished on matrices" guy - who, due 
aging, is rusting badly in all respects at this point! :-) Thank you for 
thinking about it and offering your view of how it is working. What you 
wrote is not too far off my guess. Differing only that I think we are 
both rotating and shearing with the matrices as I'm specifying them here.

You understand correctly that all that is happening is changing matrix 
transforms of the checker pattern on a fixed x,y plane at z==0 as seen 
by a fixed orthogonal camera.

I'd only ever used the matrix, direct specification feature for simple 
shears (to lean things). I vaguely understand what pure rotation, 
scaling and translation matrices looked like internally - and our 
documentation gives equations at:

   https://wiki.povray.org/content/Reference:Transformations#Matrix

I'm fuzzy about the rotation and shearing occurring together - and that 
both effects start with some speed before crawling toward some limit. 
Some thinking aloud.

If we do some left handed, positive rotations about the z axis the 
internal matrices would look like:

v00 v01 v02 v03
v10 v11 v12 v13
v20 v21 v22 v23
v30 v31 v32 v33

+1.000 +0.000 0.0 0.0 // rotate z*+0.0
-0.000 +1.000 0.0 0.0
+0.000 +0.000 1.0 0.0 // Bottom rows dropped hereafter
+0.000 +0.000 0.0 1.0

+0.996 +0.087 0.0 0.0 // rotate z*+5.0
-0.087 +0.996 0.0 0.0

+0.707 +0.707 0.0 0.0 // rotate z*+45.0
-0.707 +0.707 0.0 0.0

+0.000 +1.000 0.0 0.0 // rotate z*+90.0
-1.000 +0.000 0.0 0.0

-0.087 +0.996 0.0 0.0 // rotate z*+95.0
-0.996 -0.087 0.0 0.0

-0.707 +0.707 0.0 0.0 // rotate z*+135.0
-0.707 -0.707 0.0 0.0

-1.000 +0.000 0.0 0.0 // rotate z*+180.0
-0.000 -1.000 0.0 0.0

-0.996 -0.087 0.0 0.0 // rotate z*+185.0
+0.087 -0.996 0.0 0.0

So, with normal positive z rotations through 180 we have -v10 and +v01 
value polarities. The v00 and v11 values are adjusted throughout to 
counter the shear contribution (preventing a scaling effect).

In my scene I'm holding v00 and v11 at 1.0 while the magnitudes of -v10 
and +v01 are always increasing. Meaning there is no counter compensation 
for the shearing adder - and we effectively scale up on frame_number.

Each frame step represents a smaller an smaller delta relative to the 
prior 'magnitudes' and both rotation and scaling slow. The rotation 
itself can never quite reach +180 degrees; The scaling never quite 
infinity.

I'll also guess at this point, the initial rotation and scale speed is 
made faster because my scene has that 'scale 1/6'. I believe this means 
the starting v00 and v11 matrix values are 1/6 rather than 1.0 internally.

Reasonable thinking?

Attached another animation where I applied the matrix rotate+shear 
calculations being played with here to an isosurface where the 'shear' 
values are (+-) f_hypot(x,y)*(frame_number-1)/5.

Bill P.

[jr] Re: Go home, RSOCP, yer drunk [440 days 8 hours and 19 minutes ago]

Tue, 21 Jan 2025 07:00:02 GMT

hi,

MichaelJF <fri### [at] t-onlinede> wrote:
> Am 20.01.2025 um 21:45 schrieb Josh English:
> > On 1/19/2025 5:30 AM, jr wrote:
> > I have to admit I don't know what Strohrum refers to. Sorry. I'm a bit
> > dense.
> Not quite my taste:

the ideal stuff (the 80%) to pickle all kinds of soft fruits[*].  "Rumtopf" and
Vanilla ice cream :-).

[*] cherries ("Herzkirschen" ?, with stone & stalk), after a few years in rum
with a little demerara sugar, in particular.

regards, jr.

[MichaelJF] Re: Go home, RSOCP, yer drunk [440 days 10 hours and 8 minutes ago]

Tue, 21 Jan 2025 05:10:40 GMT

Am 20.01.2025 um 21:45 schrieb Josh English:
> On 1/19/2025 5:30 AM, jr wrote:
>> +1. ('Strohrum' ?!Â  </grin>)
> 
> I have to admit I don't know what Strohrum refers to. Sorry. I'm a bit 
> dense.
> 
> Josh

Not quite my taste:

https://en.wikipedia.org/wiki/Stroh

Best regards
Michael

[Josh English] Re: Go home, RSOCP, yer drunk [440 days 18 hours and 33 minutes ago]

Mon, 20 Jan 2025 20:45:41 GMT

On 1/19/2025 5:30 AM, jr wrote:
> +1. ('Strohrum' ?!  </grin>)

I have to admit I don't know what Strohrum refers to. Sorry. I'm a bit 
dense.

Josh

[Josh English] Re: Playing with matrix transforms [440 days 18 hours and 34 minutes ago]

Mon, 20 Jan 2025 20:44:54 GMT

On 1/19/2025 12:33 PM, William F Pokorny wrote:
> Ref:
> 
> https://news.povray.org/povray.binaries.images/thread/ 
> %3C678b9010%40news.povray.org%3E/
> 
> Playing more with matrix transforms mixing shears (and by side effect 
> rotation) led to the attached animation.
> 
> The entire animation part of the set up was:
> 
>  Â Â Â  matrix <
> 
Â Â Â Â Â Â Â 
1.0, (frame_number-1)/60, 0.0,
>  Â Â Â Â Â Â 
-(frame_number-1)/60, 1.0, 0.0,
> 
Â Â Â Â Â Â Â 
0.0, 0.0, 1.0,
> 
Â Â Â Â Â Â Â 
0.0, 0.0, 0.0>
> 
> Then using +kff480 on the command line to render 480 frames.
> 
> There is a 'scale 1/6' of the checker pattern following the matrix 
> transform in the base scene - which is slowly countered as the frame 
> number increases.
> 
> I don't 'really' understand what's happening in total. In any case, it's 
> cool, though, not as trippy as Josh's earlier post. :-)
> 
> Bill P.

Very cool. I'm very rusty on matrices. My guess is the smooth rotation 
(I'm assuming the camera is not rotating at all here, or the plane, 
other than what the matrix is doing) comes from the fact that the first 
two groups of the transform matrix are orthogonal, so it rotates instead 
of shears. The scaling happens because the first two "vectors" aren't 
constrained to the unit vector.

Or did I misunderstand what you meant by "I don't 'really' understand 
what's happening...' and just talk down to you by accident?

I had thought about shearing my meshes in the camera, so I will have 
work on that sooner rather than later.

Josh

[William F Pokorny] Playing with matrix transforms [441 days 18 hours and 46 minutes ago]

Sun, 19 Jan 2025 20:33:14 GMT

Ref:

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

Playing more with matrix transforms mixing shears (and by side effect 
rotation) led to the attached animation.

The entire animation part of the set up was:

     matrix <
         1.0, (frame_number-1)/60, 0.0,
        -(frame_number-1)/60, 1.0, 0.0,
         0.0, 0.0, 1.0,
         0.0, 0.0, 0.0>

Then using +kff480 on the command line to render 480 frames.

There is a 'scale 1/6' of the checker pattern following the matrix 
transform in the base scene - which is slowly countered as the frame 
number increases.

I don't 'really' understand what's happening in total. In any case, it's 
cool, though, not as trippy as Josh's earlier post. :-)

Bill P.

[yesbird] Re: Go home, RSOCP, yer drunk [441 days 19 hours and 41 minutes ago]

Sun, 19 Jan 2025 19:37:47 GMT

On 19/01/2025 04:00, Josh English wrote:
> Checking back in with my mesh camera tricks.
Looks very familiar ...
Don't remember where I could get such experience.
--
YB

[Alain Martel] Re: Go home, RSOCP, yer drunk [441 days 23 hours and 52 minutes ago]

Sun, 19 Jan 2025 15:26:48 GMT

Le 2025-01-18 Ã  20:00, Josh English a Ã©critÂ :
> Checking back in with my mesh camera tricks.
> 
> I hope the New Year is easier on you than it is my little
ðŸŽ‰ðŸ·ðŸ¾ðŸ¸ðŸ¹ðŸºðŸ»ðŸ¥‚RSOCP.
> 
> Josh
ðŸ¤£

[jr] Re: Go home, RSOCP, yer drunk [442 days 1 hour and 44 minutes ago]

Sun, 19 Jan 2025 13:35:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 1/18/25 20:00, Josh English wrote:
> > Checking back in with my mesh camera tricks.
> >
> > I hope the New Year is easier on you than it is my little RSOCP.
> >
> > Josh
>
> :-)

+1. ('Strohrum' ?!  </grin>)


regards, jr.

[William F Pokorny] Re: Go home, RSOCP, yer drunk [442 days 2 hours and 2 minutes ago]

Sun, 19 Jan 2025 13:16:52 GMT

On 1/18/25 20:00, Josh English wrote:
> Checking back in with my mesh camera tricks.
> 
> I hope the New Year is easier on you than it is my little RSOCP.
> 
> Josh

:-)

[Josh English] Go home, RSOCP, yer drunk [442 days 14 hours and 18 minutes ago]

Sun, 19 Jan 2025 01:00:55 GMT

Checking back in with my mesh camera tricks.

I hope the New Year is easier on you than it is my little RSOCP.

Josh

[Bald Eagle] Re: New f_dnoise(), modified f_dturbulence(). yu... [487 days 22 hours and 39 minutes ago]

Wed, 4 Dec 2024 16:40:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

> The work is still in progress, but two animations of working code
> attached. One for f_dnoise() and the other for f_dturbulenece().

If the noise is / could be made tileable, that second one would be a cool
looping animation.  Especially if it had a good color/texture map applied.

[William F Pokorny] New f_dnoise(), modified f_dturbulence(). yuqk R17 [488 days 9 hours and 6 minutes ago]

Wed, 4 Dec 2024 06:12:40 GMT

Creating noise related documentation for R17 of yuqk highlighted that 
I'd not implemented a planned f_dnoise() inbuilt wrapper function for 
the internal DNoise() function.

Three parameters of f_dnoise() amount to an independent, x,y,z 
translation of the 3D noise space. I back tracked and added these 
parameters to the existing f_dturbulence() function too. Thinking of it 
another way, it amounts to a 4D noise capability - which is itself an 
old idea suggested by others for POV-Ray.

Given how many isosurface functions end up defined about the origin or 
some other fixed 3D space, any 'noise' ends up relatively fixed / locked 
in/to that space too. It might be additional inbuilt 'noise' related 
functions in yuqk get extended in this way.

The work is still in progress, but two animations of working code 
attached. One for f_dnoise() and the other for f_dturbulenece(). The 
core isosurface functions for the animations below is:

     #include "functions.inc"
     #declare Fn00 = function (x,y,z,_v,_r) {
         f_sphere(x+f_dec3x_f21(_v,5,0),
                  y+f_dec3x_f21(_v,5,1),
                  z+f_dec3x_f21(_v,5,2),
                  _r+
                  (f_length(f_dec3x_f21(_v,5,0),
                          f_dec3x_f21(_v,5,1),
                          f_dec3x_f21(_v,5,2))*1.0)
         )
     }
     #declare Fn01 = function (x,y,z) {
         #if (1)
         Fn00(x,y,z,
             f_dturbulence(x,y,z,3,
                 0.1,0.1,0.1,
                 5,0.40,2.7,0.2,
                 frame_number*0.0005,
                 frame_number*0.0015,
                 frame_number*0.0030),
             0.7
         )
         #else
         Fn00(x,y,z,
             f_dnoise(x,y,z,3,
                 0.4,0.4,0.4,
                 frame_number*0.005,
                 frame_number*0.015,
                 frame_number*0.030),
             0.4
         )
         #end
     }

Bill P.

[Chris R] Scrabble (WIP) Animation [488 days 23 hours and 4 minutes ago]

Tue, 3 Dec 2024 16:15:00 GMT

I took a divergence in the Scrabble scene I have been working on to create
macros for setting up the game board and racks based on real game recordings.
After I got that working pretty well, I added macros to display views during the
play of a word to the board from a rack with a ghostly hand moving the tiles.
From there it is easy to create animations.

Since the scene is still in its single light-source stage, it takes about 10
seconds or less to render each frame, so I was able to create a 100-frame movie.
 There is something in my tile animation that is causing a jump when the tiles
transition from lifting above the rack to moving to the board, but you get the
idea...

-- Chris R

[William F Pokorny] Re: Animation via yuqk's f_hash() inbuilt function [490 days and 58 minutes ago]

Mon, 2 Dec 2024 14:20:49 GMT

On 12/2/24 05:47, Mr wrote:
> This is hypnotic, but maybe too small scaled to let us gaze at its evolution...
> Unless it can't show bigger cells ?

Thanks. It's admittedly a bit small at its native size. It was what I 
could do quickly while aiming for a 10 second animation at under 3MB. If 
your browser or viewer supports a full screen mode, you might find it 
some help - my old eyes do.

I have a two minute animation in my space with a slightly larger pixel 
resolution, larger 'noise-steps' and a much slower frame rate. The 
slower frame rate is better for viewing the evolution. The mp4, though, 
is a little over 29MB. I've attached the last frame of that animation.

The slower frame rates compress much less well (with my ffmpeg novice 
settings).

Bill P.

[Mr] Re: Animation via yuqk's f_hash() inbuilt function [490 days 4 hours and 29 minutes ago]

Mon, 2 Dec 2024 10:50:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> I recently made a post about rolling your own random noise generators
> with f_hash() over in the v4.0 forum:
>
>
https://news.povray.org/povray.pov4.discussion.general/thread/%3C674b018b%40news.povray.org%3E/
>
> I found myself with a few hours to burn this afternoon so I gave
> creating a special noise video a try based upon f_hash(). The core
> of the code is:
>
>      #include "functions.inc"
>      #declare Seed00 = 7834.5540283051168443;
>      #declare Delta = 880+frame_number*0.00002;
>      #declare Step = sqrt(Delta)      *0.00025;
>
>      #declare Fn2Dlen = function (x,y) {
>          f_2x_f32_vlength(f_enc2x_f32(x,y))
>      }
>      #declare Fn00 = function {
>          f_hash(
>              (
>              f_hash(Fn2Dlen(x+Delta,y+Delta),Seed00,Step,0)+
>              f_hash(Fn2Dlen(x-Delta,y+Delta),Seed00,Step,0)+
>              f_hash(Fn2Dlen(x+Delta,y-Delta),Seed00,Step,0)+
>              f_hash(Fn2Dlen(x-Delta,y-Delta),Seed00,Step,0)
>              ),
>          Seed00,0,0)
>      }
>
>      #declare Pigm00 = pigment {
>          function { Fn00(x,y,z) }
>      }
>
> Above there are four distance to x,y coordinate based f_hash()s feeding
> a final f_hash() function - all using the same seed value. An mp4 video
> attached.
>
> Bill P.

This is hypnotic, but maybe too small scaled to let us gaze at its evolution...
Unless it can't show bigger cells ?

[William F Pokorny] Animation via yuqk's f_hash() inbuilt function [490 days 17 hours and 1 minute ago]

Sun, 1 Dec 2024 22:17:50 GMT

I recently made a post about rolling your own random noise generators 
with f_hash() over in the v4.0 forum:

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

I found myself with a few hours to burn this afternoon so I gave 
creating a special noise video a try based upon f_hash(). The core
of the code is:

     #include "functions.inc"
     #declare Seed00 = 7834.5540283051168443;
     #declare Delta = 880+frame_number*0.00002;
     #declare Step = sqrt(Delta)      *0.00025;

     #declare Fn2Dlen = function (x,y) {
         f_2x_f32_vlength(f_enc2x_f32(x,y))
     }
     #declare Fn00 = function {
         f_hash(
             (
             f_hash(Fn2Dlen(x+Delta,y+Delta),Seed00,Step,0)+
             f_hash(Fn2Dlen(x-Delta,y+Delta),Seed00,Step,0)+
             f_hash(Fn2Dlen(x+Delta,y-Delta),Seed00,Step,0)+
             f_hash(Fn2Dlen(x-Delta,y-Delta),Seed00,Step,0)
             ),
         Seed00,0,0)
     }

     #declare Pigm00 = pigment {
         function { Fn00(x,y,z) }
     }

Above there are four distance to x,y coordinate based f_hash()s feeding 
a final f_hash() function - all using the same seed value. An mp4 video 
attached.

Bill P.

[yesbird] Re: multiple image_maps as media density-- ANIMA... [525 days 21 hours and 31 minutes ago]

Sun, 27 Oct 2024 17:47:23 GMT

On 27/10/2024 19:25, Kenneth wrote:
> When I make POV-ray videos now, I usually include the code I used, at the
> beginning of the animation (so that I know what I did for future reference!),
> then several duplicated frames of the first image render, *then* the animation
> begins. Maybe that is what you are seeing as the 'not smooth enough' problem?

Resetting VLC to defaults solved all the problems, sorry for the
inconvenience.
--
YB

[Kenneth] Re: multiple image_maps as media density-- ANIMA... [525 days 22 hours and 49 minutes ago]

Sun, 27 Oct 2024 16:30:00 GMT

yesbird <sya### [at] gmailcom> wrote:

>
> Looks nice, may be movement is not smooth enough, but impression is
> good in general.

When I make POV-ray videos now, I usually include the code I used, at the
beginning of the animation (so that I know what I did for future reference!),
then several duplicated frames of the first image render, *then* the animation
begins. Maybe that is what you are seeing as the 'not smooth enough' problem?

The video plays back well on the six(!) Windows video players I have--Windows
Media Player, Irfanview, VirtualDub2MOD, avidemux (an *old* one but still
useful), SMPlayer, and VLC.

I used VirtualDub2MOD to create the video.

[jr] Re: multiple image_maps as media density-- ANIMA... [526 days 2 hours and 49 minutes ago]

Sun, 27 Oct 2024 12:30:00 GMT

hi,

yesbird <sya### [at] gmailcom> wrote:
> On 27/10/2024 14:08, Alain Martel wrote:
> > Loops OK here, also using VLC. Maybe a setting issue.
>
> Although this is not POV-related issue, I've checked
> my VLC (3.0.20, Win7) with few other videos - looping was OK.

fwiw, VLC (3.5.7) on Android also loops Kenneth's video, no problem.


@Kenneth.

very interesting, thank you.


regards, jr.

[yesbird] Re: multiple image_maps as media density-- ANIMA... [526 days 3 hours and 6 minutes ago]

Sun, 27 Oct 2024 12:12:30 GMT

On 27/10/2024 14:08, Alain Martel wrote:
> Loops OK here, also using VLC. Maybe a setting issue.

Although this is not POV-related issue, I've checked
my VLC (3.0.20, Win7) with few other videos - looping was OK.
--
YB

[Alain Martel] Re: multiple image_maps as media density-- ANIMA... [526 days 4 hours and 11 minutes ago]

Sun, 27 Oct 2024 11:08:08 GMT

Le 2024-10-27 Ã  05:46, yesbird a Ã©critÂ :
> On 27/10/2024 00:46, Kenneth wrote:
>> This refers to my recent post in p.b. images, here...
>>
>> https://news.povray.org/povray.binaries.images/thread/ 
>> %3Cweb.671d5e03ca529ae591c33a706e066e29%40news.povray.org%3E/
>>
>> The camera is static, and the media container (a box) rotates
>> 360-degrees.
> 
> Looks nice, may be movement is not smooth enough, but impression is
> good in general. For unknown reason I can't loop in in VLC but may be
> this is VLC problem.
> -- 
> YB
> 
> 
Loops OK here, also using VLC. Maybe a setting issue.

[yesbird] Re: multiple image_maps as media density-- ANIMA... [526 days 5 hours and 32 minutes ago]

Sun, 27 Oct 2024 09:46:37 GMT

On 27/10/2024 00:46, Kenneth wrote:
> This refers to my recent post in p.b. images, here...
> 
>
https://news.povray.org/povray.binaries.images/thread/%3Cweb.671d5e03ca529ae591c33a706e066e29%40news.povray.org%3E/
> 
> The camera is static, and the media container (a box) rotates
> 360-degrees.

Looks nice, may be movement is not smooth enough, but impression is
good in general. For unknown reason I can't loop in in VLC but may be
this is VLC problem.
--
YB

[Kenneth] multiple image_maps as media density-- ANIMATION [526 days 17 hours and 29 minutes ago]

Sat, 26 Oct 2024 21:50:00 GMT

This refers to my recent post in p.b. images, here...

https://news.povray.org/povray.binaries.images/thread/%3Cweb.671d5e03ca529ae591c33a706e066e29%40news.povray.org%3E/

The camera is static, and the media container (a box) rotates
360-degrees.

[Cousin Ricky] Re: Aiming DeskLamp [540 days 1 hour and 41 minutes ago]

Sun, 13 Oct 2024 13:37:59 GMT

On 2024-10-13 09:34 (-4), Cousin Ricky wrote:
> On 2024-10-12 17:31 (-4), Bald Eagle wrote:
>>
>> Now you need to do a . . . Ricksar animation!   :D
> 
> I have no idea what this is.  Searches on several searches turn up
> literally only your post--along with insisting that I've misspelled
> "rockstar" or "Pixar."

Oh, I think I know what you mean.  Maybe I shouldn't try thinking so
early in the morning.

[Cousin Ricky] Re: Aiming DeskLamp [540 days 1 hour and 45 minutes ago]

Sun, 13 Oct 2024 13:34:09 GMT

On 2024-10-12 17:31 (-4), Bald Eagle wrote:
> 
> Now you need to do a . . . Ricksar animation!   :D

I have no idea what this is.  Searches on several searches turn up
literally only your post--along with insisting that I've misspelled
"rockstar" or "Pixar."

[Bald Eagle] Re: Aiming DeskLamp [540 days 17 hours and 44 minutes ago]

Sat, 12 Oct 2024 21:35:00 GMT

Whoa.

20 Years!  :O

This is, in the very real sense of the word - EPIC.

Now you need to do a . . . Ricksar animation!   :D


Well done.

- BW

[jr] Re: Aiming DeskLamp [541 days 4 hours and 44 minutes ago]

Sat, 12 Oct 2024 10:35:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> ...
> [*] to get access to the OC, once in, your old user id / p/w should still work.

your original password is the same but prefixed 'oc2_'.  (memory..)


regards, jr.

[jr] Re: Aiming DeskLamp [541 days 8 hours and 54 minutes ago]

Sat, 12 Oct 2024 06:25:00 GMT

hi,

Cousin Ricky <ric### [at] yahoocom> wrote:
> ...
> The scene description files use two of my proposed Object Collection
> libraries, ...

re OC.  I wonder if you would be willing to, um, test and review the OC as runs
now on a development server, and feedback via email ? Chris has created a login
for you[*], and will send you the p/w on request (email via the 'w1058'
webmaster address at povray.org, using "OC" as subject).  crossing fingers you
have both time and inclination :-)  thanks (in advance).

[*] to get access to the OC, once in, your old user id / p/w should still work.

regards, jr.

[Cousin Ricky] Re: Aiming DeskLamp [541 days 14 hours and 8 minutes ago]

Sat, 12 Oct 2024 01:11:15 GMT

On 2024-10-04 11:40 (-4), Bald Eagle wrote:
> 
> That's some really nice work there, Mr. Callwood.

Thanks!

> When did you write the first desk lamp scene?

This question has multiple interpretations, so forgive me for the long
timeline.

2004 December 30: Work is started.
2005 March 6: The first (unpublished) include file is completed.
2005 March 6: The lamp is used by my 3rd generation (unpublished) render
  rig.
2005 March 6: The first scene is created (lampdemo2.jpg).  Like the OP
  animation, it was a test scene.  Sure the image is small; my computer
  screen was 800x600 at the time.
2021 January 11: A rewrite of the include file is started.
2021 November 30: The hooded lamp aiming test animation is created, with
  edits until 2022 June 27.  The final animation posted to YouTube was
  created last month.  This scene turns on an undocumented debugging
  switch to reveal exactly where the lamp is aimed (the bright spot on
  the moving target).
2022 September 6: The rewritten include file is completed and published.
2022 September 6: The first non-test scene to incorporate the new lamp
  (lamp-round-dl-hiq.jpg) is an update of a scene created on 2005 April
  15 which used the old lamp include file.
2022 October 13: The new lamp is used by my 4th generation render rig.
2024 April 30: The flat panel lamp aiming test animation scenes are
  completed.  The final animations posted to YouTube were created last
  month.  Like the hooded lamp test, these scenes turn on the debugging
  switch to reveal exactly where the lamp is aimed.

> How many files and features are associated with it at this point?

The scene description files use two of my proposed Object Collection
libraries, DeskLamp and ShapeOfTheDay.  I have posted links to both of
these libraries in p.object-collection.  These two, in turn, use
RoundEdge, including its elliptical torus mesh.

> Are you using macros to calculate the positioning of the light?
> Are they "simple" vector calculations like vdot and vcross, or are you employing
> matrix transforms?

The lamp's position and up-vector are of course set by the scene, but
the macros used to aim the lamp (given its position and up-vector) are
all defined in desklamp.inc.  The transformation is defined in macro
Lamp_Orient_Trans(), which uses vcross() and vdot(), along with macro
Reorient_Trans() from transforms.inc.  Macro Lamp_Flex_Angle() completes
the aiming by flexing the neck appropriately.

[Bald Eagle] Re: Aiming DeskLamp [548 days 23 hours and 34 minutes ago]

Fri, 4 Oct 2024 15:45:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
> The lamps from the proposed Object Collection module DeskLamp rotate
> themselves and flex their necks to aim at a given location from a
> specified position and "up" direction.

That's some really nice work there, Mr. Callwood.
It's impressive how much time and work you've invested in a simple desk lamp to
get the shapes and textures and positioning right.

When did you write the first desk lamp scene?
How many files and features are associated with it at this point?

Are you using macros to calculate the positioning of the light?
Are they "simple" vector calculations like vdot and vcross, or are you employing
matrix transforms?

Again - nice work as always.

- BW

[Cousin Ricky] Aiming DeskLamp [549 days 18 hours and 36 minutes ago]

Thu, 3 Oct 2024 20:42:59 GMT

The lamps from the proposed Object Collection module DeskLamp rotate
themselves and flex their necks to aim at a given location from a
specified position and "up" direction.  These videos are a test of this
feature.

Hooded gooseneck lamp: https://youtu.be/V7GryU-SV4w
Rectangular panel lamp: https://youtu.be/HDymR-blOM0
Round panel lamp: https://youtu.be/0lu8J9dEOj8

You may notice the panel lamps changing size and shape over the course
of the animations.  This was just a separate test of macro arguments
that I piggy-backed onto the aiming test.

[Cousin Ricky] Unusual Emerald Jardin [568 days 13 hours and 38 minutes ago]

Sun, 15 Sep 2024 01:40:22 GMT

An unusual pattern of inclusions in a cut emerald.  This animation is
just straight up RGB-rendered, as spectral rendering would have taken
about 3 months to render.

https://youtu.be/GtyJlPn6gvc

The marble texture is by Tek:
https://news.povray.org/4624b281$1%40news.povray.org

[Josh English] Re: yet another fire animation (yafa ?) [340KB a... [583 days 8 hours and 3 minutes ago]

Sat, 31 Aug 2024 07:15:40 GMT

On 7/29/2024 12:38 PM, Cousin Ricky wrote:
> "RedGuff" <dom### [at] yahoofr> wrote:
>> Josh English <eng### [at] spiritonecom> wrote:
>>> I know exactly how you feel. I do most everyhting here at work, until I need to
>>> render a big file and I take it home.
>>>
>>> Paul Vanukoff wrote:
>>>
>>>> "Rick [Kitty5]" <pov### [at] dialpipexcom> wrote in message
>>>> news:3897f6fe@news.povray.org...
>>>>>
>>>>> LOL - what should you be doing?
>>>>>
>>>>> Rick
>>>>
>>>> :) Here at work? I do on-phone tech support ... I play with POV while I'm
>>>> talking to customers ... (if they only knew) ... it's actually the only
>>>> place I can get anything done .. there's too much other stuff to do at home
>>>> ...
>>>>
>>>> --
>>>> Paul Vanukoff
>>>> van### [at] primenetcom
>>>
>>> --
>>> Josh English
>>> eng### [at] spiritonecom
>>> "May your hopes, dreams, and plans not be destroyed by a few zeros."
>>
>> I suggest You to start it from zero, then grow, then reduce to zero: lengh = T.
>> Restart n times, with a n/T phase shift each time.
>> Thanks.
> 
> I think we have a new record for thread necromancy here!
> 
> 

That's my post he's responding to. Given my description of my job, my 
post was between 1995 and 2000, when I worked at Stream.

I like my old tag. I had forgotten in. The ISP I was using at the time 
was bought out by a scoundrel and he shuttered the place without 
warning. I lost a lot of email history; several local companies lost 
their internet access AND important emails from customers.

Josh--not so new and definitely not updated--English

[Cousin Ricky] Re: yet another fire animation (yafa ?) [340KB a... [615 days 19 hours and 34 minutes ago]

Mon, 29 Jul 2024 19:45:00 GMT

"RedGuff" <dom### [at] yahoofr> wrote:
> Josh English <eng### [at] spiritonecom> wrote:
> > I know exactly how you feel. I do most everyhting here at work, until I need to
> > render a big file and I take it home.
> >
> > Paul Vanukoff wrote:
> >
> > > "Rick [Kitty5]" <pov### [at] dialpipexcom> wrote in message
> > > news:3897f6fe@news.povray.org...
> > > >
> > > > LOL - what should you be doing?
> > > >
> > > > Rick
> > >
> > > :) Here at work? I do on-phone tech support ... I play with POV while I'm
> > > talking to customers ... (if they only knew) ... it's actually the only
> > > place I can get anything done .. there's too much other stuff to do at home
> > > ...
> > >
> > > --
> > > Paul Vanukoff
> > > van### [at] primenetcom
> >
> > --
> > Josh English
> > eng### [at] spiritonecom
> > "May your hopes, dreams, and plans not be destroyed by a few zeros."
>
> I suggest You to start it from zero, then grow, then reduce to zero: lengh = T.
> Restart n times, with a n/T phase shift each time.
> Thanks.

I think we have a new record for thread necromancy here!

[RedGuff] Re: yet another fire animation (yafa ?) [340KB a... [619 days 15 hours and 24 minutes ago]

Thu, 25 Jul 2024 23:55:00 GMT

Josh English <eng### [at] spiritonecom> wrote:
> I know exactly how you feel. I do most everyhting here at work, until I need to
> render a big file and I take it home.
>
> Paul Vanukoff wrote:
>
> > "Rick [Kitty5]" <pov### [at] dialpipexcom> wrote in message
> > news:3897f6fe@news.povray.org...
> > >
> > > LOL - what should you be doing?
> > >
> > > Rick
> >
> > :) Here at work? I do on-phone tech support ... I play with POV while I'm
> > talking to customers ... (if they only knew) ... it's actually the only
> > place I can get anything done .. there's too much other stuff to do at home
> > ...
> >
> > --
> > Paul Vanukoff
> > van### [at] primenetcom
>
> --
> Josh English
> eng### [at] spiritonecom
> "May your hopes, dreams, and plans not be destroyed by a few zeros."

I suggest You to start it from zero, then grow, then reduce to zero: lengh = T.
Restart n times, with a n/T phase shift each time.
Thanks.

[jr] Re: Found an old puzzle game from childhood [681 days 3 hours and 24 minutes ago]

Sat, 25 May 2024 11:55:00 GMT

hi,

Josh English <Jos### [at] joshuarenglishcom> wrote:
> Too much wood texture, I know.
> This puzzle reportedly has 240 ways to make a cube and there are dozens
> of shapes that they can build. I managed to keep the blocks but I lost
> the plans I made as a kid

:-)

very nice to watch, thanks.


> for all the other shapes, so I'm off to rebuild.

perhaps one where the camera does a 360 around the assembling shape ?


regards, jr.

[William F Pokorny] Re: Found an old puzzle game from childhood [682 days 23 hours and 34 minutes ago]

Thu, 23 May 2024 15:44:37 GMT

On 5/23/24 01:37, Josh English wrote:
> Too much wood texture, I know.
> 
> This puzzle reportedly has 240 ways to make a cube and there are dozens 
> of shapes that they can build. I managed to keep the blocks but I lost 
> the plans I made as a kid for all the other shapes, so I'm off to rebuild.
> 
> Josh

Cool.

[Josh English] Found an old puzzle game from childhood [683 days 9 hours and 41 minutes ago]

Thu, 23 May 2024 05:37:35 GMT

Too much wood texture, I know.

This puzzle reportedly has 240 ways to make a cube and there are dozens 
of shapes that they can build. I managed to keep the blocks but I lost 
the plans I made as a kid for all the other shapes, so I'm off to rebuild.

Josh

[Cousin Ricky] Re: Textured flexible cylinder [709 days 13 hours and 25 minutes ago]

Sat, 27 Apr 2024 01:53:34 GMT

On 4/26/24 21:02 (-4), Bald Eagle wrote:
> 
> Cylindrical means cylindrical.
> And you're deviating from that to toroidal.

My intended task was to bend a solid texture into an arc.  That it is
applied to a torus is incidental.  I can't even begin to imagine dealing
with warp { toroidal }.  (What you see in the animation is a solid
checker pattern.  If I were dealing with uv-mapping, of course I would
have used toroidal.)

> If I had to guess the best way to do that, it would be by geometric inversion.
> Your cylinder would be a torus of infinite radius, and then you'd translate it
> relative to the center of inversion until you got a torus with the desired major
> radius.

I suppose if I were doing those calculations myself, I'd at least know
what I was doing.  But without thinking too hard about it, it seems like
an overly convoluted and unnecessarily difficult way to get it done.
The main difficulty with warp { cylindrical } was getting all the parts
oriented and scaled properly, but the end code is remarkably simple, if
somewhat head-scratching.

FWIW, I did work from the center of curvature, then translate.  And of
course, the unbent object (which does not appear in this animation,
because it is between frames) is a special case using a straight
cylinder, because infinite radii and translations are not fun.

> Excellent job getting it all to work!
> I'm sure it must have been a hard slog to the finish line.

Thanks!

[Bald Eagle] Re: Textured flexible cylinder [709 days 14 hours and 14 minutes ago]

Sat, 27 Apr 2024 01:05:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
> Attached is a cylinder bent around a circular arc.
>
> How did I get the texture to follow the bend?  Easy: I spent 3 days
> throwing spaghetti at a wall until all of it stuck.
>
> I have to do this every time I use the cylindrical warp.  I can explain
> all about how POV-Ray handles gamma and sRGB, but warp { cylindrical }
> is still black magic to me.
>
> The code will be in the next major release of DeskLamp.

Well, to be fair, you're doing one of those Cousin-Ricky level things that I
often find myself doing.

Cylindrical means cylindrical.
And you're deviating from that to toroidal.

If I had to guess the best way to do that, it would be by geometric inversion.
Your cylinder would be a torus of infinite radius, and then you'd translate it
relative to the center of inversion until you got a torus with the desired major
radius.

Dunno if recounting my cylindrical warp woes will help you any:

http://news.povray.org/povray.bugreports/thread/%3Cweb.5c01b8a81374e197765e06870%40news.povray.org%3E/

Excellent job getting it all to work!
I'm sure it must have been a hard slog to the finish line.

- BE

[Cousin Ricky] Textured flexible cylinder [709 days 22 hours and 3 minutes ago]

Fri, 26 Apr 2024 17:15:52 GMT

Attached is a cylinder bent around a circular arc.

How did I get the texture to follow the bend?  Easy: I spent 3 days
throwing spaghetti at a wall until all of it stuck.

I have to do this every time I use the cylindrical warp.  I can explain
all about how POV-Ray handles gamma and sRGB, but warp { cylindrical }
is still black magic to me.

The code will be in the next major release of DeskLamp.

[Cousin Ricky] Re: TheEarth rotation [800 days 14 hours and 22 minutes ago]

Sat, 27 Jan 2024 00:56:41 GMT

On 2023-12-10 09:35 (-4), Alain Martel wrote:
> Le 2023-12-09 Ã  14:24, Cousin Ricky a Ã©critÂ :
>> I rendered the Object Collection's theearth.pov with the animation
>> clock.Â  I don't know whether Chris intended the clouds to rotate with
>> the rest of the planet, but I did not change his cloud code.
> 
> That would cause some serious winds...

You convinced me.  I decided to change his cloud code.

The updated code is at:
  https://github.com/CousinRicky/POV-TheEarth/releases/tag/v1.2

[Thomas de Groot] Re: Wet paper texture [805 days 7 hours and 37 minutes ago]

Mon, 22 Jan 2024 07:41:27 GMT

Op 21/01/2024 om 08:28 schreef Thomas de Groot:
> Just in case you want to play with those diffuse parameters, ...
> 

This suddenly reminds me that there also is:

interior_texture {...}

Friedrich Lohmueller used that with the leaves of his versions of Arbaro 
trees..

-- 
Thomas

[Thomas de Groot] Re: Wet paper texture [806 days 7 hours and 47 minutes ago]

Sun, 21 Jan 2024 07:31:37 GMT

forgot to add the saturation map.

-- 
Thomas

[Thomas de Groot] Re: Wet paper texture [806 days 7 hours and 50 minutes ago]

Sun, 21 Jan 2024 07:28:51 GMT

Op 20/01/2024 om 17:14 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>> I have no access presently to the PC where I have stored my stuff (and
>> it is some years since last I used backside illumination). First thing
>> in the morning, on my ToDo. Sorry for the delay!
> 
> Never fear, intrepid renderer - I figgered it out.
> 
> I just needed to add the ft values in, using a constant function in the pigment
> map.
> 
> So, it works, but probably could use a fair bit of improvement.
> 
> - BW
> 
Excellent!

Just in case you want to play with those diffuse parameters, here is 
some code (+ an image map) I used a long time ago in my window scene 
with the Sultana (Gancaloon Project):

//==================================================
#declare p_curtain_1 = pigment {image_map {png 
"Orange_Gold_Damask_by_R2krw9.png" gamma srgb interpolate 2 filter all 0.5}}
#declare p_curtain_2 = pigment {image_map {png 
"Orange_Gold_Damask_by_R2krw9.png" gamma srgb interpolate 2 filter all 0.0}}
#declare p_curtain_sat = pigment {image_map {png 
"Orange_Gold_Damask_by_R2krw9_sat.png" gamma 1 interpolate 2}}

//==================================================
//Material definitions
#declare Curtain_=
#declare f_curtain_1 =
finish {
   specular 0.0
   roughness 0.0005
   diffuse 0.8, 0.2  //using backside illumination
   conserve_energy
}

#declare f_curtain_2 =
finish {
   specular 0.25
   roughness 0.002
   diffuse 0.8, 0.3  //using backside illumination
   conserve_energy
}

material {
   texture {uv_mapping
     pigment_pattern {p_curtain_sat}
     texture_map {
       [0.0 pigment {p_curtain_1}
            finish {f_curtain_1}
       ]
       [1.0 pigment {p_curtain_2}
            finish {f_curtain_2}
       ]
     }
   }
}
//==================================================

-- 
Thomas

[Bald Eagle] Re: Wet paper texture [806 days 23 hours and 4 minutes ago]

Sat, 20 Jan 2024 16:15:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:

> I have no access presently to the PC where I have stored my stuff (and
> it is some years since last I used backside illumination). First thing
> in the morning, on my ToDo. Sorry for the delay!

Never fear, intrepid renderer - I figgered it out.

I just needed to add the ft values in, using a constant function in the pigment
map.

So, it works, but probably could use a fair bit of improvement.

- BW

[Thomas de Groot] Re: Wet paper texture [806 days 23 hours and 23 minutes ago]

Sat, 20 Jan 2024 15:56:15 GMT

Op 20-1-2024 om 16:05 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>> I was going to suggest that too indeed. I use that for simulating
>> semitransparent cloth combined with backside illumination. Is also
>> available in v3.7.
> 
> Unexplored territory for me.
> 
> 
> So, my texture is
> 
> texture {
>       slope {}
>       texture_map {
>            [0 pigment {
>                 average
>                 pigment_map {
>                      [Entries]
>                 }
>            ]
>            [0 pigment {
>                 average
>                 pigment_map {
>                      [Entries]
>                 }
>            ]
>       }
> }
> 
> I've tried plugging in a finish statement, but the parser squawks "no }, found
> finish instead"
> 
> Where does the finish GO?
> 
> I was also thinking about how to go about making a user defined finish function,
> and that will probably have to be done with another map, since we don't have
> function controlled finish parameters
> 
> - BW
> 
I have no access presently to the PC where I have stored my stuff (and 
it is some years since last I used backside illumination). First thing 
in the morning, on my ToDo. Sorry for the delay!
-- 
Thomas

[Bald Eagle] Re: Wet paper texture [806 days 23 hours and 39 minutes ago]

Sat, 20 Jan 2024 15:40:00 GMT

OK, so I finally got the finish in the right place

texture {
     slope {}
     texture_map {
          [0 pigment {
               average
               pigment_map {
                    [Entries]
               }
               finish {}
          ]
          [0 pigment {
               average
               pigment_map {
                    [Entries]
               }
               finish {}
          ]
     }
}

But no matter what I do with those 2 diffuse values, I don't get anything like
that translucent effect.  I'm also still puzzled why filter and transmit don't
seem to work at all - it doesn't result in a totally transparent region even if
I hard code the function pigment map entry to 1.
I do seem to get more "light" coming through, but strangely, it doesn't look
like the usual filtered or transmissive appearance that I normally expect.
It tried getting rid of those entries entirely, and that didn't seem to help
either.

- BW

[Bald Eagle] Re: Wet paper texture [807 days and 9 minutes ago]

Sat, 20 Jan 2024 15:10:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:

> I was going to suggest that too indeed. I use that for simulating
> semitransparent cloth combined with backside illumination. Is also
> available in v3.7.

Unexplored territory for me.


So, my texture is

texture {
     slope {}
     texture_map {
          [0 pigment {
               average
               pigment_map {
                    [Entries]
               }
          ]
          [0 pigment {
               average
               pigment_map {
                    [Entries]
               }
          ]
     }
}

I've tried plugging in a finish statement, but the parser squawks "no }, found
finish instead"

Where does the finish GO?

I was also thinking about how to go about making a user defined finish function,
and that will probably have to be done with another map, since we don't have
function controlled finish parameters

- BW

[Thomas de Groot] Re: Wet paper texture [807 days 7 hours and 54 minutes ago]

Sat, 20 Jan 2024 07:24:21 GMT

Op 19/01/2024 om 12:45 schreef William F Pokorny:
> On 1/18/24 21:53, Bald Eagle wrote:
>> I have no real idea what I'm doing with the filter and transmit 
>> values, and I
>> can't achieve any transparency no matter what values I use.
> 
> In v3.8 (v3.7?) there is that second finish { difuse } specification?
> 
> diffuse 0.6, 0.3
> 
> Bill P.

I was going to suggest that too indeed. I use that for simulating 
semitransparent cloth combined with backside illumination. Is also 
available in v3.7.

-- 
Thomas

[And] Re: Wet paper texture [808 days and 9 minutes ago]

Fri, 19 Jan 2024 15:10:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> So, I wasted half the day doing ridiculous things with cross products, dot
> products, and rotating graphs of scattering functions.
>
> Then I just decided to experiment with faking it from scratch.
>
> After wrestling with the aoi and slope patterns, I got something that more or
> less works as a basic concept.
>
> I have no real idea what I'm doing with the filter and transmit values, and I
> can't achieve any transparency no matter what values I use.
>
> Anyway, here's a quick animation I threw together to adequately show how it
> works.
>
> It's just "one" texture and 2 light sources to provide adequate illumination of
> both sides.
>
> - BE

Wow, your ridiculous thing is really attractive.

[William F Pokorny] Re: Wet paper texture [808 days 3 hours and 33 minutes ago]

Fri, 19 Jan 2024 11:45:33 GMT

On 1/18/24 21:53, Bald Eagle wrote:
> I have no real idea what I'm doing with the filter and transmit values, and I
> can't achieve any transparency no matter what values I use.

In v3.8 (v3.7?) there is that second finish { difuse } specification?

diffuse 0.6, 0.3

Bill P.

[Bald Eagle] Wet paper texture [808 days 12 hours and 24 minutes ago]

Fri, 19 Jan 2024 02:55:00 GMT

So, I wasted half the day doing ridiculous things with cross products, dot
products, and rotating graphs of scattering functions.

Then I just decided to experiment with faking it from scratch.

After wrestling with the aoi and slope patterns, I got something that more or
less works as a basic concept.

I have no real idea what I'm doing with the filter and transmit values, and I
can't achieve any transparency no matter what values I use.

Anyway, here's a quick animation I threw together to adequately show how it
works.

It's just "one" texture and 2 light sources to provide adequate illumination of
both sides.

- BE

[Bald Eagle] Re: Mirascope [827 days 11 hours and 9 minutes ago]

Sun, 31 Dec 2023 04:10:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
> To get a good handle on what I
> was seeing, I used an object somewhat more complex than a cube, with a
> gradient pigment for improved discernment.

Yeah, I just used a bozo pigmented cube.

I like the animation - it certainly looks very much like a real mirascope, wrt
the reflections.   I do think that we're missing the "sweet spot" that really
sells the illusion.

https://www.youtube.com/shorts/7gD_aXh6nx4
https://www.youtube.com/watch?v=mbBQ1vK0ELo

I'm gonna say that maybe it's the diameter of the viewing aperture, since I'm
speculating that maybe there aren't too many parabolic mirror dimensions that
satisfy the requirements?

It looks like we need to capture that first real image that appears when you
start looking into the aperture, but make the other reflections not very
visible.  I also get a sense from the videos that maybe the mirrors they are
using are somehow flatter than what you've got.

Your POV-Ray logo has an inverted reflection visible behind the real image, and
the real image sits too deep in the aperture to make it actually look like it's
floating on top of the hole.
It's even worse with the larger aperture.

I'm juggling teen-agers, but maybe you can just use the small aperture to make
another animation where you vary the parabola dimensions, and see if you can get
the logo to "rise up" out of the depths of the device.

Excellent work!

I'm also interested in seeing if the "shine a laser onto the real image" trick
works as well.That's one of the most surprising aspects of the illusion.

- BW

[Cousin Ricky] Mirascope [827 days 14 hours and 34 minutes ago]

Sun, 31 Dec 2023 00:44:52 GMT

I rendered some mirascope animations to easily get an idea of what
configurations would give good results.  To get a good handle on what I
was seeing, I used an object somewhat more complex than a cube, with a
gradient pigment for improved discernment.  The dimensions I used are
annotated at the upper left of the frames, with HEIGHT referring to the
height of the bottom mirror.  For mirascope-02.mp4, I used the
proportions from the illustration at the University of Wisconsin at
Madison at the link BE posted in p.general:

https://www.physics.wisc.edu/ingersollmuseum/exhibits/opticscolor/parabolicmirrorillusion/

That model has a rather small opening, so I rendered mirascope-04.mp4
with double the hole diameter.

It is not easy to see both the object and its reflected apparitions
simultaneously.  With both diameters, there was an angular sweet spot
between when the object itself appears, and when the opening becomes
reflected in the bottom mirror.  At low viewing angles, only the
reflections are visible.  As the viewing angle gets higher, the
reflection of the opening appears soon after the top of the actual
object comes into view, then expands quite rapidly.  At higher viewing
angles, the reflections cannot be seen.

[Alain Martel] Re: TheEarth rotation [848 days 1 hour and 44 minutes ago]

Sun, 10 Dec 2023 13:35:01 GMT

Le 2023-12-09 Ã  14:24, Cousin Ricky a Ã©critÂ :
> I rendered the Object Collection's theearth.pov with the animation
> clock.  I don't know whether Chris intended the clouds to rotate with
> the rest of the planet, but I did not change his cloud code.

That would cause some serious winds...

[kurtz le pirate] Re: TheEarth rotation [848 days 5 hours and 33 minutes ago]

Sun, 10 Dec 2023 09:45:16 GMT

On 09/12/2023 20:24, Cousin Ricky wrote:
> I rendered the Object Collection's theearth.pov with the animation
> clock.  I don't know whether Chris intended the clouds to rotate with
> the rest of the planet, but I did not change his cloud code.
> 

I did the same thing... LOL
<http://louisbel.free.fr/anime_earth.mov>


Without clouds but with another image of the Earth found here :
<https://eoimages.gsfc.nasa.gov/images/imagerecords/73000/73580/world.topo.bathy.200401.3x5400x2700.jpg>





-- 
Kurtz le pirate
Compagnie de la Banquise

[Cousin Ricky] TheEarth rotation [848 days 19 hours and 54 minutes ago]

Sat, 9 Dec 2023 19:24:25 GMT

I rendered the Object Collection's theearth.pov with the animation
clock.  I don't know whether Chris intended the clouds to rotate with
the rest of the planet, but I did not change his cloud code.

[Cousin Ricky] Gamma Showcase: how clipka did it [915 days 11 hours and 20 minutes ago]

Wed, 4 Oct 2023 03:58:32 GMT

I've always been curious how Christoph did the stripes for the gamma
showcase image
  https://wiki.povray.org/content/File:TutImgGammaShowcase.png
but only now got around to looking at the code.  I decided to do a
walk-around animation to visualize the pattern.

For some reason, at camera resolution the striped impressions don't
match the solid color in the video.  They did match in the still frames
prior to encoding.  Because the stripes are initially at the camera
resolution, moire patterns are inevitable when the camera starts moving,
but these clear up as I bring the camera in closer to the spheres.

[Dick Balaska] Re: Blinking Button [1040 days 9 hours and 47 minutes ago]

Thu, 1 Jun 2023 05:31:48 GMT

On 8/27/2022 04:50, Dave Blandston wrote:
> https://www.youtube.com/watch?v=Wi6-aASp7M8
> 
> I'm getting a lot of mileage out of the Disposable Heroes font, used here as
> sample text on a website button. The sphere_sweep objects used in that font
> caused so much trouble that I replaced them all with Cousin Ricky's awesome
> SphereSweep.inc macros.
> 
> Have a wonderful day folks!
> 
> Kind regards,
> Dave Blandston
> 

"This video isn't available anymore"

Bummer. I wanted to see an alternate font from you.

dik

[Colin Fleming] Panu Hassi - Bounce [1116 days 2 hours and 49 minutes ago]

Fri, 17 Mar 2023 12:30:01 GMT

Source files are in "povray.binaries.scene-files".

[Colin Fleming] Panu Hassi - Ring [1116 days 2 hours and 49 minutes ago]

Fri, 17 Mar 2023 12:30:00 GMT

Source files are in "povray.binaries.scene-files".

[Colin Fleming] Drew Wells - Tomb [1116 days 2 hours and 49 minutes ago]

Fri, 17 Mar 2023 12:30:00 GMT

Panu Hassi created a RayScene ARR file, I've just converted everything to
POV-Ray v3.x sytanx and added the missing "ghost.gif"

[yesbird] Re: Beetle [1117 days 21 hours and 54 minutes ago]

Wed, 15 Mar 2023 17:25:11 GMT

On 15/03/2023 19:58, Mike Miller wrote:
> Very nice YB. The metallic materials work well in animation. I also like the
> additional specular highlights in the eyeballs.

Agree with you, although this is a simple turntable animation, it works
well for 3D models, one flat image is not sufficient for presenting a
complex shape.

I like highlights too, but it seems to me that ambient light is
insufficient.

> I just finished a more traditional looking scarab beetle. I'll post it when I'm
> done with the materials. I'm modeling a fly now (I did a fairly crude one in POV
> 30 years ago).

I like this new entomology series and wonder how fast you are working.
Looking forward to new insects.
--
YB

[Mike Miller] Re: Beetle [1117 days 22 hours and 19 minutes ago]

Wed, 15 Mar 2023 17:00:00 GMT

yesbird <sya### [at] gmailcom> wrote:
> Hi,
> Here is animation of Mike's beetle:
> https://www.youtube.com/watch?v=YRxRznkDpfY
>
> I know that light setup could be much better, but I'm still learning and
> at the same time trying to save rendering time, as much as possible.
> --
> YB

Very nice YB. The metallic materials work well in animation. I also like the
additional specular highlights in the eyeballs.

I just finished a more traditional looking scarab beetle. I'll post it when I'm
done with the materials. I'm modeling a fly now (I did a fairly crude one in POV
30 years ago).

[yesbird] Beetle [1117 days 23 hours and 42 minutes ago]

Wed, 15 Mar 2023 15:37:03 GMT

Hi,
Here is animation of Mike's beetle:
https://www.youtube.com/watch?v=YRxRznkDpfY

I know that light setup could be much better, but I'm still learning and
at the same time trying to save rendering time, as much as possible.
--
YB

[yesbird] Re: Fush-14 animated [1120 days 5 hours and 53 minutes ago]

Mon, 13 Mar 2023 09:25:18 GMT

On 13/03/2023 07:19, Mike Miller wrote:
> Wow, nice. I like the animation. Lighting and rendering look very natural. Good
> job.
Btw, if you want, you can download complete set of individual frames 
from here (400.5 Mb):
https://drive.google.com/file/d/1SllR3mUMVoudLgfq-fWRCL-Cdl4Bm_Dc/view?usp=share_link
--
YB

[yesbird] Re: Fush-14 animated [1120 days 8 hours and 17 minutes ago]

Mon, 13 Mar 2023 07:02:02 GMT

On 13/03/2023 08:57, Mike Miller wrote:
> Thanks, yes. We're on the same paths. :) Very cool - I love what you've done so
> far and exited to see the boolean stuff. I'm using naming conventions to handle
> some of POV's objects like lathes, sweeps, and blobs. I'll need to download C4D.
> I'm impressed with Blender, it's tools and the speed of Eevee rendering. Add
> free. :)
Blender is a great tool, last weak I played with it and like it's power
,'freedom' and plugin for POV. Don't sure if you need C4D having a
Blender already, it's too expensive, while abilities are comparable to
Blender's. You have Blender + Sculptris - this pair covers all needs,
I suppose.

I'm working with C4D for may year, know it very well, but if I
started from scratch now, I would choose a Blender.

My future plans are following:
1. Prepare useful tools for creating geometry to speed-up modelling:
    - Complete C4D-POV converter.
    - Write converter from ZBrush->POV to obtain high-density colored
      meshes. Present standard implementation of ZBrush->OBJ is poor and
      not supports vertex coloring.

2. Explore POV materials more deeply, examples from your scenes will
    help me a lot at this point.

3. Put attention on lighting - creating adequate lighting environment is
    not easy task, as I know from working with VRay.

4. And finally construct object, combine scenes, publish :).

In parallel, filling library with object you send, probably animate
them.

PS: The idea about naming conventions is very good, it's much more
easy to tweak the scene, when knows object's types.
--
YB

[Mike Miller] Re: Fush-14 animated [1120 days 9 hours and 19 minutes ago]

Mon, 13 Mar 2023 06:00:00 GMT

yesbird <sya### [at] gmailcom> wrote:
> On 13/03/2023 07:19, Mike Miller wrote:
> > Wow, nice. I like the animation. Lighting and rendering look very natural. Good
> > job.
> > ...
> > I posted a new beetle model ...permission to use and abuse granted. :)
> Very well, I am treat it as guide to action :)
>
> > So...I programmed a few converters to write various POV types from .x3d. I
> > include the one that handles blobs and Sphere sweeps. I was happy to see that
> > blobs in the Blender viewport matched closely to the POV rendering result.
>
> Excellent, I see, that we are going on parallel courses - lack of a
> goodmodelling environment forces us to make proprietary tools. I'm in one
> step of completing first release of Cinema4D to POV converter.
>
> Now it supports:
> 1. Primitives: sphere, cube, cone, cylinder, plane, spline, mesh2.
> 2. Boolean operations: union, difference, intersection.
> 3. Constructive operations: extrude(prism).
>
> I'm working on sphere sweep and lathe now.
> In attachment are results of C4D's 'Cloner' work.
>
> > Can POV convert quaternion to euler angles ?
> May be this set of macros will help ?:
>
http://news.povray.org/povray.binaries.scene-files/message/%3CXns940C86DC9B1D4None%40204.213.191.226%3E/
> --
> YB



Thanks, yes. We're on the same paths. :) Very cool - I love what you've done so
far and exited to see the boolean stuff. I'm using naming conventions to handle
some of POV's objects like lathes, sweeps, and blobs. I'll need to download C4D.
I'm impressed with Blender, it's tools and the speed of Eevee rendering. Add
free. :)
Mike.

[yesbird] Re: Fush-14 animated [1120 days 9 hours and 53 minutes ago]

Mon, 13 Mar 2023 05:25:28 GMT

On 13/03/2023 07:19, Mike Miller wrote:
> Wow, nice. I like the animation. Lighting and rendering look very natural. Good
> job.
> ...
> I posted a new beetle model ...permission to use and abuse granted. :)
Very well, I am treat it as guide to action :)

> So...I programmed a few converters to write various POV types from .x3d. I
> include the one that handles blobs and Sphere sweeps. I was happy to see that
> blobs in the Blender viewport matched closely to the POV rendering result.

Excellent, I see, that we are going on parallel courses - lack of a 
goodmodelling environment forces us to make proprietary tools. I'm in one
step of completing first release of Cinema4D to POV converter.

Now it supports:
1. Primitives: sphere, cube, cone, cylinder, plane, spline, mesh2.
2. Boolean operations: union, difference, intersection.
3. Constructive operations: extrude(prism).

I'm working on sphere sweep and lathe now.
In attachment are results of C4D's 'Cloner' work.

> Can POV convert quaternion to euler angles ?
May be this set of macros will help ?:
http://news.povray.org/povray.binaries.scene-files/message/%3CXns940C86DC9B1D4None%40204.213.191.226%3E/
--
YB

[Mike Miller] Re: Fush-14 animated [1120 days 10 hours and 59 minutes ago]

Mon, 13 Mar 2023 04:20:00 GMT

yesbird <sya### [at] gmailcom> wrote:
> On 11/03/2023 03:16, Bald Eagle wrote:
> > That is absolutely beautiful  :O
> Thanks Bill, but this is  completely Mike's work, I'm only turned it
> on 360 degree, very slowly :)
> --
> YB

Wow, nice. I like the animation. Lighting and rendering look very natural. Good
job.

FYI,
I posted a new beetle model ...permission to use and abuse granted. :)
While looking at Blender for CAD export options, I came across the old .x3d
format which handles most of POV's primitive types including blobs. (Mballs)
So...I programmed a few converters to write various POV types from .x3d. I
include the one that handles blobs and Sphere sweeps. I was happy to see that
blobs in the Blender viewport matched closely to the POV rendering result.

Fortunately, my sphere sweeps and meta balls didn't require rotation data which
is written in quaternions. I made a stab to convert to eular but the math hurts
my head.

Can POV convert quaternion to euler angles ?
Mike

meta ball from .x3d
<Transform DEF="Mball_035_TRANSFORM"
   translation="60.537418 13.368469 -8.296644"
   scale="12.194446 7.824638 4.814421"
   rotation="-1.000000 0.000000 0.000000 1.570796"
   >

[yesbird] Yes-library: Spiral worm animation [1122 days 11 hours and 18 minutes ago]

Sat, 11 Mar 2023 04:00:39 GMT

Simple turntable animation of 'Spiral worm':

Video: https://www.youtube.com/watch?v=_ZGjlTH7dw8
Code: https://github.com/syanenko/Yes-World/blob/main/spiral_worm.pov

Animation of different parameters, like pins size, length, number of
turns. palette, etc. can give impressive effects, but I postponed it
while busy with export utilities.

Please, don't forget to switch on loop mode :)
--
YB

[yesbird] Re: Fush-14 animated [1122 days 12 hours and 57 minutes ago]

Sat, 11 Mar 2023 02:21:21 GMT

On 11/03/2023 03:16, Bald Eagle wrote:
> That is absolutely beautiful  :O
Thanks Bill, but this is  completely Mike's work, I'm only turned it
on 360 degree, very slowly :)
--
YB

[Bald Eagle] Re: Fush-14 animated [1122 days 14 hours and 59 minutes ago]

Sat, 11 Mar 2023 00:20:00 GMT

yesbird <sya### [at] gmailcom> wrote:
> Finally completed !
>
> It took about 36 hours on my Intel Core i5 750, 2.67GHz to render 360
> 1920x1080 frames with AA 0.3 of 14 sec. animation of Mike's Fish-14.

Damn, Sergey,


That is absolutely beautiful  :O

Well worth the 36 hours, and congrats to you and Mike on doing so much with this
model.

 -BW

[yesbird] Fush-14 animated [1123 days and 46 minutes ago]

Fri, 10 Mar 2023 14:33:10 GMT

Finally completed !

It took about 36 hours on my Intel Core i5 750, 2.67GHz to render 360
1920x1080 frames with AA 0.3 of 14 sec. animation of Mike's Fish-14.

The fish is so good, that I could not resist to this temptation.
To decrease rendering time I simplified lighting a little:
area_light (16, 16) changed to (2, 2), sorry, Mike, or it could be
rendered forever :).

Result is here:
https://www.youtube.com/watch?v=JomLeE21Wic
--
YB

[yesbird] Yes-library: Weed [1130 days 23 hours and 35 minutes ago]

Thu, 2 Mar 2023 15:43:40 GMT

Weed, part of Yes-library, derived from Mike's basic shape,
now animated:
https://www.youtube.com/watch?v=REc3Tk6OzqU
--
YB

[yesbird] Re: Breathing coral [1131 days 15 hours and 46 minutes ago]

Wed, 1 Mar 2023 23:33:12 GMT

On 23/02/2023 02:44, yesbird wrote:
> First object from Yes-library (https://github.com/syanenko/pov-yes):
Cloned and re-animated:
https://www.youtube.com/watch?v=R2izyG_Qv4o
--
YB

[yesbird] Re: Fish 13 cloned [1133 days 16 hours and 35 minutes ago]

Mon, 27 Feb 2023 22:44:07 GMT

On 28/02/2023 01:04, Mike Miller wrote:
> Nice!...all these models you're putting together look great. Is that a custom
> shader you're applying?  I know you mentioned cell shading.

Thanks, Mike.
I'm glad that you are not disappointed by my games with your models.

This is a hand-made 'shader' that works very simple, by applying
following textures to different parts of the models:
--------------------------------------------------------------------
#declare tex_01 =
texture {
	pigment { gradient y        // Play with it.
	 	  color_map { jet } // Use pre-defined colormap.
	          scale 100         //
	          rotate 0          // Play with transforms too.
	          translate -40 }   //
	normal { bumps scale 0.08 }
}
--------------------------------------------------------------------
By shifting gradients and transforms we can apply different segments of
colormap to object's parts, achieving a wide range of palettes.

Set of colormaps are here:
https://github.com/syanenko/pov-colormaps

> I'll try to get some other objects your way (bugs, snails, plants...). I got
> pulled into another project but will return soon. :)

Will be glad to play with old/new toys from your archive, wish you good
luck with your present project, looking forward to you coming back.

All the best,
--
YB

[Mike Miller] Re: Fish 13 cloned [1133 days 17 hours and 14 minutes ago]

Mon, 27 Feb 2023 22:05:00 GMT

yesbird <sya### [at] gmailcom> wrote:
> Another one object from Yes-library (https://github.com/syanenko/pov-yes):
>
> https://www.youtube.com/watch?v=NvTMP3XGKms
> --
> YB

Nice!...all these models you're putting together look great. Is that a custom
shader you're applying?  I know you mentioned cell shading.

I'll try to get some other objects your way (bugs, snails, plants...). I got
pulled into another project but will return soon. :)
Best regards,
Mike.

[yesbird] Fish 13 cloned [1135 days 11 hours and 52 minutes ago]

Sun, 26 Feb 2023 03:27:04 GMT

Another one object from Yes-library (https://github.com/syanenko/pov-yes):

https://www.youtube.com/watch?v=NvTMP3XGKms
--
YB

[yesbird] Breathing coral [1138 days 15 hours and 35 minutes ago]

Wed, 22 Feb 2023 23:44:07 GMT

First object from Yes-library (https://github.com/syanenko/pov-yes):

https://www.youtube.com/watch?v=Xfp7ocJBziQ
--
YB

[Mike Miller] Re: Close to the Yes [1139 days 8 hours and 59 minutes ago]

Wed, 22 Feb 2023 06:20:00 GMT

yesbird <sya### [at] gmailcom> wrote:
> This is my first experimental blob-based animation of abstract
> Yes-objects:
> https://www.youtube.com/watch?v=9blerQPA2Dk
>
> A lot of things should be done: create more impressive finish and
> bumping, adjust color palette, pack object into macro for easy duplicating.
> --
> YB

Nice form. I like what you have so far.
Mike

[yesbird] Close to the Yes [1139 days 9 hours and 53 minutes ago]

Wed, 22 Feb 2023 05:25:43 GMT

This is my first experimental blob-based animation of abstract
Yes-objects:
https://www.youtube.com/watch?v=9blerQPA2Dk

A lot of things should be done: create more impressive finish and 
bumping, adjust color palette, pack objectÂ into macro for easy duplicating.
--
YB

[yesbird] Re: Fragile Earth animation [1142 days 10 hours and 18 minutes ago]

Sun, 19 Feb 2023 05:00:46 GMT

> fwiw, just a little too fast, I thought.

  I slowed it down - apocalypse now ... postponed.

[yesbird] Re: Fragile Earth animation [1143 days 17 hours and 59 minutes ago]

Fri, 17 Feb 2023 21:20:00 GMT

> fwiw, just a little too fast, I thought.
> (2050 ?! optimist.. :-))

Yes, time flies ... )
--
YB

[jr] Re: Fragile Earth animation [1143 days 19 hours and 4 minutes ago]

Fri, 17 Feb 2023 20:15:00 GMT

hi,

"yesbird" <nomail@nomail> wrote:
> Any critical notes and suggestions about improvement are welcome.

fwiw, just a little too fast, I thought.

(2050 ?! optimist.. :-))


regards, jr.

[yesbird] Fragile Earth animation [1143 days 23 hours and 14 minutes ago]

Fri, 17 Feb 2023 16:05:00 GMT

Hi, guys !

Inspired by our discussions about height fields and color maps, I've rendered
this simple animation:

https://www.youtube.com/watch?v=i7kItZ6S6cM

Any critical notes and suggestions about improvement are welcome.
Scene in attachment.
--
YB

[Lars Rohwedder] Ideas for Voronoi animations [1196 days 1 hour and 57 minutes ago]

Tue, 27 Dec 2022 13:21:45 GMT

I created some 2D animations of Voronoi diagrams some years ago, with 
different Minkowski metrics:

https://commons.wikimedia.org/wiki/User:RokerHRO/Voronoi

Perhaps this might be an inspiration to do similar things in 3D? I'd 
like to see such animations in 3D. :-D

Lars R.

[Bill Pragnell] Voronoi cells bounding box [1196 days 2 hours and 44 minutes ago]

Tue, 27 Dec 2022 12:35:00 GMT

Hi all, Merry Christmas or the solstice celebration of your choice!

I found several major problems with my voronoi cell maker when I started messing
with non-square grids. This was hindered by a lack of input validation,
provoking me to overhaul my input parsing. The TL;DR is that anisotropic grids
are problematic, and it's difficult to sanitize inputs to avoid bad output, so I
decided to just document the input options and offer advice (!).

I'm now padding the volume of interest with extra grid points to make
calculation easier (and more correct). The change in boundary conditions means
that there are several ways to handle the cells at the edges of the box:

1) process all padded points, including the bounding planes, to fill the space
up to the faces of the box. This gives a 'filled' box with complete faces.

2) process only the points within the box, including the bounding planes to trim
the cells. This results in some cells that extend out of the box being trimmed
by the bounding planes, but also produces gaps from padding cells that extend
into the box.

3) process only the points within the box, but don't include the bounding
planes. This means that some cells extend out of the box, and some gaps from the
padding cells extend into the box. This option is the most 'natural' looking,
because there is no obvious edge to the bounded volume.

Here are three examples of the above options, all using the same seed grid. I
have combined them into a gif to more clearly show the differences.

(The attachment guidelines recommend h264, but I think this makes no sense for
comparisons with only a few frames; apologies if gifs are for some reason
frowned upon!)

Bill

[Dave Blandston] Blinking Button [1318 days 6 hours and 24 minutes ago]

Sat, 27 Aug 2022 08:55:00 GMT

https://www.youtube.com/watch?v=Wi6-aASp7M8

I'm getting a lot of mileage out of the Disposable Heroes font, used here as
sample text on a website button. The sphere_sweep objects used in that font
caused so much trouble that I replaced them all with Cousin Ricky's awesome
SphereSweep.inc macros.

Have a wonderful day folks!

Kind regards,
Dave Blandston

[Dave Blandston] Animated Function [1344 days 12 hours and 4 minutes ago]

Mon, 1 Aug 2022 03:15:00 GMT

I know there are better ways of achieving the final result but my goal was to
write the code below. Trying different functions is lots of fun.

https://www.youtube.com/watch?v=apI3E4Pt8h8

Here's the scene file which generates height_field frames: (One row and one
column should be discarded to avoid crosshatching in the image. The proper
resolution will be displayed.)

#version 3.7;

global_settings {assumed_gamma 1}

#include "colors.inc"

/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* * * * * * * * * * * * * * * * * * * */
/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* * * * * * * * * * * * * * * * * * * */
/* *
                                    * */
/* *
                                    * */
/* * SCENE SETTINGS
                                    * */
/* *
                                    * */
/* *
                                    * */
/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* * * * * * * * * * * * * * * * * * * */
/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* * * * * * * * * * * * * * * * * * * */

#local AspectRatio = 1;

camera {
   orthographic
   location <0, 0, -1>
   right AspectRatio * x
   direction <0, 0, 1>
   look_at <0, 0, 0>
} //camera

/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* * * * * * * * * * * * * * * * * * * */
/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* * * * * * * * * * * * * * * * * * * */
/* *
                                    * */
/* *
                                    * */
/* * TEXTURES
                                    * */
/* *
                                    * */
/* *
                                    * */
/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* * * * * * * * * * * * * * * * * * * */
/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* * * * * * * * * * * * * * * * * * * */

#local Color0 = Black;
#local Color1 = White;

#local NColors = 65536;

#local BlockColor = array [NColors]

#for (I, 0, NColors - 1)
   #local BlockColor [I] = (I / (NColors - 1) * Color1) + (NColors - 1 - I) /
(NColors - 1) * Color0;
#end //#for

/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* * * * * * * * * * * * * * * * * * * */
/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* * * * * * * * * * * * * * * * * * * */
/* *
                                    * */
/* *
                                    * */
/* * THE SCENE
                                    * */
/* *
                                    * */
/* *
                                    * */
/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* * * * * * * * * * * * * * * * * * * */
/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* * * * * * * * * * * * * * * * * * * */

#local AxesLengths = 540;
#local StepX = 1/2; //Should be 1, 1/2, 1/3, 1/4, et cetera
#local StepY = 1/2; //Should be 1, 1/2, 1/3, 1/4, et cetera

#local MinX = -AxesLengths;
#local MaxX = AxesLengths;
#local MinY = -AxesLengths;
#local MaxY = AxesLengths;

#local NColumns = (MaxX - MinX) / StepX + 1;
#local NRows = (MaxY - MinY) / StepY + 1;

#debug concat ("\nImage resolution should be ", str (NColumns - 1, 0, 0), " x ",
str (NRows - 1, 0, 0), " pixels.\n")

#local Block = array [NColumns] [NRows]

#local AnimationFactor = (cos (radians (180 + clock * 90)) + 1) * 16;

#local I = 0;
#for (CurX, MinX, MaxX, StepX)
   #local J = 0;
   #for (CurY, MinY, MaxY, StepY)
      //#local F = CurY * sin (radians (CurX * CurX / 256)); //The function
(AxesLengths = 800; reduce the denominator for shorter AxesLengths)
      //#local F = cos (radians (CurX * .5)) * CurY; //The function
      //#local F = cos (radians (CurX / 2)) * sin (radians (CurY / 2)); //The
function (AxesLengths = 800; reduce the denominator for shorter AxesLengths)
      //#local F = pow (cos (radians (CurX)) + 2, cos (radians (CurY)) + 1);
//The function
      //#local F = pow (cos (radians (CurX)) + 2, cos (radians (CurX / (cos
(radians (CurY)) + 2))) + 1); //The function
      #local F = pow (cos (radians (CurX)) + 2, cos (radians (CurX * (cos
(radians (CurY)) + AnimationFactor))) + 1); //The function (Use AxesLengths =
540)
      #if (I = 0 & J = 0)
         #local Lowest = F;
         #local Highest = F;
      #else
         #if (F < Lowest)
            #local Lowest = F;
         #end //#if
         #if (F > Highest)
            #local Highest = F;
         #end //#if
      #end //#if
      #local Block [I] [J] = F;
      #local J = J + 1;
   #end //#for
   #local I = I + 1;
#end //#for

#local Highest = Highest - Lowest;
#local Denominator = Highest / (NColors - 1);

#for (I, 0, NColumns - 1)
   #for (J, 0, NRows - 1)
      #local Block [I] [J] = int ((Block [I] [J] - Lowest) / Denominator + .5);
      #if (Block [I] [J] < 0)
         #debug concat ("\n", str (Block [I] [J], 0, 18), "\n")
         #debug concat ("\n", str (Lowest, 0, 6), ", ", str (Highest, 0, 6),
"\n")
         #error "Oh darn."
      #end //#if
   #end //#for
#end //#for

#local Graph = object {
   union {
      #local I = 0;
      #for (CurX, MinX, MaxX, StepX)
         #local J = 0;
         #for (CurY, MinY, MaxY, StepY)
            box {<CurX - .5, CurY - .5, 0> <CurX + .5, CurY + .5, .1> texture
{pigment {color BlockColor [Block [I] [J]]}} finish {emission .9}}
            #local J = J + 1;
         #end //#for
         #local I = I + 1;
      #end //#for
   } //union
} //object

#local S = max (NColumns, NRows);

object {Graph scale <1 / S / StepX, 1 / S / StepY, 1>}

[Dave Blandston] Website Mockup Animation [1345 days 7 hours and 24 minutes ago]

Sun, 31 Jul 2022 07:55:00 GMT

Howdy Everyone,

This is a demonstration video of a very simple website design mockup utility.
The idea is that an animation more closely resembles an actual website than just
a static image, and can also demonstrate more visual features such as changing
buttons and such. I'm sure there are better options available but this was fun
to make and fits my needs perfectly. The potential to make this utility more
sophisticated certainly exists, such as defining spline paths for the mouse
pointer to follow and adding pre-defined events such as changing backgrounds at
certain frames, but the current functionality is sufficient for my current
purposes and I'll save the extended functionality for another day since my focus
at the moment is on a website project.

https://www.youtube.com/watch?v=MnDDW82xhtI

The source is posted in the text scene files area.

Have an awesome day!

Kind regards,
Dave Blandston

[Dave Blandston] Re: 3d animation? [1377 days 7 hours and 19 minutes ago]

Wed, 29 Jun 2022 08:00:00 GMT

Well I've never done anything with anaglyphs but your website is pretty cool. I
still appreciate the things from those by-gone years as well. Have a great day!

Kind regards,
Dave Blandston

[Leroy] 3d animation? [1380 days 21 hours and 49 minutes ago]

Sat, 25 Jun 2022 17:30:00 GMT

Does any body do 3d animation? The red\blue anaglyph kind.

I wrote a windows program to combine the two 2d images into the 3d anaglyph.
Really rewrote my old 'RB_3d' program at <http://leroyw.byethost15.com/>
by adding a batch run that can do animation files.

When I was about to upgrade my web site, I thought about upgrading the POV files
that comes with 'RB_3d'. While going through them I need to know just what did
I want to do.
 If I had POV make both left and right 2d images one after the other using
animation in the ini file, I have to either rewrite the batch to skip files or
use POV shells to rename the 2d image files. So I started on how POV shells
work.
I wrote a shell program to do renaming. But I wasn't satisfied, I still had a
lot of disk space being use. A 800 frame animation would have 2400 images on
disk.
I could get rid of 2/3 of those files, if I use POV to make the 3d image from
the two 2d image already on the disk then delete the 2d images.

Now I have TWO systems to make animated Anaglyphs.

system 1 : POV makes all the left images for an animation
           POV makes all the Right images for an animation
           use RB_3d to combine images
           make animation using your favorite tools
system 2 : using animation in POV ini with my shell program
           POV makes the 3d images for an animation
           make animation using your favorite tools

Now I really have a choice do I?

 1:put both on my web site

 2:put system 1 only on my web site

 3:put system 2 only on my web site

 4: don't put upgrade

So thanks for any feed bake!

Have fun!

[m@b] Re: Weird. [1382 days and 55 minutes ago]

Fri, 24 Jun 2022 14:23:47 GMT

On 23/06/2022 4:16 pm, JÃ¶rg "Yadgar" Bleimann wrote:
> Hi(gh)!
> 
> On 13.04.21 12:44, m@b wrote:
>> Check out my animation:
>>
>> https://youtu.be/jWXSZitnqeI
>>
> I just posted a comment!

Thanks :-} made me smile.

> 
> See you in Khyberspace!
> 
> Yadgar
> 
> Now playing: Logos (Part 2) (Tangerine Dream)

Nice!

[jr] Re: Conway [1382 days 9 hours and 49 minutes ago]

Fri, 24 Jun 2022 05:30:00 GMT

hi,

ingo <ing### [at] tagpovrayorg> wrote:
> seems to be 3.7.0 vs something newer, after a quick test (win10). The
> older one seems a bit more permissive.

the .. permissiveness seems to exist on MS Windows only.  on Slackware Linux all
installed (3.7.0.8, 3.7.1-rc.1, 3.8.0-alpha.9945627 and betas) fail on the same
frame (#21); I cannot fathom why the error doesn't occur on the first read.

regards, jr.

[Jörg "Yadgar" Bleimann] Re: Weird. [1383 days and 2 minutes ago]

Thu, 23 Jun 2022 15:16:26 GMT

Hi(gh)!

On 13.04.21 12:44, m@b wrote:
> Check out my animation:
> 
> https://youtu.be/jWXSZitnqeI
> 
I just posted a comment!

See you in Khyberspace!

Yadgar

Now playing: Logos (Part 2) (Tangerine Dream)

[ingo] Re: Conway [1383 days 1 hour and 11 minutes ago]

Thu, 23 Jun 2022 14:07:45 GMT

in news:XnsAEBFA2727B6BCseed7@news.povray.org ingo wrote:

> Strange that I didn't trip over it.

seems to be 3.7.0 vs something newer, after a quick test (win10). The 
older one seems a bit more permissive.

ingo

-- 
https://ingoogni.nl

[ingo] Re: Conway [1383 days 1 hour and 21 minutes ago]

Thu, 23 Jun 2022 13:58:10 GMT

in news:web.62b4392ddef97904d6bf93276cde94f1@news.povray.org jr wrote:

> newline: 
>     #write (CAFile SizeX "," SizeY ",\n")
> 
> 
Fixed that. Thanks. Strange that I didn't trip over it.


-- 
https://ingoogni.nl

[jr] Re: Conway [1383 days 5 hours and 19 minutes ago]

Thu, 23 Jun 2022 10:00:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> "ingo" <nomail@nomail> wrote:
> > Just a Game of Life. ...
> ...
> File '/tmp/conway.arr' line 2: Parse Error: Expected 'float, vector, or string
>  literal', ,  found instead
> Fatal error in parser: Cannot parse input.
>
> same error/frame for 3.7.0.8 and beta.2.  no idea what the problem is, the file
> looks kosher.

on closer examination, there was no comma after the 2nd value of the first line,
edited the 'CAwrite()' macro to add the comma with the newline:
    #write (CAFile SizeX "," SizeY ",\n")

(now will try to find time to actually look at the code. :-))


regards, jr.

[jr] Re: Conway [1383 days 19 hours and 14 minutes ago]

Wed, 22 Jun 2022 20:05:00 GMT

hi,

"ingo" <nomail@nomail> wrote:
> Just a Game of Life. ...

looking good, until frame #21.  :-)

File '/tmp/conway.arr' line 2: Parse Error: Expected 'float, vector, or string
 literal', ,  found instead
Fatal error in parser: Cannot parse input.
Render failed

same error/frame for 3.7.0.8 and beta.2.  no idea what the problem is, the file
looks kosher.


regards, jr.

[ingo] Conway [1384 days 5 hours and 44 minutes ago]

Wed, 22 Jun 2022 09:35:00 GMT

Just a Game of Life. I wanted to see the transitions in state instead of just
flipping cells.

ingo

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

// Persistence of Vision Ray Tracer Scene Description File
// File: conway.pov
// Vers: 3.7
// Desc: Game of Life, "slow version" to show the transistions
// Date: 2022/06/16
// Auth: Ingo Janssen
//
// cmd: +am2 +a0.5 +w640 +h360 +kff3000
// ffmpeg -r 30 -f image2 -s 640x360 -i conway%04d.png -vcodec libx265 -crf 30
-preset veryslow -pix_fmt yuv420p conway.mp4

#version 3.7;
#include "rand.inc"
#include "math.inc"

global_settings{ assumed_gamma 1.0 }
#default{ finish{ ambient 0.1 diffuse 0.9 }}


#declare Stream = seed(777);

#declare _CAstate_current = 0;
#declare _CAstate_last = 1;
// variables
#declare _CAdead = 0;
#declare _CAlive = 1;


/*====
CAinit(SizeX, SizeY): Initialize the two dimensional grid for the Game of life.
It will contain te current state and the last state of each cell in the grid.

SizeX, SizeY: the grid dimensions
*/
#macro CAinit(SizeX, SizeY)
  #local CAgrid = array[SizeX][SizeY];
  #for(i,0,SizeY-1)
    #for(j,0,SizeX-1)
      #local CAgrid[j][i] = array[2]{0,0};
    #end
  #end
  CAgrid
#end

/*====
CArndState(CAgrid): Randomize the grid's current state, fill with 1 & 0's

CAgrid: Two dimensional array that is the grid.
*/
#macro CArndState(CAgrid)
  #for(i, 0, dimension_size(CAgrid, 2) - 1)
    #for(j, 0, dimension_size(CAgrid, 1) - 1)
      #local rndVal = Prob(0.5, Stream);
      #local CAgrid[j][i][_CAstate_current] = rndVal;
    #end
  #end
#end

/*====
CAwrite(CAgrid, Path): writes the current and last state of the grid to file

CAgrid: Two dimensional array that is the grid.
Path: path/file name to write the file to.
*/
#macro CAwrite(CAgrid, Path)
  #local SizeX =  dimension_size(CAgrid,1);
  #local SizeY =  dimension_size(CAgrid,2);
  #local Vals = "";
  #for(i, 0, SizeY - 1)
    #for(j, 0, SizeX - 1)
      #local Vals = concat(Vals,
        str(CAgrid[j][i][_CAstate_current],0,0),",",
        str(CAgrid[j][i][_CAstate_last],0,0),","
      );
    #end
    #local Vals = concat(Vals, "\n");
  #end
  #fopen CAFile Path write
    #write (CAFile SizeX "," SizeY "\n")
    #write (CAFile Vals)
  #fclose CAFile
#end

/*====
CAread(CAgrid, Path): reads the current and last state of the grid from file
into the grid

CAgrid: Two dimensional array that is the grid and holds the states
Path: path/file name to write the file to.
*/
#macro CAread(CAgrid, Path)
  #local SizeX = 0;
  #local SizeY = 0;
  #fopen CAFile Path read
    #read(CAFile SizeX, SizeY)
    #for(i, 0, SizeY - 1)
      #for(j, 0, SizeX - 1)
        #read(CAFile
          CAgrid[j][i][_CAstate_current],
          CAgrid[j][i][_CAstate_last],
        )
      #end
    #end
  #fclose CAFile
#end


#macro CAdebug(CAgrid)
  #debug concat("Frame number: ",str(frame_number,0,0),"\n")
  #debug "Current state:\n"
  #for(i, 0, dimension_size(CAgrid, 2) - 1)
    #for(j, 0, dimension_size(CAgrid, 1) - 1)
      #debug concat(str(CAgrid[j][i][_CAstate_current],0,0)," ")
    #end
    #debug "\n"
  #end
  #debug "Last state:\n"
  #for(i, 0, dimension_size(CAgrid, 2) - 1)
    #for(j, 0, dimension_size(CAgrid, 1) - 1)
      #debug concat(str(CAgrid[j][i][_CAstate_last],0,0)," ")
    #end
    #debug "\n"
  #end
  #debug "\n"
#end


#declare RollOver = function(ModAB, B){
  select(ModAB, B + ModAB, ModAB)
}//#debug concat(str(RollOver(mod(-0.1, 3), 3),0,-1),"\n")

#macro CAgetNeighbours(CAgrid, CurrentCell)
  #local SizeX = dimension_size(CAgrid, 1);
  #local SizeY = dimension_size(CAgrid, 2);
  #local Sum = 0;
  #for(i, CurrentCell.y-1, CurrentCell.y+1)
    #local I = RollOver(mod(i,SizeY), SizeY);
    #for(j, CurrentCell.x-1, CurrentCell.x+1)
      #local J = RollOver(mod(j,SizeX), SizeX);
      #local Sum = CAgrid[J][I][_CAstate_last] + Sum;
    #end
  #end
  #local Sum = Sum - CAgrid[CurrentCell.x][CurrentCell.y][_CAstate_last];
  Sum
#end


#macro CArulerun(CAgrid)
  #local SizeX = dimension_size(CAgrid,1);
  #local SizeY = dimension_size(CAgrid,2);
  #for(i, 0, SizeY - 1)
    #for(j, 0, SizeX - 1)
      #local CAgrid[j][i][_CAstate_last] = CAgrid[j][i][_CAstate_current];
    #end
  #end
  #for(i, 0, SizeY - 1)
    #for(j, 0, SizeX - 1)
      #local CurrentCell = <j,i>;
      #local CurrentValue = CAgrid[j][i][_CAstate_last];
      #local Neighbour = CAgetNeighbours(CAgrid, CurrentCell);
      #if(CurrentValue = 1 & Neighbour < 2)
        #local CAgrid[j][i][_CAstate_current] = 0;
      #elseif(CurrentValue = 1 & Neighbour > 3)
        #local CAgrid[j][i][_CAstate_current] = 0;
      #elseif(CurrentValue = 0 & Neighbour = 3)
        #local CAgrid[j][i][_CAstate_current] = 1;
      #end
    #end
  #end
#end


#macro CAobject(CAgrid, Frames)
  #local Frame = mod(frame_number, Frames);
  #local Half = Frames/2;
  #debug concat(str(Frame,0,-1)," , ",str(Half,0,-1) ,"\n")
  union {
    #if(Frame>Half)
      #for(i, 0, dimension_size(CAgrid, 2) - 1)
        #for(j, 0, dimension_size(CAgrid, 1) - 1)
          #if(CAgrid[j][i][_CAstate_current] = 1)
            sphere{<j,i,0> 0.5 pigment {rgb 1}}
          #end
        #end
      #end
    #elseif(Frame <= Half)
      #for(i, 0, dimension_size(CAgrid, 2) - 1)
        #for(j, 0, dimension_size(CAgrid, 1) - 1)
          #if(CAgrid[j][i][_CAstate_current] != CAgrid[j][i][_CAstate_last])
            #if (CAgrid[j][i][_CAstate_current] = 1)
              sphere{<j,i,0> adj_range2(Frame,0,Half,0,0.5) pigment {rgb 1}}
            #else
              sphere{<j,i,0> adj_range2(Frame,0,Half,0.5,0) pigment {rgb 1}}
            #end
          #elseif(
            CAgrid[j][i][_CAstate_current] = CAgrid[j][i][_CAstate_last]
            & CAgrid[j][i][_CAstate_current] = 1
          )
            sphere{<j,i,0> 0.5 pigment {rgb 1}}
          #end
        #end
      #end
    #end
  }
#end


#declare TempFn = "conway.arr" //ramdisc
#declare Frames = 20;

#declare SizeX = 48;
#declare SizeY = 27;
#declare Conway = CAinit(SizeX, SizeY);
#if(file_exists(TempFn))
  CAread(Conway, TempFn)
#else
  CArndState(Conway)
#end
#if(mod(frame_number, Frames) = 0 & frame_number > 1)
  CArulerun(Conway)
  CAwrite(Conway, TempFn)
#end
//CAdebug(Conway)
object{CAobject(Conway, Frames)}

camera {
  angle 55
  location  <(SizeX/2)-0.5,(SizeY/2)-0.5, -50>
  look_at   <(SizeX/2)-0.5,(SizeY/2)-0.5, 0>
  right     x*image_width/image_height
}
light_source{
  <SizeX, SizeY, -2000>, rgb 1
}

[Thomas de Groot] Re: object pattern as media-- animations [1423 days 2 hours and 40 minutes ago]

Sat, 14 May 2022 12:38:54 GMT

Op 13-5-2022 om 01:17 schreef Kenneth:
> Here's another one!
> 
> One of my experiments ended up looking like a nebula of some kind, so I added a
> familiar-looking(?) spaceship, and a background photo.  This is just emission
> media.
> 
> The wispy look required a HIGH samples count, to try and keep the media from
> showing 'discontinuities' between the samples/intervals as the camera moved
> through it. (I should have used an even higher value.) The camera movement is
> within a very small space.
> 
> Total render time for 400 frames: about 9 hours.

I love that one.

-- 
Thomas

[jr] Re: object pattern as media-- animations [1423 days 7 hours and 4 minutes ago]

Sat, 14 May 2022 08:15:00 GMT

hi,

"Kenneth" <kdw### [at] gmailcom> wrote:
> Here's another one!
>
> One of my experiments ended up looking like a nebula of some kind, so I added a
> familiar-looking(?) spaceship, and a background photo.  This is just emission
> media.
>
> The wispy look ...

is _real_ nice, and also the "fly-though" works for me.  cheers.


regards, jr.

[Alain Martel] Re: object pattern as media-- animations [1424 days 1 hour and 59 minutes ago]

Fri, 13 May 2022 13:19:33 GMT

Le 2022-05-12 Ã  19:17, Kenneth a Ã©critÂ :
> Here's another one!
> 
> One of my experiments ended up looking like a nebula of some kind, so I added a
> familiar-looking(?) spaceship, and a background photo.  This is just emission
> media.
> 
> The wispy look required a HIGH samples count, to try and keep the media from
> showing 'discontinuities' between the samples/intervals as the camera moved
> through it. (I should have used an even higher value.) 

You are correct, you need a higher value for your samples, like about 
50% more.
Another option would be to make the shell slightly thicker. Not by much. 
Maybe only 5 to 10% thicker could make a big difference.

[Kenneth] Re: object pattern as media-- animations [1424 days 15 hours and 59 minutes ago]

Thu, 12 May 2022 23:20:01 GMT

Here's another one!

One of my experiments ended up looking like a nebula of some kind, so I added a
familiar-looking(?) spaceship, and a background photo.  This is just emission
media.

The wispy look required a HIGH samples count, to try and keep the media from
showing 'discontinuities' between the samples/intervals as the camera moved
through it. (I should have used an even higher value.) The camera movement is
within a very small space.

Total render time for 400 frames: about 9 hours.

[Kenneth] Re: object pattern as media-- animations [1437 days 22 hours and 4 minutes ago]

Fri, 29 Apr 2022 17:15:00 GMT

This animation is similar to the previous one, but the Bunny artwork fades into
a multi-colored cells pattern... just for fun. ;-)

[Kenneth] object pattern as media-- animations [1437 days 22 hours and 14 minutes ago]

Fri, 29 Apr 2022 17:05:01 GMT

See my original post here..,

https://news.povray.org/povray.binaries.images/thread/%3Cweb.626c0f28ac9c0ae18d86850a6e066e29%40news.povray.org%3E/

An animation of 'solid'-looking emission + absorption medias, using POV-ray's
object pattern for the media.

A mesh2 model as the object pattern, with an image_map as the media density...
then all of it heavily distorted with warp{turbulence...}

The slight flickering in the media is, I think, the result of rotating the
entire media object while the media's intervals/samples remain 'fixed' in
spatial orientation, by default(?)

[Alain Martel] Re: Help With Image [1446 days 23 hours and 22 minutes ago]

Wed, 20 Apr 2022 15:56:47 GMT

Le 2022-04-19 Ã  16:04, Cousin Ricky a Ã©critÂ :
> On 2022-04-16 13:28 (-4), Craig Lindley wrote:
>>
>> After struggling with Doyle circle packing code for a week I finally have an
>> image which is close to the original image I posted. I've attached the image and
>> a POV file in case anyone wants to play around with it. I wrote the circle
>> packing code in Java and then transferred the generated spheres into a POV file.
>> If anyone is interested in the Java code, let me know and I can get it to you.
> 
> Here's an animation.

Very cool. Especially full screen and looping.

[m@b] Re: Help With Image [1447 days 14 hours and 21 minutes ago]

Wed, 20 Apr 2022 00:57:25 GMT

On 20/04/2022 4:04 am, Cousin Ricky wrote:
> On 2022-04-16 13:28 (-4), Craig Lindley wrote:
>>
>> After struggling with Doyle circle packing code for a week I finally have an
>> image which is close to the original image I posted. I've attached the image and
>> a POV file in case anyone wants to play around with it. I wrote the circle
>> packing code in Java and then transferred the generated spheres into a POV file.
>> If anyone is interested in the Java code, let me know and I can get it to you.
> 
> Here's an animation.

Very nice :-)

I played with hue cycling as well:

m@

[Cousin Ricky] Re: Help With Image [1447 days 19 hours and 15 minutes ago]

Tue, 19 Apr 2022 20:04:01 GMT

On 2022-04-16 13:28 (-4), Craig Lindley wrote:
> 
> After struggling with Doyle circle packing code for a week I finally have an
> image which is close to the original image I posted. I've attached the image and
> a POV file in case anyone wants to play around with it. I wrote the circle
> packing code in Java and then transferred the generated spheres into a POV file.
> If anyone is interested in the Java code, let me know and I can get it to you.

Here's an animation.

[Dave Blandston] Re: Music Video Project Finished [1453 days 20 hours and 9 minutes ago]

Wed, 13 Apr 2022 19:10:00 GMT

Improved version:

https://www.youtube.com/watch?v=cqsl1TY6Qbo

[William F Pokorny] Re: sink+flip [1460 days 22 hours and 35 minutes ago]

Wed, 6 Apr 2022 16:43:29 GMT

On 3/23/22 13:02, jr wrote:
> "jr" <cre### [at] gmailcom> wrote:
>> a while ago I made a simple animation ...
> 
> updated.
> 
> <https://drive.google.com/file/d/11llUEDeUjD-S6MZ3xF7cg8un5MC05E0v/view?usp=sharing>
> 
> 
> enjoy, jr.
> 
:-) Cool.

[jr] Re: sink+flip [1474 days 22 hours and 14 minutes ago]

Wed, 23 Mar 2022 17:05:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> a while ago I made a simple animation ...

updated.

<https://drive.google.com/file/d/11llUEDeUjD-S6MZ3xF7cg8un5MC05E0v/view?usp=sharing>


enjoy, jr.

[jr] Re: USaF [1485 days 6 hours and 39 minutes ago]

Sun, 13 Mar 2022 08:40:00 GMT

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

instead of posting another low-quality anim, I've opted to put the animation "in
the cloud", and a single frame in p.b.i, with ref to this thread (rendering at a
low resolution came at the "cost" of broken up grid lines, though they're not
noticeable when viewing the anim)

<https://drive.google.com/file/d/11gaKIbbZygJH0hm2v39b8SKSgd_QYdCK/view?usp=sharing>

if you don't want to download (a little over 200M), see the attached zip for
source files[*].  on my .. geriatric h/ware (all dual core 4 threads) it takes
well under two hours to render the 4K images.

[*] license GPL v3+.  have tried to make the code "cleaner", the path to adjust
in the scene file is now on line 55, and the last line in the ini (also forgot
to comment out 'display=false' in the same file, sorry).


enjoy, jr.

[jr] Re: USaF [1485 days 21 hours and 34 minutes ago]

Sat, 12 Mar 2022 17:45:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> ...  working on a follow up with (hopefully) a better view(ing).

now have basic camera control (thanks to Bald Eagle), the attached demonstrates
that I'll need to "fiddle" some more with the settings.  will (hopefully) get to
a "final" version before long, will post the updated source files then.


enjoy, jr.

[jr] Re: USaF [1487 days 23 hours and 19 minutes ago]

Thu, 10 Mar 2022 16:00:00 GMT

hi,

"Kenneth" <kdw### [at] gmailcom> wrote:
> ...
> I just tried Microsoft's EDGE browser instead of Firefox -- and the video does
> download! And plays in all of my video viewers including VLC (except in
> Irfanview).

excellent.  (used to use + really like IrfanView back when.  no video support
then that I recall)

> So the problem IS with Firefox. That's mighty strange.

as is Thunderbird..  :-)

> Anyway... I like it! Nicely done.

thank you.  working on a follow up with (hopefully) a better view(ing).

regards, jr.

[Kenneth] Re: USaF [1489 days 3 hours and 19 minutes ago]

Wed, 9 Mar 2022 12:00:00 GMT

"jr" <cre### [at] gmailcom> wrote:
>
> thank you, yes, do want to know.  :-)  fwiw, I downloaded the vid (via Chrome
> browser) to an Android + it plays alright in VLC.

I just tried Microsoft's EDGE browser instead of Firefox -- and the video does
download! And plays in all of my video viewers including VLC (except in
Irfanview).

So the problem IS with Firefox. That's mighty strange.

Anyway... I like it! Nicely done.

[jr] Re: USaF [1490 days 1 hour and 4 minutes ago]

Tue, 8 Mar 2022 14:15:00 GMT

hi,

"Kenneth" <kdw### [at] gmailcom> wrote:
> In Windows 10 with latest Firefox browser, there appears to be no video when I
> try to download it; Firefox says...
>
> "No video with supported format and MIME type found"
>
> As a trial, I 'downloaded' my own recent animation in the newsgroups,
> "media_spline_art_test_A_ 2_25_22".  Firefox itself immediately starts to play
> it as a preview (rather than 'downloading' it, which is now an extra step.) But
> I just wanted to test another video against yours, to try and figure out where
> the problem lies. Maybe your animation has no actual content? Or has some type
> of encoding problem? I thought you would want to know.

thank you, yes, do want to know.  :-)  fwiw, I downloaded the vid (via Chrome
browser) to an Android + it plays alright in VLC.  (whether there's "content" is
open to debate :-) but if you cannot convince yr s/ware to play it, hope the zip
archive will work)


> Who knows, maybe the problem is with Firefox itself (?)

"computers are like air conditioners, they stop working when you open Windows."
(read this in someone's signature block once)


regards, jr.

[Kenneth] Re: USaF [1490 days 2 hours and 9 minutes ago]

Tue, 8 Mar 2022 13:10:00 GMT

In Windows 10 with latest Firefox browser, there appears to be no video when I
try to download it; Firefox says...

"No video with supported format and MIME type found"

As a trial, I 'downloaded' my own recent animation in the newsgroups,
"media_spline_art_test_A_ 2_25_22".  Firefox itself immediately starts to play
it as a preview (rather than 'downloading' it, which is now an extra step.) But
I just wanted to test another video against yours, to try and figure out where
the problem lies. Maybe your animation has no actual content? Or has some type
of encoding problem? I thought you would want to know.

Who knows, maybe the problem is with Firefox itself (?)

[jr] USaF [1490 days 15 hours and 24 minutes ago]

Mon, 7 Mar 2022 23:55:00 GMT

hi,

Ulam Spiral (animation) Fun.  the quality is crap but posting a zip with source
in p.b.i thread "Ulam Spiral fun".


enjoy, jr.

[William F Pokorny] Re: media plus spline density-- animation test [1498 days 6 hours and 59 minutes ago]

Mon, 28 Feb 2022 08:19:50 GMT

On 2/27/22 11:02, Kenneth wrote:
> This animation relates to the discussion found here...
> 
>
https://news.povray.org/povray.binaries.images/thread/%3Cweb.621b98d84d044a474cef624e6e066e29%40news.povray.org%3E/
> 
> Just a test, while moving the camera around the media-filled box.
> 
> [BTW: From this test and others I have done in the past, it appears that there
> is an 'interplay' between a camera's position and the orientation(?) of media's
> intervals/samples; subtle visual changes occur.  This effect is more pronounced
> the more the camera faces away from +z.]

Cool! Thanks. :-)

Bill ).

[Kenneth] media plus spline density-- animation test [1498 days 23 hours and 14 minutes ago]

Sun, 27 Feb 2022 16:05:00 GMT

This animation relates to the discussion found here...

https://news.povray.org/povray.binaries.images/thread/%3Cweb.621b98d84d044a474cef624e6e066e29%40news.povray.org%3E/

Just a test, while moving the camera around the media-filled box.

[BTW: From this test and others I have done in the past, it appears that there
is an 'interplay' between a camera's position and the orientation(?) of media's
intervals/samples; subtle visual changes occur.  This effect is more pronounced
the more the camera faces away from +z.]

[Kenneth] Re: animation test-- compression encoding schemes [1505 days 2 hours and 39 minutes ago]

Mon, 21 Feb 2022 12:40:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> I had to resize a video for a friend a while back, and as far as I can remember,
> I used ffmpeg, or convert in order to resize and maybe decrease the frame rate
> to make the file size smaller.

AFAIK(?) both VLC Media Player and VirtualDub2 MOD make use of ffmpeg-- hidden
under their Windows GUI's. I confess that I have never been any good at using
ffmpeg's command-line tools; trying to remember which code settings to use makes
my brain hurt. (Translation: I'm lazy ;-) ]
>
> I'd say that this is one of those areas where you should really just jettison
> understanding how any of it works...
> Because when that waters are this deep, and you're not planning to start a
> new PhD level career in graphics formats and data compression algorithms,
> then you're not going to get anything done, and you're still not going
> to understand how it all works.

Yeah, I agree! Well-said. Although, it nags me that I don't fully understand all
of it-- just enough to be dangerous! It's fascinating to read about...until my
eyes glaze over.

But I *want* to be a PhD genius in graphics formats and data compression
algorithms!

And an astronaut. And a James Bond 007 spy. And...

[Bald Eagle] Re: animation test-- compression encoding schemes [1505 days 23 hours and 49 minutes ago]

Sun, 20 Feb 2022 15:30:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:

> > may David Buck can chip in.  I was (seriously) impressed by his recent coding
> > demo which came in at only ~1.2M.  (wouldn't mind knowing the "magic" settings)
>
> ANY help would be useful ;-) Trying to fathom the intricacies of this
> compression stuff-- AND container formats -- is like reading 'Moby Dick' in
> Sanscrit. In fact, the more I read about all of it, the more confusing it gets.
> There are HD video transmission standards, rgb vs. Rec 709 (and 601) standards,
> DVD standards, Blu_Ray standards, etc etc...
>
> :-O

I had to resize a video for a friend a while back, and as far as I can remember,
I used ffmpeg, or convert in order to resize and maybe decrease the frame rate
to make the file size smaller.

For the Secret Passage entry, I remember that all I did was open the image in
some image viewer and the re-save it using some settings that brought the file
size down.

I'd say that this is one of those areas where you should really just jettison
understanding how any of it works, and just start trying out different utilities
and software packages.   Fly by the seat of your pants.   Because when that
waters are this deep, and you're not planning to start a new PhD level career in
graphics formats and data compression algorithms, then you're not going to get
anything done, and you're still not going to understand how it all works.   Just
watch a single video on jpg compression and you'll see what I mean.

[Kenneth] Re: animation test-- compression encoding schemes [1506 days 2 hours and 59 minutes ago]

Sun, 20 Feb 2022 12:20:00 GMT

"jr" <cre### [at] gmailcom> wrote:
>
> agree with TdG, impressive.  (any darker and I'd suspect burning car tires :-))

Ha! Yes, that can easily be done too; one of my tests looked like that.

> works here, using 'ffplay' (part of 'ffmpeg') on Slackware Linux, and on Android
> using VLC, the Chromebook too plays it.

Good to know! Thanks for the feedback.

> may David Buck can chip in.  I was (seriously) impressed by his recent coding
> demo which came in at only ~1.2M.  (wouldn't mind knowing the "magic" settings)

ANY help would be useful ;-) Trying to fathom the intricacies of this
compression stuff-- AND container formats -- is like reading 'Moby Dick' in
Sanscrit. In fact, the more I read about all of it, the more confusing it gets.
There are HD video transmission standards, rgb vs. Rec 709 (and 601) standards,
DVD standards, Blu_Ray standards, etc etc...

:-O

[Kenneth] Re: animation test-- compression encoding schemes [1506 days 3 hours and 44 minutes ago]

Sun, 20 Feb 2022 11:35:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
>
> Tonga!
>
> That is pretty good, Kenneth. Impressive smoke column.
>

Thanks. I am glad it played OK for you!

My original idea was to create translucent wispy smoke or steam; but with higher
media density and a higher extinction value, the result looks like dense smoke,
which I like. Actually, this particular test reminds me of those undersea
'smoker' vents on the sea floor, where the pressure is so great that the 'smoke'
does not spread out or dissipate very much.

The test code at the beginning of the animation is good for experimenting with
the various values.

----
That Tonga volcanic explosion was quite awesome to see, especially the
time-lapse animations from space. I can imagine it being x-number of times more
powerful, as an indication of the asteroid event that wiped out the dinosaurs!

[jr] Re: animation test-- compression encoding schemes [1506 days 4 hours and 44 minutes ago]

Sun, 20 Feb 2022 10:35:00 GMT

hi,

"Kenneth" <kdw### [at] gmailcom> wrote:
> [Running v3.8.0 beta 1 in Windows 10]
> This is my first uploaded animation from my Windows 10 computer that I purchased
> in early 2021.

agree with TdG, impressive.  (any darker and I'd suspect burning car tires :-))

> ...
> This is really more of a test of my animation encoding scheme, to see if the
> file plays back for everyone. ...

works here, using 'ffplay' (part of 'ffmpeg') on Slackware Linux, and on Android
using VLC, the Chromebook too plays it.

> I am certainly no expert on the subject of video compression, but I keep trying
> to learn. There are so *many* so-called 'standards' that have accumulated over
> the years.  It was all much simple in the days of AVI video-making!

may David Buck can chip in.  I was (seriously) impressed by his recent coding
demo which came in at only ~1.2M.  (wouldn't mind knowing the "magic" settings)

regards, jr.

[Thomas de Groot] Re: animation test-- compression encoding schemes [1506 days 8 hours and 6 minutes ago]

Sun, 20 Feb 2022 07:12:25 GMT

Op 20/02/2022 om 00:34 schreef Kenneth:
> [Running v3.8.0 beta 1 in Windows 10]
> This is my first uploaded animation from my Windows 10 computer that I purchased
> in early 2021.
> 
> Scattering media plus two light_sources, using two warp{turbulences...} -- one
> moves in y, the other is static.
> 
[snip]

Tonga!

That is pretty good, Kenneth. Impressive smoke column.

-- 
Thomas

[Kenneth] animation test-- compression encoding schemes [1506 days 15 hours and 39 minutes ago]

Sat, 19 Feb 2022 23:40:00 GMT

[Running v3.8.0 beta 1 in Windows 10]
This is my first uploaded animation from my Windows 10 computer that I purchased
in early 2021.

Scattering media plus two light_sources, using two warp{turbulences...} -- one
moves in y, the other is static.

This is really more of a test of my animation encoding scheme, to see if the
file plays back for everyone. (Of course, in the newsgroups' web-portal, there
is always an extra suffix appended to the end of an animation file name, which
causes problems for playback in certain apps).

I am certainly no expert on the subject of video compression, but I keep trying
to learn. There are so *many* so-called 'standards' that have accumulated over
the years.  It was all much simple in the days of AVI video-making!

I used an old but still-available app called 'VirtualDub2 MOD' to assemble this
animation from .png renders. On my system, the resulting animation plays in all
of the video apps I have: Windows Media Player, Irfanview, avidemux (another
*old* one), VirtualDub2 MOD, and VLC Media Player.

VirtualDub2 MOD has lots of compression/encoding choices-- many of which I don't
understand, so I leave them at their defaults. But I've been experimenting with
the simpler choices. This is how I encoded the file; the stats as seen in the
app itself are copied verbatim:

COMPRESSION:
x264 8 bit - H.264/MPEG-4 AVC codec
YUV 4:2:0
MPEG 'profile' and 'Level' on 'Auto'
pixel format: 4:2:0 planar YCbCr (YV12)
YCbCr properties:  color space: Rec 709 HD
component range: Limited (Y: 16 - 235)
Source: RGBA32
Actual output: YUV420-709

CONTAINER FORMAT:
MP4 (MPEG-4 Part 14) (*.mp4)

Yeah, a lot of this stuff looks like technical gibberish and is not easily
understood. But some research on Wikipedia about 'Rec 709' as well as 'chroma
subsampling' was quite useful-- regarding the 4:2:0 and YCbCr stuff in
particular.

4:2:0 is one of the standards used for chroma subsampling for compression; but
there are others, like 4:2:2. According to what I have read, that one should
also work with the Rec 709 standard (and at a higher quality)-- but such a test
animation does not play in Windows Media Player; I get
a black screen. And it *crashes* Irfanview, so badly that the app is broken for
my entire work session-- I have to reboot Windows to bring it back to working
status. Yet, other apps I have like VLC Media Player play it back OK. I have no
idea why, so far.

The most interesting statistic IMO is the 'component range' of Y: 16 - 235.
Y itself is the luminance of the colors -- think grayscale brightness levels.
(Actually it's not luminance but 'luma', which AFAIK is the gamma-corrected
version of luminance.)  It would *seem* that a 'full' range of 0-255 brightness
levels would the ideal choice-- and VirtualDub does allow that choice as 'Rec
709 HD FR' ("full range").  But in my encoding tests, the 'limited' 16-235 range
actually reproduces the POV-ray renders far more accurately.  0 - 255 produces
higher contrast and does not match the original render. That seems strange, but
I guess it involves some deeper technical stuff.

I'm still learning  ;-)

[Dave Blandston] Re: Holey Cube puzzle animation [1552 days 19 hours and 34 minutes ago]

Tue, 4 Jan 2022 19:45:00 GMT

"Eriban" <pov### [at] spamgourmetcom> wrote:
> Hi all,
>
> First of all, best wishes to everyone for 2022!


Happy new year as well!

What an accomplishment - the technical features are impressive indeed.

Have a great day,
Dave Blandston

[Thomas de Groot] Re: Holey Cube puzzle animation [1554 days 7 hours and 46 minutes ago]

Mon, 3 Jan 2022 07:32:39 GMT

Op 02/01/2022 om 23:36 schreef Eriban:
> Hi all,
> 
> First of all, best wishes to everyone for 2022! It has been a while, but I found
> some time to work with POV-Ray again, and the result is another puzzle
> animation.
> 
Holey shit! You will be fined 100 Credits, sir, for dancing in a 
confined spaced during Covid lockdown! You should be ashamed of 
yourself, exposing all those innocent pieces to serious contamination, 
not the least being to want to start all over again watching the video!

One of your best assuredly. I seriously wonder how you could keep track 
of all those pieces moving at the same time.

-- 
Thomas

[Bald Eagle] Re: Holey Cube puzzle animation [1554 days 13 hours and 29 minutes ago]

Mon, 3 Jan 2022 01:50:00 GMT

"Eriban" <pov### [at] spamgourmetcom> wrote:
> To move as many parts in parallel without any parts colliding, a greedy scheduling
> algorithm is used together with a basic collision detection algorithm.

Wow - that's ambitious, in and of itself!

> Second, for in-flight part rotations I had a go at using Quaternions. I used
> an old quaternions.inc file
>
(http://news.povray.org/povray.binaries.scene-files/thread/%3CXns940C86DC9B1D4None%40204.213.191.226%3E/)
> as starting point. It was a good start, but I had to fix a few bugs.

But of course you did!  ;)
Next we know, you'll be into Octonions and hanging out with Cohl Furey...

> The updated
> file can be found on GitHub, alongside all other source code used to create the
> animation:
> https://github.com/erwinbonsma/HoleyCubeAnimation
>
> Anyway, enough talk. Here's the link to the video:
> https://youtu.be/nSJAEyxExLY

Wow - as if the earlier puzzle videos weren't impressive enough - now you have
everything dancing and oscillating with the musical score...

.... and of course you had to expand on the original puzzle so that it could be
fractally extended out to infinity.

What's next?  4D puzzles?

Great job as always - glad to see a new puzzle, and one that is impressive on so
many levels as well  :)

- Bill

[Ton] Re: Holey Cube puzzle animation [1554 days 15 hours and 9 minutes ago]

Mon, 3 Jan 2022 00:10:00 GMT

Yes, I like it, well done.
Going to github later and see you did all this.

Cheers
Ton.

[Eriban] Holey Cube puzzle animation [1554 days 16 hours and 39 minutes ago]

Sun, 2 Jan 2022 22:40:00 GMT

Hi all,

First of all, best wishes to everyone for 2022! It has been a while, but I found
some time to work with POV-Ray again, and the result is another puzzle
animation.

The basis is a twelve part puzzle designed by Yukio Hirose. Once I realised that
the design could be extended in a fractal-like fashion, I figured it would make
an excellent animation subject.

The textures are very basic. They are designed to show off the puzzle's
structure. However, the animation has some interesting technical features.

First, the part movement of the Level 2 assembly requires moving 144 parts. To
move as many parts in parallel without any parts colliding, a greedy scheduling
algorithm is used together with a basic collision detection algorithm.

Second, for in-flight part rotations I had a go at using Quaternions. I used
an old quaternions.inc file
(http://news.povray.org/povray.binaries.scene-files/thread/%3CXns940C86DC9B1D4None%40204.213.191.226%3E/)
as starting point. It was a good start, but I had to fix a few bugs. The updated
file can be found on GitHub, alongside all other source code used to create the
animation:
https://github.com/erwinbonsma/HoleyCubeAnimation

Anyway, enough talk. Here's the link to the video:
https://youtu.be/nSJAEyxExLY

I hope you like it!

Cheers,
Erwin

[Dave Blandston] Re: Master of Puppets Font Animation variation 1 [1557 days 5 hours and 29 minutes ago]

Fri, 31 Dec 2021 09:50:00 GMT

Variation 2... (also cyclic)

[Dave Blandston] Master of Puppets Font Animation variation 1 [1557 days 5 hours and 34 minutes ago]

Fri, 31 Dec 2021 09:45:00 GMT

Since the Master of Puppets font is made of round things the obvious course of
action is to animate the diameter of the character elements. The result isn't
quite as spectacular as I was hoping but still somewhat interesting.

The actual shape of two of the characters ("M" and "N") change according to the
diameter so you'll notice that in this video.

The animation is cyclic.

Have a great day,
Dave Blandston

[Dave Blandston] Re: Variation on the "Lava Lamp" Animated Text [1579 days 9 hours and 54 minutes ago]

Thu, 9 Dec 2021 05:25:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Ha!
> Don't we wish.

Yep that was a big project and a lot of work but also lots of fun. Thanks for
the compliment sir!

Kind regards,
Dave Blandston

[Bald Eagle] Re: Variation on the "Lava Lamp" Animated Text [1580 days 3 hours and 9 minutes ago]

Wed, 8 Dec 2021 12:10:00 GMT

"Dave Blandston" <IsN### [at] protonmailch> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > So, I'm gonna guess that it's a very skillfully applied transform matrix.
>
> What??? There's an easier way???

Ha!
Don't we wish.

It was late and I was working from memory.

And you did go ahead and "do it the hard way", didn't you...   :D
"Each and every pixel in this animation was artisinally hand-crafted from
photons generated with power from a custom-made foot-pedal operated
generator...."

I was probably mixing matrix transforms and Mike Williams' non-linear scaling of
isosurfaces in my head.  A matrix won't use the proper interpretation of 'x',
since it's outside of the function parser.
I suppose you _could_ make an object pattern function and do it the isosurface
way, but that would introduce the added complication of texturing all of the
separate parts of the lettering...

"the slices are not scaled in the x dimension, but rather each
slice is intersected from a character that is created at the correct size for
that particular deformation function value. If the slices were simply scaled,
the inner parts would not match up. This is also what allows for the vertical
deformation."

Ah, going back and watching your animation on 'loop', I understand what that
means and what you're doing.  Very clever, and it gives a very nice effect -
that goopy, squishy effect that the vertical deformation achieves.

You do nice work, Dave   :)

[Dave Blandston] Re: Variation on the "Lava Lamp" Animated Text [1580 days 7 hours and 19 minutes ago]

Wed, 8 Dec 2021 08:00:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> So, I'm gonna guess that it's a very skillfully applied transform matrix.

What??? There's an easier way???

[Dave Blandston] Re: Variation on the "Lava Lamp" Animated Text [1580 days 7 hours and 19 minutes ago]

Wed, 8 Dec 2021 08:00:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> The artifacts I see make me think of thin sections combined into full letters.
> All guesswork, of course ;-)

Howdy Kenneth,

You guessed very well! You are correct that the characters are made of thin
slices. I'm not nearly as adept at mathematics as I would like to be and am
therefore limited to the less elegant and sophisticated methods. The moire
patterns are caused by the union of the differing-width slices. One fine detail,
however, is that the slices are not scaled in the x dimension, but rather each
slice is intersected from a character that is created at the correct size for
that particular deformation function value. If the slices were simply scaled,
the inner parts would not match up. This is also what allows for the vertical
deformation.

The next font variation in the set (#38) applies the same technique to the z
dimension as well. The effect is stunning in my opinion but requires radiosity
to really see what's going on. A character would be sliced up into (number of
vertical slices) * (number of depth slices) blocks which results in very slow
rendering times. An animation should be very cool indeed but due to the render
time required I haven't done it. Maybe a single word ("POV" would do) could be
animated at relatively low resolution in a couple weeks.

Here are the demo images of the font variations in case you want to see what #38
looks like:
https://news.povray.org/povray.binaries.images/thread/%3Cweb.59f0b9385b47c265c581d2c50%40news.povray.org%3E/?ttop=43635
9&toff=500

I've added a few more characters (@, cross, arrows) since the last "Border
Characters" posting so if anyone's interested I'll post an update.

Have a wonderful day!

Kind regards,
Dave Blandston

[Bald Eagle] Re: Variation on the "Lava Lamp" Animated Text [1580 days 12 hours and 49 minutes ago]

Wed, 8 Dec 2021 02:30:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:

> The sine-wave traveling through the letters has be intrigued. If the letters are
> just CSG objects, how did you 'squash and stretch' them? My guess would be:
> using functions for initially creating the (many?) 'simple' object shapes, then
> adding an animated sine function on top of that. OR, by 'slicing' CSG objects
> into lots of thin sections, and maybe scaling the slices in x using the various
> phases of a sine function?

Very good question, Brother Kenneth.

Having gone through all of Dave's Bordered Characters (BC)code, I can say that
he could - and would - move a mountain using only a teaspoon.  However, I think
all of that is pretty complicated and would require a full reworking of the BC
code to pull off.

So, I'm gonna guess that it's a very skillfully applied transform matrix.

[Kenneth] Re: Variation on the "Lava Lamp" Animated Text [1580 days 13 hours and 14 minutes ago]

Wed, 8 Dec 2021 02:05:00 GMT

"Dave Blandston" <IsN### [at] protonmailch> wrote:
>
> No height_fields, just CSG boxes and cylinders and such.
>

That's interesting. My initial guess about height_fields was based on some
artifacts that I see, on the 'sides' of the letters U, L and A. Like moire
patterns, but more linear; not quite the the 'look' of possible AA artifacts, or
even due to the vagaries of MPEG compression-- more like the  effect when the
side of a height_field is completely vertical (and when the HF does not have a
high-enough triangle resolution).

The sine-wave traveling through the letters has be intrigued. If the letters are
just CSG objects, how did you 'squash and stretch' them? My guess would be:
using functions for initially creating the (many?) 'simple' object shapes, then
adding an animated sine function on top of that. OR, by 'slicing' CSG objects
into lots of thin sections, and maybe scaling the slices in x using the various
phases of a sine function?

The artifacts I see make me think of thin sections combined into full letters.
All guesswork, of course ;-)

Actually, my very FIRST impression was that the letters were bent by an animated
sine-wave 'camera normal'-- but the background is static, so that's not the
trick.

[Dave Blandston] Re: Variation on the "Lava Lamp" Animated Text [1581 days 9 hours and 24 minutes ago]

Tue, 7 Dec 2021 05:55:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> Height_fields, I assume?
>
> I'm curious to know which app you assembled your animation frames in.

No height_fields, just CSG boxes and cylinders and such.

I used ffmpeg to make the .mp4 file using this command line:

ffmpeg -y -r 60 -start_number 0 -i Frame%03d.png -crf 17 -c:v libx264 -pix_fmt
yuv420p -r 60 LavaText.mp4

I don't actually know what some of those switches even mean but the end result
is a high quality 60 FPS .mp4 file. I'm glad it worked for you! I know exactly
what you're talking about regarding the past problems with animation files and I
agree, it's great that it works now.

Have a fantastic day!

Kind regards,
Dave Blandston

[Kenneth] Re: Variation on the "Lava Lamp" Animated Text [1581 days 14 hours and 34 minutes ago]

Tue, 7 Dec 2021 00:45:00 GMT

I like it-- even though my name isn't Paula :-P

Height_fields, I assume?

The interesting thing from my point of view is that the downloaded animation
actually plays in Windows Media Player (on my Win 10 machine); this is the FIRST
time that a file from POV-Ray's web portal, when downloaded, actually does so!
In the past (in Win 7 and Win XP) I always had to use a different media player,
I think because of the additional '.dat' suffix that has always been added to
such files, and which I could never 'fix'. AVI, MP4, they all had the same
problem.

But that has now changed (for whatever reason)!

I'm curious to know which app you assembled your animation frames in. Currently,
I use the old but still-available VirtualDub2 MOD, although I haven't yet
uploaded one of my current POV-Ray MP4 videos since purchasing my Win 10
machine.

[Dave Blandston] Variation on the "Lava Lamp" Animated Text [1582 days 20 hours and 14 minutes ago]

Sun, 5 Dec 2021 19:05:00 GMT

In this animation the deformation function (just a simple sine function) is
offset 180 degrees from letter to letter. This is most obvious between the "u"
and the "l." The animation is cyclic.

Have a great day everyone!

Kind regards,
Dave Blandston

[Dave Blandston] Re: Music Video Project Finished [1592 days 6 hours and 34 minutes ago]

Fri, 26 Nov 2021 08:45:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> those "Bordered Characters" have come a long way.  :-)  nice.
>
>
> regards, jr.

Ha ha you caught me! Have an awesome day!

[jr] Re: Music Video Project Finished [1592 days 7 hours and 59 minutes ago]

Fri, 26 Nov 2021 07:20:00 GMT

hi,

"Dave Blandston" <IsN### [at] protonmailch> wrote:
> Greetings Friends,
>
> This was a fun project! ...

those "Bordered Characters" have come a long way.  :-)  nice.


regards, jr.

[Dave Blandston] Re: Music Video Project Finished [1592 days 19 hours and 34 minutes ago]

Thu, 25 Nov 2021 19:45:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
> Not a heavy metal fan, so naturally I was unfamiliar with the song.  It
> struck me as a powerful anti-war song, which is a striking ironic
> contrast to the visual imagery.  Is this the point?
>
> Well done!

Yep exactly - my intention is that the waving flag represents the "we" in the
lyrics ("Do just as we say") which in my mind is the state and the psychopaths
who control it (CFR, UN, military industrial complex, bankers, et cetera),
deceptively portraying itself as patriotism; and everything else represents the
resulting reality and experiences described by the soldier.

Thanks for the generous compliment!

[Cousin Ricky] Re: Music Video Project Finished [1592 days 21 hours and 18 minutes ago]

Thu, 25 Nov 2021 18:00:34 GMT

On 2021-11-25 4:32 AM (-4), Dave Blandston wrote:
> 
> This was a fun project! Some of the graphic effects worked out better than
> others as you can see. But what could be better than POV-Ray and Metallica? [...]

Not a heavy metal fan, so naturally I was unfamiliar with the song.  It
struck me as a powerful anti-war song, which is a striking ironic
contrast to the visual imagery.  Is this the point?

Well done!

[Dave Blandston] Music Video Project Finished [1593 days 6 hours and 44 minutes ago]

Thu, 25 Nov 2021 08:35:00 GMT

Greetings Friends,

This was a fun project! Some of the graphic effects worked out better than
others as you can see. But what could be better than POV-Ray and Metallica? I'll
just mention that there's some spoiler info in the Youtube description regarding
the answer to that question...

https://www.youtube.com/watch?v=a4jScFBonLg

Have a great day everyone!

Kind regards,
Dave Blandston

[Hj Malthaner] Re: The insane project - Universe class carrier ... [1604 days 19 hours and 20 minutes ago]

Sat, 13 Nov 2021 19:59:15 GMT

On 1/15/21 5:43 AM, Hj. Malthaner wrote:
> Feel free to place bets. In my favorite sci-fi series there was a ship 
> called "SOL" for the name of our sun and it's sole purpose to return to 
> our galaxy.
> 
> It's been labeled a "Universe class battle carrier", cause "Ultra 
> Battleship" had been already been taken by the former flagship units.
> 
> I want to picture this as an animation. The SOL was a carrier ship made 
> of three components. I want to show the ship arriving, and then 
> splitting into its three parts. The command and control unit moving to 
> the back of the scene, while the two ultra battleship lookalike 
> components move forward.

So, still no 3 components, but I have the "unfolding" of one battle 
carrier now. Took some artistic freedom in the mix of the daughter 
ships, they don't meet the original specification.

https://youtu.be/rzP5lE_fnKM

[Hj Malthaner] Re: The insane project - Universe class carrier ... [1607 days 19 hours and 5 minutes ago]

Wed, 10 Nov 2021 20:13:54 GMT

On 1/21/21 2:52 AM, Hj. Malthaner wrote:
 > On 1/19/21 8:38 AM, Thomas de Groot wrote:
 >> Op 19/01/2021 om 05:14 schreef Hj. Malthaner:
 >>> On 1/15/21 3:47 PM, Mr wrote:
 >>>> "Hj. Malthaner" <han### [at] nospamgmxde> wrote:
 >
 >>>>> I want to picture this as an animation. The SOL was a carrier ship
 >>>>> made of three components.
 > [snip]
 >
 >> I would suggest to drop /all/ the story from your mind and let the
 >> engineer take over. Just decide which SOL you want to model in the
 >> first place: The early one or the latter one.

So, it's been a while. Was busy with many other things, but finally 
managed to get back to this. Right now I have simple model for one of 
the spherical SOL components, and models for the typical fighter crafts. 
Also learned how to use the spline feature to move the smaller ships.

https://youtu.be/FOrMTwNEwNE

Still needs a lot of work, but a start has been made.

[William F Pokorny] Re: Animation demonstrating environment, HDRI ed... [1624 days 4 hours and 59 minutes ago]

Mon, 25 Oct 2021 10:20:11 GMT

On 10/23/21 8:53 PM, m@b wrote:
> On 24/10/2021 6:54 am, William F Pokorny wrote:
>> Credit: https://polyhaven.com/a/sunflowers
...
> 
> That's the same image that I used for my library 
> animation:<https://youtu.be/M5VC_oSY8xs>
> 

Indeed. I played with it in particular to "look around." :-)

I like how camera derived, environmental HDRIs let us drop into a place 
and time on our planet we'd otherwise never see - in an immersive way.

Bill P.

[m@b] Re: Animation demonstrating environment, HDRI ed... [1625 days 14 hours and 25 minutes ago]

Sun, 24 Oct 2021 00:53:34 GMT

On 24/10/2021 6:54 am, William F Pokorny wrote:
> Credit: https://polyhaven.com/a/sunflowers
> 
> Bill P.
> 

That's the same image that I used for my library 
animation:<https://youtu.be/M5VC_oSY8xs>

m@

[William F Pokorny] Animation demonstrating environment, HDRI editin... [1625 days 16 hours and 24 minutes ago]

Sat, 23 Oct 2021 22:54:19 GMT

Credit: https://polyhaven.com/a/sunflowers

Bill P.

[Bald Eagle] Re: We know POV-Ray =3D3D3D?utf-8?Q?doesn=3D3D3D... [1740 days 4 hours and 54 minutes ago]

Thu, 1 Jul 2021 10:25:00 GMT

Subclick <no### [at] spam> wrote:

> Thank you very much.  I guess I have a lot to learn before I face this
> problem again.

No worries.  I tend to find myself in the deep end of the pool a lot.  :D

The trick there is that since it's a discontinuous function with an infinite
gradient, one just inserts a user-made smooth gradient to join up the 2 regions
of the function.  And then the isosurface method that you want to use works just
fine.

[Subclick] Re: We know POV-Ray =3D3D?utf-8?Q?doesn=3D3DE2=3... [1740 days 7 hours and 10 minutes ago]

Thu, 1 Jul 2021 08:08:41 GMT

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

> Bill Pokorny helped me along doing the same thing
> a while back, and here's one
> of the files related to that.  Feel free to ask
> any questions if the code
> (mostly his) is unclear.

Thank you very much.  IÂ guess I have a lot to learn before I face this
problem again.

[Bald Eagle] Re: We know POV-Ray =3D3D?utf-8?Q?doesn=3D3DE2=3... [1775 days 18 hours and 19 minutes ago]

Wed, 26 May 2021 21:00:00 GMT

Subclick <no### [at] spam> wrote:

> Thanks, but my goal was to get an arbitrary POV-Ray object—like a text
> object consisting of a single theta—into an isosurface, so it could then
> be transformed non-linearly at will.  Of course, that’d require a
> generic way to make up a smooth transition, with a finite gradient, from
> the outside to the inside, to replace the ‘object’ pattern’s jump
from 0
> to 1 at the boundary.

Yes, sorry - I think I botched that reply.

Bill Pokorny helped me along doing the same thing a while back, and here's one
of the files related to that.   Feel free to ask any questions if the code
(mostly his) is unclear.

[Subclick] Re: We know POV-Ray =3D?utf-8?Q?doesn=3DE2=3D80=... [1775 days 19 hours and 59 minutes ago]

Wed, 26 May 2021 19:19:21 GMT

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

> Because it's a giant mess.  You can do it, and it will be a bit slow,
> but here's a link for you:
>
> http://news.povray.org/web.5ebedadaa032ea3dfb0b41570%40news.povray.org

Thanks, but my goal was to get an arbitrary POV-Ray objectâ€”like a
text
object consisting of a single thetaâ€”into an isosurface, so it could
then
be transformed non-linearly at will.  OfÂ course, thatâ€™d
require a
generic way to make up a smooth transition, with a finite gradient, from
the outside to the inside, to replace the â€˜objectâ€™
patternâ€™s jump from 0
to 1 at the boundary.

[Bald Eagle] Re: We know POV-Ray =3D?utf-8?Q?doesn=3DE2=3D80=... [1776 days 15 hours and 4 minutes ago]

Wed, 26 May 2021 00:15:00 GMT

Subclick <no### [at] spam> wrote:
> Alain Martel <kua### [at] videotronca> writes:
>
> > Let me guess... An isosurface with cyclical perturbation.
>
> I wish!  I couldn’t come up with a way to get rid of the infinite
> gradient of the ‘object’ pattern on the object’s boundary without
> ruining it in the process, so I made do with a ridiculous number of thin
> slices of the object rotated appropriately.

Because it's a giant mess.  You can do it, and it will be a bit slow, but here's
a link for you:

http://news.povray.org/web.5ebedadaa032ea3dfb0b41570%40news.povray.org

[Subclick] --- [1776 days 17 hours and 57 minutes ago]

Tue, 25 May 2021 21:21:43 GMT

Alain Martel <kua### [at] videotronca> writes:

> Let me guess... An isosurface with cyclical perturbation.

IÂ wish!  IÂ couldnâ€™t come up with a way to get
rid of the infinite
gradient of the â€˜objectâ€™ pattern on the
objectâ€™s boundary without
ruining it in the process, so I made do with a ridiculous number of thin
slices of the object rotated appropriately.

[Bald Eagle] Re: We know POV-Ray =3D?utf-8?Q?doesn=3DE2=3D80=... [1776 days 18 hours and 34 minutes ago]

Tue, 25 May 2021 20:45:00 GMT

Subclick <no### [at] spam> wrote:
> What now?

Make it out of jello?  :D

And also know that related to Jello, sin (b) / tan (b) = . . . ?

[Mike Horvath] --- [1776 days 18 hours and 57 minutes ago]

Tue, 25 May 2021 20:21:17 GMT

On 5/25/2021 9:40 AM, Subclick wrote:
> 
> What now?
> 
> 
> 
> Whatever you notice, itâ€™s not the mesh, because
thereâ€™s no mesh.
> 


The faceted texture makes it look like a mesh. I was fooled.


Mike

[Alain Martel] --- [1776 days 19 hours and 52 minutes ago]

Tue, 25 May 2021 19:27:15 GMT

Le 2021-05-25 Ã  09:40, Subclick a Ã©critÂ :
> 
> What now?
> 
> 
> 
> Whatever you notice, itâ€™s not the mesh, because
thereâ€™s no mesh.
> 

Nice.

Let me guess... An isosurface with cyclical perturbation.

[Mike Horvath] --- [1776 days 21 hours and 20 minutes ago]

Tue, 25 May 2021 17:59:13 GMT

On 5/25/2021 9:40 AM, Subclick wrote:
> 
> What now?
> 
> 
> 
> Whatever you notice, itâ€™s not the mesh, because
thereâ€™s no mesh.
> 


Whatever it is, it looks sweet and tasty!


Mike

[Subclick] --- [1777 days 1 hour and 39 minutes ago]

Tue, 25 May 2021 13:40:14 GMT

What now?

[Mike Horvath] Re: Colony Ship Cylindrical City [1803 days 22 hours and 28 minutes ago]

Wed, 28 Apr 2021 16:50:50 GMT

On 4/7/2021 10:04 AM, Kenneth wrote:
> An unfolding city! Wow, I can understand Chris Colefax's citigen macro being
> used for creating a 'flat' city-- but your cylindrical unfolding is really
> amazing to see. Nice!
> 
> I downloaded that macro long ago, but still haven't gotten around to using or
> experimenting with it, to see how it procedurally generates its elements...
> thinking about how it might help my own 'city generator' scene-- which I still
> haven't finished
> :-(
> 
> 
> 
> 

I just replaced all calls to "box" with calls to a macro I created that 
builds a square chunk of a difference of two cylinders. Instead of 
vertical axis coordinates, you input the radii of the cylinders. Not 
complicated at all.

Mike

[Dave Blandston] Music "Acceleration" Test [1811 days 7 hours and 24 minutes ago]

Wed, 21 Apr 2021 07:55:00 GMT

Hey folks,

I tried to reproduce the "acceleration" effect using POV-Ray that's common in
music visualization software. In my opinion the attempt was successful and I
plan to use it in my current project.

https://youtu.be/Kpheiv1EM44

Sixty frames have to be rendered for every second of music so this three-minute
sample required 10,800 frames, which took several hours to render. Because of
the time limitation I'm going to stick with textures that animate well instead
of actual moving objects. If anyone has any ideas regarding good textures please
feel free to share them in a reply. The possibilities are obviously endless and
there's plenty of opportunity for creativity. Here's the simple one used in the
example video:

#local BlockColor = texture {
   pigment {
      #local Color0 = color <0.827, 0.481, 1.000>;
      #local Color1 = color <1.000, 0.506, 0.209>;
      granite
      warp {turbulence 1}
      color_map {
         [0 color Color0 * 1]
         [.18 color Color0 * .1]
         [1 color Color1 * 1.2]
      } //color_map
      scale <10, 10, 10>
   } //pigment
   finish {emission .9}
} //texture

Kind regards,
Dave Blandston

[Dave Blandston] Re: Music Video Project [1814 days 20 hours and 59 minutes ago]

Sat, 17 Apr 2021 18:20:00 GMT

"Leroy" <whe### [at] gmailcom> wrote:
> I made a windows program a few years ago call LR_Voice that takes a wave and
> lets you place Phonemes that are saved in a file that POV can read.
> Its at
> http://leroyw.byethost15.com/WinZips/LR_Voice.zip
> Although it was written for lip syncing you could use it to mark locations.
> Have Fun!

Thanks but I'm almost done with that part of the project. The combination of
software that I settled on is working out extremely well for what I need.
IZotope RX 8 supports tabbed documents so I can have the original song open in
one tab and a modified version containing just the drums (made with SpleeterGUI)
open in another tab so I can make quick comparisons when necessary. I can place
a marker at a beat by putting the curser where I want on the waveform and
pressing the "m" key. RX 8 can export the marker times as a tab-delimited text
file that POV-Ray can read after I do about 30 seconds worth of formatting. It
still takes quite a while due to the length of the song and the number beats but
it's going well.

Have a great day and thanks for sharing your idea!

Kind regards,
Dave Blandston

[Leroy] Re: Music Video Project [1814 days 22 hours and 24 minutes ago]

Sat, 17 Apr 2021 16:55:00 GMT

"Dave Blandston" <nomail@nomail> wrote:
> Greetings Friends,
>
> More than ten years ago I made a scene that I didn't think turned out quite
> right so I set it aside until recently. I re-worked some of the textures and
> made some improvements. One of the improvements was to change the flag from a
> flat box with fake shadows to simulate ripples (not very convincing) to a mesh2
> object. Since the mesh2 is easily animatable with a simple sine function that
> led to this animation:
>
> https://www.youtube.com/watch?v=gYJac3vCHu8
>
> The message of the image is anti-war and it's based on the Metallica song
> Disposable Heroes, so I've decided to add the music to the animation and try
> animating the inside (currently green) portion of the Metallica logo. My goal is
> to animate the logo in such a manner that the animation is synchronized with the
> music, similar to the visualizations in Windows Media Player and other music
> players. It will be a big job to do by hand. One thing that would help would be
> a software application that would analyze the music and generate a list of exact
> times when a change occurs in the music and save the list as a text file that
> POV-Ray could read, but creating a program that does that is beyond my ability
> so I will try doing it by hand. There are endless possibilities so this will be
> a fun project! One thing that I have working at this point is using video frames
> as the pigment for one or more letters of the logo at a time, which can be
> combined with procedural textures.
>
> Kind regards,
> Dave Blandston

I made a windows program a few years ago call LR_Voice that takes a wave and
lets you place Phonemes that are saved in a file that POV can read.
Its at
http://leroyw.byethost15.com/WinZips/LR_Voice.zip
Although it was written for lip syncing you could use it to mark locations.
Have Fun!

[Dave Blandston] Re: Music Video Project [1816 days 2 hours and 19 minutes ago]

Fri, 16 Apr 2021 13:00:00 GMT

Interesting update:

Some parts of the song I'm working on are difficult to tell exactly where the
beats are or even how many there are, even with the "spectral view" because
there's so much happening so quickly all at once. As luck would have it, there's
a free program available called "Spleeter" that analyzes songs and splits them
into drums, bass, and vocals. This makes the drum beats MUCH easier to identify
and will save a few hours of tedious work. Here's where Spleeter comes from:
https://makenweb.com/SpleeterGUI

Kind regards,
Dave Blandston

[Dave Blandston] Re: Music Video Project [1817 days and 19 minutes ago]

Thu, 15 Apr 2021 15:00:00 GMT

Subclick <no### [at] spam> wrote:
> In case someone doesn’t know, the /POV-Ray Reference/ has something to
> say about this
> (<http://www.povray.org/documentation/3.7.0/r3_2.html#r3_2_1_2>):
>
> > Unlike some animation packages, the action in POV-Ray animated scenes
> > does not depend upon the integer frame numbers. Rather you should
> > design your scenes based upon the float identifier clock. By default,
> > the clock value is 0.0 for the initial frame and 1.0 for the final
> > frame. All other frames are interpolated between these values. For
> > example if your object is supposed to rotate one full turn over the
> > course of the animation, you could specify rotate 360*clock*y. Then as
> > clock runs from 0.0 to 1.0, the object rotates about the y-axis from 0
> > to 360 degrees.
> >
> > The major advantage of this system is that you can render a 10 frame
> > animation or a 100 frame or 500 frame or 329 frame animation yet you
> > still get one full 360 degree rotation. Test renders of a few frames
> > work exactly like final renders of many frames.
> >
> > In effect you define the motion over a continuous float valued
> > parameter (the clock) and you take discrete samples at some fixed
> > intervals (the frames). If you take a movie or video tape of a real
> > scene it works the same way. An object's actual motion depends only on
> > time. It does not depend on the frame rate of your camera.
>
> [...]
>
> > For new scenes, we recommend you do not change the Initial_Clock or
> > Final_Clock from their default 0.0 to 1.0 values. If you want the
> > clock to vary over a different range than the default 0.0 to 1.0, we
> > recommend you handle this inside your scene file as follows...
> >
> >
> > #declare Start    = 25.0;
> > #declare End      = 75.0;
> > #declare My_Clock = Start+(End-Start)*clock;
> >
> > Then use My_Clock in the scene description. This keeps the critical
> > values 25.0 and 75.0 in your .pov file.

Good point. I got a little carried away with the idea that since the song is a
fixed length and certain key frames have to match certain musical events that a
deviation from the norm might be in order. As the project is progressing though
I see that clock is still the best option. Since the music is time-based,
converting between time and frame numbers just adds another element of
complexity and possibility of error. Also, the worst case scenario of being one
frame off is totally imperceptible. (Especially at 60 FPS!)

On another note, using the spectral view of Izotope RX 8 to locate the beat
marks is working out extremely well. The software allows one to place visual
markers at any point so beats can be marked, which makes it easy to see what's
been done and what's still left. The list of markers can be exported as a text
file (including comments). Editing with the POV-Ray editor into an include file
is trivial, especially with the block selection feature.

Have an awesome day!

Kind regards,
Dave Blandston

[Subclick] Re: Music Video Project [1817 days 4 hours and 30 minutes ago]

Thu, 15 Apr 2021 10:49:06 GMT

"Dave Blandston" <nomail@nomail> writes:

> That's interesting - I had forgotten that
> frame_number even existed because I
> got used to using clock years ago, but I can see
> that frame_number would be more
> appropriate under some circumstances, possibly
> including this one. I did in fact
> have to include some code to convert number of
> frames generated to time elapsed
> so using frame_number would be exact instead of
> within 1 / framerate / 2. The
> beat markers will be in milliseconds which would
> have to be converted to
> frame_numbers though so it's a trade-off either
> way. Thank you for the excellent
> suggestion!

InÂ case someone doesnâ€™t know, the /POV-Ray Reference/ has
something to
say about this
(<http://www.povray.org/documentation/3.7.0/r3_2.html#r3_2_1_2>):

> Unlike some animation packages, the action in POV-Ray animated scenes
> does not depend upon the integer frame numbers. Rather you should
> design your scenes based upon the float identifier clock. By default,
> the clock value is 0.0 for the initial frame and 1.0 for the final
> frame. All other frames are interpolated between these values. For
> example if your object is supposed to rotate one full turn over the
> course of the animation, you could specify rotate 360*clock*y. Then as
> clock runs from 0.0 to 1.0, the object rotates about the y-axis from 0
> to 360 degrees.
>
> The major advantage of this system is that you can render a 10 frame
> animation or a 100 frame or 500 frame or 329 frame animation yet you
> still get one full 360 degree rotation. Test renders of a few frames
> work exactly like final renders of many frames.
>
> In effect you define the motion over a continuous float valued
> parameter (the clock) and you take discrete samples at some fixed
> intervals (the frames). If you take a movie or video tape of a real
> scene it works the same way. An object's actual motion depends only on
> time. It does not depend on the frame rate of your camera.

[...]

> For new scenes, we recommend you do not change the Initial_Clock or
> Final_Clock from their default 0.0 to 1.0 values. If you want the
> clock to vary over a different range than the default 0.0 to 1.0, we
> recommend you handle this inside your scene file as follows...
> 
> 
> #declare Start    = 25.0;
> #declare End      = 75.0;
> #declare My_Clock = Start+(End-Start)*clock;
> 
> Then use My_Clock in the scene description. This keeps the critical
> values 25.0 and 75.0 in your .pov file.

[Kenneth] Re: Weird. [1817 days 21 hours and 44 minutes ago]

Wed, 14 Apr 2021 17:35:00 GMT

Beautiful and well-done! Worth repeat viewings, to see all of the subtle
animated details. I especially like the gently swaying tree and sunflower. Nice
animation timings too, and with 'smooth' camera movements.

A lot of work, no doubt, but it paid off.

[jr] Re: Music Video Project [1818 days 6 hours and 59 minutes ago]

Wed, 14 Apr 2021 08:20:00 GMT

"jr" <cre### [at] gmailcom> wrote:
>
> (I know I _always_ get into .. deep water when I make "forthright" comments,
> nevertheless..)
>
> "Dave Blandston" <nomail@nomail> wrote:
> > "jr" <cre### [at] gmailcom> wrote:
> > > ...
> google 'Hayseed Dixie Enter Sandman' for one I like as well as the original.
> :-)

uh, belay that.  misremembered.  was thinking of Lemmy's version (which is ..
ok) and Hayseed Dixie did an 'Ace of Spades' cover, not Sandman.  hence (?)
mix-up.

regards, jr.

[jr] Re: Music Video Project [1818 days 7 hours and 34 minutes ago]

Wed, 14 Apr 2021 07:45:00 GMT

hi,

(I know I _always_ get into .. deep water when I make "forthright" comments,
nevertheless..)

"Dave Blandston" <nomail@nomail> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > I often find cover versions the equal of, or better than, the originals, eg:
> > <https://www.youtube.com/watch?v=BoZx9TGdWEA>
> >
> >
> > regards, jr.
>
> If you like Metallica remakes then here are two of my favorites, both unique in
> their own way:
> INouvLl1JiQ (Enter Sandman performed by extremely talented youngsters)

but where's the "kick"?  they _could_[*] have been miming to a backing track,
there's so little difference.
[*] but didn't.

google 'Hayseed Dixie Enter Sandman' for one I like as well as the original.
:-)

> odysee.com/@mediabear:5/safetyland:a (Enter Sandman parody)

didn't check this, the url looks like something I'd never click on.  (sorry, old
fool being (somewhat) paranoid)

regards, jr.

[Dave Blandston] Re: Music Video Project [1818 days 16 hours and 44 minutes ago]

Tue, 13 Apr 2021 22:35:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> I often find cover versions the equal of, or better than, the originals, eg:
> <https://www.youtube.com/watch?v=BoZx9TGdWEA>
>
>
> regards, jr.

If you like Metallica remakes then here are two of my favorites, both unique in
their own way:

https://www.youtube.com/watch?v=INouvLl1JiQ (Enter Sandman performed by
extremely talented youngsters)

https://odysee.com/@mediabear:5/safetyland:a (Enter Sandman parody)

Cheers!

[Alain Martel] Re: Weird. [1818 days 21 hours ago]

Tue, 13 Apr 2021 18:18:55 GMT

Le 2021-04-13 Ã  06:44, m@b a Ã©critÂ :
> Check out my animation:
> 
> https://youtu.be/jWXSZitnqeI
> 
Nice and impressive.
Very good work.

[jr] Re: Music Video Project [1819 days and 19 minutes ago]

Tue, 13 Apr 2021 15:00:00 GMT

hi,

"Dave Blandston" <nomail@nomail> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> ...
> 23.116
> 23.242
> 23.393
> 23.549
> 23.675
> 23.829
> 23.961

:-)


> Also this particular song does not have a regular, constant beat - it changes
> continually. It took well over an hour, probably closer to two hours just to get
> to the 44 second mark but it is possible. I wish I could use your script but I
> think it would be impossible to get accurate results, at least for this song.

would need .. nimble fingers.


> If you haven't heard it check it out and you'll see what I mean...
> {...}
> Plus listening to it will make your day better!

it did.  :-)

I often find cover versions the equal of, or better than, the originals, eg:
<https://www.youtube.com/watch?v=BoZx9TGdWEA>


regards, jr.

[Kenneth] Re: Music Video Project [1819 days 1 hour and 34 minutes ago]

Tue, 13 Apr 2021 13:45:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
> > ...but I'm thinking now of extending the length of
> > the entire animation with some new action at the end, maybe by 25%, but
> > without messing up all of the clock-specified events and timings that are
> > already there.
>
> Those ought to stay exactly the same.
> If you're just increasing the number of frames, then everything should
> stay the same as well.
>
> If you are _appending_ more things to the animation, then maybe just declare a
> Clock2 variable that is
> #declare Clock2 = max (1, 2-clock);
> Then when the 0-1 clock "runs out", you get a second 0-1 clock variable
> to use.
> You can also just search-replace all of your "clock" instances with "Clock"
> #declare Clock = min (1, clock);
> so that it stops at 1.
>

Yes, I've used constructs similar to those as well (although the use of min/max
is a new twist that I didn't think of; thanks.)

For me though, it really boils down to 'clarity of code'. In other words, if I
use frame_number to start an event, I'll 'know' immediately what I intended, and
where the event happens in the animation. With something like max(1,2-clock), I
have to actually think about it-- ouch! :-P Especially if I come across this
piece of code years from now, not remembering why I did it this way. Unless I'm
smart and add a nice little comment to *tell* me why, ha.

But there ARE other instances where I'll 'mix and match' clock and frame_number.
Dave B's waving flag is a good example: something like sin(19*pi*clock) is
perfectly fine for such 'continuous' animation, regardless of if I change the
running length of my animation later (where clock would go past 1.0). Using
frame_number there instead would be an unnecessary complication.

[Dave Blandston] Re: Music Video Project [1819 days 2 hours and 24 minutes ago]

Tue, 13 Apr 2021 12:55:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> the presumption was/is that you are comfortable with the idea of "programming"
> since you use (at least) the POV-Ray SDL.  there's nothing special about the
> language, almost any scripting/compiled language will do.  I wrote the code to
> illustrate that you can make a simple tool to take some of the drudge out of the
> job and take (human) fallibility out of the equation, with little effort -- make
> your computer earn its electricity.  (besides, it also delivered a pleasure
> "kick" similar to solving a good crossword. :-))
>
>
> regards, jr.

I have begun the arduous task of logging the beat marks by hand. I ended up
using a program called RX 8 by Izotope to display the "spectral" music view
since it shows a little more clarity than Audacity and it displays the exact
time where the cursor is so it's easy to get the info. In many instances there
are several beats per second, for example:

23.116
23.242
23.393
23.549
23.675
23.829
23.961

Also this particular song does not have a regular, constant beat - it changes
continually. It took well over an hour, probably closer to two hours just to get
to the 44 second mark but it is possible. I wish I could use your script but I
think it would be impossible to get accurate results, at least for this song. If
you haven't heard it check it out and you'll see what I mean...

https://www.youtube.com/watch?v=6rNELTZO0QQ

Plus listening to it will make your day better!

[Dave Blandston] Re: Weird. [1819 days 2 hours and 44 minutes ago]

Tue, 13 Apr 2021 12:35:01 GMT

"m@b" <sai### [at] googlemailcom> wrote:
> Check out my animation:
>
> https://youtu.be/jWXSZitnqeI

Astounding! I hear POV-Ray music videos are all the rage these days.

Have a great day!

-Dave Blandston

[jr] Re: Weird. [1819 days 4 hours and 9 minutes ago]

Tue, 13 Apr 2021 11:10:00 GMT

hi,

"m@b" <sai### [at] googlemailcom> wrote:
> Check out my animation:
> ...

choice track.  "I wear no shoes" :-)  love it.  (the whole thing)


regards, jr.

[m@b] Weird. [1819 days 4 hours and 34 minutes ago]

Tue, 13 Apr 2021 10:44:52 GMT

Check out my animation:

https://youtu.be/jWXSZitnqeI

[jr] Re: Music Video Project [1819 days 4 hours and 39 minutes ago]

Tue, 13 Apr 2021 10:40:00 GMT

hi,

(this has been nagging me since I posted, sorry)

"jr" <cre### [at] gmailcom> wrote:
> "Dave Blandston" <nomail@nomail> wrote:
> > "jr" <cre### [at] gmailcom> wrote:
> > > run it, right-click to start, left-click or 'b' key each beat, then
> > > right-click again to stop; 'q' at any time to abandon.
> >
> > This sounds intriguing - I've never heard of Tcl/Tk so I'm not sure what you
> > mean - should I run this script then play the song and press the "b" key every
> > time I hear a beat, and the script will record the timing of the keypresses?
>
> yes.

the presumption was/is that you are comfortable with the idea of "programming"
since you use (at least) the POV-Ray SDL.  there's nothing special about the
language, almost any scripting/compiled language will do.  I wrote the code to
illustrate that you can make a simple tool to take some of the drudge out of the
job and take (human) fallibility out of the equation, with little effort -- make
your computer earn its electricity.  (besides, it also delivered a pleasure
"kick" similar to solving a good crossword. :-))

regards, jr.

[Dave Blandston] Re: Music Video Project [1819 days 7 hours and 9 minutes ago]

Tue, 13 Apr 2021 08:10:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
> no worries, the "white men can't jump" syndrome.  :-)
>
> <https://www.youtube.com/watch?v=-FvsgGp8rSE>
>
>
> regards, jr.

Yep, that's me!

[jr] Re: Music Video Project [1819 days 7 hours and 49 minutes ago]

Tue, 13 Apr 2021 07:30:00 GMT

hi,

"Dave Blandston" <nomail@nomail> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > hi,
> >
> > run it, right-click to start, left-click or 'b' key each beat, then
> > right-click again to stop; 'q' at any time to abandon.
>
> This sounds intriguing - I've never heard of Tcl/Tk so I'm not sure what you
> mean - should I run this script then play the song and press the "b" key every
> time I hear a beat, and the script will record the timing of the keypresses?

yes.

> If
> so then I must admit that I have no musical talent whatsoever of my own and my
> ability to keep a beat is nearly non-existent. If you saw me TRY to dance you
> would immediately agree that I would fail terribly at this!

no worries, the "white men can't jump" syndrome.  :-)

<https://www.youtube.com/watch?v=-FvsgGp8rSE>


regards, jr.

[Dave Blandston] Re: Music Video Project [1819 days 8 hours and 9 minutes ago]

Tue, 13 Apr 2021 07:10:00 GMT

"m@b" <sai### [at] googlemailcom> wrote:
> Further - frame numbers are better if you are including video frames in
> an animation. Using clock derived functions results in dropped or
> doubled frames from time to time.

Precision errors can be an issue in situations like this and they're more common
than some folks might realize. You would never know the difference if some
object is positioned at 43.9999999 instead of 44 POV units and the difference is
one billionth the width of a pixel and has zero effect on the final image
values, but you will certainly notice if FRAME #43 is displayed instead of FRAME
#44!

#local FrameNumber = int (EventClock * (NumberOfFrames - 1) + .1); //Correct for
precision errors
#local Padding = strlen (str (NumberOfFrames - 1, 0, 0));
#local SourceImageFileName = concat ("VideoFrame_", str (FrameNumber, -Padding,
0), ".png")

Just something to keep in mind...

Kind regards,
Dave Blandston

[m@b] Re: Music Video Project [1819 days 8 hours and 36 minutes ago]

Tue, 13 Apr 2021 06:42:51 GMT

On 13/04/2021 6:32 am, Dave Blandston wrote:
> Here's a short test to show the use of the "spectral" display to locate beat
> times. It appears to be right on. (Note that not all beats are used, but when a
> visual transition does occur it coincides with a beat.) It's great that Audacity
> includes this functionality!
> 
> https://www.youtube.com/watch?v=RifdL-c0QMM
> 
> Kind regards,
> Dave Blandston
> 

Looking good :-)

[m@b] Re: Music Video Project [1819 days 8 hours and 37 minutes ago]

Tue, 13 Apr 2021 06:41:34 GMT

On 13/04/2021 2:38 am, Kenneth wrote:
> "Dave Blandston" <nomail@nomail> wrote:
>>
>> Hey this is super interesting! We are doing some very similar things - I am also
>> using local "Event clocks" that go from 0 to 1 at pre-determined intervals, and
>> look how similar our "smoothing" functions are:
>>
>> #local ClockFactor = (sin (radians (EventClock [I] * 180 - 90)) + 1) / 2; //0 ..
>> 1
>> #local ClockFactor = pow (ClockFactor, 1); //Adjust for a faster or slower start
>>
> 
> Just a suggestion:
> Although clock, clock_delta and Final_Clock are great tools for creating
> animations, and for causing 'events' to happen at certain times, I use
> frame_number (or some fraction thereof) more often now. It's probably a personal
> choice, of course; but frame_number seems more intuitive to me-- and I don't
> have to think in 'clock division' terms for the timing of animation events.
> 
> I'm currently reworking an old and complex animation scene, which has various
> #include files, where I used clock etc. exclusively throughout the scene. It
> worked beautifully at the time-- but I'm thinking now of extending the length of
> the entire animation with some new action at the end, maybe by 25%, but
> without messing up all of the clock-specified events and timings that are
> already there. I *could* simply change Final_clock to be 1.25, but I'm not yet
> sure what that will do to some of the events which actually depend on the
> (previous) clock-end of 1.0.  As a simple example,
> 
> #if(clock <= 0.3) --do this-- #else -- do that-- #end
> 
> .....but now I don't want the #else action to extend past a clock of,say, 1.15. I
> could easily change the #if clause of course, but changing all such constructs
> to use frame_number instead tells me exactly and visually when to expect the
> action, or to easily change it.
> 
> I also like frame-number because, after a test animation, I can immediately see
> where any animation glitches need correcting-- at which frame, in other words,
> without having to make a clock-division computation to figure it out.


Good points.
Further - frame numbers are better if you are including video frames in 
an animation. Using clock derived functions results in dropped or 
doubled frames from time to time.


> 
> However, I haven't yet worked out how to 'start and end events slowly like an
> S-curve' as was mentioned previously, when using frame_number instead of clock.
> I'll have to explore that!
> 

You can't do it with frame numbers directly as each frame has a fixed time.

Presumably you could use the formulas as mentioned above and just 
substitute Frame_A, Frame_B instead if Time_A, Time_B to make a local 
clock? the start and end points would still be tied to frame numbers.


> But your music video project uses a song length that is 'set in stone', so using
> clock is a perfectly natural way to achieve the results.
> 
> ----
> [Btw, I just discovered that the Audacity app can show 'spectral timings' for a
> song too, like the image you posted; I had never used that feature before.
> Thanks for the suggestion!]
> 
> 
>

[Bald Eagle] Re: Music Video Project [1819 days 15 hours and 54 minutes ago]

Mon, 12 Apr 2021 23:25:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:

> I'm currently reworking an old and complex animation scene, which has various
> #include files, where I used clock etc. exclusively throughout the scene. It
> worked beautifully at the time-- but I'm thinking now of extending the length of
> the entire animation with some new action at the end, maybe by 25%, but
> without messing up all of the clock-specified events and timings that are
> already there.

Those ought to stay exactly the same.
If you're just increasing the number of frames, then everything should stay the
same as well.

If you are _appending_ more things to the animation, then maybe just declare a
Clock2 variable that is
#declare Clock2 = max (1, 2-clock);
Then when the 0-1 clock "runs out", you get a second 0-1 clock variable to use.
You can also just search-replace all of your "clock" instances with "Clock"
#declare Clock = min (1, clock);
so that it stops at 1.

> However, I haven't yet worked out how to 'start and end events slowly like an
> S-curve' as was mentioned previously, when using frame_number instead of clock.
> I'll have to explore that!

"Smoothstep" in glsl, shadertoy, etc.
https://en.wikipedia.org/wiki/Smoothstep
https://www.youtube.com/watch?v=60VoL-F-jIQ
https://iquilezles.org/www/articles/ismoothstep/ismoothstep.htm
https://thebookofshaders.com/glossary/?search=smoothstep

[Dave Blandston] Re: Music Video Project [1819 days 16 hours and 44 minutes ago]

Mon, 12 Apr 2021 22:35:00 GMT

Here's a short test to show the use of the "spectral" display to locate beat
times. It appears to be right on. (Note that not all beats are used, but when a
visual transition does occur it coincides with a beat.) It's great that Audacity
includes this functionality!

https://www.youtube.com/watch?v=RifdL-c0QMM

Kind regards,
Dave Blandston

[Dave Blandston] Re: Music Video Project [1819 days 16 hours and 54 minutes ago]

Mon, 12 Apr 2021 22:25:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> Just a suggestion:
> Although clock, clock_delta and Final_Clock are great tools for creating
> animations, and for causing 'events' to happen at certain times, I use
> frame_number (or some fraction thereof) more often now. It's probably a personal
> choice, of course; but frame_number seems more intuitive to me-- and I don't
> have to think in 'clock division' terms for the timing of animation events.

That's interesting - I had forgotten that frame_number even existed because I
got used to using clock years ago, but I can see that frame_number would be more
appropriate under some circumstances, possibly including this one. I did in fact
have to include some code to convert number of frames generated to time elapsed
so using frame_number would be exact instead of within 1 / framerate / 2. The
beat markers will be in milliseconds which would have to be converted to
frame_numbers though so it's a trade-off either way. Thank you for the excellent
suggestion!

Have an awesome day Kenneth!

Kind regards,
Dave Blandston

[Dave Blandston] Re: Music Video Project [1819 days 17 hours and 9 minutes ago]

Mon, 12 Apr 2021 22:10:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> run it, right-click to start, left-click or 'b' key each beat, then
> right-click again to stop; 'q' at any time to abandon.

This sounds intriguing - I've never heard of Tcl/Tk so I'm not sure what you
mean - should I run this script then play the song and press the "b" key every
time I hear a beat, and the script will record the timing of the keypresses? If
so then I must admit that I have no musical talent whatsoever of my own and my
ability to keep a beat is nearly non-existent. If you saw me TRY to dance you
would immediately agree that I would fail terribly at this!

Have a great day!

Kind regards,
Dave Blandston

[Kenneth] Re: Music Video Project [1819 days 20 hours and 39 minutes ago]

Mon, 12 Apr 2021 18:40:00 GMT

"Dave Blandston" <nomail@nomail> wrote:
>
> Hey this is super interesting! We are doing some very similar things - I am also
> using local "Event clocks" that go from 0 to 1 at pre-determined intervals, and
> look how similar our "smoothing" functions are:
>
> #local ClockFactor = (sin (radians (EventClock [I] * 180 - 90)) + 1) / 2; //0 ..
> 1
> #local ClockFactor = pow (ClockFactor, 1); //Adjust for a faster or slower start
>

Just a suggestion:
Although clock, clock_delta and Final_Clock are great tools for creating
animations, and for causing 'events' to happen at certain times, I use
frame_number (or some fraction thereof) more often now. It's probably a personal
choice, of course; but frame_number seems more intuitive to me-- and I don't
have to think in 'clock division' terms for the timing of animation events.

I'm currently reworking an old and complex animation scene, which has various
#include files, where I used clock etc. exclusively throughout the scene. It
worked beautifully at the time-- but I'm thinking now of extending the length of
the entire animation with some new action at the end, maybe by 25%, but
without messing up all of the clock-specified events and timings that are
already there. I *could* simply change Final_clock to be 1.25, but I'm not yet
sure what that will do to some of the events which actually depend on the
(previous) clock-end of 1.0.  As a simple example,

#if(clock <= 0.3) --do this-- #else -- do that-- #end

.....but now I don't want the #else action to extend past a clock of,say, 1.15. I
could easily change the #if clause of course, but changing all such constructs
to use frame_number instead tells me exactly and visually when to expect the
action, or to easily change it.

I also like frame-number because, after a test animation, I can immediately see
where any animation glitches need correcting-- at which frame, in other words,
without having to make a clock-division computation to figure it out.

However, I haven't yet worked out how to 'start and end events slowly like an
S-curve' as was mentioned previously, when using frame_number instead of clock.
I'll have to explore that!

But your music video project uses a song length that is 'set in stone', so using
clock is a perfectly natural way to achieve the results.

----
[Btw, I just discovered that the Audacity app can show 'spectral timings' for a
song too, like the image you posted; I had never used that feature before.
Thanks for the suggestion!]

[jr] Re: Music Video Project [1820 days 2 hours and 29 minutes ago]

Mon, 12 Apr 2021 12:50:00 GMT

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

ouch, complete with bug even.  forgot to use 'rt(begin)' hence subtracting from
wrong value.  </hang-head-in-shame>


regards, jr.

[jr] Re: Music Video Project [1820 days 2 hours and 39 minutes ago]

Mon, 12 Apr 2021 12:40:00 GMT

hi,

"Dave Blandston" <nomail@nomail> wrote:
> ... The time display is in milliseconds
> which is plenty accurate. Unfortunately there are many hundreds of musical
> events that I will have to log by hand.

don't you own a computer?  :-)

anyway, reading this I (may have) got carried away and wrote a few lines of
script[*] over lunch (can't tell what OS you're running from the screenshot,
however, if you haven't Tcl/Tk installed, it is freely available on all
platforms).  run it, right-click to start, left-click or 'b' key each beat, then
right-click again to stop; 'q' at any time to abandon.  the only thing left to
do, as exercise for the interested reader ;-), is subtracting the initial mark
from all subsequent ones, and writing them to file.  hope you'll enjoy it, I
certainly did.

[*] hack. :-)

regards, jr.

# ------------------------------------------------------------------------

#!/usr/bin/env wish

proc doStuff {} {
  global T
    set a [lsort -integer [array names T]]
    set from [lindex $a 0]
    set to [lindex $a end]
    set n [llength $a]
    set s [format {recorded %d beats, total ms: %d} $n [expr {$to - $from}]]
    tk_dialog .dlg foobar $s info 0 ok
  return
}

proc rightClick {} {
  global rt T
  if {!$rt(run)} {
    set rt(run) true
    set rt(begin) [clock milliseconds]
  } \
  else {
    unset rt(run)
    if {![array exists T]} {exit 99}
    doStuff
    destroy .
  }
  return
}

proc leftClick {} {
  global rt T
  if {$rt(run)} {
    set T([clock milliseconds]) {}
  }
  return
}

set rt(run) false

label .lbl -padx 2cm -pady 2cm

pack .lbl

bind . <KeyPress-q>  [list destroy .]
bind . <KeyPress-b> leftClick
bind . <ButtonRelease-1> leftClick
bind . <ButtonRelease-3> rightClick

# ------------------------------------------------------------------------

[Dave Blandston] Re: Music Video Project [1820 days 2 hours and 49 minutes ago]

Mon, 12 Apr 2021 12:30:01 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Silly cro-magnon idea here -
> what about using sheet music and a ruler?

Ha ha I wish!!!

Correction: 6 - 3 - 6 etc. bass notes...

[Bald Eagle] Re: Music Video Project [1820 days 4 hours and 19 minutes ago]

Mon, 12 Apr 2021 11:00:00 GMT

"Dave Blandston" <nomail@nomail> wrote:

> I am in luck regarding my hope of being able to see changes in the music better
> than just looking at the waveform. I got the spectral display up and running and
> it makes it pretty easy to spot acoustic "events." The screen shot of the first
> five seconds of music that I'm using clearly shows six quick bass notes then
> three slower ones then five quick ones etc. The time display is in milliseconds
> which is plenty accurate. Unfortunately there are many hundreds of musical
> events that I will have to log by hand. But the final product should be nearly
> perfect.
>
> Thanks for sharing your technique!

Silly cro-magnon idea here -
what about using sheet music and a ruler?

[Dave Blandston] Re: Music Video Project [1820 days 4 hours and 44 minutes ago]

Mon, 12 Apr 2021 10:35:00 GMT

"m@b" <sai### [at] googlemailcom> wrote:
> I put the scene all in one file, the timings go in another (.inc) file,
> I find it convenient to switch between the two when working.
>
> Here is the layout of the timing file:
>
> SETUP TIMES FROM THE SPREADSHEET
>
> #declare T000 = 0.0000;  // Start
> #declare T001 = 0.0667;  // Weird                   Zoom to 1
> #declare T002 = 0.0833;  // Dum dum                 Rotate Florets
> #declare T003 = 0.1433;  // I'm a little weird      Zoom out 1
> #declare T004 = 0.2083;  // I wear a little beard   To Ladybird
> #declare T005 = 0.2483;  // Durul ural um dum       Ladybird
>
> INITIALISE ELEMENTS THAT WILL BE ACTIVATED/CHANGED DURING RENDER
>
> #declare FlowerHead  = 0;
> #declare Stalk       = 0;
> #declare Grass       = 0;
> #declare GroundPlane = 1;
> #declare Mushroom    = 0;
>
> USE SWITCH TO RENDER SCENE BY SCENE
> See screen shot
>
> This macro sets up some local clocks. Start runs from 1 to 0, End runs
> from 0 to 1, they both start and end slowly like an S-curve, this avoids
> jerky camera movements at each scene change. Bumper runs 0-1-0.
>
> #macro Cosify()
>  #declare Start =  (cos(1*pi*Current_clock)+1)/2;
>  #declare End = (1-(cos(1*pi*Current_clock)+1)/2);
>  #declare Bumper = sin(pi*Current_clock); #end
>
> PRINT OUT SOME STATS SO i CAN FOLLOW HOW THE ANIMATION IS PROGRESSING
>
> #debug concat( Handle_1, "   Clock = ", str(clock,0,3), "
> Current_clock = ", str(Current_clock,0,4), "    Frame = ",
> str(frame_number,0,0),  "\n")
> #debug concat("Look at = ", Vstr(Camera_look_at, 0, 0), "    Camera
> location = ", Vstr(Camera_shift, 0, 0),  "    Zoom = ", str(Zoom,2,2),
> "\n")

Hey this is super interesting! We are doing some very similar things - I am also
using local "Event clocks" that go from 0 to 1 at pre-determined intervals, and
look how similar our "smoothing" functions are:

#local ClockFactor = (sin (radians (EventClock [I] * 180 - 90)) + 1) / 2; //0 ..
1
#local ClockFactor = pow (ClockFactor, 1); //Adjust for a faster or slower start

I am in luck regarding my hope of being able to see changes in the music better
than just looking at the waveform. I got the spectral display up and running and
it makes it pretty easy to spot acoustic "events." The screen shot of the first
five seconds of music that I'm using clearly shows six quick bass notes then
three slower ones then five quick ones etc. The time display is in milliseconds
which is plenty accurate. Unfortunately there are many hundreds of musical
events that I will have to log by hand. But the final product should be nearly
perfect.

Thanks for sharing your technique!

[m@b] Re: Music Video Project [1820 days 6 hours and 32 minutes ago]

Mon, 12 Apr 2021 08:47:15 GMT

On 11/04/2021 9:59 pm, Kenneth wrote:
> "m@b" <sai### [at] googlemailcom> wrote:
> 
>> I use Audacity to find the start time of each phrase in the song, I then
>> put these times in a spreadsheet to get the clock values and frame
>> numbers for POV-Ray .
> 
> I use Audacity too, a great free app. And your spreadsheet for creating
> animation timings is a great idea. If I understand your spreadsheet-use
> correctly, how do you ultimately output the values there into a form that
> POV-ray can #read during its animation render? 

I just copy and paste manually. I am sure it would be possible to output 
the spreadsheet as a CSV file and have POV-Ray read it but I haven't yet.

>> If there is a constant beat throughout the song you can set up a
>> variable direct from clock which can be used to animate all sorts of things.
>>
> 
> The 'constant beat' is sometimes not so constant, ha. Especially during long
> songs. (Unless the beat is generated by a drum machine or click track, for
> example.) 

Good point

[m@b] Re: Music Video Project [1820 days 6 hours and 42 minutes ago]

Mon, 12 Apr 2021 08:36:28 GMT

On 12/04/2021 10:18 am, Dave Blandston wrote:
> "m@b" <sai### [at] googlemailcom> wrote:
>> I don't find it takes too much time, admittedly I chose shorter and much
>>    slower songs than you are planning.
>>
>> If there is a constant beat throughout the song you can set up a
>> variable direct from clock which can be used to animate all sorts of things.
>>
>> See:
>> <https://www.tiktok.com/@matthew.bradwell/video/6944909548163484930>
>> and
>> <https://www.youtube.com/watch?v=djJGXZB6yRE>
>>
>> Best,
>> m@
>>
>> p.s. I just watched the song - there is a lot going on there!
> 
> I'm curious about a couple things, since you have already solved some problems
> that I'm currently working on. Did you create one giant POV-Ray file for the
> entire animation, or did you split it up into multiple files? If you split it
> up, did you need to devise a method of passing information from one file to the
> next? If so I'm very interested to hear the basic details of how you did this,
> especially since you had to plan much farther ahead by positioning the camera
> correctly. I will have to split my project into multiple files for sure and so
> far I've written a macro that automatically keeps track of the current number of
> frames/time elapsed but ideally it would be nice to be able to pass information
> about changing textures as well. I don't think this is possible, but maybe
> there's a way...
> 
> Also my original belief that it would be possible to visually examine the
> waveform with a music editor and identify beats and other musical events has
> turned out to be totally false. Drum beats can be identified easily enough but
> bass notes are not as obvious especially when there is singing and/or other
> guitar stuff going on simultaneously.
> 
> It has been brought to my attention that the mathematical method of detecting
> beats/changes is by the use of Fourier transforms. So my current options are to
> try to locate and adapt some Fourier transform code to POV-Ray SDL and use it to
> generate a list of acoustic event times (probably beyond my ability), or find
> another alternative. One option that I'll explore next is the "spectral" view.
> In the past I used Magix Audio Cleaning Lab to remove tape hiss and unwanted
> sounds from commercial recordings and one of the features was "spectral
> cleaning" which displayed the music in a unique visual manner, which may help.
> Re-installing that program and checking that option out will be my next project.
> 
> I made a five-second test animation by guessing the approximate times of the
> first few bass notes and it's definitely not good enough. I posted it anyway for
> an example of what not to do:
> 
> https://www.youtube.com/watch?v=Rv8kGq9PUkM
> 
> This also includes a test of using video frames in one of the characters of the
> logo. I picked a random five-second segment from a concert video and it didn't
> work out at all, at least not with the big "A." I think that carefully selected
> video segments have potential in the smaller characters though.
> 
> Cheers,
> Dave Blandston
> 

I put the scene all in one file, the timings go in another (.inc) file, 
I find it convenient to switch between the two when working.

Here is the layout of the timing file:

SETUP TIMES FROM THE SPREADSHEET

#declare T000 = 0.0000;  // Start
#declare T001 = 0.0667;  // Weird                   Zoom to 1
#declare T002 = 0.0833;  // Dum dum                 Rotate Florets
#declare T003 = 0.1433;  // I'm a little weird      Zoom out 1
#declare T004 = 0.2083;  // I wear a little beard   To Ladybird
#declare T005 = 0.2483;  // Durul ural um dum       Ladybird

INITIALISE ELEMENTS THAT WILL BE ACTIVATED/CHANGED DURING RENDER

#declare FlowerHead  = 0;
#declare Stalk       = 0;
#declare Grass       = 0;
#declare GroundPlane = 1;
#declare Mushroom    = 0;

USE SWITCH TO RENDER SCENE BY SCENE
See screen shot

This macro sets up some local clocks. Start runs from 1 to 0, End runs 
from 0 to 1, they both start and end slowly like an S-curve, this avoids 
jerky camera movements at each scene change. Bumper runs 0-1-0.

#macro Cosify()
	#declare Start =  (cos(1*pi*Current_clock)+1)/2;
	#declare End = (1-(cos(1*pi*Current_clock)+1)/2);
	#declare Bumper = sin(pi*Current_clock); #end

PRINT OUT SOME STATS SO i CAN FOLLOW HOW THE ANIMATION IS PROGRESSING

#debug concat( Handle_1, "   Clock = ", str(clock,0,3), " 
Current_clock = ", str(Current_clock,0,4), "    Frame = ", 
str(frame_number,0,0),  "\n")
#debug concat("Look at = ", Vstr(Camera_look_at, 0, 0), "    Camera 
location = ", Vstr(Camera_shift, 0, 0),  "    Zoom = ", str(Zoom,2,2), 
"\n")

[Dave Blandston] Re: Music Video Project [1820 days 12 hours and 59 minutes ago]

Mon, 12 Apr 2021 02:20:00 GMT

"m@b" <sai### [at] googlemailcom> wrote:
> I don't find it takes too much time, admittedly I chose shorter and much
>   slower songs than you are planning.
>
> If there is a constant beat throughout the song you can set up a
> variable direct from clock which can be used to animate all sorts of things.
>
> See:
> <https://www.tiktok.com/@matthew.bradwell/video/6944909548163484930>
> and
> <https://www.youtube.com/watch?v=djJGXZB6yRE>
>
> Best,
> m@
>
> p.s. I just watched the song - there is a lot going on there!

I'm curious about a couple things, since you have already solved some problems
that I'm currently working on. Did you create one giant POV-Ray file for the
entire animation, or did you split it up into multiple files? If you split it
up, did you need to devise a method of passing information from one file to the
next? If so I'm very interested to hear the basic details of how you did this,
especially since you had to plan much farther ahead by positioning the camera
correctly. I will have to split my project into multiple files for sure and so
far I've written a macro that automatically keeps track of the current number of
frames/time elapsed but ideally it would be nice to be able to pass information
about changing textures as well. I don't think this is possible, but maybe
there's a way...

Also my original belief that it would be possible to visually examine the
waveform with a music editor and identify beats and other musical events has
turned out to be totally false. Drum beats can be identified easily enough but
bass notes are not as obvious especially when there is singing and/or other
guitar stuff going on simultaneously.

It has been brought to my attention that the mathematical method of detecting
beats/changes is by the use of Fourier transforms. So my current options are to
try to locate and adapt some Fourier transform code to POV-Ray SDL and use it to
generate a list of acoustic event times (probably beyond my ability), or find
another alternative. One option that I'll explore next is the "spectral" view.
In the past I used Magix Audio Cleaning Lab to remove tape hiss and unwanted
sounds from commercial recordings and one of the features was "spectral
cleaning" which displayed the music in a unique visual manner, which may help.
Re-installing that program and checking that option out will be my next project.

I made a five-second test animation by guessing the approximate times of the
first few bass notes and it's definitely not good enough. I posted it anyway for
an example of what not to do:

https://www.youtube.com/watch?v=Rv8kGq9PUkM

This also includes a test of using video frames in one of the characters of the
logo. I picked a random five-second segment from a concert video and it didn't
work out at all, at least not with the big "A." I think that carefully selected
video segments have potential in the smaller characters though.

Cheers,
Dave Blandston

[Kenneth] Re: Music Video Project [1821 days 1 hour and 19 minutes ago]

Sun, 11 Apr 2021 14:00:00 GMT

"m@b" <sai### [at] googlemailcom> wrote:

> I use Audacity to find the start time of each phrase in the song, I then
> put these times in a spreadsheet to get the clock values and frame
> numbers for POV-Ray .

I use Audacity too, a great free app. And your spreadsheet for creating
animation timings is a great idea. If I understand your spreadsheet-use
correctly, how do you ultimately output the values there into a form that
POV-ray can #read during its animation render? I assume that it would be a
simple text file-- but does the spreadsheet app automatically format its
frame-number data in the proper POV-ray-required format?

(Obviously, I'm not very familiar with spreadsheet use.)
>
> If there is a constant beat throughout the song you can set up a
> variable direct from clock which can be used to animate all sorts of things.
>

The 'constant beat' is sometimes not so constant, ha. Especially during long
songs. (Unless the beat is generated by a drum machine or click track, for
example.) Human drummers sometimes have a tendency to ever-so-slightly slow down
or speed up-- which is probably not noticed by most listeners, but might create
minor glitches when compared to computer timings.

[Dave Blandston] Re: Music Video Project [1821 days 6 hours and 19 minutes ago]

Sun, 11 Apr 2021 09:00:00 GMT

"m@b" <sai### [at] googlemailcom> wrote:
> I don't find it takes too much time, admittedly I chose shorter and much
>   slower songs than you are planning.
>
> If there is a constant beat throughout the song you can set up a
> variable direct from clock which can be used to animate all sorts of things.
>
> See:
> <https://www.tiktok.com/@matthew.bradwell/video/6944909548163484930>
> and
> <https://www.youtube.com/watch?v=djJGXZB6yRE>
>
> Best,
> m@
>
> p.s. I just watched the song - there is a lot going on there!

I enjoyed your video very much, especially the leaning tree and the big
geographical surprise at the end! The story is very entertaining as well -
that's a great accomplishment!

[m@b] Re: Music Video Project [1821 days 8 hours and 24 minutes ago]

Sun, 11 Apr 2021 06:54:21 GMT

On 11/04/2021 10:22 am, Dave Blandston wrote:
> "m@b" <sai### [at] googlemailcom> wrote:
>> I use Audacity to find the start time of each phrase in the song, I then
>> put these times in a spreadsheet to get the clock values and frame
>> numbers for POV-Ray .
>> See screen shots.
>>
>> Best wishes,
>> m@
> 
> That's almost exactly what I'm planning to do (minus the spreadsheet) but I
> think it will be painstaking. How has this method worked out for you? I have
> written a POV-Ray macro that will keep track of the number of frames and elapsed
> time so that will help a little. Choosing a song that's over eight minutes long
> might not have been the best idea for me...
> 
> Have a great day!
> 

I don't find it takes too much time, admittedly I chose shorter and much 
  slower songs than you are planning.

If there is a constant beat throughout the song you can set up a 
variable direct from clock which can be used to animate all sorts of things.

See:
<https://www.tiktok.com/@matthew.bradwell/video/6944909548163484930>
and
<https://www.youtube.com/watch?v=djJGXZB6yRE>

Best,
m@

p.s. I just watched the song - there is a lot going on there!

[Dave Blandston] Re: Music Video Project [1821 days 12 hours and 54 minutes ago]

Sun, 11 Apr 2021 02:25:00 GMT

"m@b" <sai### [at] googlemailcom> wrote:
> I use Audacity to find the start time of each phrase in the song, I then
> put these times in a spreadsheet to get the clock values and frame
> numbers for POV-Ray .
> See screen shots.
>
> Best wishes,
> m@

That's almost exactly what I'm planning to do (minus the spreadsheet) but I
think it will be painstaking. How has this method worked out for you? I have
written a POV-Ray macro that will keep track of the number of frames and elapsed
time so that will help a little. Choosing a song that's over eight minutes long
might not have been the best idea for me...

Have a great day!

[m@b] Re: Music Video Project [1821 days 13 hours and 49 minutes ago]

Sun, 11 Apr 2021 01:30:14 GMT

On 11/04/2021 8:20 am, Dave Blandston wrote:
> Greetings Friends,
> 
> More than ten years ago I made a scene that I didn't think turned out quite
> right so I set it aside until recently. I re-worked some of the textures and
> made some improvements. One of the improvements was to change the flag from a
> flat box with fake shadows to simulate ripples (not very convincing) to a mesh2
> object. Since the mesh2 is easily animatable with a simple sine function that
> led to this animation:
> 
> https://www.youtube.com/watch?v=gYJac3vCHu8
> 
> The message of the image is anti-war and it's based on the Metallica song
> Disposable Heroes, so I've decided to add the music to the animation and try
> animating the inside (currently green) portion of the Metallica logo. My goal is
> to animate the logo in such a manner that the animation is synchronized with the
> music, similar to the visualizations in Windows Media Player and other music
> players. It will be a big job to do by hand. One thing that would help would be
> a software application that would analyze the music and generate a list of exact
> times when a change occurs in the music and save the list as a text file that
> POV-Ray could read, but creating a program that does that is beyond my ability
> so I will try doing it by hand. There are endless possibilities so this will be
> a fun project! One thing that I have working at this point is using video frames
> as the pigment for one or more letters of the logo at a time, which can be
> combined with procedural textures.
> 
> Kind regards,
> Dave Blandston
> 

I use Audacity to find the start time of each phrase in the song, I then 
put these times in a spreadsheet to get the clock values and frame 
numbers for POV-Ray .
See screen shots.

Best wishes,
m@

[Dave Blandston] Music Video Project [1821 days 14 hours and 54 minutes ago]

Sun, 11 Apr 2021 00:25:00 GMT

Greetings Friends,

More than ten years ago I made a scene that I didn't think turned out quite
right so I set it aside until recently. I re-worked some of the textures and
made some improvements. One of the improvements was to change the flag from a
flat box with fake shadows to simulate ripples (not very convincing) to a mesh2
object. Since the mesh2 is easily animatable with a simple sine function that
led to this animation:

https://www.youtube.com/watch?v=gYJac3vCHu8

The message of the image is anti-war and it's based on the Metallica song
Disposable Heroes, so I've decided to add the music to the animation and try
animating the inside (currently green) portion of the Metallica logo. My goal is
to animate the logo in such a manner that the animation is synchronized with the
music, similar to the visualizations in Windows Media Player and other music
players. It will be a big job to do by hand. One thing that would help would be
a software application that would analyze the music and generate a list of exact
times when a change occurs in the music and save the list as a text file that
POV-Ray could read, but creating a program that does that is beyond my ability
so I will try doing it by hand. There are endless possibilities so this will be
a fun project! One thing that I have working at this point is using video frames
as the pigment for one or more letters of the logo at a time, which can be
combined with procedural textures.

Kind regards,
Dave Blandston

[Kenneth] Re: Colony Ship Cylindrical City [1825 days 1 hour and 14 minutes ago]

Wed, 7 Apr 2021 14:05:00 GMT

An unfolding city! Wow, I can understand Chris Colefax's citigen macro being
used for creating a 'flat' city-- but your cylindrical unfolding is really
amazing to see. Nice!

I downloaded that macro long ago, but still haven't gotten around to using or
experimenting with it, to see how it procedurally generates its elements...
thinking about how it might help my own 'city generator' scene-- which I still
haven't finished
:-(

[Mike Horvath] Colony Ship Cylindrical City [1832 days 9 hours and 33 minutes ago]

Wed, 31 Mar 2021 05:46:14 GMT

https://youtu.be/Y_qlK-4aC4o

[Le Forgeron] Re: Spiral Warp [1869 days 22 hours and 12 minutes ago]

Sun, 21 Feb 2021 17:07:02 GMT

Le 21/02/2021 Ã  15:10, William F Pokorny a Ã©critÂ :
> On 2/21/21 6:03 AM, Le_Forgeron wrote:
>> Le 19/02/2021 Ã  00:32, Bald Eagle a Ã©critÂ :
>>>>
>>>> Do you have some commercials for povr ?
>>>>
>>>> I mean some catalog of all the features that povr has ?
>>>
>>> I think that may mean "You should consider doing an hgpovray38 version."
>>> Which, I think, is an excellent idea.Â  :D
>>>
>>
>> The catalog for hgpovray38 is in the wiki.
>> (as well as illustrated in the distribution, but that's only after
>> download, so not a real advertisement)
>>
>> http://wiki.povray.org/content/User:Le_Forgeron/HgPovray38
>>
>> I'm lacking such information about povr.
>>
> 
> As am I currently for any concise form for the whole.
> 
> ---
> 
> I'm struggling with how to document. I have no plans to continue to use
> the wiki though a chunk of my early documentation is there, if you look.
> The wiki method is too slow to use and not under code control.
> [SNIP]
I tried to use the github wiki (separate repository, tied to the
project), but it was painful (especially with dual repository in github
& bitbucket). So I returned to povray.wiki.

If you like documentation in code control, there is the md files which
could be used (but focus on supported features by github, forget fancy
options). Everything starts at README.md,

> The povr branch is based off of v3.8, but it's absolutely a break from
> strong backward compatibility. Mostly, this is because it's all I can
> manage - but I also think it's necessary to fix many of the long
> standing issues! There are hundreds of fixes little and large in povr. I
> think too often today's documented features are not really working as
> they should! Is adding many new features on such a base the best
> immediate path forward?
> 

Stalled fixing, or adding needed stuff, large dilemma.
I answered for myself when CLipka starts rewriting a lot of the code and
moved files. One cook in the kitchen is enough.

> Aside: I'm only four years getting into c++ when it takes 10 to be
> really good at anything. I'd probably be much further along if I'd long
> been a c++ programmer. As a language c++ is nothing if not a huge
> mountain to climb all by itself... :-( Let alone all our own classes and
> template classes.)
> 

Beware, CLipka (I believe) was applying Misra/Autosar C++ coding rules,
a fully painful set of constraints, on the rewrite of the old C object
oriented code (from the very old code in 3.1). It is more than just C++.

> Anyway. Me rambling. The povr branch is my strong push toward what I
> think 'POV-Ray' should be in the future, but there is no doubt, it's
> more than I can handle in any short term time frame.
> 
> FYI. I'm away from my computer for the next few days.
> 
> Bill P.
>

[William F Pokorny] Re: Spiral Warp [1870 days 1 hour and 9 minutes ago]

Sun, 21 Feb 2021 14:10:05 GMT

On 2/21/21 6:03 AM, Le_Forgeron wrote:
> Le 19/02/2021 Ã  00:32, Bald Eagle a Ã©critÂ :
>>>
>>> Do you have some commercials for povr ?
>>>
>>> I mean some catalog of all the features that povr has ?
>>
>> I think that may mean "You should consider doing an hgpovray38 version."
>> Which, I think, is an excellent idea.  :D
>>
> 
> The catalog for hgpovray38 is in the wiki.
> (as well as illustrated in the distribution, but that's only after
> download, so not a real advertisement)
> 
> http://wiki.povray.org/content/User:Le_Forgeron/HgPovray38
> 
> I'm lacking such information about povr.
> 

As am I currently for any concise form for the whole.

---

I'm struggling with how to document. I have no plans to continue to use 
the wiki though a chunk of my early documentation is there, if you look. 
The wiki method is too slow to use and not under code control.

I believe it essential to any vibrant future for includes, scene files 
and documentation to each have their own code control repositories and 
multiple gate keepers. Further we should have additional repositories 
such as 'tools' an 'tutorials'. I don't want to put stuff on the wiki I 
don't believe should, in the end, be on a wiki.

I'm struggling with when to 'really' document as some areas of code are 
still churning. I've posted on line in detail about many of the changes 
and new features. I hope to use a lot of those images and that text in 
any final documentation.

The final form of the inbuilt functions - where I have replaced nearly 
everything there previously - is finally settling, but it's not quite 
there. For that I can attach my current functions.inc to this - the base 
intended documentation is in there in text. Some of the new inbuilt 
functions folks could just borrow and use, but some require fixes and 
enhancements in the pattern/function bridge to work properly.

I have too my commit log off v3.8, but it's, of course, not the best 
documentation.

About half of what I've been doing is fixing issues. So, for example, I 
still have fog, but it isn't POV-Ray's fog. I have isosurfaces but 
without the broken evaluate and with a new report on/off.

I went with 'report' as the keyword because I am thinking of extending 
it to more that max gradient warnings and all shapes and surfaces. I 
find the current reporting not all that useful and it isn't free, but 
neither will 'report' control be - I've not done enough testing to trust 
a general report yes/no the way to go. Being able to turn on reporting 
for just one or some of a set of shapes in a scene would be useful.

The povr branch is based off of v3.8, but it's absolutely a break from 
strong backward compatibility. Mostly, this is because it's all I can 
manage - but I also think it's necessary to fix many of the long 
standing issues! There are hundreds of fixes little and large in povr. I 
think too often today's documented features are not really working as 
they should! Is adding many new features on such a base the best 
immediate path forward?

Aside: I'm only four years getting into c++ when it takes 10 to be 
really good at anything. I'd probably be much further along if I'd long 
been a c++ programmer. As a language c++ is nothing if not a huge 
mountain to climb all by itself... :-( Let alone all our own classes and 
template classes.)

Anyway. Me rambling. The povr branch is my strong push toward what I 
think 'POV-Ray' should be in the future, but there is no doubt, it's 
more than I can handle in any short term time frame.

FYI. I'm away from my computer for the next few days.

Bill P.

[Le Forgeron] Re: Spiral Warp [1870 days 4 hours and 15 minutes ago]

Sun, 21 Feb 2021 11:03:23 GMT

Le 19/02/2021 Ã  00:32, Bald Eagle a Ã©critÂ :
> Le_Forgeron <jgr### [at] freefr> wrote:
>> Le 14/02/2021 ÃƒÂ  06:46, Dick Balaska a
ÃƒÂ©critÃ‚Â :
> 
>> *sliding surreptitiously on our back*
>>
>> Do you have some commercials for povr ?
>>
>> I mean some catalog of all the features that povr has ?
> 
> I think that may mean "You should consider doing an hgpovray38 version."
> Which, I think, is an excellent idea.  :D
> 

The catalog for hgpovray38 is in the wiki.
(as well as illustrated in the distribution, but that's only after
download, so not a real advertisement)

http://wiki.povray.org/content/User:Le_Forgeron/HgPovray38


I'm lacking such information about povr.

[Bald Eagle] Re: Spiral Warp [1872 days 15 hours and 44 minutes ago]

Thu, 18 Feb 2021 23:35:01 GMT

Le_Forgeron <jgr### [at] freefr> wrote:
> Le 14/02/2021 Ã  06:46, Dick Balaska a Ã©critÂ :

> *sliding surreptitiously on our back*
>
> Do you have some commercials for povr ?
>
> I mean some catalog of all the features that povr has ?

I think that may mean "You should consider doing an hgpovray38 version."
Which, I think, is an excellent idea.  :D

[Le Forgeron] Re: Spiral Warp [1877 days 4 hours and 12 minutes ago]

Sun, 14 Feb 2021 11:06:49 GMT

Le 14/02/2021 Ã  06:46, Dick Balaska a Ã©critÂ :
> On 2/13/2021 7:17 PM, Bald Eagle wrote:
>> Cousin Ricky <ric### [at] yahoocom> wrote:
>>
>>> qtpovray *is* an unofficial patch.Â  Do you mean that you used only
>>> standard POV-Ray 3.8 features?
>>
>> I think of a "patch" as a slightly modified version that includes
>> things not
>> available in the standard version.
>>
>> AFAIK, qtpovray is just an interface for 3.8 - which is as official as
>> it's
>> likely to get for a while.
> 
> One thing I've been pondering lately is that official is stuck/dead. My
> plan is to not deviate from that.
> OTOH, povr has some interesting features that would be nice to slurp.
> And there is the .grey bug that has an easy fix that I really want to
> incorporate. What to do?
> 

*sliding surreptitiously on our back*

Do you have some commercials for povr ?

I mean some catalog of all the features that povr has ?

[Dick Balaska] Re: Spiral Warp [1877 days 9 hours and 32 minutes ago]

Sun, 14 Feb 2021 05:46:52 GMT

On 2/13/2021 7:17 PM, Bald Eagle wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
> 
>> qtpovray *is* an unofficial patch.  Do you mean that you used only
>> standard POV-Ray 3.8 features?
> 
> I think of a "patch" as a slightly modified version that includes things not
> available in the standard version.
> 
> AFAIK, qtpovray is just an interface for 3.8 - which is as official as it's
> likely to get for a while.

One thing I've been pondering lately is that official is stuck/dead. My 
plan is to not deviate from that.
OTOH, povr has some interesting features that would be nice to slurp.
And there is the .grey bug that has an easy fix that I really want to 
incorporate. What to do?

-- 
dik
Rendered 50,081,587,200 of 50,081,587,200 pixels (100%)

[Bald Eagle] Re: Spiral Warp [1877 days 14 hours and 59 minutes ago]

Sun, 14 Feb 2021 00:20:01 GMT

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

> qtpovray *is* an unofficial patch.  Do you mean that you used only
> standard POV-Ray 3.8 features?

I think of a "patch" as a slightly modified version that includes things not
available in the standard version.

AFAIK, qtpovray is just an interface for 3.8 - which is as official as it's
likely to get for a while.

But yes, it's all just standard functions and pigments.

[Cousin Ricky] Re: Spiral Warp [1877 days 17 hours and 19 minutes ago]

Sat, 13 Feb 2021 22:00:13 GMT

On 2021-02-12 8:20 PM (-4), Bald Eagle wrote:
> =?UTF-8?Q?J=c3=b6rg_=22Yadgar=22_Bleimann?= <yaz### [at] gmxde> wrote:
>>
>> Which unofficial patch did you use?
> 
> No unofficial patch - it was all done in standard POV-Ray 3.8 (qtpovray)

qtpovray *is* an unofficial patch.  Do you mean that you used only 
standard POV-Ray 3.8 features?

[Bald Eagle] Re: Spiral Warp [1878 days 14 hours and 54 minutes ago]

Sat, 13 Feb 2021 00:25:00 GMT

=?UTF-8?Q?J=c3=b6rg_=22Yadgar=22_Bleimann?= <yaz### [at] gmxde> wrote:
> Hi(gh)!

> Wow! That would be perfect for my gas giants, such as Sagan/Whatmough or
> Qais/Ghurghusht!
>
> Which unofficial patch did you use?

When I get some rest and have some more energy and focus, I'm going to try to
make sure it's fully applicable for use with 3D pigment patterns and media.

I figured out how to implement a placement / repetition warp in SDL, and so once
it's all worked out, you should be able to plop multiple spiral warps into a
single pigment pattern definition, and have them all work.

It's gonna be a little complicated, so it may take some time, but the important
parts are figured out - so now it's just making a scene incorporating all of the
pieces, seeing what's broken or missing, and iteratively tweaking it...

No unofficial patch - it was all done in standard POV-Ray 3.8 (qtpovray)

[Jörg "Yadgar" Bleimann] Re: Spiral Warp [1878 days 15 hours and 31 minutes ago]

Fri, 12 Feb 2021 23:48:15 GMT

Hi(gh)!

On 07.02.21 03:02, Bald Eagle wrote:

> I worked it all out to my satisfaction at the time:
> 
>
http://news.povray.org/povray.binaries.images/thread/%3Cweb.5d3c5fe27be432e04eec112d0%40news.povray.org%3E/?ttop=429839
> &toff=50
> 
> It hasn't been implemented anywhere else AFAIK.

Wow! That would be perfect for my gas giants, such as Sagan/Whatmough or 
Qais/Ghurghusht!

Which unofficial patch did you use?

See you in Khyberspace!

Yadgar

Now playing: Polonaise (Jon and Vangelis)

[Mike Horvath] Re: Spiral Warp [1883 days 16 hours and 44 minutes ago]

Sun, 7 Feb 2021 22:34:32 GMT

On 2/7/2021 10:04 AM, Bald Eagle wrote:
> The basic code to add a localized vortex to a pigment pattern is here:
> 
>
http://news.povray.org/povray.binaries.images/message/%3Cweb.5d2a0c323717ac604eec112d0%40news.povray.org%3E/#%3Cweb.5d2
> a0c323717ac604eec112d0%40news.povray.org%3E
> 
> Try that in a simple test scene and see if that works.
> 
> 


Okay thanks!


Mike

[Bald Eagle] Re: Spiral Warp [1884 days and 14 minutes ago]

Sun, 7 Feb 2021 15:05:10 GMT

Mike Horvath <mik### [at] gmailcom> wrote:
> Can you link to the code itself? Have you written a tutorial? Thanks.
> Mike

I mean there's what I posted, which includes the fundamental functions to
perturb a pigment pattern.

I haven't posted the source for the twisted spheres image - since that was long,
involved, and a skull-cracker.

I juggled a lot of big projects in a explosion of sustained activity, and then
with all that's been happening IRL, I just hit burnout, and needed to focus on
local things here for a while - so no tutorial.

I'm assuming you want to use it to make storms in your media?

The basic code to add a localized vortex to a pigment pattern is here:

http://news.povray.org/povray.binaries.images/message/%3Cweb.5d2a0c323717ac604eec112d0%40news.povray.org%3E/#%3Cweb.5d2
a0c323717ac604eec112d0%40news.povray.org%3E

Try that in a simple test scene and see if that works.

[Mike Horvath] Re: Spiral Warp [1884 days 8 hours and 29 minutes ago]

Sun, 7 Feb 2021 06:50:07 GMT

Can you link to the code itself? Have you written a tutorial? Thanks.


Mike

[Bald Eagle] Re: Spiral Warp [1884 days 13 hours and 14 minutes ago]

Sun, 7 Feb 2021 02:05:00 GMT

Mike Horvath <mik### [at] gmailcom> wrote:

> Was the work on spiral warp ever completed? Is it implemented in POV 3.8?


http://news.povray.org/povray.binaries.images/thread/%3Cweb.5d2919d8729ff1951b6c6b3a0%40news.povray.org%3E/?ttop=432701
&toff=200

http://news.povray.org/povray.binaries.images/thread/%3Cweb.5d2a00d41a6827c24eec112d0%40news.povray.org%3E/?ttop=430026
&toff=50


I worked it all out to my satisfaction at the time:

http://news.povray.org/povray.binaries.images/thread/%3Cweb.5d3c5fe27be432e04eec112d0%40news.povray.org%3E/?ttop=429839
&toff=50

It hasn't been implemented anywhere else AFAIK.

[Mike Horvath] Re: Spiral Warp [1884 days 14 hours and 31 minutes ago]

Sun, 7 Feb 2021 00:47:35 GMT

On 7/22/2018 10:43 PM, Bald Eagle wrote:
> A storm is approaching.
> 
> Still working this out, but the key concepts are in place.
> I could probably use a helpful quick-start pointer or two in using ffmpeg.
> (but DAMN it is FAST! :O )
> 
> 60 frames at 15 fps rendered in qtpov on Linux Mint 18.3
> 
> ffmpeg -y -r 15 -i SpiralWarp%02d.png -crf 15 -c:v libx264 -pix_fmt yuv420p
> -metadata title="Prototype Spiral Warp - Bald Eagle 2018-07-22" Warp.mp4
> 
> looked good in konqeror
> 


Was the work on spiral warp ever completed? Is it implemented in POV 3.8?


Mike

[Hj Malthaner] Re: The insane project - Universe class carrier ... [1895 days 14 hours and 23 minutes ago]

Wed, 27 Jan 2021 00:55:50 GMT

On 1/23/21 10:18 AM, Dick Balaska wrote:
> On 1/14/2021 11:43 PM, Hj. Malthaner wrote:
> 
>>
>>
https://lh3.googleusercontent.com/proxy/fJkTS5jjpkJYfpPx5780IthviNf2t29gEN9BRvwMYJN7Q9XrDRnOFZcKtd6PtbzzbisZf6mrrcVOA8QrVGDf1dnb7mFzVIv5oxevwh4nDR5TdcidHA

>
> Forbidden Thatâ€™s all we know.

I'm sorry. Hope this works better.
http://www.modellversium.de/kit/bilder/3/4/1/11341-deckel.jpg

-- 
Some of my PovRay works:
https://www.deviantart.com/antarasol/gallery/42758766/3D

[Dick Balaska] Re: The insane project - Universe class carrier ... [1899 days 6 hours ago]

Sat, 23 Jan 2021 09:18:51 GMT

On 1/14/2021 11:43 PM, Hj. Malthaner wrote:

> 
>
https://lh3.googleusercontent.com/proxy/fJkTS5jjpkJYfpPx5780IthviNf2t29gEN9BRvwMYJN7Q9XrDRnOFZcKtd6PtbzzbisZf6mrrcVOA8QrVGDf1dnb7mFzVIv5oxevwh4nDR5TdcidHA

> 

403. Thatâ€™s an error.

Your client does not have permission to get URL 
/proxy/fJkTS5jjpkJYfpPx5780IthviNf2t29gEN9BRvwMYJN7Q9XrDRnOFZcKtd6PtbzzbisZf6mrrcVOA8QrVGDf1dnb7mFzVIv5oxevwh4nDR5TdcidHA

from this server. (Client IP address: 73.227.216.78)

Forbidden Thatâ€™s all we know.

[Hj Malthaner] Re: The insane project - Universe class carrier ... [1901 days 13 hours and 26 minutes ago]

Thu, 21 Jan 2021 01:52:16 GMT

On 1/19/21 8:38 AM, Thomas de Groot wrote:
> Op 19/01/2021 om 05:14 schreef Hj. Malthaner:
>> On 1/15/21 3:47 PM, Mr wrote:
>>> "Hj. Malthaner" <han### [at] nospamgmxde> wrote:

>>>> I want to picture this as an animation. The SOL was a carrier ship made
>>>> of three components. I want to show the ship arriving, and then
>>>> splitting into its three parts. The command and control unit moving to
>>>> the back of the scene, while the two ultra battleship lookalike
>>>> components move forward.
>>>>
>>>> All three components then launch the smaller ships. Cruisers, corvettes
>>>> and fighters. Cruisers themselves carrying fighters again and also
>>>> launch them.

[snip]

> I would suggest to drop /all/ the story from your mind and let the 
> engineer take over. Just decide which SOL you want to model in the first 
> place: The early one or the latter one.

The first one, for me being a teenager the time when the story was hot 
and it's been the epic ship for me.

> Then, while the hardware takes 
> shape, pieces of the history will come back and fall into place (or not) 
> to be incorporated. Just not to be overwhelmed by (needless) details.

I think I'll start with very simple shapes. The tricky points here are 
the camera changes and moving all the elements. If I can't get that 
right, detailed models won't help.

I think I'll start with a test, how to open a hangar bay door and start 
the ship, move it along a spline to the destination position. That will 
be something that I need all over.

> A challenge indeed!

Yes. Thanks for the response!

-- 
Hajo

[Thomas de Groot] Re: The insane project - Universe class carrier ... [1903 days 7 hours and 40 minutes ago]

Tue, 19 Jan 2021 07:38:37 GMT

Op 19/01/2021 om 05:14 schreef Hj. Malthaner:
> On 1/15/21 3:47 PM, Mr wrote:
>> "Hj. Malthaner" <han### [at] nospamgmxde> wrote:
>>> Feel free to place bets. In my favorite sci-fi series there was a ship
>>> called "SOL" for the name of our sun and it's sole purpose to return to
>>> our galaxy.
>>>
>>> It's been labeled a "Universe class battle carrier", cause "Ultra
>>> Battleship" had been already been taken by the former flagship units.
>>>
>>> I want to picture this as an animation. The SOL was a carrier ship made
>>> of three components. I want to show the ship arriving, and then
>>> splitting into its three parts. The command and control unit moving to
>>> the back of the scene, while the two ultra battleship lookalike
>>> components move forward.
>>>
>>> All three components then launch the smaller ships. Cruisers, corvettes
>>> and fighters. Cruisers themselves carrying fighters again and also
>>> launch them.
>>>
>>> Cuts, camera focusing on the split of the combined ship, the initial
>>> launch of cruisers and fighters, the forward move of the two ultra
>>> battle ship parts, then the secondary launch of fighters from the 
>>> cruisers.
>>>
>>> And finally a sweeping look over the combined fleet, the command and
>>> control module in the back, the two ultra battleships a bit a head and a
>>> total of 6000 cruisers and fighters lined up ahead of them.
>>>
>>> Yes the source was generous with the numbers (google SOL and Perry
>>> Rhodan for details, little results in English though).
>>>
>>>
https://lh3.googleusercontent.com/proxy/fJkTS5jjpkJYfpPx5780IthviNf2t29gEN9BRvwMYJN7Q9XrDRnOFZcKtd6PtbzzbisZf6mrrcVOA

>>>
>> 8QrVGDf1dnb7mFzVIv5oxevwh4nDR5TdcidHA
>>>
>>> A dream right now. A dream since years. I post this to have something
>>> out there as psychological crutch to actually try and start this
>>> project. The SOL was the Terran ship that traveled farther than any
>>> other, a ship that saw places and spaces like no other. Inside the
>>> fandom it's the epic ship even that there were others, more powerful
>>> ships. But at one time this ship was the sole hope of humanity to
>>> survive. I might be wrong but the ship was in duty for at least 1.500
>>> years in the novels. Captured by aliens, regained by humans. After the
>>> original mission to return to sol after Terra accidentally had been
>>> moved to a location incredibly far, it always had been a symbol for
>>> humanities will to survive.
>>>
>>> -- 
>>> Some of my PovRay works:
>>> https://www.deviantart.com/antarasol/gallery/42758766/3D
>>
>>
>> You know we'll be there ;-)
>> Stop dreaming only... start sharing the dream, that's what POV is all 
>> about !
>> (And using frontends to help you is not cheating, its only a better 
>> way to do
>> POV justice.)
> 
> I'll do my best ... still I feel intimidated by the backstory of this 
> ship. Must create something that other fans will find worthy.
> 
[snip]

A little piece of goo would be helpful at this stage. :-)

I would suggest to drop /all/ the story from your mind and let the 
engineer take over. Just decide which SOL you want to model in the first 
place: The early one or the latter one. Then, while the hardware takes 
shape, pieces of the history will come back and fall into place (or not) 
to be incorporated. Just not to be overwhelmed by (needless) details.

A challenge indeed!


-- 
Thomas

[Hj Malthaner] Re: The insane project - Universe class carrier ... [1903 days 11 hours and 5 minutes ago]

Tue, 19 Jan 2021 04:14:12 GMT

On 1/15/21 3:47 PM, Mr wrote:
> "Hj. Malthaner" <han### [at] nospamgmxde> wrote:
>> Feel free to place bets. In my favorite sci-fi series there was a ship
>> called "SOL" for the name of our sun and it's sole purpose to return to
>> our galaxy.
>>
>> It's been labeled a "Universe class battle carrier", cause "Ultra
>> Battleship" had been already been taken by the former flagship units.
>>
>> I want to picture this as an animation. The SOL was a carrier ship made
>> of three components. I want to show the ship arriving, and then
>> splitting into its three parts. The command and control unit moving to
>> the back of the scene, while the two ultra battleship lookalike
>> components move forward.
>>
>> All three components then launch the smaller ships. Cruisers, corvettes
>> and fighters. Cruisers themselves carrying fighters again and also
>> launch them.
>>
>> Cuts, camera focusing on the split of the combined ship, the initial
>> launch of cruisers and fighters, the forward move of the two ultra
>> battle ship parts, then the secondary launch of fighters from the cruisers.
>>
>> And finally a sweeping look over the combined fleet, the command and
>> control module in the back, the two ultra battleships a bit a head and a
>> total of 6000 cruisers and fighters lined up ahead of them.
>>
>> Yes the source was generous with the numbers (google SOL and Perry
>> Rhodan for details, little results in English though).
>>
>>
https://lh3.googleusercontent.com/proxy/fJkTS5jjpkJYfpPx5780IthviNf2t29gEN9BRvwMYJN7Q9XrDRnOFZcKtd6PtbzzbisZf6mrrcVOA
> 8QrVGDf1dnb7mFzVIv5oxevwh4nDR5TdcidHA
>>
>> A dream right now. A dream since years. I post this to have something
>> out there as psychological crutch to actually try and start this
>> project. The SOL was the Terran ship that traveled farther than any
>> other, a ship that saw places and spaces like no other. Inside the
>> fandom it's the epic ship even that there were others, more powerful
>> ships. But at one time this ship was the sole hope of humanity to
>> survive. I might be wrong but the ship was in duty for at least 1.500
>> years in the novels. Captured by aliens, regained by humans. After the
>> original mission to return to sol after Terra accidentally had been
>> moved to a location incredibly far, it always had been a symbol for
>> humanities will to survive.
>>
>> --
>> Some of my PovRay works:
>> https://www.deviantart.com/antarasol/gallery/42758766/3D
> 
> 
> You know we'll be there ;-)
> Stop dreaming only... start sharing the dream, that's what POV is all about !
> (And using frontends to help you is not cheating, its only a better way to do
> POV justice.)

I'll do my best ... still I feel intimidated by the backstory of this 
ship. Must create something that other fans will find worthy.

More story.

---

A so far unknown race of aliens shows up in the milky way. They proclaim 
they want to make the milky way part of their empire. They also proclaim 
to havce chosen the terrans to be their governors and enforce their law 
in the milky way.

The terrans refuse and start plans to transport their home planet terra 
to a safer place.

The terrans had discovered ancient transport systems of unknown origin. 
Constellations of suns. If something entered the focus point it became 
tranported to another constellations focus point. The terrans had been 
using those systems since a while to relocate fleets.

In a desperate attempt to safe earth, the terrans try to set up a 
transmitter constellation made of sun and a white dwarf. Once done, the 
majority of the terran fleet tugs earth out of orbit and steers it to 
the focus point of the new transmitter. Earth enters the focus and 
vanishes with most of the terran fleet.

At the receiving constellation high officers of the fleet and engineers 
await earth arrival. Earth actually shows up for a moment and then vanishes.

The remaining terrans face the loss of their home world and most of 
their fleet.

Earth appears in a location far away and unknown to the terrans. It's 
steered into orbit of the most nearby sun and terrans try to find out 
where they arived.

It's a place in the universe where no terran ship has ever been, far 
away from the milky way. But the milky way is not out of reach.

A ship is built to be sent back and bring message that earth is still 
existing. Using plans for the new class of military long range carrier 
ships, the already begun new flagship of the fleet is being repurposed. 
The name SOL now being more fitting than ever, it's destination to 
return to the milky way, the home star Sol and bring the news that terra 
and the terrans are still alive.

40 years of travel. More adventures than any other ship has seen. The 
crew of the SOL unleashes the secrets behind the alien empire that wants 
to annexate the milky way.

Children are being born on the ship during those 40 years. The SOL faces 
battles for life and destruction.

The SOL returns to the milky way. The alien invaders can be repelled. 
Terra is being brought back to its rightful place, the orbit around the 
home sun Sol.

The ship eventually is handed to the children of the crew who claim in 
their home and don't want to settle on any planet, having spent all 
their life in space.

It departs and seems to be gone for good.

Centuries later, a caravan of friendly minded aliens visits the milky 
way with 2/3rd of the SOL. They had found the ship wrecked and crashed 
on an planet but restored the logs and brought it back to terra in an 
attempt to start friendly relations.

The gesture is welcomed, the SOL is being repaired and modernized with 
new drives and weapons. It is returned to the terran fleet,

After this point, the SOL has become symbol for the terrans, and has 
been captured at least twice by aliens just to be re-won as flagship by 
the terrans later. While I was following the story, the SOL was in duty 
for 1.500 years eventually.

Plus, the SOL was the only ship ever built with a sentient central 
computer. Much earlier the terrans had established a friendship with a 
sort of sentient goo that lived in symbiosis with a robot civilisation. 
Some of that sentient goo was donated and became part of the central 
computing unit of the SOL. So the ship was not only technology but home 
to a living and sentient entity who was meant to control all the little 
things that the crew could not oversee. And at least once in the travels 
controlled a very large thing thing the crew could not comprehend.

And now I am here, trying to give that ship justice in an animation ....

[Mr] Re: The insane project - Universe class carrier ... [1907 days and 29 minutes ago]

Fri, 15 Jan 2021 14:50:08 GMT

"Hj. Malthaner" <han### [at] nospamgmxde> wrote:
> Feel free to place bets. In my favorite sci-fi series there was a ship
> called "SOL" for the name of our sun and it's sole purpose to return to
> our galaxy.
>
> It's been labeled a "Universe class battle carrier", cause "Ultra
> Battleship" had been already been taken by the former flagship units.
>
> I want to picture this as an animation. The SOL was a carrier ship made
> of three components. I want to show the ship arriving, and then
> splitting into its three parts. The command and control unit moving to
> the back of the scene, while the two ultra battleship lookalike
> components move forward.
>
> All three components then launch the smaller ships. Cruisers, corvettes
> and fighters. Cruisers themselves carrying fighters again and also
> launch them.
>
> Cuts, camera focusing on the split of the combined ship, the initial
> launch of cruisers and fighters, the forward move of the two ultra
> battle ship parts, then the secondary launch of fighters from the cruisers.
>
> And finally a sweeping look over the combined fleet, the command and
> control module in the back, the two ultra battleships a bit a head and a
> total of 6000 cruisers and fighters lined up ahead of them.
>
> Yes the source was generous with the numbers (google SOL and Perry
> Rhodan for details, little results in English though).
>
>
https://lh3.googleusercontent.com/proxy/fJkTS5jjpkJYfpPx5780IthviNf2t29gEN9BRvwMYJN7Q9XrDRnOFZcKtd6PtbzzbisZf6mrrcVOA
8QrVGDf1dnb7mFzVIv5oxevwh4nDR5TdcidHA
>
> A dream right now. A dream since years. I post this to have something
> out there as psychological crutch to actually try and start this
> project. The SOL was the Terran ship that traveled farther than any
> other, a ship that saw places and spaces like no other. Inside the
> fandom it's the epic ship even that there were others, more powerful
> ships. But at one time this ship was the sole hope of humanity to
> survive. I might be wrong but the ship was in duty for at least 1.500
> years in the novels. Captured by aliens, regained by humans. After the
> original mission to return to sol after Terra accidentally had been
> moved to a location incredibly far, it always had been a symbol for
> humanities will to survive.
>
> --
> Some of my PovRay works:
> https://www.deviantart.com/antarasol/gallery/42758766/3D


You know we'll be there ;-)
Stop dreaming only... start sharing the dream, that's what POV is all about !
(And using frontends to help you is not cheating, its only a better way to do
POV justice.)

[Hj Malthaner] The insane project - Universe class carrier ship [1907 days 10 hours and 36 minutes ago]

Fri, 15 Jan 2021 04:43:07 GMT

Feel free to place bets. In my favorite sci-fi series there was a ship 
called "SOL" for the name of our sun and it's sole purpose to return to 
our galaxy.

It's been labeled a "Universe class battle carrier", cause "Ultra 
Battleship" had been already been taken by the former flagship units.

I want to picture this as an animation. The SOL was a carrier ship made 
of three components. I want to show the ship arriving, and then 
splitting into its three parts. The command and control unit moving to 
the back of the scene, while the two ultra battleship lookalike 
components move forward.

All three components then launch the smaller ships. Cruisers, corvettes 
and fighters. Cruisers themselves carrying fighters again and also 
launch them.

Cuts, camera focusing on the split of the combined ship, the initial 
launch of cruisers and fighters, the forward move of the two ultra 
battle ship parts, then the secondary launch of fighters from the cruisers.

And finally a sweeping look over the combined fleet, the command and 
control module in the back, the two ultra battleships a bit a head and a 
total of 6000 cruisers and fighters lined up ahead of them.

Yes the source was generous with the numbers (google SOL and Perry 
Rhodan for details, little results in English though).

https://lh3.googleusercontent.com/proxy/fJkTS5jjpkJYfpPx5780IthviNf2t29gEN9BRvwMYJN7Q9XrDRnOFZcKtd6PtbzzbisZf6mrrcVOA8QrVGDf1dnb7mFzVIv5oxevwh4nDR5TdcidHA

A dream right now. A dream since years. I post this to have something 
out there as psychological crutch to actually try and start this 
project. The SOL was the Terran ship that traveled farther than any 
other, a ship that saw places and spaces like no other. Inside the 
fandom it's the epic ship even that there were others, more powerful 
ships. But at one time this ship was the sole hope of humanity to 
survive. I might be wrong but the ship was in duty for at least 1.500 
years in the novels. Captured by aliens, regained by humans. After the 
original mission to return to sol after Terra accidentally had been 
moved to a location incredibly far, it always had been a symbol for 
humanities will to survive.

-- 
Some of my PovRay works:
https://www.deviantart.com/antarasol/gallery/42758766/3D

[kurtz le pirate] Re: Sundial and shadow problem [1914 days 21 hours and 7 minutes ago]

Thu, 7 Jan 2021 18:11:47 GMT

Hello,


You can look the result with the kenneth's method here :
<http://louisbel.free.fr/wip/sundial.html>

Very close to Subclick LOL


-- 
Kurtz le pirate
Compagnie de la Banquise

[William F Pokorny] Re: Sundial and shadow problem [1915 days 1 hour and 10 minutes ago]

Thu, 7 Jan 2021 14:08:17 GMT

On 1/6/21 10:01 PM, Subclick wrote:
...
> 
> Iâ€™ve tried that out, too.  With a shadowless light source, you
donâ€™t get
> highlights.  You can remedy this by setting
â€œno_shadowâ€ for both the
> wall and the gnomon, and putting the former in a light group with a
> negative-intensity light source projected through the gnomon.
...
> 

A clever approach!

Bill P.

[Subclick] Re: Sundial and shadow problem [1915 days 12 hours and 17 minutes ago]

Thu, 7 Jan 2021 03:01:49 GMT

"Kenneth" <kdw### [at] gmailcom> writes:
> After reading the various suggestions here, I
> experimented with different
> set-ups, and finally found one that works. It uses
> two light sources: a
> shadowless one in a light_group with the large
> horizonal disc, and another light
> for everything else. The no_shadow flag is not
> needed in any of the objects.

Iâ€™ve tried that out, too.  With a shadowless light source, you
donâ€™t get
highlights.  You can remedy this by setting
â€œno_shadowâ€ for both the
wall and the gnomon, and putting the former in a light group with a
negative-intensity light source projected through the gnomon.

[Kenneth] Re: radiosity in animation-- a partial solution ... [1943 days 20 hours and 54 minutes ago]

Wed, 9 Dec 2020 18:25:00 GMT

Alain Martel <kua### [at] videotronca> wrote:
> Le 2020-12-08 à 21:16, Kenneth a écrit :
> >
> > The message pane reports only this info, regardless of the Work_Threads setting:
> >         Parse time... using 1 thread
> >         Bounding time...using 1 thread
> >
>
> Can't be otherwise. Parsing and bounding are strictly sequential, single
> thread, operations.
> Photons shooting IF multiple lights or target, radiosity pretrace and
> render are the steps that can use all of your cores.

Ah, good to know. So I guess POV-ray's Windows GUI/CODEMAX message pane is
leaving out any info about the number of threads used for *radiosity*.

BTW, thanks for the tip (in another discussion in the newsgroups here) about
radiosity light not having an effect on scattering MEDIA; I didn't know that.

[Alain Martel] Re: radiosity in animation-- a partial solution ... [1943 days 21 hours and 30 minutes ago]

Wed, 9 Dec 2020 17:48:20 GMT

Le 2020-12-08 à 21:16, Kenneth a écrit :
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> On 12/6/20 6:58 PM, Kenneth wrote:
>> BTW, real-time-raytracing automatically uses only 1 thread, as far as I can
>> tell from POV-ray's message pane.
>>
>> Oh, at least in my environment, I see all processors used.
>>
> 
> Hey, you are correct! The Windows version's message pane is returning the wrong
> values; RTR *is* using both of my Win 7 machine's 2 threads. (I did a test to
> confirm this, changing v3.8's Work_Threads from my default of 2 to 1, and a
> complete loop of the first RTR animation proceeds twice as fast.)
> 
> The message pane reports only this info, regardless of the Work_Threads setting:
>         Parse time... using 1 thread
>         Bounding time...using 1 thread
> 

Can't be otherwise. Parsing and bounding are strictly sequential, single 
thread, operations.
Photons shooting IF multiple lights or target, radiosity pretrace and 
render are the steps that can use all of your cores.

[Kenneth] Re: radiosity in animation-- a partial solution ... [1944 days 12 hours and 59 minutes ago]

Wed, 9 Dec 2020 02:20:01 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 12/6/20 6:58 PM, Kenneth wrote:
> BTW, real-time-raytracing automatically uses only 1 thread, as far as I can
> tell from POV-ray's message pane.
>
> Oh, at least in my environment, I see all processors used.
>

Hey, you are correct! The Windows version's message pane is returning the wrong
values; RTR *is* using both of my Win 7 machine's 2 threads. (I did a test to
confirm this, changing v3.8's Work_Threads from my default of 2 to 1, and a
complete loop of the first RTR animation proceeds twice as fast.)

The message pane reports only this info, regardless of the Work_Threads setting:
       Parse time... using 1 thread
       Bounding time...using 1 thread

Thanks for the tip. Now, I can do some RTR/radiosity light-patch 'quality' tests
comparing 1 vs 2 threads-- which is not exactly a *definitive* test set-up,
compared to a really *multi*-threaded computer like a Core i7,etc...

[William F Pokorny] Re: radiosity in animation-- a partial solution ... [1945 days 20 hours and 33 minutes ago]

Mon, 7 Dec 2020 18:46:02 GMT

On 12/6/20 6:58 PM, Kenneth wrote:
> [Just a reminder: I'm currently running the latest v3.8 Windows develpment
> build, which piggybacks on v3.7.0]
> 
> POV-ray's real-time-raytracing feature for animation (since v3.7.0?) is
> something I use from time to time, so I decided to make a radiosity test with
> it. 

Using RTR for animations & radiosity. Another cool idea.

While the rtr / kla option is not available by default on unix based 
systems I've updated povr to run it. Thanks to Jerome, povr also 
supports x11 display and I looked briefly at the x windows dump 
capability to dump at the end of each camera render. Ran into some 
encoding / conversion issues from that format into something more usable 
- and dropped the effort.

Letting a 60 frame render loop at least 500 frames.

[17.7767 FPS]
-cc -fn -a0.3 -am2 +r2 -j2 +wt2 +w80 +h200 +rtr +kla -y x11

[17.6482 FPS]
-cc +fn -a0.3 -am2 +r2 -j2 +wt2 +w80 +h200 +rtr +kla -y x11

What the -fn to +fn slow down hints at is the internal structures needed 
for file output are being updated position to position. This means 
another and better option besides the x window dump would be trigger the 
usual output mechanism on the change to a new camera.

  [ 8.34761 FPS]
-cc -fn -a0.3 +am2 +r2 -j2 +wt2 +w80 +h200 +rtr +kla -y x11

Showing that AA costs.

My animation set up is different than your fly by camera positions. In 
my set up the camera is at the center and rotates.  At each of 60 
positions, it points to a different version of at scene. In this way 
stuff other than camera position can change.

When I turn on radiosity:

[ 8.46870 FPS]
-cc -fn -a0.3 +am2 +r2 -j2 +wt2 +w80 +h200 +rtr +kla -y x11

I do see flickering frame to frame. I think what's happening is we are 
getting an initial set of in scene samples, with rtr, but these don't 
get updated camera move to camera move - IF, there are already
enough samples.

Further, what I see in my real time set up on adding

  Radiosity_File_Name="RadSamples" +rfo +rfi

is an empty radiosity file getting additions on each camera position to 
camera position change until it hits frame 60. The saved file sample 
count is unchanged once the camera positions are revisited - until I 
break out of the animation loop at which point another burst of samples 
amounting to about 6% of the initial 60 camera position total is added.

If I then start a rtr cylic render up again with radiosity and the file 
of samples as input, I immediately get another 6% addition to the 
samples but then the sample count holds until I break out of the 
rendering loop when I get another 5.6%

FWIW. I don't completely understand what is going on. Seems like the 
preview part of radiosity only happens once on cyclic start. If I lower
the error_bound and low_error_factor I can get additional camera to 
camera samples 60 frame loop to 60 frame loop. Makes me think these are 
tied to the actual global space geometry in some way - which would mean 
they should be adjusted for each scene's scale...

Oh, at least in my environment, I see all processors used.

Lastly, I tried the larger render size idea and it changes a little the 
sample count, but not a lot. What changes I think is due the preview 
start / end windows being a little different. It must be the decisions 
on whether to add additional samples is all happening in the global 
scene coordinate space. See error_bound and low_error_factor comments 
above.

Bill P.

[William F Pokorny] Re: radiosity in animation-- a partial solution ... [1945 days 22 hours and 37 minutes ago]

Mon, 7 Dec 2020 16:41:17 GMT

On 12/6/20 3:48 PM, Kenneth wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:

> 
> Do you happend to know how those string representations can be 'decoded'? They
> are written as
>    7ffe7   ,  11ba94 , etc.
> 

Probably, but not sure off the top of my head. Let's see if I can find 
the code. Yep. Decoding shown below:

// normals aren't very critical for direction precision,
// so they are packed

sscanf(normal_string, "%02x%02x%02x", &tx, &ty, &tz);
normal[X] = ((double)tx * (1./ 254.))*2.-1.;
normal[Y] = ((double)ty * (1./ 254.))*2.-1.;
normal[Z] = ((double)tz * (1./ 254.))*2.-1.;
normal.normalize();

sscanf(to_nearest_string, "%02x%02x%02x", &tx, &ty, &tz);
to_nearest[X] = ((double)tx * (1./ 254.))*2.-1.;
to_nearest[Y] = ((double)ty * (1./ 254.))*2.-1.;
to_nearest[Z] = ((double)tz * (1./ 254.))*2.-1.;
to_nearest.normalize();

> Is it hexadecimal, perhaps? (Sorry, I'm no longer familiar with hex, from my
> university days long ago; I'm way out of practice with it.)
> 
...
> 
> About 'hacking' the saved radiosity file:
> It's an interesting idea, but will probably not work as intended. Here's an
> example of why:
> 1) I rendered a typical still-image radiosity scene, while saving the rad data
> to a file.
> 2) I re-rendered the scene using the saved data, with always_sample off and
> pretrace_start/end changed to 1.0. At this point, I cannot tell how many 'new'
> radiosity light patches have been created (without doing a 'difference'
> comparison in Photoshop); probably more than what is in the saved file.
> 3) I then opened the file in POV-ray and *erased* 90+ percent of the data lines
> there(!), then re-saved the file.
> 4) I re-rendered the scene again with the 'new' file-- and there are just as
> many radiosity light patches as before, except that most are now
> randomly-placed.
> 
> I had *assumed* that this new file would greatly reduce the number of light
> patches, but that's not the case.
> 
> Apparently,POV-ray is always trying to add new light patches when there are 'not
> enough' (?), or something like that. So, editing/hacking the file may not
> produce the intended results.
> 

Yeah. I'm not sure what might work and what might not. I suspect we 
would at least be able to do things like shift hues by mangling the 
saved colors, but time will tell.

Bill P.

[Kenneth] Re: radiosity in animation-- a partial solution ... [1946 days 15 hours and 14 minutes ago]

Mon, 7 Dec 2020 00:05:02 GMT

[Just a reminder: I'm currently running the latest v3.8 Windows develpment
build, which piggybacks on v3.7.0]

POV-ray's real-time-raytracing feature for animation (since v3.7.0?) is
something I use from time to time, so I decided to make a radiosity test with
it. I had seen some promising results years ago, but I never followed up-- my
computer at the time was too slow. And it only works with a moving camera, not
with moving scene objects.

I've posted the test here; you might or might not recognize my on-going 'city
buildings' scene. I used BAD radiosity settings again, to clearly show the
rad-light patches. No actual light_source is in the scene...and NO saved
radiosity file was used.

  +kla +rtr   are the command-line settings. POV-ray does not output the
resulting image files, so I automatically  'captured'  the preview-window
screenshots with a free app called Automatic Screenshotter. .. with a lot of
tedious per-frame editing in Avidemux to remove duplicated images. What a chore!
 (I downloaded the screenshot app only yesterday, so I haven't learned its finer
points yet.)

The animation here is blown up 150% from the original render size, using
Avidemux. It is 300 frames long, so    +kla +rtr   used 300 cameras/positions,
generated in a #while loop.

[BTW, this is my first time using the 'new' antialias method 3 and
Stochastic_Seed for a full animation-- which did not mess up or alter the
radiosity light patches in any detrimental way. The render took about 4 hours...
not exactly 'real-time', but that was mostly due to the AA.]

Comparing this real-time-raytracing render with my original post's animation
method and video, this is *extremely* smooth. From what I see, there are NO
extra radiosity patches produced from frame to frame, just a bit of noise from
video encoding (and possibly a minor change from frame 1 to frame 2). As the
animation pregresses, there could be a  few patches that *slightly* change as
the building faces are uncovered to the camera, but those changes might simply
be video compression artifacts. Or my imagination?

For the animation's radiosity , I used
always_sample off
pretrace_start 1.0
pretrace_end 1.0

....but none of those seem to matter when using real-time-raytracing. I did an
alternate short test with always_sample on, pretrace_start .32, and pretrace_end
..01, and there were still no extra light patches; same result as this posted
animation.

So real-time-raytracing must be doing 1 of 2 things with radiosity:
1) creating a truly global 3D light 'map' of the entire scene before rendering
(unlike  regular animation-with-radiosity-- see my original animation)
OR...
2) As each new animation frame/camera position is rendered, POV-ray
saves/appends that new position's rad data to an internal file-- similar(?) to
my own multi-camera-position file saving scheme mentioned earlier.

.... and automatically turns OFF any new patch creation(?)

Those are the only two schemes I can think of; but whatever the complex method
is, it creates a really smooth result, superior to the other methods I've tried.
It would be great if just the 'radiosity part' of this process could be applied
to 'standard' animation.

BTW, real-time-raytracing automatically uses only 1 thread, as far as I can tell
from POV-ray's message pane. *Maybe* this has the effect of keeping new patches
from being created? Possibly; but I'm still not convinced of that (yet!), from
my earlier 1-thread-vs-multiple-threads tests. But my machine has only 2
threads, so I really don't know...  :-(

[Kenneth] Re: radiosity in animation-- a partial solution ... [1946 days 15 hours and 29 minutes ago]

Sun, 6 Dec 2020 23:50:00 GMT

Alain Martel <kua### [at] videotronca> wrote:
> Le 2020-12-04 à 12:49, Kenneth a écrit :
>
> > ...The result is that the sphere actually
> > reflects the incoming radiosity light.. and produces crude 'radiosity
> > caustics' on the plane, no photons required!
>
> The same also happen with transparent objects. A lens can project an
> image of what is in front of it on a surface behind it.
>

I suspected that the radisoity light patches might do that as well, although I
haven't tried it yet. And I guess that using HDR lighting would show a *much*
better and more pronounced effect than my typical LDR tests.

[Alain Martel] Re: radiosity in animation-- a partial solution ... [1946 days 17 hours and 52 minutes ago]

Sun, 6 Dec 2020 21:26:16 GMT

Le 2020-12-04 à 12:49, Kenneth a écrit :

> I did an odd radiosity test, using a sky dome photo for the rad emitter, a gray
> ground plane, and a perfectly-relective sphere for a scene object...
>      (ambient 0 emission 0 diffuse 0 reflection 1.0)
> ... except that I cranked up its reflection to 8.0-- just an arbitrarily HIGH
> value. I also added a normal to it. The result is that the sphere actually
> reflects the incoming radiosity light.. and produces crude 'radiosity caustics'
> on the plane, no photons required! I didn't realize that radiosity light could
> be reflected, without using photons in some way. It seems that the two methods
> do operate in a somewhat similar(?) way.
> 
> 
> 

The same also happen with transparent objects. A lens can project an 
image of what is in front of it on a surface behind it.

I first experience it with the woodbox scene modified to use radiosity 
and adding a light probe.

[Kenneth] Re: radiosity in animation-- a partial solution ... [1946 days 18 hours and 29 minutes ago]

Sun, 6 Dec 2020 20:50:06 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> C seems to stand for color. (There are other unused classifications)
> The number after the D is depth [recursion_limit]...
>
> The next three float values are the location.
> ...
> Field 11, like the normal field, is a string representing 3 x,y,z values
> pointing, roughly in the direction where the nearest distance sample was
> taken.

Do you happend to know how those string representations can be 'decoded'? They
are written as
  7ffe7   ,  11ba94 , etc.

Is it hexadecimal, perhaps? (Sorry, I'm no longer familiar with hex, from my
university days long ago; I'm way out of practice with it.)

>
> I'm not aware of a way to force a stop immediately after...
> radiosity sample file creation. Is there one?

I have not yet found a way either; it seems that *some* new radiosity samples
are always created when using a saved radiosity file, regardless of
always_sample on/off or pretrace_start/pretrace_end being changed to 1.0.
(Changing any of radiosity's other settings has unintended and unexpected
results, from my tests *so far*.)

About 'hacking' the saved radiosity file:
It's an interesting idea, but will probably not work as intended. Here's an
example of why:
1) I rendered a typical still-image radiosity scene, while saving the rad data
to a file.
2) I re-rendered the scene using the saved data, with always_sample off and
pretrace_start/end changed to 1.0. At this point, I cannot tell how many 'new'
radiosity light patches have been created (without doing a 'difference'
comparison in Photoshop); probably more than what is in the saved file.
3) I then opened the file in POV-ray and *erased* 90+ percent of the data lines
there(!), then re-saved the file.
4) I re-rendered the scene again with the 'new' file-- and there are just as
many radiosity light patches as before, except that most are now
randomly-placed.

I had *assumed* that this new file would greatly reduce the number of light
patches, but that's not the case.

Apparently,POV-ray is always trying to add new light patches when there are 'not
enough' (?), or something like that. So, editing/hacking the file may not
produce the intended results.

[Tor Olav Kristensen] Re: Planetary fly-overs with height-fields [1947 days 22 hours and 44 minutes ago]

Sat, 5 Dec 2020 16:35:01 GMT

=?UTF-8?Q?J=c3=b6rg_=22Yadgar=22_Bleimann?= <yaz### [at] gmxde> wrote:
> Hi(gh)!
>
> On 04.12.20 11:27, Tor Olav Kristensen wrote:
> > Hi Yadgar
> >
> > =?UTF-8?Q?J=c3=b6rg_=22Yadgar=22_Bleimann?= <yaz### [at] gmxde> wrote:
> >> ...
> >> The faces are constructed this way:
> >>
> >> #declare a = 0;
> >> #declare c = 0;
> >> #while (a < ydim-1)
> >>     #declare b = 0;
> >>     #while (b < xdim-1)
> >>       #declare Faces[a*ydim+b]  = <a*res+b, a*res+b+1, (a+1)*res+b>;
> >>       #declare Faces[a*ydim+b+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
> >
> > Have you tested if the code above works as you intended ?
>
> With the script I extracted the code from, it works perfectly!

But about all of the calculations you do in this line "#declare
Faces[a*ydim+b+1] = ..." are wasted (i.e. not used), except for in the last
iteration of the "#while (b < xdim-1)" loop. That is because they are
overwritten in the next iteration of the loop.

And if you use c to count the number of vectors defined so far in the Faces
array, then the count will be about twice as high as the actual number of
vectors put into that array.

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

[Jörg "Yadgar" Bleimann] Re: Planetary fly-overs with height-fields [1948 days 1 hour and 23 minutes ago]

Sat, 5 Dec 2020 13:55:48 GMT

Hi(gh)!

On 04.12.20 11:27, Tor Olav Kristensen wrote:
> Hi Yadgar
> 
> =?UTF-8?Q?J=c3=b6rg_=22Yadgar=22_Bleimann?= <yaz### [at] gmxde> wrote:
>> ...
>> vertpos = height*<radians(sin(-longitude))*radians(cos(latitude)),
>> radians(sin(latitude)), radians(cos(-longitude))*radians(cos(latitude))>
> 
> The code above seems wrong. Your vector should probably be calculated like this:
> 
> <
>      cos(radians(latitude))*sin(radians(-longitude)),
>      sin(radians(latitude)),
>      cos(radians(latitude))*cos(radians(-longitude))

Yes, you're right - I just typed it from memory, I should have looked it 
up in my scripts instead!

>> The faces are constructed this way:
>>
>> #declare a = 0;
>> #declare c = 0;
>> #while (a < ydim-1)
>>     #declare b = 0;
>>     #while (b < xdim-1)
>>       #declare Faces[a*ydim+b]  = <a*res+b, a*res+b+1, (a+1)*res+b>;
>>       #declare Faces[a*ydim+b+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
> 
> Have you tested if the code above works as you intended ?

With the script I extracted the code from, it works perfectly!

See you in Khyberspace!

Yadgar

[William F Pokorny] Re: radiosity in animation-- a partial solution ... [1948 days 2 hours and 37 minutes ago]

Sat, 5 Dec 2020 12:41:52 GMT

On 12/4/20 12:49 PM, Kenneth wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
...
>> ---
>> C seems to stand for color. (There are other unused classifications)
>> The number after the D is depth. I've only ever seen 1 or 2 - maybe if
>> recursion depth increased?
> 
> Yes, you're right, it's recursion_limit. (In my tests so far, I had set it to
> 2.) I ran another test with somewhat high-quailty settings (to produce a LARGE
> saved rad file), and cranked resursion_limit up to 20. Now I see data lines
> starting with C3,C4 etc. Interestingly, they 'top out' at about C8-- with fewer
> entries too-- which agrees with the documentation about higher recursion_limit
> settings having less and less of a visual effect on the render.

Thanks. Good to know.

>>
>> The next three float values are the location...
>> ...
...
> 
>  From my animation tests with a moving camera, I assume that the x,y,z
> values/direction vectors have something to do with CAMERA's viewpoint as well
> (whatever it happens to be.) That is, if I understand your description
> correctly.

I think only to the extent the camera rays set where the code will look 
to take samples. Nearly positive, the stored sample coordinates are 
locations in global scene space. Most, excepting media ones, on 
surfaces. Normals, distance and direction information would all be 
relative to the surface(1).

(1) - Wonder what happens with normals in media...

> 
> IMO, there does seem to be a similarity:
> 
(Interesting experiment - ie reflection 8)

On similarity between photons and radiosity, I was speaking mostly about 
saved file formats.

Photons and radiosity start in fundamentally different ways. Photons 
shoot rays (forward) from light sources into the scene to create photon 
samples. Radiosity traces backward in the more traditional ray tracing 
way and it might find light sources or not depending on the ray tracing 
bend/bounce depth.

Both types of samples are gathered and merged in with the usual ray 
tracing results for each ray to give a final result.

(One more thought. If there is no way to stop after the radiosity file 
is updated, we should be sure options like AA are off to save that time 
- if you are not already doing this.)

Bill P.

[William F Pokorny] Re: radiosity in animation-- a partial solution ... [1948 days 2 hours and 58 minutes ago]

Sat, 5 Dec 2020 12:20:25 GMT

On 12/4/20 11:46 AM, Kenneth wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
...
> 2nd added only 9 lines; the third, 9 more. Then I tried to find duplicated data
> lines among the total, but again no luck. So it *seems* that POV-ray
> automatically removes any redundant data from an appended radiosity file.
> 
See my response to Mr as to why redundant (or near redundant) samples 
might not be getting added to the file.

Bill P>

[William F Pokorny] Re: radiosity in animation-- a partial solution ... [1948 days 3 hours and 1 minute ago]

Sat, 5 Dec 2020 12:18:03 GMT

On 12/4/20 11:43 AM, Mr wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
... the
> radiosity algorithm is supposed to do unique samples to avoid wasting
> computation, that is precisely why I mentioned to truncate the precision : so
> that the samples closest would thus falsely appear as duplicates but the lines
> suppressed in the initial data would rather be considered merged by that
> (truncation) threshold criteria. Does that naive approach make sense to someone
> more experienced than me, or am I missing something?
> 
Expect quite a few things in play. There is some initial sampling 
density relative the the scene depending on numerous things for any 
given frame. If we change one or more of the dependencies enough, 
additional samples will be shot. Of those "perhaps" some will be added 
to the saved file.

In the moving camera case I think it likely new, duplicate or very 
nearby lines (samples) don't get added after a point because the some 
criteria (error, distance, ?) kicks in on seeing local context for the 
existing samples - and any in hand, "duplicate," potential sample is 
tossed in the bit bucket - but, I'm guessing.

---
I wonder if anyone has tried creating a radiosity file at a resolution 
larger than the final frame/scene?

I'm not aware of a way to force a stop immediately after photon / 
radiosity sample file creation. Is there one?

It would be handy to avoid the cost of the final pass render, saving of 
other intermediate and output files when just creating the larger 
radiosity file for the actual final frame/scene renders.

Bill P.

[Kenneth] Re: radiosity in animation-- a partial solution ... [1948 days 21 hours and 24 minutes ago]

Fri, 4 Dec 2020 17:55:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> I dug up the source code not too long ago and made these notes:

Fascinating! Thanks for taking the time to do this, and for posting your info.
>
> ---
> C seems to stand for color. (There are other unused classifications)
> The number after the D is depth. I've only ever seen 1 or 2 - maybe if
> recursion depth increased?

Yes, you're right, it's recursion_limit. (In my tests so far, I had set it to
2.) I ran another test with somewhat high-quailty settings (to produce a LARGE
saved rad file), and cranked resursion_limit up to 20. Now I see data lines
starting with C3,C4 etc. Interestingly, they 'top out' at about C8-- with fewer
entries too-- which agrees with the documentation about higher recursion_limit
settings having less and less of a visual effect on the render.
>
> The next three float values are the location...
> ...
>
> In field 10 the nearest sample distance found is recorded.
>
> Field 11, like the normal field, is a string representing 3 x,y,z values
> pointing, roughly in the direction where the nearest distance sample was
> taken.

From my animation tests with a moving camera, I assume that the x,y,z
values/direction vectors have something to do with CAMERA's viewpoint as well
(whatever it happens to be.) That is, if I understand your description
correctly.
>
>
> Aside: I suspect, there are some similarities to the saved photons file,
> but I've not gotten to even a first look at it...
>

IMO, there does seem to be a similarity:

I did an odd radiosity test, using a sky dome photo for the rad emitter, a gray
ground plane, and a perfectly-relective sphere for a scene object...
    (ambient 0 emission 0 diffuse 0 reflection 1.0)
... except that I cranked up its reflection to 8.0-- just an arbitrarily HIGH
value. I also added a normal to it. The result is that the sphere actually
reflects the incoming radiosity light.. and produces crude 'radiosity caustics'
on the plane, no photons required! I didn't realize that radiosity light could
be reflected, without using photons in some way. It seems that the two methods
do operate in a somewhat similar(?) way.

[Kenneth] Re: radiosity in animation-- a partial solution ... [1948 days 22 hours and 29 minutes ago]

Fri, 4 Dec 2020 16:50:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> It would indeed be useful to optimize the final saved data file, if possible...
>
> Unfortunately, not a single line of [the saved data] data seems to repeat;
> I tried hard to find at least one repetition, with no luck...
> I haven't yet tried a test where the camera is static; maybe there *would*
> be duplicate entries that could be eliminated.
>

In all my animation/radiosity tests so far, I've used a moving CAMERA (and no
moving scene objects) to create the composite rad-data file. That seemed a
logical way to proceed; but I just did a 'static' camera test-- which produced
some interesting results:

Saving/appending 3 identical radiosity renders, with identical rad settings,
seems to be enough to prevent any 'new' rad light patches from being created
when running the final animation (assuming pretrace_start and pretrace_end are
changed to 1.0 for the final run; and assuming that the camera remains static.)
I would call it a '3-pass' technique. There are still a *few* stray patches
created, but they are very hard to spot. Of course, this doesn't take into
account any moving OBJECTS in the scene; I haven't gotten that far yet ;-)

As for the data file itself and its possible duplicated entries: I decided to
render and save a *tiny* radiosity file-- 4X3 pixels(!)-- made with a static
camera, and using the 3-pass trick. The final saved file is a 'composite' of the
3 renders and their data. The first 'pass' produced 108 saved data lines; the
2nd added only 9 lines; the third, 9 more. Then I tried to find duplicated data
lines among the total, but again no luck. So it *seems* that POV-ray
automatically removes any redundant data from an appended radiosity file.

[Mr] Re: radiosity in animation-- a partial solution ... [1948 days 22 hours and 34 minutes ago]

Fri, 4 Dec 2020 16:45:01 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 12/4/20 9:06 AM, Kenneth wrote:
> > "Mr" <nomail@nomail> wrote:
> >
> ...
> >
> > C1 6.40944 0 10.2727 7ffe7f 0.5393 0.5634 0.6627 0.0673439 2.02194 13b2aa
> > C1 5.07783 0 9.9777 7ffe7f 0.2932 0.2820 0.3779 0.0626854 19990.9 94c3e8
> > C2 4.67263 2.28262 10.8619 fd7f6d 0.2772 0.0367 0.0002 0.123517 2.80274 c81887
> > C1 5.22191 0 9.92912 7ffe7f 0.3809 0.2062 0.1807 0.0629131 2.52627 63f2ae
> > C1 5.40516 0 9.95757 7ffe7f 0.5724 0.6442 0.7586 0.0635047 19991.6 90cde2
> > C1 5.59453 0 9.99461 7ffe7f 0.4496 0.4617 0.5039 0.0641466 1.52217 33bfce
> >
> > ......etc. etc. Each line starts with C1 or C2. (And there's no obvious 'order'
> > to
> > the entries.) I have no idea what the data actually means.
> >
>
> I dug up the source code not too long ago and made these notes:
>
> ---
> C seems to stand for color. (There are other unused classifications)
> The number after the D is depth. I've only ever seen 1 or 2 - maybe if
> recursion depth increased?
>
> The next three float values are the location.
>
> The text string in position 5 is the normal encoded for +-(2 byte
> value/254) it looked.
>
> Positions 6,7 and 8 are the three color channel values at the point.
>
> In field 9 we have the harmonic mean. The inverse of the mean of the
> inverses of distances to all samples used to set a point's "radiosity
> view." This read as a double (long float) but later used in calculations
> as a float.
>
> In field 10 the nearest sample distance found is recorded.
>
> Field 11, like the normal field, is a string representing 3 x,y,z values
> pointing, roughly in the direction where the nearest distance sample was
> taken.
>
> ---
> The floats are all read/scanned as doubles, but the file representation
> seems to be float. The internal usage in calculations is sometimes
> (always?) cast to float. Expect this means not too much difference
> between binary file encoding (as doubles) and current text encoding.
> However, if internally stored as all doubles and all only used as floats
> - the internal representation could probably be better?
>
> FWIW.
>
> ... Yeah, hacking the radiosity file for effects is not something I
> recall anyone doing. It could be interesting. Color shifts. By global
> locations increase or decrease intensities. Insertion of samples by
> interpolation from existing ones? Completely contrived radiosity files
> with gradients or whatever...
>
> Aside: I suspect, there are some similarities to the saved photons file,
> but I've not gotten to even a first look at it...
>
> Bill P.

Why not, ! Radiosity filters ! with that some inbuilt effect could be done like
the recent tests done for paint effect by Kenneth with his circular lights...
Back on initial topic, This is axactly the kind of data I hoped: So yes, the
radiosity algorithm is supposed to do unique samples to avoid wasting
computation, that is precisely why I mentioned to truncate the precision : so
that the samples closest would thus falsely appear as duplicates but the lines
suppressed in the initial data would rather be considered merged by that
(truncation) threshold criteria. Does that naive approach make sense to someone
more experienced than me, or am I missing something?

[William F Pokorny] Re: radiosity in animation-- a partial solution ... [1949 days and 27 minutes ago]

Fri, 4 Dec 2020 14:51:50 GMT

On 12/4/20 9:06 AM, Kenneth wrote:
> "Mr" <nomail@nomail> wrote:
> 
...
> 
> C1 6.40944 0 10.2727 7ffe7f 0.5393 0.5634 0.6627 0.0673439 2.02194 13b2aa
> C1 5.07783 0 9.9777 7ffe7f 0.2932 0.2820 0.3779 0.0626854 19990.9 94c3e8
> C2 4.67263 2.28262 10.8619 fd7f6d 0.2772 0.0367 0.0002 0.123517 2.80274 c81887
> C1 5.22191 0 9.92912 7ffe7f 0.3809 0.2062 0.1807 0.0629131 2.52627 63f2ae
> C1 5.40516 0 9.95757 7ffe7f 0.5724 0.6442 0.7586 0.0635047 19991.6 90cde2
> C1 5.59453 0 9.99461 7ffe7f 0.4496 0.4617 0.5039 0.0641466 1.52217 33bfce
> 
> ......etc. etc. Each line starts with C1 or C2. (And there's no obvious 'order'
> to
> the entries.) I have no idea what the data actually means.
> 

I dug up the source code not too long ago and made these notes:

---
C seems to stand for color. (There are other unused classifications)
The number after the D is depth. I've only ever seen 1 or 2 - maybe if
recursion depth increased?

The next three float values are the location.

The text string in position 5 is the normal encoded for +-(2 byte 
value/254) it looked.

Positions 6,7 and 8 are the three color channel values at the point.

In field 9 we have the harmonic mean. The inverse of the mean of the 
inverses of distances to all samples used to set a point's "radiosity 
view." This read as a double (long float) but later used in calculations 
as a float.

In field 10 the nearest sample distance found is recorded.

Field 11, like the normal field, is a string representing 3 x,y,z values 
pointing, roughly in the direction where the nearest distance sample was 
taken.

---
The floats are all read/scanned as doubles, but the file representation 
seems to be float. The internal usage in calculations is sometimes 
(always?) cast to float. Expect this means not too much difference 
between binary file encoding (as doubles) and current text encoding. 
However, if internally stored as all doubles and all only used as floats 
- the internal representation could probably be better?

FWIW.

... Yeah, hacking the radiosity file for effects is not something I 
recall anyone doing. It could be interesting. Color shifts. By global 
locations increase or decrease intensities. Insertion of samples by 
interpolation from existing ones? Completely contrived radiosity files
with gradients or whatever...

Aside: I suspect, there are some similarities to the saved photons file, 
but I've not gotten to even a first look at it...

Bill P.

[Kenneth] Re: radiosity in animation-- a partial solution ... [1949 days 1 hour and 9 minutes ago]

Fri, 4 Dec 2020 14:10:06 GMT

"Mr" <nomail@nomail> wrote:

>
> ...So you're saying that this radiosity data file is human readable. If each
>  sample is clearly identifiable, and can be split on a per line basis then
> it's worth trying some kind of script (even maybe a notepad++ macro if it
> could recognize and operate on numbers?) to do the following:
>
> ...find any line that now has the same patch coordinates in "radtemp2"
> store its index in a list.
>
> ...And finally merge "rad2" at the end of rad1" to get your incremented but more
> optimized rad2
>

It would indeed be useful to optimize the final saved data file, if possible; my
animation test for *today*, with a moving camera, has a saved 'composite'
radiosity file with 47000+ lines of data! Here's a sample of what it looks like,
opened in POV-ray...

C1 6.40944 0 10.2727 7ffe7f 0.5393 0.5634 0.6627 0.0673439 2.02194 13b2aa
C1 5.07783 0 9.9777 7ffe7f 0.2932 0.2820 0.3779 0.0626854 19990.9 94c3e8
C2 4.67263 2.28262 10.8619 fd7f6d 0.2772 0.0367 0.0002 0.123517 2.80274 c81887
C1 5.22191 0 9.92912 7ffe7f 0.3809 0.2062 0.1807 0.0629131 2.52627 63f2ae
C1 5.40516 0 9.95757 7ffe7f 0.5724 0.6442 0.7586 0.0635047 19991.6 90cde2
C1 5.59453 0 9.99461 7ffe7f 0.4496 0.4617 0.5039 0.0641466 1.52217 33bfce

......etc. etc. Each line starts with C1 or C2. (And there's no obvious 'order'
to
the entries.) I have no idea what the data actually means.

Unfortunately, not a single line of that data seems to repeat; I tried hard to
find at least one repetition, with no luck. So my guess is that, as the *camera*
moves during the animation, totally-new 'coordinates' (or whatever) are
generated, with somewhat overlapping 'rad light patches'. I haven't yet tried a
test where the camera is static; maybe there *would* be duplicate entries that
could be eliminated.

BTW: From what I can tell so far, this 'additive' rad-data scheme (for the final
saved file) adds new light patches that sometimes overlap previous ones,
sometimes not. In effect, it seems to be adding to radiosity's COUNT value. So
it might be possible to 'relax' that value-- like, changing COUNT 200 to some
lower value-- to still get the original expected visual result. I haven't yet
tested the idea though.

[Mr] Re: radiosity in animation-- a partial solution ... [1949 days 3 hours and 34 minutes ago]

Fri, 4 Dec 2020 11:45:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> > On 11/24/20 2:10 PM, Kenneth wrote:
>
> > D) This uses TWO initial saved radiosity files, one made at the camera's
> > start position and one made at the end (with different file names, of
> > course!). Those files can be opened and inspected in POV-ray-- they are
> > just text/data files of some kind-- then I simply copied-and-pasted the
> > complete contents of the 2nd file onto the end of the 1st file, which is
> > then re-saved. This 'composite' rad file is then used for the animation.
>
> > Cool idea and demo! Not positive, but I think if you both loaded and
> > saved the radiosity samples the "new" ones would get appended to the
> > file by POV-Ray (no need to edit). If so, it should be you could run a
> > sampling of the total frames where you let POV-Ray keep adding to the
> > radiosity file...
>
> Yes, you're right; I didn't think to try that easy trick until after I posted
> here.  I had assumed that the two file-appending schemes *might* produce
> different results, but they are the same.
>
> Taking that idea to its logical conclusion, the following scheme is a
> nicely-efficient way to generate the 'composite' saved radiosity file from
> multiple camera viewpoints (for 'overlapping' rad data). Say you want a 50-frame
> animation where the camera moves like
>   <-3 + 6*clock,5,0>.
> To create the composite rad file, the *initial* position would be  <-3,5,0>--
> and the initial .INI file-saving settings need to be:
> Radiosity_File_Name="RAD data" (or whatever name)
> Radiosity_To_File=on
> (animation turned OFF temporarily)
>
> Then, to create the *full* saved composite file (the required interim process):
> Radiosity_File_Name="RAD data"
> Radiosity_To_File=on (to append more data to it)
> Radiosity_From_File=on
> Final_Frame=50
> Subset_Start_Frame=2 (because frame 1 already has  its data saved)
> Frame_Step=4 (or some other value-- because it is probably not necessary to save
> rad data for *every* animation frame/camera position)
>
> Then, to render the FINAL animation-with-radiosity:
> Radiosity_File_Name="RAD data"
> Radiosity_From_File=on
> Final_Frame=50
> .... along with the radiosity block's pretrace_start and pretrace_end both
> changed to 1.0.
>
> From experiments I've done, this works quite well-- with almost no flickering
> rad-light patches.
>
> Here's something interesting, though: For typical still-image renders, others
> here have mentioned that a small-size (faster) initial radiosity render can be
> made, while saving that data file for a *larger* render. This scheme works
> reasonably OK for still images more or less, although there is a kind of 'lack
> of radiosity detail' from the smaller render, and the saved file size is
> correspondingly small as well, with fewer data entries. But this small-to-large
> render scheme doesn't work well for creating a composite *animation* rad file--
> there are still too many 'dancing light patches' in the final larger-size
> animation. The only way the composite-saved-file idea works is to pre-render the
> frames at their final intended pixel size, a slow process (while saving the
> frame-to-frame data of course.)
> >
> > I've not been following the radiosity discussions closely, but there is
> > since v3.7 a +HR or High_Reproducibility option. Have you tried this? As
> > far as I know, it still works only with radiosity though its initial aim
> > was broader.
>
> So far, I have not gotten to that point in my experiments ;-) And I've been
> running tests all week!
> >
> > IIRC, what it does is change the seed to the render block "number" so
> > even with multiple threads (SMP) you get the same random numbers (and so
> > radiosity ray samples - at least by ordering) in any given block. The
> > render image size and render block size would need to stay constant too
> > of course.
>
> That's an interesting suggestion about render block size, that I had not thought
> about; I need to experiment with that as well.
> >
> > Another option which obviously helps with reproducibility is running
> > with one thread.
> >
>
> From initial experiments I've done on my lowly Windows 7 computer (with its 2
> threads or cores or whatever), changing POV-Ray's Works_Threads setting in my
> ..INI file from 2 to 1 does not *seem* to affect the animation results re: the
> look or placement of the radiosity light patches. I should probably do some more
> tests though.

Interesting tests, If I remember correctly, Mental ray used to have a way to do
this as well... or maybe it was just for geometry export, but some kind of
incremental feature for animation.


Anyway, to my rather profane user ears your idea sounds sane to keep initial
radiosity data and only compute necessary additions for each new frame. So
you're saying that this radiosity data file is human readable. If each sample is
clearly identifiable, and can be split on a per line basis then it's worth
trying some kind of script (even maybe a notepad++ macro if it could recognize
and operate on numbers?) to do the following:

-copy the first ("rad1") and second ("rad2") frame's radiosity data files
calling these copies say "radtemp1" "radtemp2"

-pick a (low) precision threshold (a small enough number of digits after the
decimal points)to truncate all numbers of "radtemp1" and "radtemp2" to this
precision, so that you can...

-...iterate while keeping counted index, through each line of truncated
"radtemp1", find any line that now has the same patch coordinates in "radtemp2"
store its index in a list.

-suppress all lines corresponding to these indices in the original "rad2"

-And finally merge "rad2" at the end of rad1" to get your incremented but more
optimized rad2

However I would not be surprised if POV was already supposed to do all that kind
of stuff or even better optimization internally?

[Tor Olav Kristensen] Re: Planetary fly-overs with height-fields [1949 days 4 hours and 49 minutes ago]

Fri, 4 Dec 2020 10:30:00 GMT

Hi Yadgar

=?UTF-8?Q?J=c3=b6rg_=22Yadgar=22_Bleimann?= <yaz### [at] gmxde> wrote:
>...
> vertpos = height*<radians(sin(-longitude))*radians(cos(latitude)),
> radians(sin(latitude)), radians(cos(-longitude))*radians(cos(latitude))>

The code above seems wrong. Your vector should probably be calculated like this:

<
    cos(radians(latitude))*sin(radians(-longitude)),
    sin(radians(latitude)),
    cos(radians(latitude))*cos(radians(-longitude))
>

>...
> The faces are constructed this way:
>
> #declare a = 0;
> #declare c = 0;
> #while (a < ydim-1)
>    #declare b = 0;
>    #while (b < xdim-1)
>      #declare Faces[a*ydim+b]  = <a*res+b, a*res+b+1, (a+1)*res+b>;
>      #declare Faces[a*ydim+b+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

Have you tested if the code above works as you intended ?

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

[Kenneth] Re: radiosity in animation-- a partial solution ... [1949 days 18 hours and 29 minutes ago]

Thu, 3 Dec 2020 20:50:08 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 11/24/20 2:10 PM, Kenneth wrote:

> D) This uses TWO initial saved radiosity files, one made at the camera's
> start position and one made at the end (with different file names, of
> course!). Those files can be opened and inspected in POV-ray-- they are
> just text/data files of some kind-- then I simply copied-and-pasted the
> complete contents of the 2nd file onto the end of the 1st file, which is
> then re-saved. This 'composite' rad file is then used for the animation.

> Cool idea and demo! Not positive, but I think if you both loaded and
> saved the radiosity samples the "new" ones would get appended to the
> file by POV-Ray (no need to edit). If so, it should be you could run a
> sampling of the total frames where you let POV-Ray keep adding to the
> radiosity file...

Yes, you're right; I didn't think to try that easy trick until after I posted
here.  I had assumed that the two file-appending schemes *might* produce
different results, but they are the same.

Taking that idea to its logical conclusion, the following scheme is a
nicely-efficient way to generate the 'composite' saved radiosity file from
multiple camera viewpoints (for 'overlapping' rad data). Say you want a 50-frame
animation where the camera moves like
  <-3 + 6*clock,5,0>.
To create the composite rad file, the *initial* position would be  <-3,5,0>--
and the initial .INI file-saving settings need to be:
Radiosity_File_Name="RAD data" (or whatever name)
Radiosity_To_File=on
(animation turned OFF temporarily)

Then, to create the *full* saved composite file (the required interim process):
Radiosity_File_Name="RAD data"
Radiosity_To_File=on (to append more data to it)
Radiosity_From_File=on
Final_Frame=50
Subset_Start_Frame=2 (because frame 1 already has  its data saved)
Frame_Step=4 (or some other value-- because it is probably not necessary to save
rad data for *every* animation frame/camera position)

Then, to render the FINAL animation-with-radiosity:
Radiosity_File_Name="RAD data"
Radiosity_From_File=on
Final_Frame=50
.... along with the radiosity block's pretrace_start and pretrace_end both
changed to 1.0.

From experiments I've done, this works quite well-- with almost no flickering
rad-light patches.

Here's something interesting, though: For typical still-image renders, others
here have mentioned that a small-size (faster) initial radiosity render can be
made, while saving that data file for a *larger* render. This scheme works
reasonably OK for still images more or less, although there is a kind of 'lack
of radiosity detail' from the smaller render, and the saved file size is
correspondingly small as well, with fewer data entries. But this small-to-large
render scheme doesn't work well for creating a composite *animation* rad file--
there are still too many 'dancing light patches' in the final larger-size
animation. The only way the composite-saved-file idea works is to pre-render the
frames at their final intended pixel size, a slow process (while saving the
frame-to-frame data of course.)
>
> I've not been following the radiosity discussions closely, but there is
> since v3.7 a +HR or High_Reproducibility option. Have you tried this? As
> far as I know, it still works only with radiosity though its initial aim
> was broader.

So far, I have not gotten to that point in my experiments ;-) And I've been
running tests all week!
>
> IIRC, what it does is change the seed to the render block "number" so
> even with multiple threads (SMP) you get the same random numbers (and so
> radiosity ray samples - at least by ordering) in any given block. The
> render image size and render block size would need to stay constant too
> of course.

That's an interesting suggestion about render block size, that I had not thought
about; I need to experiment with that as well.
>
> Another option which obviously helps with reproducibility is running
> with one thread.
>

From initial experiments I've done on my lowly Windows 7 computer (with its 2
threads or cores or whatever), changing POV-Ray's Works_Threads setting in my
..INI file from 2 to 1 does not *seem* to affect the animation results re: the
look or placement of the radiosity light patches. I should probably do some more
tests though.

[Jörg "Yadgar" Bleimann] Re: Planetary fly-overs with height-fields [1950 days 2 hours and 19 minutes ago]

Thu, 3 Dec 2020 13:00:00 GMT

Hi(gh)!

On 22.11.20 17:44, Alain Martel wrote:

> Converting an 8-bit image to 16-bits can't help. All it can do is append 
> 8 zeros as low order bits.
> You need some more steps to interpolate smoothly between the original 
> steps.

MÃ¤tes, you might try the (very ancient, for MS-DOS!) tool "HF-Lab" 
written back in the last century by John Beale... when you apply a 
slight blur filter (command: nsmooth 7, just 7 iterations of nsmooth) to 
your heightfield, it might benefit considerably!

See you in Khyberspace!

Yadgar

Now playing: Aranjuez (Blonker)

[Jörg "Yadgar" Bleimann] Re: Planetary fly-overs with height-fields [1950 days 4 hours and 2 minutes ago]

Thu, 3 Dec 2020 11:16:24 GMT

Hi(gh)!

On 22.11.20 12:02, Mï¿½tes wrote:
> Hi Yadgar,
> 
> the original pictures are all 8-bit greyscale, and to convert them into 16-bit
> didnt help. I want to ask a co-worker if there are some Gimp-Filters to better
> them, maybe that helps. At them moment there are only 265 steps in height, hope
> that I can smooth them a littlebit.
> 
> To get better pics I have to invest many hours of look and search in the
> internet, there was no time for this in the past month.
> 
> Your movie looks nice, more detailed than mine.
> I plan to check out meshes to but didnt start with it.
> Do you have a skript as a starting-point for me?
> 
> Yes, I am from cologne, you're right.
> I have a small personal blog but my website is down at the moment.
> Will inform the povray-world when its online again :)
> 
> Alaaf,
> MÃ¤tes
> 

To get "spherical" heightfields which follow the planet's curvature it's 
best to have a topographical bitmap in simple cylindrical projection 
(side ratio 2:1, which is important!) and then start getting the color 
values for each pixel using eval_pigment(), in a nested loop running 
from 90 to -90 degrees (latitude) and -180 to 180 degrees (longitude). 
Then you convert each color value to a height within the elevation range 
of the planet - with Earth and greyscales this would be (assuming a 
scale of 1 km per POV unit):

height = radius (i. e. 6377.5-11.022 for Earth - sealevel radius minus 
deepest point of the ocean) + (gray value*255)*((11.022 [Mariana trench] 
+ 8.8848 [Mt. Everest])/255)

(or height = radius (6377.5-0.422) + (gray value*255)*(0.422 [Dead Sea] 
+ 8.8848 [Mt. Everest])/255), if your map doesn't include ocean depths)

This height value translates as follows to a 3D point for each mesh vertex:

vertpos = height*<radians(sin(-longitude))*radians(cos(latitude)), 
radians(sin(latitude)), radians(cos(-longitude))*radians(cos(latitude))>

Note that the longitude value has to be multiplied with -1, as Earth 
longitudes increase counter-clockwise from west to east!

I think you will be able to transfer this to your Martian project 
without much effort...

...of course, after that you will have to set up the mesh2 faces from 
the index values of the vertices!

The faces are constructed this way:

#declare a = 0;
#declare c = 0;
#while (a < ydim-1)
   #declare b = 0;
   #while (b < xdim-1)
     #declare Faces[a*ydim+b]  = <a*res+b, a*res+b+1, (a+1)*res+b>;
     #declare Faces[a*ydim+b+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

I hope I could help you...

See you in Khyberspace!

Yadgar

Now playing: Madeleine (Bernhard Brink)

[William F Pokorny] Re: Star Wars - Part 1 [1954 days 23 hours and 34 minutes ago]

Sat, 28 Nov 2020 15:44:52 GMT

On 11/22/20 6:16 AM, Mï¿½tes wrote:
> I was experimenting with some height-fields, as I remembered that I downloaded
> years earlier some models from Starwars.
> So I combined them with a spline and tried to create a small fight between them.
> 
> 
Cool!

Bill P.

[William F Pokorny] Re: radiosity in animation-- a partial solution ... [1954 days 23 hours and 38 minutes ago]

Sat, 28 Nov 2020 15:40:31 GMT

On 11/24/20 2:10 PM, Kenneth wrote:
> Radiosity in animation suffers from a kind of jitter or flicker problem, even
> with high-quality settings... a result of the random nature of the rad 'light
> patches' from frame to frame. Using a SAVED radiosity file, from an initial
> camera viewpoint, would seem to solve that issue, but it's only partially
> successful: As the camera moves-- and the scene's objects move as well-- the
> saved radiosity file is no longer adequate to produce an expected smooth effect.
> 
> I came up with an interesting solution to part of this problem, at least for
> POV-ray v3.8xx and maybe 3.7 too, which is more easily explained in an animation
> test.
> 
...
> 
Cool idea and demo! Not positive, but I think if you both loaded and 
saved the radiosity samples the "new" ones would get appended to the 
file by POV-Ray (no need to edit). If so, it should be you could run a 
sampling of the total frames where you let POV-Ray keep adding to the 
radiosity file. This would be an initial pass for the purposes of 
creating the "all-frames" sample file used then for the all frames 
renders. Your file size concerns, still a worry, but...

I've not been following the radiosity discussions closely, but there is 
since v3.7 a +HR or High_Reproducibility option. Have you tried this? As 
far as I know, it still works only with radiosity though its initial aim 
was broader.

IIRC, what it does is change the seed to the render block "number" so 
even with multiple threads (SMP) you get the same random numbers (and so 
radiosity ray samples - at least by ordering) in any given block. The 
render image size and render block size would need to stay constant too 
of course.

Another option which obviously helps with reproducibility is running 
with one thread.

Bill P.

[Kenneth] Re: Star Wars - Part 1 [1955 days 1 hour and 9 minutes ago]

Sat, 28 Nov 2020 14:10:08 GMT

Nicely done!

I especially like the smooth and natural banking/turning of the X-Wing as it
pursues its prey. Your coding for that looks very realistic.

[Kenneth] radiosity in animation-- a partial solution to '... [1958 days 20 hours and 4 minutes ago]

Tue, 24 Nov 2020 19:15:03 GMT

Radiosity in animation suffers from a kind of jitter or flicker problem, even
with high-quality settings... a result of the random nature of the rad 'light
patches' from frame to frame. Using a SAVED radiosity file, from an initial
camera viewpoint, would seem to solve that issue, but it's only partially
successful: As the camera moves-- and the scene's objects move as well-- the
saved radiosity file is no longer adequate to produce an expected smooth effect.

I came up with an interesting solution to part of this problem, at least for
POV-ray v3.8xx and maybe 3.7 too, which is more easily explained in an animation
test.

In my test scene, there are no actual light sources; the lighting is from pure
radiosity, from a skydome that has a cloudy-sky photo. I purposely chose BAD
radiosity quality settings to make the effect of the radiosity light patches
more obvious.

settings...
radiosity{
brightness 1.0
count 1
recursion_limit 1
error_bound 0.9
minimum_reuse .0009
maximum_reuse .0117
pretrace_start .08
pretrace_end .01
always_sample off
(all the others at their defaults)
}

The camera just moves from left to right...
location <0 + 5*clock,5,0>

Referring to the animation...
A) This is what typical radiosity light patches do in an animation, from frame
to frame-- completely random patch placement. Of course, this raw look would be
much less obvious with higher-quality rad settings, but it would still be there,
as a sort of minor noisy flicker in the animation.

B) This uses a saved radiosity file, made from a still image at the camera's
starting position. The animated scene's rad settings as kept as they are. As the
camera moves, there are a few extra rad samples created for the objects-- but
the initial 'unseen' parts of the scene require NEW patches, to fill in the
apparenty blank radiosity areas. They are like 'shadow areas' behind objects, as
seen from the initial camera position.

C) This is the same set-up as B, using the same saved rad file, but I changed
radiosity's pretrace_start and pretrace_end to 1.0 in the scene. This prevents
any 'new' rad samples from being created for most of the objects. It's an
improvement, but the 'rad shadows' are still being filled in with new patches.

D) This uses TWO initial saved radiosity files, one made at the camera's start
position and one made at the end (with different file names, of course!). Those
files can be opened and inspected in POV-ray-- they are just text/data files of
some kind-- then I simply copied-and-pasted the complete contents of the 2nd
file onto the end of the 1st file, which is then re-saved. This 'composite' rad
file is then used for the animation. In effect, the two different files, from
two vantage points, have overlapped and filled in the missing radiosity areas
seen in C). Again, pretrace_start and pretrace_end are both changed to 1.0 for
this final animation. There are still a few small areas that are not filled in
by this trick; they could be left as is-- or a *3rd* camera viewpoint could be
chosen to make a 3rd initial saved file...maybe from a vantage point above the
scene. The end result is smooth radiosity lighting during at least most of the
animation.

The only difficulty I see is when lots of objects move in the scene; perhaps
creating even more initial rad files could improve on that somewhat. But the
only way I can see to create a 'perfect' final rad file in such a case would be
to save a new file for every animation frame, then combine them *all* into one
final file! Not very efficient, of course; and the file would be HUGE.

For the entire time that I've been working with POV-ray, I assumed that a saved
radiosity file was a 'global' light map-- that is, creating a full 3-D map of
all areas of the scene, whether seen by the camera or not. That's not the case--
and I see now that such a map would usually be grossly inefficient and a waste
of RAM, for typical still-image renders which have only one camera viewpoint.
There is usually no need for light patches to 'fill in' the unseen parts of a
scene, such as behind opague objects...but animations could make use of such a
concept, if it was possible.

Here's a thought which I haven't tried yet: For a single saved rad file, I could
make all of the objects in the scene temporarily semi-transparent, so that at
least *some* light patches would be created everywhere in the scene. But at this
stage of my experimenting, I don't yet know how radiosity deals with
semi-transpartent objects.

[Alain Martel] Re: Planetary fly-overs with height-fields [1960 days 22 hours and 35 minutes ago]

Sun, 22 Nov 2020 16:44:05 GMT

Le 2020-11-22 Ã  06:02, Mï¿½tes a
Ã©critÂ :
> Hi Yadgar,
> 
> the original pictures are all 8-bit greyscale, and to convert them into 16-bit
> didnt help. I want to ask a co-worker if there are some Gimp-Filters to better
> them, maybe that helps. At them moment there are only 265 steps in height, hope
> that I can smooth them a littlebit.
> 

Converting an 8-bit image to 16-bits can't help. All it can do is append 
8 zeros as low order bits.
You need some more steps to interpolate smoothly between the original steps.

[] Star Wars - Part 1 [1961 days 3 hours and 59 minutes ago]

Sun, 22 Nov 2020 11:20:01 GMT

I was experimenting with some height-fields, as I remembered that I downloaded
years earlier some models from Starwars.
So I combined them with a spline and tried to create a small fight between them.

https://www.youtube.com/watch?v=BDE5s72xvms

Yes, of course, there is much to do.
I have to teach the models shoot-n-crash, the terrain isnt very detailed, the
flight-path is very un-smooth, ... and 1000 other things I have to do.

Nevertheless - I love this small sequence :)

May the force be with you,
Martin

ps:
The original models are from D. M. Beattie / 1997

[] Re: Planetary fly-overs with height-fields [1961 days 4 hours and 14 minutes ago]

Sun, 22 Nov 2020 11:05:00 GMT

Hi Yadgar,

the original pictures are all 8-bit greyscale, and to convert them into 16-bit
didnt help. I want to ask a co-worker if there are some Gimp-Filters to better
them, maybe that helps. At them moment there are only 265 steps in height, hope
that I can smooth them a littlebit.

To get better pics I have to invest many hours of look and search in the
internet, there was no time for this in the past month.

Your movie looks nice, more detailed than mine.
I plan to check out meshes to but didnt start with it.
Do you have a skript as a starting-point for me?

Yes, I am from cologne, you're right.
I have a small personal blog but my website is down at the moment.
Will inform the povray-world when its online again :)

Alaaf,
Mätes

[jr] Re: kspiral [1962 days and 19 minutes ago]

Sat, 21 Nov 2020 15:00:00 GMT

hi,

one more "kaleidoscope", blue-green's the theme.  :-)

<https://drive.google.com/file/d/1x80gko3X6PWZwRt6yj4cDFnnCliBeVYt/view?usp=sharing>

Dick Balaska <dic### [at] buckosoftcom> wrote:
> Math is groovy.

thanks.  (wish I understood what I'm doing..)


enjoy, jr.

[Jörg "Yadgar" Bleimann] Re: Planetary fly-overs with height-fields [1965 days 2 hours and 15 minutes ago]

Wed, 18 Nov 2020 13:03:18 GMT

Hi(gh)!

On 16.11.20 20:23, Mätes wrote:
 > Hi Povrayer,
 >
 > 2018 I worked with real height-data of planets and tried some 
fly-over with help
 > from Povrays height-fields.
 > Here one of the Moon (Mare Imbrium) and two from Mars (Vallis 
Marineris and
 > Olympus Mons).
 >
 > Videos:
 > https://www.youtube.com/watch?v=dw8pX6D5ky0
 > https://www.youtube.com/watch?v=0CAEoP-xg5U
 > https://www.youtube.com/watch?v=HOXpAtFe2mQ

Nicely done... what vertical resolution did you use - 8 or 16 bit? The 
Olympus Mons flyaround shows some "terraced" terrain usually seen with 
8-bit grayscale heightfields...
 > Playlist:
 > https://www.youtube.com/playlist?list=PLyqRFFB9kitzKn_a_-PQa-DMO24SXNE-Z
 >
 > The DEM and the visual maps I downlaoded from the former NASA-Site 
Map-A-Planet
 > (version 1).
 > The resolution isnt the best, due to the former download-limit of 
Map-A-Planet.
 > Also there is some flickering in the movies, partially by switched-off
 > anti-aliasing.

Meanwhile, there should be higher-quality data downloadable... if only 
NASA servers would not be so chaotically structured!

I myself plan to do planetary flyovers with spherical "heightfields", i. 
e. mesh2 reliefs wrapped around a sphere, like this:

https://www.youtube.com/watch?v=PKxHFAlz2Ns&pbjreload=101

Your nickname indicates that you're from Cologne - or at least the 
bordering Ripuarian-speaking regions... am I right?

See you in Khyberspace!

Yadgar

[] Planetary fly-overs with height-fields [1966 days 19 hours and 54 minutes ago]

Mon, 16 Nov 2020 19:25:07 GMT

Hi Povrayer,

2018 I worked with real height-data of planets and tried some fly-over with help
from Povrays height-fields.
Here one of the Moon (Mare Imbrium) and two from Mars (Vallis Marineris and
Olympus Mons).

Videos:
https://www.youtube.com/watch?v=dw8pX6D5ky0
https://www.youtube.com/watch?v=0CAEoP-xg5U
https://www.youtube.com/watch?v=HOXpAtFe2mQ

Playlist:
https://www.youtube.com/playlist?list=PLyqRFFB9kitzKn_a_-PQa-DMO24SXNE-Z

The DEM and the visual maps I downlaoded from the former NASA-Site Map-A-Planet
(version 1).
The resolution isnt the best, due to the former download-limit of Map-A-Planet.
Also there is some flickering in the movies, partially by switched-off
anti-aliasing.

The elevation is exaggerated by a factor 1.5 to 2, I dont know the exact values.

But a nice try I think, I would love to get additional and more detailed maps to
play with.
Unfortunately NASA shuts down the old site and replaced it by a much more
complicated one.

By the way:
This is the sub-board to present movies, right? Or the other animation
sub-board?
Its my 2nd post here, thats why I ask.

Ciao,
Mätes

[jr] Re: kspiral [1967 days 4 hours and 4 minutes ago]

Mon, 16 Nov 2020 11:15:01 GMT

"jr" <cre### [at] gmailcom> wrote:
> I made an animation ...

made another, more "traditional", kaleidoscope animation.  winter colours.  :-)

it's around 235M, so I've included a zip with the necessary files.  to view:
<https://drive.google.com/file/d/11MbupFweiXcic-FcU6sbFvc0YNQ7htDa/view?usp=sharing>


enjoy, jr.

[Dick Balaska] Re: kspiral [1968 days 11 hours and 5 minutes ago]

Sun, 15 Nov 2020 04:13:40 GMT

Am 11/12/20 7:34 PM, also sprach jr:
> hi,

Math is groovy.

-- 
dik
Rendered 50,081,587,200 of 50,081,587,200 pixels (100%)

[jr] Re: kspiral [1969 days 5 hours and 34 minutes ago]

Sat, 14 Nov 2020 09:45:01 GMT

hi,

Alain Martel <kua### [at] videotronca> wrote:
> Le 2020-11-12 à 19:34, jr a écrit :
> > I made an animation ...
>
> Cool. Very Zen.

thanks/merci bien.


regards, jr.

[Alain Martel] Re: kspiral [1970 days 14 hours and 18 minutes ago]

Fri, 13 Nov 2020 01:00:32 GMT

Le 2020-11-12 à 19:34, jr a écrit :
> hi,
> 
> I made an animation "marrying" a spiral shape (derived from Ive's "Golden Ratio"
> code) with a kaleidoscope (based on code found on Mark Newbold's dogfeathers.com
> site), and got lucky.  put on loop.  ;-)  too large to post here, alas.
> 
> <https://drive.google.com/file/d/1dZw-HrERaKuRDjyBQbc14fXDYCNAW14j/view?usp=sharing>
> 
> enjoy, jr.
> 

Cool. Very Zen.

[jr] kspiral [1970 days 14 hours and 44 minutes ago]

Fri, 13 Nov 2020 00:35:00 GMT

hi,

I made an animation "marrying" a spiral shape (derived from Ive's "Golden Ratio"
code) with a kaleidoscope (based on code found on Mark Newbold's dogfeathers.com
site), and got lucky.  put on loop.  ;-)  too large to post here, alas.

<https://drive.google.com/file/d/1dZw-HrERaKuRDjyBQbc14fXDYCNAW14j/view?usp=sharing>

enjoy, jr.

[jr] POTUS [1986 days 16 hours and 34 minutes ago]

Tue, 27 Oct 2020 22:45:03 GMT

hi,

another topical wordplay, for fun.  quality so so, but got it down to about 3M.


enjoy, jr.

[William F Pokorny] Re: Planet animation [2054 days 4 hours and 4 minutes ago]

Fri, 21 Aug 2020 11:14:44 GMT

On 8/20/20 7:46 PM, Bald Eagle wrote:
> 360 frames, 24x24 tiles for each face of the QuadSphere.
> Development version:
> light source indicators, tile numbers, test tile textures, floating image_map,
> etc.
> 
> Hoping to make some more meaningful progress soon.
> 
> Questions, comments, constructive criticism welcome as always.
> 
Cool. Looking good.
Bill P.

[Bald Eagle] Planet animation [2054 days 15 hours and 29 minutes ago]

Thu, 20 Aug 2020 23:50:01 GMT

360 frames, 24x24 tiles for each face of the QuadSphere.
Development version:
light source indicators, tile numbers, test tile textures, floating image_map,
etc.

Hoping to make some more meaningful progress soon.

Questions, comments, constructive criticism welcome as always.

[Leroy] Re: ttbo-bsAniPic [2058 days 21 hours and 29 minutes ago]

Sun, 16 Aug 2020 17:50:01 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 5/20/20 11:29 PM, Dick Balaska wrote:
> > This is something I've wanted to show off for awhile. I just realized I
> > now have the technology thanks to OBS Studio.
> >
> > This is my tool to view the individual frames of an animation I'm
> > working on.Â  What sets bsAniPic apart is its ability to display the
> > POV-Ray debug text along with the image.
> >
> >
> > http://www.buckosoft.com/tteoac/video/testRenders/ttbo-bsAniPic-2020-05-20.mp4
> >
> >
> Really neat! And I was not aware of Open Broadcaster Software. Available
> in 55 languages...
>
> Bill P.

 I wasn't either. I'll have to check it out!

Have Fun!

[Leroy] Re: Simple Wrapped Text [2058 days 21 hours and 39 minutes ago]

Sun, 16 Aug 2020 17:40:00 GMT

"Dave Blandston" <nomail@nomail> wrote:
> Hey there,
>
> This has been done before (more than 20 years ago!)
>
> https://www.youtube.com/watch?v=CGlj0FKLPhw
>
> Kind regards,
> Dave Blandston

 Beautiful!

Have Fun!

[Dave Blandston] Re: GIF tool comparison [2086 days 8 hours and 9 minutes ago]

Mon, 20 Jul 2020 07:10:02 GMT

Hi there, I know this thread is over a year old but I recently needed to make an
animated .GIF. I also did some comparisons and found a combination of tools that
produced excellent results. Here's what I did:

1. Use IrfanView to reduce the images to 256 colors (no dithering, check the
"Use best color quality" box)

2. Use Photoshop to create the animated .GIF.

Using Photoshop to reduce the bit depth of the images produced surprisingly poor
results. I also tried Paint.net. On-line .GIF making utilities were even worse.
My final product is attached for comparison.

IrfanView is also a great tool to compare animated .GIFs because it can play
them magnified.

Mike, if you don't have Photoshop and you'd like to give it a try let me know
and I'll make the .GIF for you.

Have a great day!

Kind regards,
Dave Blandston

[Dave Blandston] Simple Wrapped Text [2086 days 16 hours and 54 minutes ago]

Sun, 19 Jul 2020 22:25:00 GMT

Hey there,

This has been done before (more than 20 years ago!)

https://www.youtube.com/watch?v=CGlj0FKLPhw

Kind regards,
Dave Blandston

[Dave Blandston] Re: My first Povray animation [2086 days 16 hours and 59 minutes ago]

Sun, 19 Jul 2020 22:20:00 GMT

Very impressive - lots of great special effects!

[Dave Blandston] Re: ttbo-bsAniPic [2086 days 17 hours and 9 minutes ago]

Sun, 19 Jul 2020 22:10:00 GMT

Incredible!

[Bald Eagle] Re: le Weekend [2142 days 18 hours and 29 minutes ago]

Sun, 24 May 2020 20:50:09 GMT

> And what has this all to do with raytracing and 3D modeling? POVEarth,
> as it develops in the coming decades, surely will also provide a solid
> geographic background for the virtual rebirth of the hippie trail! Even
> more so as I plan to model the whole thing also in X3D... this would be
> real-time interactive!


[Unity] Procedural Planets (E01 the sphere)
https://www.youtube.com/watch?v=QN39W020LqU

[Jörg "Yadgar" Bleimann] Re: le Weekend [2144 days 14 hours and 33 minutes ago]

Sat, 23 May 2020 00:46:03 GMT

Hi(gh)!

On 19.05.20 08:27, Thomas de Groot wrote:

 >
 > https://en.wikipedia.org/wiki/Hippie_trail ;-)
 >

It all started in 1957 with the Indiaman buses - see 
http://www.indiaman.101answers.com/ - even before Afghanistan officially 
opened its borders for tourists, which was only in 1959! Interestingly, 
otherwise than the "classic" hippie trail, the (initial) route of the 
Indiaman, left out Kurdistan, but instead fully ran though the Near East 
including Jerusalem (which after the Six Days War of 1967 probably was 
no longer feasible)... and they entered Afghanistan not, like 60s/70s 
hippies mostly did, via Islam Qal'a to Herat, but from Quetta via Spin 
Boldak to Kandahar! Back then, the Kandahar-Kabul road was not even 
metalled...

And what has this all to do with raytracing and 3D modeling? POVEarth, 
as it develops in the coming decades, surely will also provide a solid 
geographic background for the virtual rebirth of the hippie trail! Even 
more so as I plan to model the whole thing also in X3D... this would be 
real-time interactive!

See you in Khyberspace!

Yadgar

[William F Pokorny] Re: ttbo-bsAniPic [2146 days 3 hours and 2 minutes ago]

Thu, 21 May 2020 12:16:38 GMT

On 5/20/20 11:29 PM, Dick Balaska wrote:
> This is something I've wanted to show off for awhile. I just realized I 
> now have the technology thanks to OBS Studio.
> 
> This is my tool to view the individual frames of an animation I'm 
> working on.Â  What sets bsAniPic apart is its ability to display the 
> POV-Ray debug text along with the image.
> 
> 
> http://www.buckosoft.com/tteoac/video/testRenders/ttbo-bsAniPic-2020-05-20.mp4 
> 
> 
Really neat! And I was not aware of Open Broadcaster Software. Available 
in 55 languages...

Bill P.

[Dick Balaska] ttbo-bsAniPic [2146 days 11 hours and 49 minutes ago]

Thu, 21 May 2020 03:29:38 GMT

This is something I've wanted to show off for awhile. I just realized I 
now have the technology thanks to OBS Studio.

This is my tool to view the individual frames of an animation I'm 
working on.  What sets bsAniPic apart is its ability to display the 
POV-Ray debug text along with the image.


http://www.buckosoft.com/tteoac/video/testRenders/ttbo-bsAniPic-2020-05-20.mp4

-- 
dik
Rendered 49,882,521,600 of 49,882,521,600 pixels (100%)

[BayashiPascal] Re: My first Povray animation [2147 days 7 hours and 44 minutes ago]

Wed, 20 May 2020 07:35:01 GMT

For a first work it's impressive. I wish "The end" won't be the end at all and
can't wait for the next one. :-)

Pascal



"Thomas" <now### [at] gmailcom> wrote:
> Hi, here the link to the result of my first work using Povray. Maybe it's too
> long (10 minutes, including the credits)...
>
> https://youtu.be/hUvGUomvYiY
>
> It took quite a long time for programming and rendering, but I've learned a lot
> and there a some new ideas already.
>
> Greetings, Thomas

[Thomas] Outtake scene from my first video [2148 days and 34 minutes ago]

Tue, 19 May 2020 14:45:00 GMT

Hi again,
the wrong place for that (?). Anyway, here an image and the code of an outtake I
didn't use. Easy to setup an animation...

Instead of the pendulum in the beginning, I thought about a nixie-clock. I
decided not to use that and I never will for future work. Maybe it's useful for
somebody, so here it is (code and image attached).

The source of the nixie tube I found somewhere, but don't remember where. It was
available as an STL model only, I converted that with freecad into the Povray
format. As far as I know, the STL model is free for non-commercial usage.

Regards, Thomas

[jr] Re: le Weekend [2148 days 5 hours and 59 minutes ago]

Tue, 19 May 2020 09:20:01 GMT

hi,

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 18/05/2020 om 21:49 schreef jr:
> > Yadgar wrote:
> >> ...waiting for the bus to Kabul!
> > ...
> > Berlin to Kabul, five or six weeks overland by bus.  (guessing the cost was
> > little more than the petrol money)
>
> https://en.wikipedia.org/wiki/Hippie_trail ;-)

thanks, had not thought of/remembered that phrase.  (imo, Wikipedia is one of
very few examples of the interweb not having gone wrong)

regards, jr.

[Thomas de Groot] Re: le Weekend [2148 days 8 hours and 51 minutes ago]

Tue, 19 May 2020 06:27:47 GMT

Op 18/05/2020 om 21:49 schreef jr:
> hi,
> 
> Yadgar wrote:
>> High!
>>
>> On 16.05.20 00:47, jr wrote:
>>> hi,
>>>
>>> weekend lockdown "advice".  :-)   (loop)
>>
>> Kiff...kiff...kiff...kiff...kiff...kiff...kiff...kiff...kiff...kiff...kiff...
>>
>> ...waiting for the bus to Kabul!
> 
> :-)
> 
> in the late 70s, in West-Berlin, there was (still) talk of just such a service.
> Berlin to Kabul, five or six weeks overland by bus.  (guessing the cost was
> little more than the petrol money)
> 
> 
> regards, jr.
> 


https://en.wikipedia.org/wiki/Hippie_trail ;-)

-- 
Thomas

[jr] Re: le Weekend [2148 days 19 hours and 24 minutes ago]

Mon, 18 May 2020 19:55:00 GMT

hi,

Yadgar wrote:
> High!
>
> On 16.05.20 00:47, jr wrote:
> > hi,
> >
> > weekend lockdown "advice".  :-)   (loop)
>
> Kiff...kiff...kiff...kiff...kiff...kiff...kiff...kiff...kiff...kiff...kiff...
>
> ...waiting for the bus to Kabul!

:-)

in the late 70s, in West-Berlin, there was (still) talk of just such a service.
Berlin to Kabul, five or six weeks overland by bus.  (guessing the cost was
little more than the petrol money)

regards, jr.

[Jörg "Yadgar" Bleimann] Re: le Weekend [2148 days 21 hours and 16 minutes ago]

Mon, 18 May 2020 18:02:54 GMT

Hi(gh)!

On 17.05.20 09:38, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> On 5/15/20 6:47 PM, jr wrote:
>>> weekend lockdown "advice".  :-)   (loop)
>>>
>> Cool. :-)
> 
> thanks.  fyi, the scene code crashes ("segfault") alpha.10064268 on one machine,
> but not on another; the only difference being, afaict, the optimisation flags
> provided in the package build scripts.  using "-march=core2" works (gcc 4.8.2),
> using "-march=haswell" crashes (gcc 5.5.0).  :-)

POVing under the influence? I'm not so sure...

See you in Khyberspace!

Yadgar

[Jörg "Yadgar" Bleimann] Re: le Weekend [2148 days 21 hours and 18 minutes ago]

Mon, 18 May 2020 18:00:39 GMT

High!

On 16.05.20 00:47, jr wrote:
> hi,
> 
> weekend lockdown "advice".  :-)   (loop)

Kiff...kiff...kiff...kiff...kiff...kiff...kiff...kiff...kiff...kiff...kiff...

...waiting for the bus to Kabul!

See you in Khyberspace!

Yadgar

[Thomas de Groot] Re: My first Povray animation [2149 days 8 hours and 45 minutes ago]

Mon, 18 May 2020 06:33:30 GMT

Op 17/05/2020 om 11:45 schreef Thomas:
> Hi, here the link to the result of my first work using Povray. Maybe it's too
> long (10 minutes, including the credits)...
> 
> https://youtu.be/hUvGUomvYiY
> 
> It took quite a long time for programming and rendering, but I've learned a lot
> and there a some new ideas already.
> 
> Greetings, Thomas
> 

Very well done, especially as a first work. I am truly impressed indeed.

-- 
Thomas

[Thomas] Re: My first Povray animation [2149 days 22 hours and 4 minutes ago]

Sun, 17 May 2020 17:15:02 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "Thomas" <now### [at] gmailcom> wrote:
> > Hi, here the link to the result of my first work using Povray. Maybe it's too
> > long (10 minutes, including the credits)...
> >
> > https://youtu.be/hUvGUomvYiY
> >
> > It took quite a long time for programming and rendering, but I've learned a lot
> > and there a some new ideas already.
> >
> > Greetings, Thomas
>
> labour of love, nice.  shades of "2001".  :-)
>
>
> regards, jr.

Thanks! Yes, 2001 - see the credits...

regards, Thomas

[Thomas] Re: My first Povray animation [2149 days 22 hours and 4 minutes ago]

Sun, 17 May 2020 17:15:01 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Thomas" <now### [at] gmailcom> wrote:
> > Hi, here the link to the result of my first work using Povray. Maybe it's too
> > long (10 minutes, including the credits)...
>
> > Greetings, Thomas
>
> :O
>
> Buddy - if _that_ is your first animation, then I can hardly wait to see the
> second.
>
> I saw (or imagined ;) ) influence and inspiration from Clarke & Kubrick, the
> team of Jos Leys, Étienne Ghys, and Aurélien Alvarez, James Gleick, Lucas,
> Tolkien, and the work of many POV-Ray users over the years.
>
> I now know about "Arrival" and will have to watch it.   Thanks for that   :)
>
> Excellent work.
> Welcome.
> Looking forward to --- More.  ;)
>
>
> - Bill

Yes, that is really the first one...

It took me a year or so, with a lot of retries and plenty of scenes not used. Of
course I started with examples from Povray users, first I had to figure out how
that works. Later, the manual was more helpful than examples, and for some
problems I wasn't able to solve in Povray, I used the Pre_Frame_Command with
other software (R and python). The liquid simulation was completely offline, but
as Paraview has an option to create Povray code, the integration into a scene
file was not so hard.

You are right, Clarke and Kubrick are mentioned in the credits section...

Maybe that R2D2 will have an appearance in the next video, but a realistic model
will take some time.

Thanks! More will come, but don't ask me when...

regards, Thomas

[Mr] Re: My first Povray animation [2150 days and 44 minutes ago]

Sun, 17 May 2020 14:35:00 GMT

"Thomas" <now### [at] gmailcom> wrote:
> Hi, here the link to the result of my first work using Povray. Maybe it's too
> long (10 minutes, including the credits)...
>
> https://youtu.be/hUvGUomvYiY
>
> It took quite a long time for programming and rendering, but I've learned a lot
> and there a some new ideas already.
>
> Greetings, Thomas

That's an encouraging start!

[Bald Eagle] Re: My first Povray animation [2150 days 2 hours and 59 minutes ago]

Sun, 17 May 2020 12:20:00 GMT

"Thomas" <now### [at] gmailcom> wrote:
> Hi, here the link to the result of my first work using Povray. Maybe it's too
> long (10 minutes, including the credits)...

> Greetings, Thomas

:O

Buddy - if _that_ is your first animation, then I can hardly wait to see the
second.

I saw (or imagined ;) ) influence and inspiration from Clarke & Kubrick, the
team of Jos Leys, Étienne Ghys, and Aurélien Alvarez, James Gleick, Lucas,
Tolkien, and the work of many POV-Ray users over the years.

I now know about "Arrival" and will have to watch it.   Thanks for that   :)

Excellent work.
Welcome.
Looking forward to --- More.  ;)

- Bill

[jr] Re: My first Povray animation [2150 days 4 hours and 44 minutes ago]

Sun, 17 May 2020 10:35:01 GMT

hi,

"Thomas" <now### [at] gmailcom> wrote:
> Hi, here the link to the result of my first work using Povray. Maybe it's too
> long (10 minutes, including the credits)...
>
> https://youtu.be/hUvGUomvYiY
>
> It took quite a long time for programming and rendering, but I've learned a lot
> and there a some new ideas already.
>
> Greetings, Thomas

labour of love, nice.  shades of "2001".  :-)


regards, jr.

[jr] Re: le Weekend [2150 days 4 hours and 44 minutes ago]

Sun, 17 May 2020 10:35:01 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> In short, wondering if the hard coded architecture the problem?

very likely, although, as often, it's unclear whether "the fault" lies with the
compiler or the source.  guessing that some code (in spline, or text object) is
vulnerable wrt optimisation(s).  I will rebuild the alpha with 'core2' options,
sometime in the next few days; I expect the scene code will work then.

regards, jr.

[Thomas] My first Povray animation [2150 days 5 hours and 29 minutes ago]

Sun, 17 May 2020 09:50:00 GMT

Hi, here the link to the result of my first work using Povray. Maybe it's too
long (10 minutes, including the credits)...

https://youtu.be/hUvGUomvYiY

It took quite a long time for programming and rendering, but I've learned a lot
and there a some new ideas already.

Greetings, Thomas

[William F Pokorny] Re: le Weekend [2150 days 5 hours and 48 minutes ago]

Sun, 17 May 2020 09:30:31 GMT

On 5/17/20 4:43 AM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> On 5/17/20 3:38 AM, jr wrote:
>>> fyi, the scene code crashes ("segfault") alpha.10064268 on one machine,
>>> but not on another; ...
>>
>> IIRC, the build scripts end up with -march=native by default. Are you
>> offering us the compilers 'native' translation or did you specify those
>> architectures specifically on the two machines?
> 
> explicit spec.  Slackware package build scripts have a variable used to
> set/append CFLAGS etc, I used the 'haswell' in both '-march' and '-mtune'.
> 

OK. This leads me to wonder what more, or less, these spawn than 
'native' given the compilers should do the right things with native for 
an optimized compile on the local machine.

In short, wondering if the hard coded architecture the problem?

Bill P.

[jr] Re: le Weekend [2150 days 6 hours and 34 minutes ago]

Sun, 17 May 2020 08:45:01 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 5/17/20 3:38 AM, jr wrote:
> > fyi, the scene code crashes ("segfault") alpha.10064268 on one machine,
> > but not on another; ...
>
> IIRC, the build scripts end up with -march=native by default. Are you
> offering us the compilers 'native' translation or did you specify those
> architectures specifically on the two machines?

explicit spec.  Slackware package build scripts have a variable used to
set/append CFLAGS etc, I used the 'haswell' in both '-march' and '-mtune'.


regards, jr.

[William F Pokorny] Re: le Weekend [2150 days 7 hours and 9 minutes ago]

Sun, 17 May 2020 08:09:21 GMT

On 5/17/20 3:38 AM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> On 5/15/20 6:47 PM, jr wrote:
>>> weekend lockdown "advice".  :-)   (loop)
>>>
>> Cool. :-)
> 
> thanks.  fyi, the scene code crashes ("segfault") alpha.10064268 on one machine,
> but not on another; the only difference being, afaict, the optimisation flags
> provided in the package build scripts.  using "-march=core2" works (gcc 4.8.2),
> using "-march=haswell" crashes (gcc 5.5.0).  :-)
> 

IIRC, the build scripts end up with -march=native by default. Are you 
offering us the compilers 'native' translation or did you specify those 
architectures specifically on the two machines?

Bill P.

[jr] Re: le Weekend [2150 days 7 hours and 39 minutes ago]

Sun, 17 May 2020 07:40:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 5/15/20 6:47 PM, jr wrote:
> > weekend lockdown "advice".  :-)   (loop)
> >
> Cool. :-)

thanks.  fyi, the scene code crashes ("segfault") alpha.10064268 on one machine,
but not on another; the only difference being, afaict, the optimisation flags
provided in the package build scripts.  using "-march=core2" works (gcc 4.8.2),
using "-march=haswell" crashes (gcc 5.5.0).  :-)

Dick Balaska <dic### [at] buckosoftcom> wrote:
> I have to wait until the weekend?

_you_ will have to wait 'til Wednesday!  :-)

regards, jr.

[Dick Balaska] Re: le Weekend [2150 days 21 hours and 53 minutes ago]

Sat, 16 May 2020 17:25:34 GMT

Am 5/15/20 6:47 PM, also sprach jr:
> hi,
> 
> weekend lockdown "advice".  :-)   (loop)
> 
> 
> enjoy, jr.
> 

I have to wait until the weekend?

-- 
dik
Rendered 49,882,521,600 of 49,882,521,600 pixels (100%)

[William F Pokorny] Re: le Weekend [2151 days 1 hour and 9 minutes ago]

Sat, 16 May 2020 14:09:54 GMT

On 5/15/20 6:47 PM, jr wrote:
> hi,
> 
> weekend lockdown "advice".  :-)   (loop)
> 
> 
> enjoy, jr.
> 
Cool. :-)

Bill P.

[jr] le Weekend [2151 days 16 hours and 29 minutes ago]

Fri, 15 May 2020 22:50:00 GMT

hi,

weekend lockdown "advice".  :-)   (loop)


enjoy, jr.

[jr] Re: SARS-CoV-2 [2210 days 22 hours and 54 minutes ago]

Tue, 17 Mar 2020 16:25:01 GMT

hi,

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 16/03/2020 om 23:16 schreef jr:
> > topical wordplay.
>
> LOL! ...

perfect  :-)  thanks.


regards, jr.

[Thomas de Groot] Re: SARS-CoV-2 [2211 days 7 hours and 50 minutes ago]

Tue, 17 Mar 2020 07:28:55 GMT

Op 16/03/2020 om 23:16 schreef jr:
> hi,
> 
> topical wordplay.
> 
> 
> enjoy, jr.
> 
> 
> NB. much (most!) credit goes to Bald Eagle, for supplying elegant maths and
> hands-on help resolving "issues".
> 

LOL! Now to make them autophagous and all our troubles are gone. ;-)

-- 
Thomas

[jr] SARS-CoV-2 [2211 days 16 hours and 59 minutes ago]

Mon, 16 Mar 2020 22:20:02 GMT

hi,

topical wordplay.


enjoy, jr.


NB. much (most!) credit goes to Bald Eagle, for supplying elegant maths and
hands-on help resolving "issues".

[Dick Balaska] Re: Absolutely relative woes [2232 days 11 hours and 34 minutes ago]

Tue, 25 Feb 2020 03:44:49 GMT

Am 2/24/20 5:05 PM, also sprach Dick Balaska:
> 
> I see a matrix multiplication difference (there are two different 
> multiplies and I used one).
> 
> I can't believe I never saw this before.
> 

This was cool.  I set a breakpoint in my SDL debugger just before the 
vrotate.  Once that hit, I set a breakpoint in the POV-Ray c++.
I then stepped through the vrotate while at the same time stepping 
through my library.  Lo, I got the exact same results.

I'm in agony.

When I first saw this phenomenon, I said "interesting, the vector looks 
correct, just the wrong length.  But I'm not doing any vlength work so 
that's just a coincidence."  Wrong!  I scaled the Tugboat by 0.7 so he'd 
fit in the tub better.  I need a drink.


-- 
dik
Rendered 49,882,521,600 of 49,882,521,600 pixels (100%)

[Dick Balaska] Re: Absolutely relative woes [2232 days 17 hours and 14 minutes ago]

Mon, 24 Feb 2020 22:05:07 GMT

Am 2/23/20 10:16 PM, also sprach Bald Eagle:
> Dick Balaska <dic### [at] buckosoftcom> wrote:
> 
>> I don't know what I'm doing wrong.
> 
> I can't really see it either, but maybe just do a simple scene with spheres 
> ...
> and see if anything jumps out.
> 

Ugh.  What jumps out is ... I told a half truth.  When I perform the 
calcs in actual SDL it works as expected.  When I do it in my c++ 
library, that I ported from my Java library, that I ripped from the 
POV-Ray source (core/math/matrix.cpp), that I've used for years, I get 
the wrong answer.

Comparing the logic flow of my
void Vector::rotateDegrees(const Vector& rot){}
with POV-Ray's
void Compute_Rotation_Transform (TRANSFORM *transform, const Vector3d& 
vector)

I see a matrix multiplication difference (there are two different 
multiplies and I used one).

I can't believe I never saw this before.

-- 
dik
Rendered 49,882,521,600 of 49,882,521,600 pixels (100%)

[Bald Eagle] Re: Absolutely relative woes [2233 days 11 hours and 59 minutes ago]

Mon, 24 Feb 2020 03:20:00 GMT

Dick Balaska <dic### [at] buckosoftcom> wrote:

> I don't know what I'm doing wrong.

I can't really see it either, but maybe just do a simple scene with spheres and
a for loop tracing out the rotation.

compare it to things like

CrewOnBoatVec=vrotate(TugVec-CrewVec, y*-TugRot.y)
                      ^^^^^^^^^^^^^^

and see if anything jumps out.

[Dick Balaska] Absolutely relative woes [2233 days 14 hours and 8 minutes ago]

Mon, 24 Feb 2020 01:10:18 GMT

This has me stumped.  In these two images, I would expect the greenish 
crewman in the water to be in the exact same position.
ttbo1392 crewman is an absolute vector
ttbo1393 crewman is relative to tugboat.

The scenario is, crewman is drifting in the bathtub and gets rescued by 
the Tug.  So his vector starts out absolute and the moment the rescue 
starts, he becomes part of the tugboat object.

TugVec =<700.50, 144.50, 215.50> Rot=<4.04, 155.00, 1.73>
CrewVec=<697.50, 143.92, 217.00>

So, CrewOnBoatVec=vrotate(CrewVec-TugVec, y*-TugRot.y)

which gives me
CrewOnBoatVec=<2.08, 0.00, -2.63>
close, but no cigar.
Ignore the y component. That gets handled special. It's the x,z that's 
the issue.

If I unwind it,
vrotate(CrewOnBoatVec, y*TugRot.y)+TugVec
I get back the original absolute CrewVec, but that just verifies the 
math works, but it's still wrong.

I don't know what I'm doing wrong.
-- 
dik
Rendered 49,882,521,600 of 49,882,521,600 pixels (100%)

[jr] Re: mandelbulb [2279 days 2 hours and 4 minutes ago]

Thu, 9 Jan 2020 13:15:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> on Dec 5th Chris Thomasson posted some code in comp.lang.c to render a set of
> images forming an "Experimental Power Stack Mandelbulb".  ...

also posted a strangely beguiling animation of (related) code:
<https://www.youtube.com/watch?v=XpbPzrSXOgk>


enjoy, jr.

[jr] Re: mandelbulb [2302 days 13 hours and 24 minutes ago]

Tue, 17 Dec 2019 01:55:00 GMT

hi,

Dick Balaska <dic### [at] buckosoftcom> wrote:
> Am 12/16/19 7:54 PM, also sprach jr:
> >    ppmtogif -nolzw ct_anime_$(printf %03d $i).ppm |
> >    giftopnm |
> >    pnmtopng > frm_$(printf %03d $i).png;
>
> Why do you convert to gif first?  pnmtopng will read any of the netpbm
> formats.

heh, ignorance?  made me read the man page again, to be fair, it does say "reads
a portable pixmap" in the first sentence. :-)  and, re-reading, I see there's an
option to include a text chunk.  thanks!

regards, jr.

[Dick Balaska] Re: mandelbulb [2302 days 13 hours and 48 minutes ago]

Tue, 17 Dec 2019 01:31:01 GMT

Am 12/16/19 7:54 PM, also sprach jr:
> # mkdf3-sh
> for i in $(seq 0 255)
> do
>    ppmtogif -nolzw ct_anime_$(printf %03d $i).ppm |
>    giftopnm |
>    pnmtopng > frm_$(printf %03d $i).png;
>    sync
> done

Why do you convert to gif first?  pnmtopng will read any of the netpbm 
formats.


-- 
dik
Rendered 49,882,521,600 of 49,882,521,600 pixels (100%)

[jr] Re: mandelbulb [2302 days 14 hours and 19 minutes ago]

Tue, 17 Dec 2019 01:00:01 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > can post the code used if you want to take a gander.
>
> Is it like an adjustable mandelbulb thing where the result can be animated, or
> does it just make a single DF3?

a c program which outputs 256 frames/images.

there's not much by way of parameters, <x,y,z> dims and iteration count, I've
attached a source which is formatted (and slightly modified from the original),
compile with:

  $ cc -std=c99 ct.c -lm

the author recommends doubling the resolution.


> I can take a look at the DF3, and maybe
> someone can suggest a texture / uv map to use.

the df3 is 256^3, build your own?!  :-)

fwiw, this is the BASH to do it:

# mkdf3-sh
for i in $(seq 0 255)
do
  ppmtogif -nolzw ct_anime_$(printf %03d $i).ppm |
  giftopnm |
  pnmtopng > frm_$(printf %03d $i).png;
  sync
done

df3util create 256,256,256 1 ctdata  && sync

for i in $(seq 0 255)
do
  df3util -w import ctdata y:$i frm_$(printf %03d $i).png
done


> I would imagine a proximity
> pattern would be the closest to what people do with raymarching / signed
> distance functions.

I'd be interested in the program writing more than just a single value
("colour"), but haven't the maths to divine where to .. interfere.



> It looks like the bad guy in a cheesy action movie.
> "Pink Ranger, I am your father!"
> --
> dik
> Rendered 49,882,521,600 of 49,882,521,600 pixels (100%)

</grin>  (although the reference is straight over my head)


regards, jr.

[Dick Balaska] Re: mandelbulb [2302 days 15 hours and 17 minutes ago]

Tue, 17 Dec 2019 00:01:16 GMT

Am 12/16/19 9:55 AM, also sprach jr:
> hi,
> 
> on Dec 5th Chris Thomasson posted some code in comp.lang.c to render a set of
> images forming an "Experimental Power Stack Mandelbulb".  converted and imported
> those into a df3, and rendered a view revolving around Y.
> 
> 
> enjoy, jr.
> 

It looks like the bad guy in a cheesy action movie.

"Pink Ranger, I am your father!"


-- 
dik
Rendered 49,882,521,600 of 49,882,521,600 pixels (100%)

[Bald Eagle] Re: mandelbulb [2302 days 15 hours and 34 minutes ago]

Mon, 16 Dec 2019 23:45:00 GMT

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

> can post the code used if you want to take a gander.

Is it like an adjustable mandelbulb thing where the result can be animated, or
does it just make a single DF3?   I can take a look at the DF3, and maybe
someone can suggest a texture / uv map to use.   I would imagine a proximity
pattern would be the closest to what people do with raymarching / signed
distance functions.

[jr] Re: mandelbulb [2302 days 19 hours and 19 minutes ago]

Mon, 16 Dec 2019 20:00:07 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> > converted and imported those into a df3,
> I'll bet that would look cool as an isosurface

can post the code used if you want to take a gander.


regards, jr.

[Bald Eagle] Re: mandelbulb [2302 days 20 hours and 49 minutes ago]

Mon, 16 Dec 2019 18:30:01 GMT

> converted and imported those into a df3,

I'll bet that would look cool as an isosurface

[jr] mandelbulb [2303 days and 19 minutes ago]

Mon, 16 Dec 2019 15:00:02 GMT

hi,

on Dec 5th Chris Thomasson posted some code in comp.lang.c to render a set of
images forming an "Experimental Power Stack Mandelbulb".  converted and imported
those into a df3, and rendered a view revolving around Y.


enjoy, jr.

[jr] Re: sink+flip [2340 days 3 hours and 19 minutes ago]

Sat, 9 Nov 2019 12:00:00 GMT

hi,

Dick Balaska <dic### [at] buckosoftcom> wrote:
> ...
> Did you post this before?  It looks very familiar.

no, don't think so.  you saw an earlier version in an email exchange (where you
advocated zooming out + displaying .. patterns on the flaps' reverse).


regards, jr.

[Dick Balaska] Re: sink+flip [2340 days 12 hours and 24 minutes ago]

Sat, 9 Nov 2019 02:54:17 GMT

On 11/8/19 6:02 PM, jr wrote:
> hi,
> 
> a while ago I made a simple animation which, imo, works well with music.
> Norbert Kern's cool image (posted today) brought it back to mind.  posting a
> link since it's a little over 7M.
> 
> <https://drive.google.com/file/d/1T_7HsUYTCwiwitbc_yNMr3aXJvcqYnA2/view?usp=sharing>
> 
> 
> enjoy, jr.
> 

Did you post this before?  It looks very familiar.

-- 
dik
Rendered 22,859,366,400 of 40,928,716,800 pixels (55%)

[jr] sink+flip [2340 days 16 hours and 14 minutes ago]

Fri, 8 Nov 2019 23:05:01 GMT

hi,

a while ago I made a simple animation which, imo, works well with music.
Norbert Kern's cool image (posted today) brought it back to mind.  posting a
link since it's a little over 7M.

<https://drive.google.com/file/d/1T_7HsUYTCwiwitbc_yNMr3aXJvcqYnA2/view?usp=sharing>


enjoy, jr.

[jr] Re: ttso2393/cute [2353 days and 14 minutes ago]

Sun, 27 Oct 2019 15:05:00 GMT

hi,

Dick Balaska <dic### [at] buckosoftcom> wrote:
> On 10/26/19 4:36 PM, jr wrote:
> > blame the posting of this mp4 on the silhouette of DB's 'ttso2393', plus his use
> > of the word "cute".
>
> This actually makes me nauseated.

oh dear, dire.

> I think it is because the blurriness
> timing is different between the top and bottom halves.

if that is your main .. issue with the anim, and if you have a VR browser
installed, I can post a VRML equivalent.


regards, jr.

[Dick Balaska] Re: ttso2393/cute [2353 days 3 hours and 20 minutes ago]

Sun, 27 Oct 2019 11:58:28 GMT

On 10/26/19 4:36 PM, jr wrote:
> hi,
> 
> 
> blame the posting of this mp4 on the silhouette of DB's 'ttso2393', plus his use
> of the word "cute".
> 

This actually makes me nauseated.  I think it is because the blurriness 
timing is different between the top and bottom halves.

-- 
dik
Rendered 18,243,532,800 of 40,928,716,800 pixels (40%)

[jr] ttso2393/cute [2353 days 18 hours and 39 minutes ago]

Sat, 26 Oct 2019 20:40:07 GMT

hi,


blame the posting of this mp4 on the silhouette of DB's 'ttso2393', plus his use
of the word "cute".

:-)


regards, jr.

[Subclick] Re: A test. Testing Re [2397 days 19 hours and 55 minutes ago]

Thu, 12 Sep 2019 19:24:05 GMT

Well, I took a bit longer than expected to have everything set up again
and come back.  The least I can do is to bring a more elaborate
umbrella, with a higher diffuse value.

About two years ago, Hugo R. Giulietti <hug### [at] gmailcom> wrote:

> The umbrella have too low diffuse value

This has a diffuse value higher than 1.  Stimulated emission has never
been a problem for POV-Ray as far as I know.

[jr] Re: Android in fancy dress [2414 days 15 hours and 34 minutes ago]

Mon, 26 Aug 2019 23:45:01 GMT

hi,

dick balaska <dic### [at] buckosoftcom> wrote:
> That is *some* texture!

cheers.  "serendipity" (or a rotation gone wtong) :-)


regards, jr.

[dick balaska] Re: Android in fancy dress [2415 days 12 hours and 49 minutes ago]

Mon, 26 Aug 2019 02:29:24 GMT

On 8/25/19 6:53 AM, jr wrote:
> hi,
> 
> party time.  and Android (thanks Cousin Ricky) is all dressed up, ready to go.
> 
> :-)
> 
> 
> regards, jr.
> 

That is *some* texture!

-- 
dik
Rendered 1024 of 921600 pixels (0%)

[jr] Android in fancy dress [2416 days 4 hours and 24 minutes ago]

Sun, 25 Aug 2019 10:55:03 GMT

hi,

party time.  and Android (thanks Cousin Ricky) is all dressed up, ready to go.

:-)


regards, jr.

[Thomas de Groot] Re: Steam engine animation [2450 days 8 hours and 53 minutes ago]

Mon, 22 Jul 2019 06:25:36 GMT

Op 21-7-2019 om 23:58 schreef Mike Horvath:
> On 7/21/2019 5:56 PM, Mike Horvath wrote:
>> I wish they had high res renders/photos. I mean, if you want people to 
>> donate to the fund.
>>
>>
>> Michael
> 
> Also, I'm guessing this thing will produce some carbon emissions. Derp.
> 

I had been thinking that too. It is not the most ambient-friendly 
project I know of, although everything probably concentrates on the 
building rather than on the running of the engine afterwards, at least 
for the time being...

-- 
Thomas

[Mike Horvath] Re: Steam engine animation [2450 days 17 hours and 20 minutes ago]

Sun, 21 Jul 2019 21:58:48 GMT

On 7/21/2019 5:56 PM, Mike Horvath wrote:
> I wish they had high res renders/photos. I mean, if you want people to 
> donate to the fund.
> 
> 
> Michael

Also, I'm guessing this thing will produce some carbon emissions. Derp.


Michael

[Mike Horvath] Re: Steam engine animation [2450 days 17 hours and 23 minutes ago]

Sun, 21 Jul 2019 21:56:11 GMT

On 7/20/2019 7:57 PM, Ton wrote:
>> Working smoothly!
> 
> Thanks Thomas
> 
>> Well, it shows!  :)
>> Your camera work - the acceleration, motion, and fades is excellent.
>> Really very professional looking - I like your choice of background and setting.
>>
>> This just came up in my news feed - maybe you'd find it interesting, if only to
>> look over casually.
>>
>> https://prrt1steamlocomotivetrust.org/station/
>>
>> Keep up the good work!
> 
> Thanks Mr. Eagle
> That locomotive might be an interesting for Povray. What a beast!
> 
> Cheers
> Ton
> 
> 

I wish they had high res renders/photos. I mean, if you want people to 
donate to the fund.


Michael

[Ton] Re: Steam engine animation [2451 days 15 hours and 19 minutes ago]

Sun, 21 Jul 2019 00:00:01 GMT

> Working smoothly!

Thanks Thomas

> Well, it shows!  :)
> Your camera work - the acceleration, motion, and fades is excellent.
> Really very professional looking - I like your choice of background and setting.
>
> This just came up in my news feed - maybe you'd find it interesting, if only to
> look over casually.
>
> https://prrt1steamlocomotivetrust.org/station/
>
> Keep up the good work!

Thanks Mr. Eagle
That locomotive might be an interesting for Povray. What a beast!

Cheers
Ton

[Bald Eagle] Re: Steam engine animation [2452 days 13 hours and 29 minutes ago]

Sat, 20 Jul 2019 01:50:00 GMT

"Ton" <ton### [at] gmailcom> wrote:

> the last couple of weeks I've been working on this little animation.

Well, it shows!  :)
Your camera work - the acceleration, motion, and fades is excellent.
Really very professional looking - I like your choice of background and setting.

This just came up in my news feed - maybe you'd find it interesting, if only to
look over casually.

https://prrt1steamlocomotivetrust.org/station/

Keep up the good work!

[Thomas de Groot] Re: Steam engine animation [2453 days 8 hours and 48 minutes ago]

Fri, 19 Jul 2019 06:31:05 GMT

Op 18-7-2019 om 05:53 schreef Ton:
> Hi everybody
> 
> the last couple of weeks I've been working on this little animation.
> A "working" triple cylinder oscillating steam engine.
> The background is from Greg Zaal HDRI Haven.
> 
> https://youtu.be/kc_MOXAHquo
> 
> Enjoy
> Ton.
> 
> 

Working smoothly!

-- 
Thomas

[Ton] Steam engine animation [2454 days 11 hours and 24 minutes ago]

Thu, 18 Jul 2019 03:55:00 GMT

Hi everybody

the last couple of weeks I've been working on this little animation.
A "working" triple cylinder oscillating steam engine.
The background is from Greg Zaal HDRI Haven.

https://youtu.be/kc_MOXAHquo

Enjoy
Ton.

[Jörg "Yadgar" Bleimann] Re: Clive Barker's Hellraiser box [2468 days 17 hours and 34 minutes ago]

Wed, 3 Jul 2019 21:45:11 GMT

Hi(gh)!

On 13.06.19 02:05, Bald Eagle wrote:
> I could have sworn I had posted this ages ago...

Probably not... I would have noticed it!

> Anyway, here's an old experiment with animating a BOX, with sound effects.

Neat!

See you in Khyberspace!

Yadgar

Now playing: Men Before The Mirror (Mark Isham)

[Hj Malthaner] Re: Clive Barker's Hellraiser box [2489 days 14 hours and 11 minutes ago]

Thu, 13 Jun 2019 01:07:25 GMT

On 6/13/19 2:05 AM, Bald Eagle wrote:
> I could have sworn I had posted this ages ago...
> 
> Anyway, here's an old experiment with animating a BOX, with sound effects.

Nice one! Needs more mystic lighting if you can be bothered to do that!
I like the sound effects.

-- 
Some of my PovRay works:
https://www.deviantart.com/antarasol/gallery/42758766/3D

[Bald Eagle] Clive Barker's Hellraiser box [2489 days 15 hours and 9 minutes ago]

Thu, 13 Jun 2019 00:10:02 GMT

I could have sworn I had posted this ages ago...

Anyway, here's an old experiment with animating a BOX, with sound effects.

[jr] Re: =3D?UTF-8?Q?Sierpi=3Dc5=3D84ski_tests_=3D28a... [2502 days 3 hours and 39 minutes ago]

Fri, 31 May 2019 11:40:01 GMT

hi,

Mike Horvath <mik### [at] gmailcom> wrote:
> Which of these do you like best? ...

fwiw, I prefer 'aa', and think the shadows are fine.  :-)


regards, jr.

[Mike Horvath] --- [2502 days 14 hours and 8 minutes ago]

Fri, 31 May 2019 01:10:16 GMT

Also, ignore the artifacts in the GIFs. I used the wrong settings when 
creating them.


Michael

[Mike Horvath] --- [2502 days 14 hours and 14 minutes ago]

Fri, 31 May 2019 01:04:16 GMT

Which of these do you like best? I am frustrated because in both cases 
it's hard to see what's going on. Everything is so busy and just kind of 
blends into its neighbor. The shadows are also not very dark.

Source code is at github:

https://github.com/mjhorvath/mike_illustrations

In the "mike_illustrations\Math\FractalObjects" folder.


Michael

[Mike Horvath] Re: GIF tool comparison [2581 days 6 hours and 5 minutes ago]

Wed, 13 Mar 2019 09:14:03 GMT

On 3/9/2019 9:32 AM, Bald Eagle wrote:
> Mike, have you tried IrfanView for conversion?
> How about Paint.Net?
> 
> 
> 
> 
> 

I don't have IrfanView installed, and Paint.net apparently requires a 
plugin to do animations. (I tried without the plugin and it only 
recognized the first frame.)


Mike

[Bald Eagle] Re: GIF tool comparison [2585 days and 44 minutes ago]

Sat, 9 Mar 2019 14:35:01 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:

> Be aware though that Windows 7 is almost finished: January 2020. Is it
> worth the while? Better to make the effort for Widows 10, I guess...

I hated 8 and 8.1.   Not ever doing 10 if I can help it.
Really trying to transition over to Linux and open-source, non-proprietary
software.

Too much lying, spying, stealing, unwanted/unneeded auto-updates, data-mining,
etc.

Mike, have you tried IrfanView for conversion?
How about Paint.Net?

[Thomas de Groot] Re: GIF tool comparison [2585 days 7 hours and 47 minutes ago]

Sat, 9 Mar 2019 07:31:56 GMT

On 8-3-2019 19:55, JÃ¶rg "Yadgar" Bleimann wrote:
> Hi(gh)!
> 
> On 07.03.19 08:38, Mike Horvath wrote:
> 
>> I use mostly Windows 7 but also Windows 10 depending.
>>
>>
>> Mike
> 
> That's fine! I will install DEV-CPP on my Windows 7 and compile yip for 
> you! But be aware that its development is far from finished, and even 
> some of the already implemented features are not fully functional yet!
> 

Be aware though that Windows 7 is almost finished: January 2020. Is it 
worth the while? Better to make the effort for Widows 10, I guess...

-- 
Thomas

[Jörg "Yadgar" Bleimann] Re: GIF tool comparison [2585 days 20 hours and 26 minutes ago]

Fri, 8 Mar 2019 18:52:33 GMT

Hi(gh)!

On 07.03.19 08:38, Mike Horvath wrote:

> I use mostly Windows 7 but also Windows 10 depending.
> 
> 
> Mike

That's fine! I will install DEV-CPP on my Windows 7 and compile yip for 
you! But be aware that its development is far from finished, and even 
some of the already implemented features are not fully functional yet!

See you in Khyberspace!

Yadgar

[Mike Horvath] Re: GIF tool comparison [2587 days 7 hours and 41 minutes ago]

Thu, 7 Mar 2019 07:38:09 GMT

On 3/5/2019 8:25 AM, JÃ¶rg "Yadgar" Bleimann wrote:
> Hi(gh)!
> 
> On 05.03.19 05:37, Mike Horvath wrote:
> 
>> I wouldn't know what to do with the source code sadly. But I would be 
>> willing to test a Windows executable.
> 
> What Windows version do you use?
> 
> See you in Khyberspace!
> 
> Yadgar


I use mostly Windows 7 but also Windows 10 depending.


Mike