 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Here's the animation of the solar system over one Earth year.
I just worked out a fast and efficient approximation for apsidal (orbital)
precession last night. (not that it will make any noticeable effect)
Still need to look up a bunch of things and do some further editing on the code
before it gets fleshed out.
Not sure how I ought to place the planets - so I just started at full syzygy.
I may trace out the orbits in a future version.
Post a reply to this message
Attachments:
Download 'solarsystem2.mpg' (2542 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi(gh)!
On 12.05.2017 14:10, Bald Eagle wrote:
>
> Here's the animation of the solar system over one Earth year.
Are the orbits true Keplerian ellipses? If yes, how did you code that?
See you in Khyberspace!
Yadgar
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/12/2017 1:10 PM, Bald Eagle wrote:
>
> Here's the animation of the solar system over one Earth year.
>
> I just worked out a fast and efficient approximation for apsidal (orbital)
> precession last night. (not that it will make any noticeable effect)
>
> Still need to look up a bunch of things and do some further editing on the code
> before it gets fleshed out.
>
I kept loosing sight of the Earth watching the download. :(
One frame it's there. The next frame it's not.
I'm thinking it might be your encoding settings.
> Not sure how I ought to place the planets - so I just started at full syzygy.
> I may trace out the orbits in a future version.
>
The orbit of the moon would be nice to see.
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
=?UTF-8?Q?J=c3=b6rg_=22Yadgar=22_Bleimann?= <yaz### [at] gmx de> wrote:
> Are the orbits true Keplerian ellipses? If yes, how did you code that?
They aren't (yet) - but ellipses are easy to code in POV-Ray, since they're just
circles scaled in one axis. Not that the elliptical orbits of the planets are
very elliptical.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Stephen <mca### [at] aolcom> wrote:
> I kept loosing sight of the Earth watching the download. :(
> One frame it's there. The next frame it's not.
>
> I'm thinking it might be your encoding settings.
Might be. I have that problem with several of the planets.
Suggestions?
I also have some formulas for scaling something so that it's always at least a
pixel wide. I may add that so the apparent size never drops below a pixel.
> > Not sure how I ought to place the planets - so I just started at full syzygy.
> > I may trace out the orbits in a future version.
> >
>
> The orbit of the moon would be nice to see.
I'm going to play with parameters to see what I can get to fit on the screen and
be aesthetically pleasing, but not too wildly unrealistic.
Maybe even code in proximity conditions for textures vs uv-mapping.
Still pondering how to rotate the sun faster around the axis than the equator -
how to procedurally texture that....
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/12/2017 2:31 PM, Bald Eagle wrote:
> Stephen <mca### [at] aolcom> wrote:
>
>> I kept loosing sight of the Earth watching the download. :(
>> One frame it's there. The next frame it's not.
>>
>> I'm thinking it might be your encoding settings.
>
> Might be. I have that problem with several of the planets.
> Suggestions?
>
Only what I do myself.
I stick to Mpeg-2 because I had to pick one format.
Variable bit rate and multi-pass (2) encoding.
I play with the bit rate and maximum bit rate settings. I always used
the default setting in TMPGEnc. But since I can't get it to run on my
current machine. I've started using Blender and there starting values are:
Bitrate: 6000
Minimum: 0
Maximum: 9000
Buffer: 1792
I move the Bitrate and Maximum up and down together to reach a
compromise between quality and file size.
If someone wants to tell me how to do it properly. I am all ears. :)
> I also have some formulas for scaling something so that it's always at least a
> pixel wide. I may add that so the apparent size never drops below a pixel.
>
>>> Not sure how I ought to place the planets - so I just started at full syzygy.
>>> I may trace out the orbits in a future version.
>>>
>>
>> The orbit of the moon would be nice to see.
>
> I'm going to play with parameters to see what I can get to fit on the screen and
> be aesthetically pleasing, but not too wildly unrealistic.
>
Ghost images that fade out?
> Maybe even code in proximity conditions for textures vs uv-mapping.
>
Why, is it not complicated enough?
> Still pondering how to rotate the sun faster around the axis than the equator -
> how to procedurally texture that....
>
>
You have started me thinking about creating a DF3 animation, of the sun.
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> I also have some formulas for scaling something so that it's always at least a
> pixel wide. I may add that so the apparent size never drops below a pixel.
>
That sounds interesting; I've never tried anything like that. If it's not too
complicated to explain, *I'm* all ears. ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>
> >
> > I also have some formulas for scaling something so that it's always at least a
> > pixel wide. I may add that so the apparent size never drops below a pixel.
> >
>
> That sounds interesting; I've never tried anything like that. If it's not too
> complicated to explain, *I'm* all ears. ;-)
So, for background, I've always used cylinders or tori or wire-boxes to draw
"lines" as indicators or guides in images. I'd always have to fiddle with the
radius of the object to get it so it was wide enough to be useful (visible) but
not like a tree obstructing the scene.
When one studies the curves of --- small objects directed at larger ones --- the
concept of "MOA" comes into play. Same with visual phenomena and cameras.
If I have an object in front of the default perspective camera, (and let's say
the image size is 640 x 480) then anything that's [(1/640)/2] in radius will
have a diameter of one pixel. Adjust for aspect ratio in the case of
horizontal "lines".
Then, to account for distance, when something is doubled in distance, it appears
half the size - it covers half of its former angular field of view. So the
radius needs to be doubled. So just add a multiplier.
I need to work out the Euclidean distance from a point in the plane parallel to
the right-up plane, and use that instead of just z, but I've tested the basic
concept, and the code works nicely. Cylinders of different heights at different
distances from the camera all have the same apparent width. :)
So, for the planetary orbits, I can just calculate the minimum radius necessary
for visibility at it's present Euclidean distance from the camera, and just
redefine the planet's radius as a #declare PlanetRadius=max(Real,
MinForVisibility) function.
If I remember to copy the scene file to my USB stick, I ought to be able to post
the working prototype code on Monday.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Stephen <mca### [at] aolcom> wrote:
> On 5/12/2017 2:31 PM, Bald Eagle wrote:
> > Suggestions?
> >
> Only what I do myself.
> I stick to Mpeg-2 because I had to pick one format.
Oh, the _video_ encoding. I'll have to go back and look at the still frames
and see if they have the same problem.
> > I'm going to play with parameters to see what I can get to fit on the screen and
> > be aesthetically pleasing, but not too wildly unrealistic.
>
> Ghost images that fade out?
Elaborate, please.
I was thinking about the parameters of the radii, the distances, and the orbital
eccentricities to get a nice but highly unrealistic animation of the
elliptically orbiting planets- but it sounds like you have another interesting
idea.
> > Maybe even code in proximity conditions for textures vs uv-mapping.
>
> Why, is it not complicated enough?
It is not. At the moment it's some spinning spheres revolving around a textured
sphere. Earth has the very complex texture of pigment {Blue} with specular 0.6.
"We need nine columns for the motions of Jupiter, nine for the motions of
Saturn, and so on. Then when we have all initial positions and velocities we can
calculate all the accelerations from Eq. (9.18) by first calculating all the
distances, using Eq. (9.19). How long will it take to do it? If you do it at
home, it will take a very long time! But in modern times we have machines which
do arithmetic very rapidly; a very good computing machine may take 11
microsecond, that is, a millionth of a second, to do an addition. To do a
multiplication takes longer, say 1010 microseconds. It may be that in one cycle
of calculation, depending on the problem, we may have 3030 multiplications, or
something like that, so one cycle will take 300300 microseconds. That means that
we can do 30003000 cycles of computation per second. In order to get an
correspond to one revolution of a planet around the sun. That corresponds to a
computation time of 130130 seconds or about two minutes. Thus it takes only two
minutes to follow Jupiter around the sun, with all the perturbations of all the
planets correct to one part in a billion, by this method!"
http://www.feynmanlectures.caltech.edu/I_09.html
And really, all it is is a conditional statement.
if the distance > some trigger, use a simple procedural texture.
if it's less, use a more complex one, or a UV map.
> > Still pondering how to rotate the sun faster around the axis than the equator -
> > how to procedurally texture that....
>
> You have started me thinking about creating a DF3 animation, of the sun.
Excellent! Inspiration strikes!
Looks like Bob Hughes has taken a stab at that already:
http://objects.povworld.org/binaries/sun.pov
And it looks like there are some other toys to play with there as well! :)
http://objects.povworld.org/cat/Space/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/12/2017 5:31 PM, Bald Eagle wrote:
> Stephen <mca### [at] aolcom> wrote:
>> On 5/12/2017 2:31 PM, Bald Eagle wrote:
>
>>> Suggestions?
>>>
>> Only what I do myself.
>> I stick to Mpeg-2 because I had to pick one format.
>
> Oh, the _video_ encoding. I'll have to go back and look at the still frames
> and see if they have the same problem.
>
>
Yes, that is the first step. That's if you d
see what I described.
>>> I'm going to play with parameters to see what I can get to fit on the screen and
>>> be aesthetically pleasing, but not too wildly unrealistic.
>>
>> Ghost images that fade out?
>
> Elaborate, please.
The moon leaves a trail of increasingly transparent images. It is a
common effect but I cannot remember what it is called. but I wasn't
being serious. A solid or broken line would be good enough.
> I was thinking about the parameters of the radii, the distances, and the orbital
> eccentricities to get a nice but highly unrealistic animation of the
> elliptically orbiting planets- but it sounds like you have another interesting
> idea.
>
>>> Maybe even code in proximity conditions for textures vs uv-mapping.
>>
>> Why, is it not complicated enough?
>
> It is not. At the moment it's some spinning spheres revolving around a textured
> sphere. Earth has the very complex texture of pigment {Blue} with specular 0.6.
>
> "We need nine columns for the motions of Jupiter, nine for the motions of
> Saturn, and so on. Then when we have all initial positions and velocities we can
> calculate all the accelerations from Eq. (9.18) by first calculating all the
> distances, using Eq. (9.19). How long will it take to do it? If you do it at
> home, it will take a very long time! But in modern times we have machines which
> do arithmetic very rapidly; a very good computing machine may take 11
> microsecond, that is, a millionth of a second, to do an addition. To do a
> multiplication takes longer, say 1010 microseconds. It may be that in one cycle
> of calculation, depending on the problem, we may have 3030 multiplications, or
> something like that, so one cycle will take 300300 microseconds. That means that
> we can do 30003000 cycles of computation per second. In order to get an
> accuracy, of, say, one part in a billion, we would need 4×1054×105 cycles to
> correspond to one revolution of a planet around the sun. That corresponds to a
> computation time of 130130 seconds or about two minutes. Thus it takes only two
> minutes to follow Jupiter around the sun, with all the perturbations of all the
> planets correct to one part in a billion, by this method!"
>
> http://www.feynmanlectures.caltech.edu/I_09.html
>
> And really, all it is is a conditional statement.
> if the distance > some trigger, use a simple procedural texture.
> if it's less, use a more complex one, or a UV map.
>
>
Yes, I understand but have you experimented with the technique. When I
did years ago I found little difference in the times taken. It is a good
technique though.
As for as accuracy goes. I am always disappointed with PovRay's realism.
The camera in my mind's eye is much better than RL. :-(
>
>>> Still pondering how to rotate the sun faster around the axis than the equator -
>>> how to procedurally texture that....
>
>>
>> You have started me thinking about creating a DF3 animation, of the sun.
>
> Excellent! Inspiration strikes!
>
Maybe not. I was thinking about converting Blender's particle system
into a point cloud or something like that but it is not obvious how it
is done. I'll give it another decade or two to come up with an idea. ;)
> Looks like Bob Hughes has taken a stab at that already:
> http://objects.povworld.org/binaries/sun.pov
>
Always worth looking at Bob's code.
> And it looks like there are some other toys to play with there as well! :)
> http://objects.povworld.org/cat/Space/
>
There are a lot of good ideas out there. A lot of them very old. :)
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
