|
![](/i/fill.gif) |
Hi Tracers!
Back from PoVghanistan (for the time being...) - as a relaxing exercise,
I created this scene, mainly for decorative purposes on my homepage
currently under construction. As you can see, the scene is intended to
be located on an icy moon orbiting a Neptune-like ringed gas giant in
the outer reaches of some extrasolar planetary system. Of course, given
the original idea to make a decorative side frame, I was firstly tempted
to use Chris Colefax' Galaxy package for the sky background, but then
the whole thing looked somewhat overstyled, so I left it out - this
scene is completely "homegrown", no innocent imagemaps have been
harmed... expect for the heightfield, which is based on a 6400 x 4800
crackle pattern.
Perhaps the layered vertical ice cliffs are a bit too flashy, surely the
large moon looming over the horizon (some kind of "inverted Europa" -
its old surface covered with dark meteorite dust is crisscrossed with
cracks exposing fresh ice) should have a more heterogenous surface
between the cracks.
Any more suggestions?
Then, there's still a very different question. I started to program an
animation with zooms in on a heightfield starting with a ridiculously
low resolution (of the heightfield, not the rendered frame!), something
about 2 x 1 pixel (!!!), exponentially increasing (10 times each 30
frames).
Last year, I already did such a movie, but back then, I rendered each
heightfield manually, which would be quite exhausting. as there would be
at least 100 frames to render.
So I looked up the INI file section and wrote a small INI, where I
linked the Height and Width keywords with the clock variable, such as
Width=int(2*pow(1.0797752, clock));
Height=int(Width*0.75);
PoV-Ray displayed no error messages when starting ... but all
heightfield image files were "rendered" at 0 by 0 pixels instead of
something like
2 by 1,
2 by 1,
2 by 1,
3 by 2,
3 by 2,
4 by 3,
etc... what went wrong?
See you in Khyberspace -
http://www.geocities.com/electricafghan/index-e.html
Yadgar
Post a reply to this message
Attachments:
Download 'space.jpg' (72 KB)
Preview of image 'space.jpg'
![space.jpg](/povray.binaries.images/attachment/%3C3C2EC9C3.F50A1A02%40ndh.net%3E/space.jpg?ttop=443840&toff=9950&preview=1)
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Yadgar" <j.b### [at] ndh net> wrote in message
news:3C2EC9C3.F50A1A02@ndh.net...
>
---snip---
> Then, there's still a very different question. I started to program an
> animation with zooms in on a heightfield starting with a ridiculously
> low resolution (of the heightfield, not the rendered frame!), something
> about 2 x 1 pixel (!!!), exponentially increasing (10 times each 30
> frames).
> Last year, I already did such a movie, but back then, I rendered each
> heightfield manually, which would be quite exhausting. as there would be
> at least 100 frames to render.
>
> So I looked up the INI file section and wrote a small INI, where I
> linked the Height and Width keywords with the clock variable, such as
>
> Width=int(2*pow(1.0797752, clock));
> Height=int(Width*0.75);
>
> PoV-Ray displayed no error messages when starting ... but all
> heightfield image files were "rendered" at 0 by 0 pixels instead
---snip---
I could be wrong but I don't think math is allowed for from within INI
files; at least checking this out in v3.5 beta 9, it cannot be done
apparently since I did get an error.
Either a positive integer for actual pixel resolution or a decimal from 0 to
1 for percentage of whole is all I know about.
--
text{ttf"timrom""bob h"0,0pigment{rgb 7}translate 7*z}
Post a reply to this message
|
![](/i/fill.gif) |