Pekka Aho wrote on 02/06/2017 18:19:
> "Warping in to a world at its end."
>
> :O
>
Wow, really nice pieces (the last one especially, is very detailed)!
The palette used is very fine: the images seem both ancient and futuristic.

Paolo

Post a reply to this message

> Hi(gh)!
>
> On 05.06.2017 08:46, Thomas de Groot wrote:

>>> Now playing: Ludwig II von Bayern (Klaus Schulze)
>>
>> Another one indeed!
>>
>
> Yes, I recently started to buy the albums (one CD per month) played in
> "Schwingungen" ("oscillations"), the famous German electronic music
> radio show aired from 1984 to 1995, which I frequently taped back
> then... and there also was Schulze's double album "X", containing
> "musical biographies", amazingly (as Schulze declares himself a
> Wagnerian) there is no track dedicated to Richard Wagner... perhaps it
> would have turned "X" into a triple or even quadruple album!
>
> To get the topic back to POV-Ray... there are in fact some electronic
> pieces in my collection which I really would like to translate into
> POV-Ray images or animations... for example "Delta One", "Legacy" and
> "Phobos and Deimos go to Mars" by Synergy, or "The Message" by Robert
> Schroeder... and there is even one composed by myself, which I would
> like to make a (POV-Ray or Blender) video for: "Transrapid",
> http://www.myownmusic.de/Yadgar/play/?songid=429382
>

I forgot to tell that the paintings at the exhibition were painted while 
listening to the music of Schulze, so yes, that would be a good idea.

I could not get the music playing though ...


-- 
Thomas

Post a reply to this message

"Pekka Aho" <pek### [at] gmailcom> wrote:
>

I love these sequences. This is something I have never tried, to make the viewer
ask the question 'what exactly am I looking at?' The sense of disorientation is
captured beautifully, just like those first photographs from the various landers
(agree with Bald Eagle, also thinking of venus (that russian photo) and various
martain aerial views) where you end up turning your head this way and that to
see if it makes things any clearer.

Are these images composites or a single rendering?

Cheers,

Simon.

Post a reply to this message

> To get the topic back to POV-Ray... there are in fact some electronic
> pieces in my collection which I really would like to translate into
> POV-Ray images or animations...

Currently, I'd have to cast my vote for:
"Phobos and Deimos go to Mars"

:)

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> Good to see you making more scenes for your world :)

Cheers! :) There are plenty of ideas popping up constantly and already planned
stuff on my to-do list as well, so more scenes coming up for sure. :)


Thomas de Groot <tho### [at] degrootorg> wrote:
>
> This latest series of images would be a good basis for a weird animation.

Hehe, still trying to wrap my head around animation in POV, but perhaps some
day. :D


"Simon J. Cambridge" <nomail@nomail> wrote:
>
> Are these images composites or a single rendering?

All my images are single renders, and I tend to keep the resolution of 1280 x
720 in the final POV output.

To open my planetary scenes a bit, they're somewhat minimalistic in structure
and code. Eg. this latest one is an f_wrinkles isosurface with scattering media
around it and camera zoomed in (or zoomed out as in the image from the orbit).
No light_source as separate object this time, but emission on the media and
reflection on the object texture. Then the usual stuff with radiosity and focal
blur. The 3 images close to surface are actually the one and same scene, but
with different camera angles and blur values, and a bit of rotation here and
there. =)

As for some music things, while POVing I often find myself listening to the
older games music stream at: http://www.kohina.com/
Tunes my brain nicely for some "weird" things, hehe. :D

Post a reply to this message

"Pekka Aho" <pek### [at] gmailcom> wrote:

> Cheers! :) There are plenty of ideas popping up constantly and already planned
> stuff on my to-do list as well, so more scenes coming up for sure. :)

Indeed!  "A creative man is motivated by the desire to achieve..."


> Hehe, still trying to wrap my head around animation in POV, but perhaps some
> day. :D

Until you actually do it, it seems a little intimidating.
But all it is, a separate "scene file" (the .ini file) that performs the
equivalent of a for/next loop:

#for (clock, 0, 1, STEP)
     // render your scene file for all clock values
#end

.... only this takes place OUTSIDE of the scene file, so for every clock value,
the scene gets rendered, and then the clock increments - whereas, obviously, a
#for-next loop INSIDE the scene file runs the full range and THEN the scene gets
rendered.

That's pretty much all there is to it.
(just copy the scene and the .ini to a separate directory to keep all of those
rendered frames easy to manage)
Then you just pop open something like VideoMach, highlight all of the frames,
select the video file type, and hit GO.   And you're done.

So you just use clock just like any other variable in your scene.
Add it to anything, multiply things by it, divide things by it....

clock * 360 will give you 360 degrees
clock * tau will give you 2*pi radians
translate <X+clock, 0, 0> will make something move to the right
scale 1-clock will make it shrink away to nothing

you can use it in isosurface functions, as the amplitude for noise, as an rgb
component, as a light source strength, a camera location or look_at attribute
.....

Just give it a go - you'll like it   :)



> "Simon J. Cambridge" <nomail@nomail> wrote:
> >
> > Are these images composites or a single rendering?
>
> All my images are single renders, and I tend to keep the resolution of 1280 x
> 720 in the final POV output.
>
> To open my planetary scenes a bit, they're somewhat minimalistic in structure
> and code. Eg. this latest one is an f_wrinkles isosurface with scattering media
> around it and camera zoomed in (or zoomed out as in the image from the orbit).
> No light_source as separate object this time, but emission on the media and
> reflection on the object texture. Then the usual stuff with radiosity and focal
> blur. The 3 images close to surface are actually the one and same scene, but
> with different camera angles and blur values, and a bit of rotation here and
> there. =)
>
> As for some music things, while POVing I often find myself listening to the
> older games music stream at: http://www.kohina.com/
> Tunes my brain nicely for some "weird" things, hehe. :D

Post a reply to this message

On 6/6/2017 1:01 PM, Bald Eagle wrote:
> "Pekka Aho" <pek### [at] gmailcom> wrote:

>> Hehe, still trying to wrap my head around animation in POV, but perhaps some
>> day. :D
>
> Until you actually do it, it seems a little intimidating.
> But all it is, a separate "scene file" (the .ini file) that performs the
> equivalent of a for/next loop:
>
> #for (clock, 0, 1, STEP)
>       // render your scene file for all clock values
> #end
>

An alternative view.
I prefer to use frame_number rather than the clock variable.
For a start you will want to know how long your animation to last and 
the framerate of your animation. This will give you the total number of 
frames needed. I find it easier to work with integers as when working 
with complicated animations it is useful to define key frames where 
changes occur. The arithmetic* is not really harder than using decimals 
and reduces the chances of rounding errors. It also makes it easier to 
have cyclic functions within your animations using mod(A,B).



> ..... only this takes place OUTSIDE of the scene file, so for every clock value,
> the scene gets rendered, and then the clock increments - whereas, obviously, a
> #for-next loop INSIDE the scene file runs the full range and THEN the scene gets
> rendered.
>
> That's pretty much all there is to it.
> (just copy the scene and the .ini to a separate directory to keep all of those
> rendered frames easy to manage)

Or you can define where the image files are to be saved in the ini file. 
Alternatively there is an option to define the output directory in 
povray.ini. (But I cannot remember what it is as it has been years since 
I used it. :-(  )

> Then you just pop open something like VideoMach, highlight all of the frames,
> select the video file type, and hit GO.   And you're done.
>
> So you just use clock just like any other variable in your scene.
> Add it to anything, multiply things by it, divide things by it....
>
> clock * 360 will give you 360 degrees
> clock * tau will give you 2*pi radians
> translate <X+clock, 0, 0> will make something move to the right
> scale 1-clock will make it shrink away to nothing
>
Which reminds me that you can have your clock running from A to B not 
just 0 to 1


> you can use it in isosurface functions, as the amplitude for noise, as an rgb
> component, as a light source strength, a camera location or look_at attribute
> ......
>
> Just give it a go - you'll like it   :)
>
>

And it is fascinating watching your animation render frame by frame.
So don't let the multiple ways of doing things put you off. It is 
certainly easier using the clock variable to start off.


* I've given up on the maths Vs math controversy. I'm now going to 
concentrate in correcting the world when it uses maths for something 
that is only arithmetic. ;)


-- 

Regards
     Stephen

Post a reply to this message

Stephen <mca### [at] aolcom> wrote:

> An alternative view.
> I prefer to use frame_number rather than the clock variable.
> For a start you will want to know how long your animation to last and
> the framerate of your animation. This will give you the total number of
> frames needed. I find it easier to work with integers as when working
> with complicated animations it is useful to define key frames where
> changes occur.

I have not learned the method doing animations through KeyFrames (yet), but it
seems to be the way a lot of people do things.

