 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'm trying to use a media to produce volumetric clouds. However, I'm
getting really strange results. If you look at the following image:
http://twitpic.com/y7642
...you can see odd longitudinal stripes in the clouds. Something appears
to be dividing the clouds up into slices. However, animation shows that
moving the camera causes the slices to flicker and pulse irregularly:
http://www.youtube.com/watch?v=mdSYui1-vAo
(actually a different scene, but showing the same problem.)
The clouds are represented by a hollow sphere some 1747 units in radius
(1 unit == 1 km in my model). The lower edge of the clouds are 5 km from
the camera, which means that the smallest detail visible in the clouds
are unlikely to be bigger than 10m, which is 0.010 units; therefore I
don't think I'm hitting any numerical limit issues.
Can anyone shed any light on this? Right now I'm completely stumped.
Code snippet follows:
#declare Nominal_Terrain_Radius = 1737.400;
#declare Sea_Level = -1;
#declare Cloud_Base = 5;
#declare Cloud_Height = 10;
#local Bottom_Of_Atmosphere = Nominal_Terrain_Radius + Sea_Level;
#local Cloud_Bottom = Cloud_Base + Bottom_Of_Atmosphere;
#local Cloud_Top = Cloud_Bottom + Cloud_Height;
#local Clouds_Media =
media
{
method 3 // adaptive
intervals 3
samples 3
scattering
{
1 1
}
density
{
bumps
scale Cloud_Height/2
density_map
{
[0 rgb 0]
[0.6 rgb 0]
[1 rgb .5]
}
}
}
#local Clouds_Object =
difference
{
sphere
{
<0, 0, 0>, Cloud_Top
}
sphere
{
<0, 0, 0>, Cloud_Bottom
}
pigment
{
rgbt 1
}
hollow
interior
{
media
{
Clouds_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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Try changing this:
#local Clouds_Media =
media
{
method 3 // adaptive
aa_threshold 0.1 aa_level 3
intervals 3
samples 20
jitter .1
scattering
{ ...
That's basically what I've got in my planet close-up scene.
--
-Nekar Xenos-
"The spoon is not real"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Try changing this:
>
> #local Clouds_Media =
> media
> {
> method 3 // adaptive
> aa_threshold 0.1 aa_level 3
> intervals 3
> samples 20
> jitter .1
> scattering
> { ...
>
> That's basically what I've got in my planet close-up scene.
>
>
Even beter:
...
media{
samples 60
jitter 0.1
scattering{...}
}
...
Same numbre of samples, but significantly faster.
Method 3 is default, aa is also default, so, they don't need to be
specified.
With method 3, it's recomended to keep the default intervals value,
whitch is 1, and only use the samples.
What append is that at places, you samples just miss the parts of your
media that have larger density value and fall on bits with very low to
zero density.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 15/01/10 21:01, Alain wrote:
> Le 2010-01-15 15:43, Nekar Xenos a écrit :
[...]
>> media
>> {
>> method 3 // adaptive
>> aa_threshold 0.1 aa_level 3
>> intervals 3
>> samples 20
>> jitter .1
>> scattering
>> { ...
[...]
> media{
> samples 60
> jitter 0.1
> scattering{...}
> }
Thank-you, but alas, neither of those work! In fact, they both render
identically, taking the same amount of time. (And I did check to make
sure that I was modifying the right bit of the right file...) I even
tried going as far as samples 1000 and jitter 0.01 but that had no
effect either. Even changing the sampling method produces images that
are *pixel identical* with the original. (Changing the media type from
scattering to emission produces glowing clouds with the same artifacts
in them in precisely the same place.)
Any ideas?
Incidentally, what is jitter, and is it safe to use in media when doing
an animation? (The documentation on media sampling mentions jitter in
passing but doesn't say what it does or what the parameter is. I'm
finding this to be a common theme in the Povray docs, unfortunately.)
--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────
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] cowlark com> wrote:
> On 15/01/10 21:01, Alain wrote:
> > Le 2010-01-15 15:43, Nekar Xenos a écrit :
> [...]
> >> media
> >> {
> >> method 3 // adaptive
> >> aa_threshold 0.1 aa_level 3
> >> intervals 3
> >> samples 20
> >> jitter .1
> >> scattering
> >> { ...
> [...]
> > media{
> > samples 60
> > jitter 0.1
> > scattering{...}
> > }
>
> Thank-you, but alas, neither of those work! In fact, they both render
> identically, taking the same amount of time. (And I did check to make
> sure that I was modifying the right bit of the right file...) I even
> tried going as far as samples 1000 and jitter 0.01 but that had no
> effect either. Even changing the sampling method produces images that
> are *pixel identical* with the original. (Changing the media type from
> scattering to emission produces glowing clouds with the same artifacts
> in them in precisely the same place.)
>
> Any ideas?
>
> Incidentally, what is jitter, and is it safe to use in media when doing
> an animation? (The documentation on media sampling mentions jitter in
> passing but doesn't say what it does or what the parameter is. I'm
> finding this to be a common theme in the Povray docs, unfortunately.)
>
> --
> ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────
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
Those are artifacts caused by too few samples. Are you absolutely certain that
you did modify the right part of the file? Because settings samples to 1000
would be extremely slow. I would expect a samples setting of 100 to be more
than enough.
Can you post more related code and the version you are using? I have a
suspicion involving the use of more than one media per object (sometimes the
value specified for samples gets reused inappropriately).
-Reactor
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David Given <dg### [at] cowlarkcom> wrote:
> Can anyone shed any light on this? Right now I'm completely stumped.
>
As others have mentioned, such problems usually occur when the samples value is
simply set too low. (Also noted: Only 1 interval is recommended for method 3,
which will then create more intervals automatically, as-needed.) BTW, the
documentation's stated defaults for intervals and samples are incorrect. The
real defaults (at least for method 3) are: intervals 1, samples 10.
I find it strange that even 1000 samples doesn't improve things for you. How
about changing jitter to some *higher* value, like 2? I confess that I don't
usually mess with jitter in media, and leave it at its default (whatever that
is!) Perhaps a too-low jitter value is causing the banding, by not allowing the
media to 'spread out' across intervals. (My assumption is based on jitter in
photons--lowering the jitter value *there* does produce distinct photon bands.)
As far as how media jitter affects animation: I don't really know; haven't yet
animated any clouds. (A good experiment to try.) But I suspect that it would
look OK, IF the samples are high enough, and if the media density pattern has
smooth transitions, as yours does. Just a guess.
My own approach to making clouds like this is to make lots of *individual*
clouds instead (in their own spheres.) Not as difficult as it sounds, using a
#while loop (with random turbulence for each cloud's density.) I *think* the
scene might render faster as well, for two reasons: the camera doesn't have to
look through an entire large media-filled sphere; and the samples value can be
much lower per cloud.
Ken
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 16/01/10 02:29, Reactor wrote:
[...]
> Those are artifacts caused by too few samples. Are you absolutely certain that
> you did modify the right part of the file? Because settings samples to 1000
> would be extremely slow. I would expect a samples setting of 100 to be more
> than enough.
Yeah, sorry about that --- I edited my post at the last moment and, of
course, cocked it up. 1000 samples was indeed *agonisingly* slow, but
produced identical results to 100, 60 or 30 samples.
> Can you post more related code and the version you are using? I have a
> suspicion involving the use of more than one media per object (sometimes the
> value specified for samples gets reused inappropriately).
In fact, I'm making progress. I put together an isolated test case that
I could post here and, naturally, discovered that it wasn't manifesting
the problem. A bit more investigation revealed that the problem has
nothing to do with my clouds at all --- it's the *atmosphere*.
My planet's atmosphere is another sphere with a media in it; it's
running a fairly complicated function to get the Rayleigh density right
(it's not, but that's another story). The clouds and the atmosphere are
union'd together. It turns out that there's some very odd interaction
between the two. Changing the sampling settings on the *atmosphere*
changes the appearance of the *clouds*.
Are there any gotchas involved in unioning two hollow objects with media
together? Changing the atmosphere sampling method to 1 or 2 makes the
clouds look *really* weird, which is not what I was expecting.
--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────
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:
> Are there any gotchas involved in unioning two hollow objects with media
> together? Changing the atmosphere sampling method to 1 or 2 makes the
> clouds look *really* weird, which is not what I was expecting.
>
The gotcha is a bug that can inappropriately reuse the sample settings for two
medias in an object. I don't know the exact details of it, I just know that it
can sometimes show up.
To work around it, try reordering the medias (it shouldn't make a difference,
but it might). If it is possible, avoid having two medias with a large
difference between samples attached to the same object. If you are unioning the
objects together, apply each media to the appropriate object within the union.
If you don't mind posting a code sample, I might be of more help.
-Reactor
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2010-01-16 08:08, David Given a écrit :
> On 16/01/10 02:29, Reactor wrote:
> [...]
>> Those are artifacts caused by too few samples. Are you absolutely certain that
>> you did modify the right part of the file? Because settings samples to 1000
>> would be extremely slow. I would expect a samples setting of 100 to be more
>> than enough.
>
> Yeah, sorry about that --- I edited my post at the last moment and, of
> course, cocked it up. 1000 samples was indeed *agonisingly* slow, but
> produced identical results to 100, 60 or 30 samples.
>
>> Can you post more related code and the version you are using? I have a
>> suspicion involving the use of more than one media per object (sometimes the
>> value specified for samples gets reused inappropriately).
>
> In fact, I'm making progress. I put together an isolated test case that
> I could post here and, naturally, discovered that it wasn't manifesting
> the problem. A bit more investigation revealed that the problem has
> nothing to do with my clouds at all --- it's the *atmosphere*.
>
> My planet's atmosphere is another sphere with a media in it; it's
> running a fairly complicated function to get the Rayleigh density right
> (it's not, but that's another story). The clouds and the atmosphere are
> union'd together. It turns out that there's some very odd interaction
> between the two. Changing the sampling settings on the *atmosphere*
> changes the appearance of the *clouds*.
>
> Are there any gotchas involved in unioning two hollow objects with media
> together? Changing the atmosphere sampling method to 1 or 2 makes the
> clouds look *really* weird, which is not what I was expecting.
>
When you have overlaping media containers, you risk to get the samples
only according to that of the first media encountered.
Try to see if you can place the containers so that they never overlap.
If needed, use two containers for the athmosphere, one for the upper
part and one for the part under the clouds.
From top to ground:
Outer athmospheric media. Can have a low sample value like 3 to 5.
Small gap with no media.
Container for the clouds media. This one will have a samples of about 30
to 60.
May be present or not...
Second small gap.
Lower athmospheric media. Again, use a low samples value.
That way, you are always only traveling through one media that can each
have ther own sample number without interfering with that of the others.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Reactor" <rea### [at] hotmailcom> wrote:
> David Given <dg### [at] cowlarkcom> wrote:
>
> > Are there any gotchas involved in unioning two hollow objects with media
> > together? Changing the atmosphere sampling method to 1 or 2 makes the
> > clouds look *really* weird, which is not what I was expecting.
> >
>
>
> The gotcha is a bug that can inappropriately reuse the sample settings for two
> medias in an object. I don't know the exact details of it, I just know that
> it can sometimes show up.
>
Yeah, there is some non-intuitive behavior going on (although I don't think it
has much if anything to do with the union itself.) Once this behavior is
understood, though, it can be dealt with relatively easily. As Alain has
mentioned, the first sphere that the camera sees (with its particular samples
count) is the one that sets the samples value for any other media spheres
contained inside it--even if those spheres are given completely different
samples counts. Personally, I've always wondered if this is a bug, or 'just the
way POV operates' with media and transparency.
Here's a somewhat more telling example, of two spheres that only partially
overlap:
camera{
....
location <0, 0, -15>
look_at <0, 0, 0>
....
}
sphere{0,1.5 // the larger sphere
....
media{
emission .1
method 3
//intervals 1 // the default
samples 5 // very low
}
....
}
and
sphere{0,1 // smaller than first sphere
....
media{
emission .1*<1,0,0>
method 3
//intervals 1
samples 100 // much higher than 1st sphere
}
....
translate 1.5*x // so that it's partly inside 1st sphere, and partly outside
}
The majority of this combination will show only 5 samples in the
media--including the part of the 2nd sphere contained inside the 1st; but the
part of the 2nd sphere which extends *outside* the 1st will show its own 100
samples. It all depends on where the camera is--i.e., which sphere it first sees
at a particular point. (If the 2nd smaller sphere is BEHIND the first sphere and
completely outside it, I don't know what happens; I haven't tried that
experiment. I suspect that both would show their correct samples.)
The *easiest* way out of this situation is to give each sphere the same samples
count. That would eliminate any surprises--especially during animation, if the
camera is moving around or through the spheres.
Ken
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
