 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I hope I'm not in the wrong group when asking
the following question here, if I am, please forget
that you know me. :-)
How does POV-Ray's Radiosity method work?
I've tried searching the web for a document covering
the actual function and approach, but was unable
to find something useful.
Anyways, as far as I've understood the docs, its
like this:
1. Pretrace-Level:
Divide scene into patches, calculate ambient light-values
for those, gathering diffuse-reflected light by shooting
rays (amount given by "count") outward.
For each successive step, we'll check if neighbouring
patches are too different in brightness, and subdivide
them. If we use a recursion_limit, we'll do another
"bounce" of light outward, though I'm unsure if that
happens in a new pretrace-step, or is done right at the
beginning, and further pretrace-steps just do the
subdivision.
That's just about how far I was able to understand
it, but I'd like to know it in detail. For example, if
someone could point me on a document describing
the technique, and provide some information on what
POV-Ray has used and what was modified...
The main thing I'm actually trying to do with this question
is gather information on what different pretrace-steps do,
if and which some calculations are done iterative (and thus
the need for several pretrace-passes), etc. I'd like to really
fully understand the individual options for radiosity, cause for
some I've just got the feeling like:
use lower values for more detail (regarding pretrace),
use higher values for more accuracy (regarding count),
etc.
Regards,
Tim
--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.495 / Virus Database: 294 - Release Date: 01.07.2003
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I've tried searching the web for a document covering
> the actual function and approach, but was unable
> to find something useful.
Tip: search for "global illumination," since that's what POV-Ray's
"radiosity" feature really is. Radiosity is something else. At least, that's
what I heard from someone at some point.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tim Nikias v2.0 <tim### [at] gmx de> wrote:
> How does POV-Ray's Radiosity method work?
> I've tried searching the web for a document covering
> the actual function and approach, but was unable
> to find something useful.
http://radsite.lbl.gov/radiance/papers/sg88/paper.html
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hm, I've tried searching both. Haven't found
any useful difference between both terms.
It seems that Global Illumination is more or
less used for describing the problem itself:
Light is being reflected off of diffuse-reflecting
objects, and how do we solve that?
And Radiosity is then used as the term describing
an implemented technique: I use patches or
photons, scatter these around the scene and
do several rebounces.
Why there are two terms which seem to be
exact same thing goes above me. Anyone
care to elaborate?
I've got a 3D-Graphiks Book at hand, but it just
goes on explaining the radiosity-function, and
naming it a global lighting modell, but since its
a german book, I'd say it might have been named
global illumination at some point, but got translated.
--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
> > I've tried searching the web for a document covering
> > the actual function and approach, but was unable
> > to find something useful.
>
>
> Tip: search for "global illumination," since that's what POV-Ray's
> "radiosity" feature really is. Radiosity is something else. At least,
that's
> what I heard from someone at some point.
>
> - Slime
> [ http://www.slimeland.com/ ]
>
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.495 / Virus Database: 294 - Release Date: 30.06.2003
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thanks! That sure looks interesting and what I'm after.
Now I've just got to get the time to actually read it. :-)
--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
> > How does POV-Ray's Radiosity method work?
> > I've tried searching the web for a document covering
> > the actual function and approach, but was unable
> > to find something useful.
>
> http://radsite.lbl.gov/radiance/papers/sg88/paper.html
>
> --
> #macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb
M()}}
> N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
> N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// -
Warp -
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.495 / Virus Database: 294 - Release Date: 30.06.2003
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ahead of everything else: I'm asking
stuff, so to all those "newbies" to radiosity:
don't expect this to be correct!
...
Okay, I've read through the paper, but I'm
no mathematician and haven't fully understood
all details. This is what I think POV's radiosity
does, I'd be happy if anyone could correct me:
First, it shoots rays outwards. The position where
it hits will then send "count"-many rays outwards,
in an even distribution, to collect light-values from
"outside". This is the Monte-Carlo-Part of the
algorithm.
Then, as a new ray is shot, it tests if other samples
are nearby, and if there aren't enough (set by varios
details like minimum_reuse, error_bound etc), I
place a new sample there.
But what about recursion_limit? As I understand it,
I do that all at once: shoot rays outward from first
sample. The places where these hit will also shoot
samples outward, and so, until recursion-limit is
met. This way, I quickly get samples across the
scene in the very beginning, which may then be
accessed for the next samples. For this to work,
the samples would have to get marked how deep
they've already done their own recursion_limit... Tricky.
Perhaps someone could explain that to me?
And finally, pretrace. As I understand it, pretrace is
just another pass over the picture in order to check
if enough samples are present at any given spot. If
I'd be crazy enough, I could test this for every pixel
of a scene (though this doesn't necessarily lead to
best results, I've understood that much at least :-)
I'm really curious how all this works together. I formerly
thought that POV-Ray creates patches across the
scene, but that doesn't seem to be the case. Instead,
it averages samples points in a given radius for a pixel.
Which leads me to the conclusion that the radiosity
can't "detect" shadowlines, and do better sampling
there. Right?
--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
"Tim Nikias v2.0" <tim### [at] gmxde> schrieb im Newsbeitrag
news:3f0f50b5@news.povray.org...
> I hope I'm not in the wrong group when asking
> the following question here, if I am, please forget
> that you know me. :-)
>
> How does POV-Ray's Radiosity method work?
> I've tried searching the web for a document covering
> the actual function and approach, but was unable
> to find something useful.
>
> Anyways, as far as I've understood the docs, its
> like this:
> 1. Pretrace-Level:
> Divide scene into patches, calculate ambient light-values
> for those, gathering diffuse-reflected light by shooting
> rays (amount given by "count") outward.
>
> For each successive step, we'll check if neighbouring
> patches are too different in brightness, and subdivide
> them. If we use a recursion_limit, we'll do another
> "bounce" of light outward, though I'm unsure if that
> happens in a new pretrace-step, or is done right at the
> beginning, and further pretrace-steps just do the
> subdivision.
>
> That's just about how far I was able to understand
> it, but I'd like to know it in detail. For example, if
> someone could point me on a document describing
> the technique, and provide some information on what
> POV-Ray has used and what was modified...
>
> The main thing I'm actually trying to do with this question
> is gather information on what different pretrace-steps do,
> if and which some calculations are done iterative (and thus
> the need for several pretrace-passes), etc. I'd like to really
> fully understand the individual options for radiosity, cause for
> some I've just got the feeling like:
> use lower values for more detail (regarding pretrace),
> use higher values for more accuracy (regarding count),
> etc.
>
> Regards,
> Tim
>
>
> --
> Tim Nikias v2.0
> Homepage: http://www.digitaltwilight.de/no_lights
>
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.495 / Virus Database: 294 - Release Date: 01.07.2003
>
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.495 / Virus Database: 294 - Release Date: 30.06.2003
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Another sidenote:
When exporting the calculated radiosity
via save_file, the resulting file has some
nice columns...
What do the different columns stand for? Is
there a possibility to convert that data into,
for example, cones or spheres, with the
color of the sample, perhaps size, heading
(dependant on the information saved)?
--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.495 / Virus Database: 294 - Release Date: 30.06.2003
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
And one last thing:
When using ordinary lightsources, do they
affect radiosity? I'd think that radiosity uses
only ambient values, and lightsources affect
the diffuse value, and thus, when using radiosity,
I have to take care of ambient lightsources.
Is that correct?
I've just experimented and found that using
photons (loaded, without lightsource) affects
the image only very very slightly, and perhaps
that is the same case with lightsources?
I'd like some answers, even though I'll do more
experiments when I've got time. Just to make
sure that I'm not riding on any assumptions...
--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.495 / Virus Database: 294 - Release Date: 30.06.2003
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tim Nikias v2.0 <tim### [at] gmxde> wrote:
> But what about recursion_limit? As I understand it,
> I do that all at once: shoot rays outward from first
> sample. The places where these hit will also shoot
> samples outward, and so, until recursion-limit is
> met.
I think that the recursion can stop earlier for a certain sample ray
than recursion-limit if there are enough samples nearby, but basically
you are right.
> This way, I quickly get samples across the
> scene in the very beginning, which may then be
> accessed for the next samples. For this to work,
> the samples would have to get marked how deep
> they've already done their own recursion_limit... Tricky.
Why do samples need to store their recursion level?
*Rays* need to know their recursion level when they are traced, but that's
all. This is trivial and it's the exact same thing as the regular raytracing
process is doing anyways (for reflections and refractions).
> And finally, pretrace. As I understand it, pretrace is
> just another pass over the picture in order to check
> if enough samples are present at any given spot.
AFAIK pretrace is simply a preprocessing step to get some initial
samples in the scene, thus speeding up the actual raytracing.
--
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tim Nikias v2.0 <tim### [at] gmxde> wrote:
> When using ordinary lightsources, do they
> affect radiosity? I'd think that radiosity uses
> only ambient values, and lightsources affect
> the diffuse value, and thus, when using radiosity,
> I have to take care of ambient lightsources.
> Is that correct?
No.
Diffuse affects radiosity. That's why it's called "diffuse inter-reflection"
in the first place.
And this is a good thing. You get a lot better results faster using real
light sources than using high-ambient objects. This is because real light
sources are very fast to calculate, while getting a good illumination from
a high-ambient object needs tons and tons of samples.
--
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>
> Why do samples need to store their recursion level?
> *Rays* need to know their recursion level when they are traced, but
that's
> all. This is trivial and it's the exact same thing as the regular
raytracing
> process is doing anyways (for reflections and refractions).
Ah, yes, that makes sense. Hadn't thought about that.
> > And finally, pretrace. As I understand it, pretrace is
> > just another pass over the picture in order to check
> > if enough samples are present at any given spot.
>
> AFAIK pretrace is simply a preprocessing step to get some initial
> samples in the scene, thus speeding up the actual raytracing.
But then there wouldn't be a need for several pretrace
passes, would there? I could do one rather detailed pass
right away, and leave it at that. Since POV-Ray normally
works as efficient as possible (there are a lot of really
good programmers working on it), I came to the conclusion
that since sampling is the main factor for the radiosity
calculations, samples are spread and gathered in several
passes, to only place samples where needed.
--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Warp -
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.495 / Virus Database: 294 - Release Date: 30.06.2003
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> No.
> Diffuse affects radiosity. That's why it's called "diffuse
inter-reflection"
> in the first place.
>
> And this is a good thing. You get a lot better results faster using real
> light sources than using high-ambient objects. This is because real light
> sources are very fast to calculate, while getting a good illumination from
> a high-ambient object needs tons and tons of samples.
Hm. So then samples store the actual brightness at a sampled
spot, right? For example, if I light a sphere with a pointlight
somewhere, a sample won't just store the brightness of samples,
but inhibit the brightness of the position as well.
Makes sense, come to think of it.
So photons also affect radiosity?
I've noticed some of that in the later experiments I did AFTER
writing these posts (and their pretty time-consuming, as we
all know about radiosity, right? :-)
I find this topic very interesting, and experimenting with it
is fun. Understanding the main algorithm however is a
very useful addition when trying to tweak the settings. You
know what you're actually affecting, and don't just have to
think like "the smaller, the more detailed". You'll also know
things like "the smaller, the more detailed, but the more
undesired contrast is introduced, e.g. edges..."
--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.495 / Virus Database: 294 - Release Date: 30.06.2003
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> [...]
>
> > And finally, pretrace. As I understand it, pretrace is
> > just another pass over the picture in order to check
> > if enough samples are present at any given spot.
>
> AFAIK pretrace is simply a preprocessing step to get some initial
> samples in the scene, thus speeding up the actual raytracing.
No, pretrace does not speed up the render, on the contrary it nearly
always slows it down. Its purpose is to achieve a better distribution of
the radiosity samples taken. How much this affects the results depends on
the settings. Just try it out yourself.
In quite a lot of cases it can be efficient not to use pretrace but you
should know what you are doing since it is more likely to cause problems.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 17 Jun. 2003 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
What kind of settings? I've been experimenting all weekend
now. I've noticed that using pretrace_start .5 and pretrace_end .01
don't make a difference when compared to start and end at .01.
If you know something we don't, then don't hold it back! :-)
--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
>
>
> Warp wrote:
> >
> > [...]
> >
> > > And finally, pretrace. As I understand it, pretrace is
> > > just another pass over the picture in order to check
> > > if enough samples are present at any given spot.
> >
> > AFAIK pretrace is simply a preprocessing step to get some initial
> > samples in the scene, thus speeding up the actual raytracing.
>
> No, pretrace does not speed up the render, on the contrary it nearly
> always slows it down. Its purpose is to achieve a better distribution of
> the radiosity samples taken. How much this affects the results depends on
> the settings. Just try it out yourself.
>
> In quite a lot of cases it can be efficient not to use pretrace but you
> should know what you are doing since it is more likely to cause problems.
>
> Christoph
>
> --
> POV-Ray tutorials, include files, Sim-POV,
> HCR-Edit and more: http://www.tu-bs.de/~y0013390/
> Last updated 17 Jun. 2003 _____./\/^>_*_<^\/\.______
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.495 / Virus Database: 294 - Release Date: 30.06.2003
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tim Nikias v2.0" wrote:
>
> What kind of settings? I've been experimenting all weekend
> now. I've noticed that using pretrace_start .5 and pretrace_end .01
> don't make a difference when compared to start and end at .01.
>
> If you know something we don't, then don't hold it back! :-)
I have shown samples with the effect of rendering with and without
pretrace before. You will of course have difficulties to spot any
differences when using high quality settings which lead to a very smooth
lighting anyway. For tracing without pretrace set both start and end to
1.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 17 Jun. 2003 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hm, can't seem to find any images with the web-interface,
and I haven't got all posts on my HD... :-)
Still, the note about using pretrace start and end of 1
was good, I'll fumble with that. And I didn't realize
that max_trace_level would be that important as well,
but you're right, again, I should've thought about that
earlier. Still, higher max_trace_level isn't needed
desperately, as you've surely noticed with my other
pics... But perhaps I can keep more detailed radiosity
with higher trace_level...
--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
>
>
> "Tim Nikias v2.0" wrote:
> >
> > What kind of settings? I've been experimenting all weekend
> > now. I've noticed that using pretrace_start .5 and pretrace_end .01
> > don't make a difference when compared to start and end at .01.
> >
> > If you know something we don't, then don't hold it back! :-)
>
> I have shown samples with the effect of rendering with and without
> pretrace before. You will of course have difficulties to spot any
> differences when using high quality settings which lead to a very smooth
> lighting anyway. For tracing without pretrace set both start and end to
> 1.
>
> Christoph
>
> --
> POV-Ray tutorials, include files, Sim-POV,
> HCR-Edit and more: http://www.tu-bs.de/~y0013390/
> Last updated 17 Jun. 2003 _____./\/^>_*_<^\/\.______
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.495 / Virus Database: 294 - Release Date: 30.06.2003
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Whoot!
Max_Trace_level set to 256, pretrace start and end to 1,
what do I get?
Stack overflow! :-O
And restarting the image after a reboot doesn't help, it'll
gag again after two lines. And all this on 240x180 image...
I'll post a notice on this shortly, but perhaps my insane
settings aren't meant to be... :-)
--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
> Hm, can't seem to find any images with the web-interface,
> and I haven't got all posts on my HD... :-)
>
> Still, the note about using pretrace start and end of 1
> was good, I'll fumble with that. And I didn't realize
> that max_trace_level would be that important as well,
> but you're right, again, I should've thought about that
> earlier. Still, higher max_trace_level isn't needed
> desperately, as you've surely noticed with my other
> pics... But perhaps I can keep more detailed radiosity
> with higher trace_level...
>
>
> --
> Tim Nikias v2.0
> Homepage: http://www.digitaltwilight.de/no_lights
>
>
> >
> >
> > "Tim Nikias v2.0" wrote:
> > >
> > > What kind of settings? I've been experimenting all weekend
> > > now. I've noticed that using pretrace_start .5 and pretrace_end .01
> > > don't make a difference when compared to start and end at .01.
> > >
> > > If you know something we don't, then don't hold it back! :-)
> >
> > I have shown samples with the effect of rendering with and without
> > pretrace before. You will of course have difficulties to spot any
> > differences when using high quality settings which lead to a very smooth
> > lighting anyway. For tracing without pretrace set both start and end to
> > 1.
> >
> > Christoph
> >
> > --
> > POV-Ray tutorials, include files, Sim-POV,
> > HCR-Edit and more: http://www.tu-bs.de/~y0013390/
> > Last updated 17 Jun. 2003 _____./\/^>_*_<^\/\.______
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.495 / Virus Database: 294 - Release Date: 30.06.2003
>
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.495 / Virus Database: 294 - Release Date: 30.06.2003
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann <chr### [at] gmxde> wrote:
> No, pretrace does not speed up the render, on the contrary it nearly
> always slows it down. Its purpose is to achieve a better distribution of
> the radiosity samples taken.
You are actually contradicting yourself.
Why do you want a better distribution of samples? Because that way you
get a better result with fewer samples, that is, a faster rendering.
Without the pretrace step you need a lot more samples to get a good result,
thus resulting in a slower rendering.
--
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tim Nikias v2.0 <tim### [at] gmxde> wrote:
> Max_Trace_level set to 256, pretrace start and end to 1,
> what do I get?
> Stack overflow! :-O
Why is it a surprise?
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
It isn't, but if I'd expected it, I wouldn't have attempted
it, right?
Anyways, on a sidepath: aren't there possibilities to circumvent
this stack overflow, or is this out of POV-Ray's hands?
--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
> > Max_Trace_level set to 256, pretrace start and end to 1,
> > what do I get?
>
> > Stack overflow! :-O
>
> Why is it a surprise?
>
> --
> #macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb
x]
> [1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
> -1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// -
Warp -
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.495 / Virus Database: 294 - Release Date: 30.06.2003
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3f11746b@news.povray.org> , "Tim Nikias v2.0"
<tim### [at] gmxde> wrote:
> Anyways, on a sidepath: aren't there possibilities to circumvent
> this stack overflow, or is this out of POV-Ray's hands?
You really don't want to, unless you want to wait until the death of the
universe for your render to finish with such settings...
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Well, okay, I understand that. :-)
Still, the message POV-Ray issues tells me to restart
POV-Ray. Isn't there some way around that? Like,
when POV-Ray notices things are getting out of hand,
it'll stop generating data for that pixel and just take
what it's got?
OTOH, I don't know what is actually overflowing, so
I might be suggesting complete bullsh** here. But isn't
there a possibility for a more user-friendly approach?
Like a message telling me "Don't use so many freakin'
radiosity samples, it cracks me up!" or so?
Hm, yet again, perhaps POV-Ray can't tell that for sure.
So, then just out of interest: what is actually placed in
the stack which overflows? Is it amount of rays? Gathered
samples? Thinking about it, the way POV-Ray handles
it seems to be best possible method, but I'd still like to
know the background, if someone can be bothered... :-)
--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
>
> > Anyways, on a sidepath: aren't there possibilities to circumvent
> > this stack overflow, or is this out of POV-Ray's hands?
>
> You really don't want to, unless you want to wait until the death of the
> universe for your render to finish with such settings...
>
> Thorsten
>
> ____________________________________________________
> Thorsten Froehlich, Duisburg, Germany
> e-mail: tho### [at] trfde
>
> Visit POV-Ray on the web: http://mac.povray.org
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.495 / Virus Database: 294 - Release Date: 30.06.2003
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tim Nikias v2.0 <tim### [at] gmxde> wrote:
> Anyways, on a sidepath: aren't there possibilities to circumvent
> this stack overflow, or is this out of POV-Ray's hands?
Recompile POV-Ray with a larger stack (it's a compiler setting, not
a POV-Ray setting).
--
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3f118cfd@news.povray.org> , "Tim Nikias v2.0"
<tim### [at] gmxde> wrote:
> Still, the message POV-Ray issues tells me to restart
> POV-Ray. Isn't there some way around that?
So if a program tells you to take a gun and shoot your neighbor, you will do
that as well? ;-) In fact this is just a precaution, and if POV-Ray for
Windows is still working after this message, then there probably isn't a
dangerous problem...
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3f118cfd@news.povray.org> , "Tim Nikias v2.0"
<tim### [at] gmxde> wrote:
> OTOH, I don't know what is actually overflowing, so
> I might be suggesting complete bullsh** here. But isn't
> there a possibility for a more user-friendly approach?
> Like a message telling me "Don't use so many freakin'
> radiosity samples, it cracks me up!" or so?
This isn't a message that comes from POV-Ray itself. If an application runs
out of memory in a certain way (that is on the stack), the operating system
will notice. Usually an application then crashes unless it is able to catch
this notice from the operating system. This is what POV-Ray for Windows
does.
> So, then just out of interest: what is actually placed in
> the stack which overflows?
The stack itself has a limited size. It cannot really be explained to a
non-programmer well at all...sorry!
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> The stack itself has a limited size. It cannot really be explained to a
> non-programmer well at all...sorry!
I am a programmer, but only novice. I was just interested
in the type of data. Rays, samples, colors, statistics for
color calculations...
Interested just out of curiosity, not because I could actually do
something about that... :-)
But nevermind, you probably have more important issues
at hand than explaining details I couldn't even change something
about. I just like to put my nose everywhere... :-)
--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
>
> > OTOH, I don't know what is actually overflowing, so
> > I might be suggesting complete bullsh** here. But isn't
> > there a possibility for a more user-friendly approach?
> > Like a message telling me "Don't use so many freakin'
> > radiosity samples, it cracks me up!" or so?
>
> This isn't a message that comes from POV-Ray itself. If an application
runs
> out of memory in a certain way (that is on the stack), the operating
system
> will notice. Usually an application then crashes unless it is able to
catch
> this notice from the operating system. This is what POV-Ray for Windows
> does.
>
> > So, then just out of interest: what is actually placed in
> > the stack which overflows?
>
> The stack itself has a limited size. It cannot really be explained to a
> non-programmer well at all...sorry!
>
> Thorsten
>
> ____________________________________________________
> Thorsten Froehlich, Duisburg, Germany
> e-mail: tho### [at] trfde
>
> Visit POV-Ray on the web: http://mac.povray.org
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.495 / Virus Database: 294 - Release Date: 30.06.2003
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> So if a program tells you to take a gun and shoot your neighbor, you will
do
> that as well? ;-) In fact this is just a precaution, and if POV-Ray for
> Windows is still working after this message, then there probably isn't a
> dangerous problem...
Nah. I'd only do what POV-Ray tells me. ;-)
--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.495 / Virus Database: 294 - Release Date: 30.06.2003
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