> The arithmetic* is not really harder than using decimals
> and reduces the chances of rounding errors. It also makes it easier to
> have cyclic functions within your animations using mod(A,B).

You certainly are a ... polymath.  :D


> Or you can define where the image files are to be saved in the ini file.
> Alternatively there is an option to define the output directory in
> povray.ini. (But I cannot remember what it is as it has been years since
> I used it. :-(  )

Noted.  Thanks!

> Which reminds me that you can have your clock running from A to B not
> just 0 to 1

Well, sure.
I also have learned not to use the clock variable directly, as I have often run
into the situation where I want to modify something halfway in.
So rather than having to hunt down all of the instances of clock, I usually
start off with

#declare Clock = clock;
And then all I have to do is edit my single function.

#declare Clock = clock*2;
#declare Clock = clock*360;
#declare Clock = (clock*9)+1;


> And it is fascinating watching your animation render frame by frame.

Fascinating .... and sometimes dismaying, when you've totally miscalculated
something in a long train of ... maths.

Post a reply to this message

On 6/6/2017 3:08 PM, Bald Eagle wrote:
> Stephen <mca### [at] aolcom> wrote:
>
>> An alternative view.
>> I prefer to use frame_number rather than the clock variable.
>> For a start you will want to know how long your animation to last and
>> the framerate of your animation. This will give you the total number of
>> frames needed. I find it easier to work with integers as when working
>> with complicated animations it is useful to define key frames where
>> changes occur.
>
> I have not learned the method doing animations through KeyFrames (yet), but it
> seems to be the way a lot of people do things.
>

It is the way to go when your scene starts getting complex. Break things 
down to the lowest common denominator. Then put them back together 
again. That is why (for me) using frame_number with initial_frame & 
final_frame is better than plain simple clock.
For instance, in this animation. The chain drive between two of the 
drive gears is only a quarter of a full revolution of the drive, 
repeated ad infinitum.

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

But then I came to PovRay because I wanted to make a fly through a 
Fractint plasma heightfield almost 20 years ago. (Still not done it.)
Here is what I did instead.

https://www.youtube.com/watch?v=RP4BMrfMLSk
&
https://www.youtube.com/watch?v=d-OPfs25aRM

Most of my animations are cyclic.

>> The arithmetic* is not really harder than using decimals
>> and reduces the chances of rounding errors. It also makes it easier to
>> have cyclic functions within your animations using mod(A,B).
>
> You certainly are a ... polymath.  :D
>

Wrong word. I am more of an autodidact. You can't teach me anything. ;)
I've got to learn from my mistakes. Of which I make many. :(

>
>> Or you can define where the image files are to be saved in the ini file.
>> Alternatively there is an option to define the output directory in
>> povray.ini. (But I cannot remember what it is as it has been years since
>> I used it. :-(  )
>
> Noted.  Thanks!

It was a "FYI". I use your method. :)
>
>> Which reminds me that you can have your clock running from A to B not
>> just 0 to 1
>
> Well, sure.
> I also have learned not to use the clock variable directly, as I have often run
> into the situation where I want to modify something halfway in.
> So rather than having to hunt down all of the instances of clock, I usually
> start off with
>
> #declare Clock = clock;
> And then all I have to do is edit my single function.
>
> #declare Clock = clock*2;
> #declare Clock = clock*360;
> #declare Clock = (clock*9)+1;
>
>

Whichever way you do it. Sums are involved. :)


>> And it is fascinating watching your animation render frame by frame.
>
> Fascinating .... and sometimes dismaying, when you've totally miscalculated
> something in a long train of ... maths.
>

Wrong attitude. ;) It gives you an opportunity to restart before the end.
https://www.youtube.com/watch?v=jHPOzQzk9Qo

-- 

Regards
     Stephen

Post a reply to this message

Stephen <mca### [at] aolcom> wrote:

> It is the way to go when your scene starts getting complex. Break things
> down to the lowest common denominator. Then put them back together
> again. That is why (for me) using frame_number with initial_frame &
> final_frame is better than plain simple clock.

This may be of interest:

"This file may help, if you want to create a POV-Ray-animation, which is
splitted in to many parts (all parts take the same amount of time).
For example: The clock value should run from 0 to 1 in the 3rd part of a total
amount of 7 parts. Then "Sclock_01(3,7)" will exactly do that for you."

http://flex.phys.tohoku.ac.jp/public_html/simon/povray/GIF/Clock_Splitting.txt

Post a reply to this message