![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Hi there!
Still working on atmospheres and cloudscapes for TerraPOV, I discoverd recently
something that puzzles me unexpectedly. Two media-filled objects that I was
expecting to render the same do not. Run the following fragment of code. You
can notice that the spheres on the right (UnionedSpheres) are significantly
brighter than those on the left (DistinctSpheres).
In UnionedSpheres, there is a single interior with two spherical-shaped medias.
In DistinctSpheres, each sphere has its own interior media.
I had in mind that the two definitions were equivalent.
I cannot figure out where the problem is. Could it be related to the container
artifact?
Bruno
#version 3.5;
#include "colors.inc"
global_settings {
assumed_gamma 1.0
}
// ----------------------------------------
camera {
orthographic
location -100*z
look_at 0
right 5*x*image_width/image_height
up 5*y
}
light_source {
<0, 0, 0>
color rgb 0.8
parallel point_at -y
translate 100*y
}
#declare DistinctSpheres = union
{
sphere
{
0, 1
hollow
pigment {rgbt 1}
interior
{
media
{
intervals 3 samples 3 method 3
scattering {1, Blue}
density {function{1}} // Optionnal statement
}
}
translate 1.1*y
}
sphere
{
0, 1
hollow
pigment {rgbt 1}
interior
{
media
{
intervals 3 samples 3 method 3
scattering {1, White}
density {function{1}} // Optionnal statement
}
}
translate -1.1*y
}
}
#declare UnionedSpheres = union
{
sphere {0, 1 translate 1.1*y}
sphere {0, 1 translate -1.1*y}
hollow
pigment {rgbt 1}
interior
{
media
{
intervals 3 samples 3 method 3
scattering {1, Blue}
density {spherical color_map {[0 rgb 0] [0.001 rgb 1]} translate
1.1*y}
}
media
{
intervals 3 samples 3 method 3
scattering {1, White}
density {spherical color_map {[0 rgb 0] [0.001 rgb 1]} translate
-1.1*y}
}
}
}
object {DistinctSpheres translate -2*x}
object {UnionedSpheres translate 2*x}
Post a reply to this message
Attachments:
Download '2mediatest.png' (19 KB)
Preview of image '2mediatest.png'
![2mediatest.png](/povray.binaries.images/attachment/%3Cweb.48454c2d23bf798ee8ba46670%40news.povray.org%3E/2mediatest.png?ttop=443866&toff=3200&preview=1)
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Bruno Cabasson" <bru### [at] alcatelaleniaspace fr> wrote:
> Hi there!
>
> ...I discovered recently
> something that puzzles me unexpectedly. Two media-filled objects that I was
> expecting to render the same do not. Run the following fragment of code. You
> can notice that the spheres on the right (UnionedSpheres) are significantly
> brighter than those on the left (DistinctSpheres).
>
I played around with your code in lots of different ways, trying to see what
might happen by changing this or that. (My usual problem-solving method!) My
own conclusion is that the spheres on the right--the ones made from a single
interior and multiple shifted medias--are the problem spheres, not the ones on
the left. (I guess that's kind of obvious, eh?) IMO, what you're seeing is yet
another scattering-media-and-transparency problem. Not that I know the
solution. Out of curiosity, I added another media sphere to both of your
'schemes'--and it makes the spheres on the right even brighter! What that tells
me is that the multiple medias in that union are 'adding
up' in some way...even though they are properly translated and supposedly don't
overlap. OR, that the medias' (default) extinction values are not behaving
properly...something I've noticed in some scenes of my own. (OR, it just might
be a strange by-product of your coding method--multiple unioned spheres sharing
a single interior with multiple shifted medias. That's new to me; very
interesting!)
But crazy experimenter that I am, I kept messing around with your code and came
across a quasi-solution to the problem that actually seems to fix it! I arrived
at this through...sheer luck. :-) It doesn't 'explain' the problem, but may give
some insight into it. In your code for the right-hand sphere grouping, I first
commented-out the density functions (which, as you say, are optional) just as a
way to eliminate one possible problem. Then, since your union has two spheres in
it, I reduced the color_map brightness of each media to .5 at index list .001
(i.e., 1/2 of its original value), then changed extinction in each media to
2--twice its value. Each of these 'fixes' has a reason behind it: Reducing the
brightness to half makes the media half as dense--and kind of 'watered down,'
color-wise--yet doubling the extinction compensates for that color weakening,
like a contrast control. Again, this was just some wild experimenting--but the
result happens to look identical to the spheres on the left; I'm hard-pressed
to see any difference. (The only thing I DO see is the lack of that subtle
shadow-line on the bottom/right sphere...which *might* actually be a
coincident-surface-like shadow problem on the bottom/LEFT sphere, from the
parallel light source.)
BTW, with THREE spheres (and three medias) in the right-hand union, the same
visual match is created by using extinction 3 and a color_map value of .333.
Strange but fascinating!
I can't say this 'scheme' of mine makes any real sense, but it does seem to be a
workaround to the problem.
Here's the re-worked code (with slightly different media values that work
better, I think).
Ken W.
-----------
#declare UnionedSpheres = // grouping to RIGHT
union{
sphere {0, 1 translate 1.1*y}
sphere {0, 1 translate -1.1*y}
hollow
pigment {rgbt 1}
interior
{
media{
method 3
intervals 1
samples 40
scattering {1, Blue extinction 2}
density {
spherical
color_map {
[0 rgb 0]
[0.001 rgb .5]
}
translate 1.1*y
}
}
media{
method 3
intervals 1
samples 40
scattering {1, White extinction 2}
density {
spherical
color_map {
[0 rgb 0]
[0.001 rgb .5]
}
translate -1.1*y
}
}
}
}
Post a reply to this message
Attachments:
Download 'sphere_media_problem.jpg' (33 KB)
Preview of image 'sphere_media_problem.jpg'
![sphere_media_problem.jpg](/povray.binaries.images/attachment/%3Cweb.48461a929a2aa19278dcad930%40news.povray.org%3E/sphere_media_problem.jpg?ttop=443866&toff=3200&preview=1)
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Thanks a lot Kenneth for your analysis. I guess you spent quite a lot of time!
Media in POV can be sometimes a little puzzling and mysterious. Not the best
situation for controlling what happens in my clouds. Your work-around is a good
idea. However, and AFAIK, extinction is not the same as density, but it might
compensate. Before I posted, I tried many things in order to have some symptoms
and clues, but I did not try to increase the number of spheres.
Perhaps that is the most significant symptom in that problem and this will help
finding the reason.
Bruno
"Kenneth" <kdw### [at] earthlink net> wrote:
> "Bruno Cabasson" <bru### [at] alcatelaleniaspace fr> wrote:
> > Hi there!
> >
> > ...I discovered recently
> > something that puzzles me unexpectedly. Two media-filled objects that I was
> > expecting to render the same do not. Run the following fragment of code. You
> > can notice that the spheres on the right (UnionedSpheres) are significantly
> > brighter than those on the left (DistinctSpheres).
> >
>
> I played around with your code in lots of different ways, trying to see what
> might happen by changing this or that. (My usual problem-solving method!) My
> own conclusion is that the spheres on the right--the ones made from a single
> interior and multiple shifted medias--are the problem spheres, not the ones on
> the left. (I guess that's kind of obvious, eh?) IMO, what you're seeing is yet
> another scattering-media-and-transparency problem. Not that I know the
> solution. Out of curiosity, I added another media sphere to both of your
> 'schemes'--and it makes the spheres on the right even brighter! What that tells
> me is that the multiple medias in that union are 'adding
> up' in some way...even though they are properly translated and supposedly don't
> overlap. OR, that the medias' (default) extinction values are not behaving
> properly...something I've noticed in some scenes of my own. (OR, it just might
> be a strange by-product of your coding method--multiple unioned spheres sharing
> a single interior with multiple shifted medias. That's new to me; very
> interesting!)
>
> But crazy experimenter that I am, I kept messing around with your code and came
> across a quasi-solution to the problem that actually seems to fix it! I arrived
> at this through...sheer luck. :-) It doesn't 'explain' the problem, but may give
> some insight into it. In your code for the right-hand sphere grouping, I first
> commented-out the density functions (which, as you say, are optional) just as a
> way to eliminate one possible problem. Then, since your union has two spheres in
> it, I reduced the color_map brightness of each media to .5 at index list .001
> (i.e., 1/2 of its original value), then changed extinction in each media to
> 2--twice its value. Each of these 'fixes' has a reason behind it: Reducing the
> brightness to half makes the media half as dense--and kind of 'watered down,'
> color-wise--yet doubling the extinction compensates for that color weakening,
> like a contrast control. Again, this was just some wild experimenting--but the
> result happens to look identical to the spheres on the left; I'm hard-pressed
> to see any difference. (The only thing I DO see is the lack of that subtle
> shadow-line on the bottom/right sphere...which *might* actually be a
> coincident-surface-like shadow problem on the bottom/LEFT sphere, from the
> parallel light source.)
>
> BTW, with THREE spheres (and three medias) in the right-hand union, the same
> visual match is created by using extinction 3 and a color_map value of .333.
> Strange but fascinating!
>
> I can't say this 'scheme' of mine makes any real sense, but it does seem to be a
> workaround to the problem.
>
> Here's the re-worked code (with slightly different media values that work
> better, I think).
>
> Ken W.
>
> -----------
>
> #declare UnionedSpheres = // grouping to RIGHT
> union{
> sphere {0, 1 translate 1.1*y}
> sphere {0, 1 translate -1.1*y}
> hollow
> pigment {rgbt 1}
> interior
> {
> media{
> method 3
> intervals 1
> samples 40
> scattering {1, Blue extinction 2}
> density {
> spherical
> color_map {
> [0 rgb 0]
> [0.001 rgb .5]
> }
> translate 1.1*y
> }
> }
> media{
> method 3
> intervals 1
> samples 40
> scattering {1, White extinction 2}
> density {
> spherical
> color_map {
> [0 rgb 0]
> [0.001 rgb .5]
> }
> translate -1.1*y
> }
> }
> }
> }
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
I simplified the problem, and the artifact occurs with this basic situation:
sphere
{
0, 1
hollow
pigment {rgbt 1}
interior
{
media {scattering {1, 1}}
media {scattering {1, 1} density {function {0}}}
}
}
Comment/uncomment the second null media, or add more null medias. When multiple
medias, POV adds each individual contribution. But in the presnet case, I
wonder what POV adds! The behaviour seems to be like x + 0 > x ...
This problem can become a major concern for my cloud system to implement my
"physically accurate" model.
Bruno
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Bruno Cabasson" <bru### [at] alcatelaleniaspace fr> wrote:
> Thanks a lot Kenneth for your analysis. I guess you spent quite a lot of time!
>
Sometimes, when I come across an interesting POV problem, I 'm like a dog
chewing on a bone: I can't let it go! :-) When I'm experimenting, I like to
throw some really ridiculous things at POV-Ray--just to see what might happen!
More times than not, it leads me to a better understanding of how POV works.
> Your work-around is a good
> idea. However, and AFAIK, extinction is not the same as density, but it might
> compensate.
You're right, of course. In coming up with this goofy work-around, I was tying
to figure out--in my own mind-- *some* kind of logical reason as to why it
seemed to work; but my explanation is probably not accurate at all.
BTW, I'm curious as to what function{1) or function{0} actually do. I've never
used a function of a constant before. Can you explain?
Ken W.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Kenneth" <kdw### [at] earthlink net> wrote:
> "Bruno Cabasson" <bru### [at] alcatelaleniaspace fr> wrote:
> > Thanks a lot Kenneth for your analysis. I guess you spent quite a lot of time!
> >
> Sometimes, when I come across an interesting POV problem, I 'm like a dog
> chewing on a bone: I can't let it go! :-) When I'm experimenting, I like to
> throw some really ridiculous things at POV-Ray--just to see what might happen!
> More times than not, it leads me to a better understanding of how POV works.
>
>
> > Your work-around is a good
> > idea. However, and AFAIK, extinction is not the same as density, but it might
> > compensate.
>
> You're right, of course. In coming up with this goofy work-around, I was tying
> to figure out--in my own mind-- *some* kind of logical reason as to why it
> seemed to work; but my explanation is probably not accurate at all.
>
> BTW, I'm curious as to what function{1) or function{0} actually do. I've never
> used a function of a constant before. Can you explain?
>
> Ken W.
Try this code. It is some kind of nebula, which is more accurate for comparison
between renders than simple spheres. You can check that varying the number N of
medias yields the exact same render (verified with a color picker).
Bruno.
#version 3.5;
#include "colors.inc"
global_settings {
assumed_gamma 1.0
}
// ----------------------------------------
camera {
location <0.0, 0.0, -4.0>
direction 1.5*z
right x*image_width/image_height
look_at <0.0, 0.0, 0.0>
}
#declare N = 10;
light_source {
<0, 0, 0>
color rgb 3/N
}
// ----------------------------------------
difference
{
sphere {0, 1}
sphere {0, 0.01} // The light source must be outside the container,
otherwise scattering does not work properly (as if extinction were
inoperative).
hollow
pigment {rgbt 1}
interior
{
#local i = 0;
#while (i<N)
media
{
scattering {1, rgb 7*<1, 0.7, 0.1>/N}
absorption 10*(1-OrangeRed)/N
density
{
spherical scale 0.4
turbulence 1 lambda 1.4 omega 0.9 octaves 10
}
}
#local i = i+1;
#end
}
}
However, this technique applied to the original problem does not work, as the
following code shows when rendered:
#version 3.5;
#include "colors.inc"
global_settings {
assumed_gamma 1.0
}
// ----------------------------------------
camera {
orthographic
location -100*z
look_at 0
right 5*x*image_width/image_height
up 5*y
}
light_group
{
light_source {
<0, 0, 0>
color rgb 0.8
parallel point_at -y
translate 100*y
}
#declare DistinctSpheres = union
{
sphere
{
0, 1
hollow
pigment {rgbt 1}
interior
{
media
{
intervals 3 samples 3 method 3
scattering {1, Blue}
density {function{1}} // Optionnal statement
}
}
translate 1.1*y
}
sphere
{
0, 1
hollow
pigment {rgbt 1}
interior
{
media
{
intervals 3 samples 3 method 3
scattering {1, White}
density {function{1}} // Optionnal statement
}
}
translate -1.1*y
}
}
object {DistinctSpheres}
}
light_group
{
light_source {
<0, 0, 0>
color rgb 0.8/2 // 2 medias
parallel point_at -y
translate 100*y
}
#declare UnionedSpheres = union
{
sphere {0, 1 translate 1.1*y}
sphere {0, 1 translate -1.1*y}
hollow
pigment {rgbt 1}
interior
{
media
{
intervals 3 samples 3 method 3
scattering {1, rgb Blue/2}
density {spherical color_map {[0 rgb 0] [0.001 rgb 1]} translate
1.1*y}
}
media
{
intervals 3 samples 3 method 3
scattering {1, rgb White/2}
density {spherical color_map {[0 rgb 0] [0.001 rgb 1]} translate
-1.1*y}
}
}
}
object {UnionedSpheres translate 2*x}
}
You can also try to make the medias overlap (suppress the translate statements),
and see the differences. So why exact same values with the nebula, and not with
the spheres? The only thing I see is that in the sphere case, there are two
distinct containers, and therefore the rays pass through container boundary,
and we may face the container artifact. This is a good bone to chew ...
Bruno
PS: I just hope that I am not mislead by something so obvious I can't see it!
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Bruno Cabasson nous illumina en ce 2008-06-03 09:50 -->
> Hi there!
>
> Still working on atmospheres and cloudscapes for TerraPOV, I discoverd recently
> something that puzzles me unexpectedly. Two media-filled objects that I was
> expecting to render the same do not. Run the following fragment of code. You
> can notice that the spheres on the right (UnionedSpheres) are significantly
> brighter than those on the left (DistinctSpheres).
>
> In UnionedSpheres, there is a single interior with two spherical-shaped medias.
> In DistinctSpheres, each sphere has its own interior media.
>
> I had in mind that the two definitions were equivalent.
>
> I cannot figure out where the problem is. Could it be related to the container
> artifact?
>
>
> Bruno
>
Even with the density of the bottom sphere set to zero, the blue media still
looks dencer.
The two media are supposed to add together, but a value of zero in one media
should leave the other media unchanged.
Not related to your problem.
This line cause your rendering speed to drop significantly:
> intervals 3 samples 3 method 3
This rewriten line give you more samples AND is faster:
samples 12
You don't need to specify method 3, it's the default.
With this method, you should always use only one intervals (the new default) and
increase the number of samples as needed, and never set it to less than 3.
--
Alain
-------------------------------------------------
They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety.
Benjamin Franklin
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Le Thu, 05 Jun 2008 02:00:52 +0200, Alain <ele### [at] netscape net> a
> Bruno Cabasson nous illumina en ce 2008-06-03 09:50 -->
>> Hi there!
>> Still working on atmospheres and cloudscapes for TerraPOV, I discoverd
>> recently
>> something that puzzles me unexpectedly. Two media-filled objects that I
>> was
>> expecting to render the same do not. Run the following fragment of
>> code. You
>> can notice that the spheres on the right (UnionedSpheres) are
>> significantly
>> brighter than those on the left (DistinctSpheres).
>> In UnionedSpheres, there is a single interior with two
>> spherical-shaped medias.
>> In DistinctSpheres, each sphere has its own interior media.
>> I had in mind that the two definitions were equivalent.
>> I cannot figure out where the problem is. Could it be related to the
>> container
>> artifact?
>> Bruno
>>
> Even with the density of the bottom sphere set to zero, the blue media
> still looks dencer.
> The two media are supposed to add together, but a value of zero in one
> media should leave the other media unchanged.
>
> Not related to your problem.
> This line cause your rendering speed to drop significantly:
>
>> intervals 3 samples 3 method 3
> This rewriten line give you more samples AND is faster:
> samples 12
>
> You don't need to specify method 3, it's the default.
> With this method, you should always use only one intervals (the new
> default) and increase the number of samples as needed, and never set it
> to less than 3.
>
>
Hello Alain.
Concerning the values for the media, I am aware of your advises, thanks
anyway for enlighting.
The fact is that, with the study on clouds I am currently conducting, I
never got acceptable results with only one interval, especially for rays
that approach the horizon, and more especially when the sun is at low
elevation. This is due to the occupation of the 'high' density media
within the container (a spherical shell), and also due to the turbulent
nature of the media for clouds. The integration must not miss the
turbulenced media, otherwise you get awful splotchy results and nothing
that resembles a cloud. So I always use such values as a reflex, as I am
focused on the subject since quite a while. Articles coming soon, I hope.
In this regard, 3 intervals and 3 samples yield better results that 1
interval and 9 or 12 samples. It is slower, but one conclusion of my study
is that you can't expect realistic wolumetric media clouds and a quick
render. Some of my experiments require several hours on an overclocked
Q6600.
However, for spheres, default values are OK and I could have used them for
my example. Sorry if it was confusing.
And, when coding, I generally prefer be explicit rather than use implicit
default values. Depends on cases, and mood ...
Trying to understand what happens with this media artifact, origin of the
thread, using several medias, I ended up with the code that renders
something like a nebula that I quoted in my reply to Kenneth earlier in
the thread (see
http://news.povray.org/*/message/%3Cweb.4846bf2b9a2aa192e8ba46670%40news.povray.org%3E/#%3Cweb.4846bf2b9a2aa192e8ba46670%40news.povray.org%3E).
I am thankful to him that he got interested and is willing to dig.
So far, I tend to believe that the problem is related to containers,
because it seems it is the only difference I see between the two cases.
For my amusement, I improved the nebula a little in order to have a more
artistic result. The media is highly turbulenced, and I had to specify 10
intervals (you read well...), and 3 samples, leaving the adaptive method 3
do the job within the intervals. Render time 51 minutes on a Q6600@3.2 GHz.
Bruno.
--
http://www.opera.com/mail/
Post a reply to this message
Attachments:
Download 'nebula.png' (149 KB)
Preview of image 'nebula.png'
![nebula.png](/povray.binaries.images/attachment/%3Cop.ub83kgnvm1sclq%40pignouf%3E/nebula.png?ttop=443866&toff=3200&preview=1)
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Bruno Cabasson" <bru### [at] cabasson com> wrote:
>
> Concerning the values for the media, I am aware of your advises, thanks
> anyway for enlighting.
>
> The fact is that, with the study on clouds I am currently conducting, I
> never got acceptable results with only one interval, especially for rays
> that approach the horizon, and more especially when the sun is at low
> elevation...
>
> In this regard, 3 intervals and 3 samples yield better results that 1
> interval and 9 or 12 samples.
That's interesting. I usually use the recommended method 3, intervals 1 approach
(basically because it renders faster.) But your method seems useful and
logical; I'll have to experiment with it!
>
> And, when coding, I generally prefer be explicit rather than use implicit
> default values. Depends on cases, and mood ...
I agree! I don't always *trust* that POV's stated default values are correct.
I'm still testing out your nebula code, and will report back with some comments,
if I can contribute anything useful or helpful. Yes, it's a tasty bone to chew
on :-)
Ken W.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Le Thu, 05 Jun 2008 19:44:14 +0200, Kenneth <kdw### [at] earthlink net> a
> "Bruno Cabasson" <bru### [at] cabasson com> wrote:
>
>>
>> Concerning the values for the media, I am aware of your advises, thanks
>> anyway for enlighting.
>>
>> The fact is that, with the study on clouds I am currently conducting, I
>> never got acceptable results with only one interval, especially for rays
>> that approach the horizon, and more especially when the sun is at low
>> elevation...
>>
>> In this regard, 3 intervals and 3 samples yield better results that 1
>> interval and 9 or 12 samples.
>
> That's interesting. I usually use the recommended method 3, intervals 1
> approach
> (basically because it renders faster.) But your method seems useful and
> logical; I'll have to experiment with it!
>>
>> And, when coding, I generally prefer be explicit rather than use
>> implicit
>> default values. Depends on cases, and mood ...
>
> I agree! I don't always *trust* that POV's stated default values are
> correct.
>
> I'm still testing out your nebula code, and will report back with some
> comments,
> if I can contribute anything useful or helpful. Yes, it's a tasty bone
> to chew
> on :-)
>
> Ken W.
>
>
Here is the code for the nebula on th epicture.
#version 3.5;
#include "colors.inc"
global_settings {
assumed_gamma 1.0
}
// ----------------------------------------
camera {
location <0.0, 0.0, -4.0>
direction 1.5*z
right x*image_width/image_height
look_at <0.0, 0.0, 0.0>
}
#declare N = 2; // 2 medias
light_source {
<0, 0, 0>
color rgb 4/N // light power of 4 is required because high level of
scattering/absorption
}
// ----------------------------------------
difference
{
sphere {0, 1}
sphere {0, 0.01} // The light source must be outside the container,
otherwise scattering does not work properly (as if extinction were
inoperative).
hollow
pigment {rgbt 1}
interior
{
media
{
intervals 10 samples 3 method 3
scattering {1, rgb 10*<1, 0.7, 0.1>/N}
absorption 15*(1-OrangeRed)/N
density
{
spherical scale 0.4
scale 10 warp {turbulence 0.6 omega 0.7 octaves 10} scale
1/10
turbulence 1 lambda 1.4 omega 0.8 octaves 10
}
}
media
{
intervals 10 samples 3 method 3
scattering {1, rgb 30*<0.7, 0.5, 1>/N}
absorption 2*(1-VioletRed)/N
density
{
spherical scale 0.45
scale 10 translate 0.5 warp {turbulence 0.6 omega 0.7
octaves 10} translate -0.5 scale 1/10
turbulence 1 lambda 1.4 omega 0.8 octaves 10
}
}
#end
}
}
--
http://www.opera.com/mail/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |