So I've got this planet.

http://twitpic.com/xiy1y (the planet from space)
http://twitpic.com/xixp0 (a low level view)

Actually it's the moon. The land is an isosurface using topographic data
from the Kaguya space probe (a 280MB .png file!). The sea is a simple
sphere. The atmosphere is a media with a modified version of Bruno
Cabasson's TerraPOV Rayleigh scattering code. The clouds are another
media with two density functions, one for the puffy clouds and another
to change the distribution.

It looks pretty good, even though I say so myself. However...

- I want to play with the atmospheric density function (to allow for the
moon's very low gravity gradient). This means I need to adjust Bruno
Cabasson's original code so that it doesn't depend on the height of the
atmosphere. Unfortunately there's something about how to scale media
that I'm just not getting --- the bigger I make the object containing
the atmosphere, the less dense the atmosphere gets, regardless how I
modify the density function. (Code below.)

- I want the sea to have waves, but I can't get a waves normal effect to
work. Dents work fine:

        normal {
            dents 0.1
            scale 0.001 * km
        }

Replacing dents with waves appears to do nothing. At the scale I'm
using, km == 1. I shouldn't be hitting any numerical domain limits,
surely? I can make planet-sized waves, but no matter what I do, when I
scale it down the magnitude appears to diminish to zero. And what is the
mysterious undocumented parameter to the dents and waves keyword?

- Right now the land texture depends solely on the altitude. I'd rather
like to use the slope pattern so that I can also make it depend on the
gradient, to avoid embarrassments like fields going up the side of
cliffs. Unfortunately, slope appears to work soley in cartesian space...
and my planet is spherical. Is there any way to persuade slope to work
in polar space instead?

- There's an occasional rendering artifact in the clouds --- which,
annoyingly, you can't quite see in the low-level scene. Thin
longitudinal lines trace the shape of the cloud. I assume this is a
sampling issue, but I don't understand how the adjustments work. Does
anyone have any advice?

Incidentally, the clouds take an absolute age to render. The
high-altitude picture took 20 minutes, with antialiasing on. An 800x600
version takes about six hours. Given that my scene contains precisely
four objects, not including the sun, I'd like to put in a bid for the
Least Efficient Scene prize...

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────
http://www.cowlark.com ─────
│ "There does not now, nor will there ever, exist a programming
│ language in which it is the least bit hard to write bad programs." ---
│ Flon's Axiom

Post a reply to this message

David Given <dg### [at] cowlarkcom> wrote:
> The land is an isosurface using topographic data
> from the Kaguya space probe

  Is there a reason to use an isosurface instead of a heightfield?
Heightfields usually render tens of times faster than isosurfaces.

-- 
                                                          - Warp

Post a reply to this message

On 10/01/10 18:45, Warp wrote:
> David Given <dg### [at] cowlarkcom> wrote:
>> The land is an isosurface using topographic data
>> from the Kaguya space probe
> 
>   Is there a reason to use an isosurface instead of a heightfield?
> Heightfields usually render tens of times faster than isosurfaces.

Isosurfaces were the only way of doing spherical heightfields that I
could find. Are there any other ways?

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────
http://www.cowlark.com ─────
│ "There does not now, nor will there ever, exist a programming
│ language in which it is the least bit hard to write bad programs." ---
│ Flon's Axiom

Post a reply to this message

David Given <dg### [at] cowlarkcom> wrote:
> Isosurfaces were the only way of doing spherical heightfields that I
> could find. Are there any other ways?

  Not spherical heightfields per se, but you can create spherical meshes:

http://wiki.povray.org/content/Documentation:Reference_Section_7.3#The_HF_Macros

-- 
                                                          - Warp

Post a reply to this message

On 10/01/10 15:30, David Given wrote:
[...]
> - I want to play with the atmospheric density function (to allow for the
> moon's very low gravity gradient). This means I need to adjust Bruno
> Cabasson's original code so that it doesn't depend on the height of the
> atmosphere. Unfortunately there's something about how to scale media
> that I'm just not getting --- the bigger I make the object containing
> the atmosphere, the less dense the atmosphere gets, regardless how I
> modify the density function. (Code below.)

I now realise that I forgot to attach the relevant bit of code for the
atmosphere that I wanted people to lookat. Whoops.

Nominal_Terrain_Radius and Sea_Level describe the size of the planet.
Atmospheric_Scale and Atmospheric_Depth describe the size of the
atmosphere. Atmospheric_Scale is a scale factor indicating the nominal
depth of the atmosphere; this should correspond to the original TerraPOV
'depth of atmosphere' field. Atmospheric_Depth describes the depth of
the actual atmosphere object. I want to be able to adjust
Atmospheric_Depth arbitrarily and have my media remain looking (largely)
the same.

#local Bottom_Of_Atmosphere = Nominal_Terrain_Radius + Sea_Level;
#local Top_Of_Atmosphere = Bottom_Of_Atmosphere
	+ Atmospheric_Depth;

#local Base_Rayleigh_Power = 6.7;
// don't know what the following line means.
#local Rayleigh_Factor = 1 / Atmospheric_Scale;
#local Rayleigh_Scale = 1;
#local Rayleigh_Power = Base_Rayleigh_Power * Rayleigh_Factor;

#local Rayleigh_Density =
	density
	{
        #local height_from_centre =
	        function(x, y, z) {
	            sqrt(x*x + y*y + z*z)
	        }
	
	    #local height_from_surface =
	        function(x, y, z) {
	            height_from_centre(x, y, z) - Bottom_Of_Atmosphere
	        }
	
		function
		{
			Rayleigh_Scale * exp(
				-Rayleigh_Power *
				height_from_surface(x, y, z)
		            )
			    // this line doesn't work
		            * (Atmospheric_Scale / Atmospheric_Depth)
		}
	}

#local Rayleigh_Colour = rgb <0.2061, 0.3933, 1.0>;

#local Rayleigh_Media =
	media
	{
		method 3 // adaptive
		intervals 3
		samples 3
		scattering
		{
			RAYLEIGH_SCATTERING
			color Rayleigh_Colour / Atmospheric_Scale
			extinction 1
		}
		density
		{
			Rayleigh_Density
		}
	}

#local Sky_Object =
	sphere
	{
		<0, 0, 0>, 1

		pigment
		{
			rgbt 1
		}

		hollow
		scale Top_Of_Atmosphere
		
		interior
		{
			media
			{
				Rayleigh_Media
			}
		}
	}

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────
http://www.cowlark.com ─────
│ "There does not now, nor will there ever, exist a programming
│ language in which it is the least bit hard to write bad programs." ---
│ Flon's Axiom

Post a reply to this message

Warp wrote:

> David Given <dg### [at] cowlarkcom> wrote:
>> Isosurfaces were the only way of doing spherical heightfields that I
>> could find. Are there any other ways?
> 
>   Not spherical heightfields per se, but you can create spherical
>   meshes:
> 
>http://wiki.povray.org/content/Documentation:Reference_Section_7.3#The_HF_Macros
> 

I tried to use the HF_Sphere macro but it seems that this macro expects a 
function that provides x,y,z data and gives an error if I specify an 
height_field definition consisting of an PNG image instead. Any hints?

-- 
Best regards,
Matthias

Post a reply to this message

Matthias Wieser <mat### [at] gmxde> wrote:
> Warp wrote:

> > David Given <dg### [at] cowlarkcom> wrote:
> >> Isosurfaces were the only way of doing spherical heightfields that I
> >> could find. Are there any other ways?
> > 
> >   Not spherical heightfields per se, but you can create spherical
> >   meshes:
> > 
> >http://wiki.povray.org/content/Documentation:Reference_Section_7.3#The_HF_Macros
> > 

> I tried to use the HF_Sphere macro but it seems that this macro expects a 
> function that provides x,y,z data and gives an error if I specify an 
> height_field definition consisting of an PNG image instead. Any hints?

  You have to give it a pattern function which uses the PNG.

-- 
                                                          - Warp

Post a reply to this message

David Given <dg### [at] cowlarkcom> wrote:
> So I've got this planet.

> - There's an occasional rendering artifact in the clouds --- which,
> annoyingly, you can't quite see in the low-level scene. Thin
> longitudinal lines trace the shape of the cloud. I assume this is a
> sampling issue, but I don't understand how the adjustments work. Does
> anyone have any advice?

You are correct that this is a sampling error, but we would have to see your
media code to help you correct it.  This is generally caused by too few samples
or low quality samples.  I saw the atmospheric code down there, you should leave
intervals at 1 for method 3.  Intervals greater than 1 is only really needed for
methods 1 or 2.  If your clouds media is in a different container shape, test it
without the atmosphere and see if there is a marked difference.  There is a bug
with the samples value of the first media container hit by rays being
inappropriately reused.  This can cause your results to be very different from
different views.  I recommend making the samples value the same or very close
for both medias.

Try increasing the confidence and reducing the variance, and try raising the
samples.  If the patterns are fairly subtle, a small amount of jitter can help
break up the regularity for minimal speed penalty (depending on your aa
settings).


> Incidentally, the clouds take an absolute age to render. The
> high-altitude picture took 20 minutes, with antialiasing on. An 800x600
> version takes about six hours. Given that my scene contains precisely
> four objects, not including the sun, I'd like to put in a bid for the
> Least Efficient Scene prize...

Scattering media is slow, but can be optimized.  Make sure medias with complex
densities fit their container shape as tightly as possible.  Be careful about
boosting the aa values too high - I rarely see much improvement over 5.  I tend
to stick with 4 for most finals, and use 2 or 3 for testing.


HTH,
-Reactor

Post a reply to this message