 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 25 Jul 1999 20:28:46 -0400, "Dave Kreskowiak"
<dkr### [at] home com> wrote:
>Maybe I'll go back and try the MaxTraceLevel on the smoke again to see if it
>corrects the problem I was having. (Didn't do anything with it because it
>took too long to try and fix a problem and test!)
>
>Thanks!
Replacing the spheres with the equivalent blob (of threshold 0.0001 or
similar) will result in a much faster and smoother render, and you
won't need to set max_trace_level too high. (You might need the
'sturm' keyword if there're a lot of elements, but that's all.) I have
too overlooked this method in the past until Chris Colefax opened my
eyes.
Peter Popov
ICQ: 15002700
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Peter Popov wrote:
>
> On Sun, 25 Jul 1999 20:28:46 -0400, "Dave Kreskowiak"
> <dkr### [at] homecom> wrote:
>
> >Maybe I'll go back and try the MaxTraceLevel on the smoke again to see if it
> >corrects the problem I was having. (Didn't do anything with it because it
> >took too long to try and fix a problem and test!)
> >
> >Thanks!
>
> Replacing the spheres with the equivalent blob (of threshold 0.0001 or
> similar) will result in a much faster and smoother render, and you
> won't need to set max_trace_level too high. (You might need the
> 'sturm' keyword if there're a lot of elements, but that's all.) I have
> too overlooked this method in the past until Chris Colefax opened my
> eyes.
>
> Peter Popov
> ICQ: 15002700
Why would this be ?
--
Ken Tyler
mailto://tylereng@pacbell.net
http://home.pacbell.net/tylereng/links.htm
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 26 Jul 1999 01:55:17 -0700, Ken <tyl### [at] pacbellnet> wrote:
>> Replacing the spheres with the equivalent blob (of threshold 0.0001 or
>> similar) will result in a much faster and smoother render, and you
>> won't need to set max_trace_level too high. (You might need the
>> 'sturm' keyword if there're a lot of elements, but that's all.) I have
>> too overlooked this method in the past until Chris Colefax opened my
>> eyes.
>>
>> Peter Popov
>> ICQ: 15002700
>
>Why would this be ?
I didn't believe it either before I did the tests. First of all,
multiple containers for multiple media proved a lot faster and
smoother than multiple media in a single container. The reason is
that, as the media are better enclosed each in its own container, a)
fewer unnecessary calculations are performed and b) media intervals
are closer together. Or, if we choose a container that's fast and
tightly fitting the media, then it's ok too. With that said, there are
three ways to go:
Union of spheres - fast, but has the problem of the high
max_trace_level needed. Also, if the spheres are closely packed, it
gets really slow. I think the reason is that every time the ray
enters/leaves a sphere and leaves/enters another, that segment of it
gets media sampled. Imagine what happens with 150 closely packed
spheres.
Merge of spheres - the problems typical for the union of spheres are
avoided, but merge is really slow as is.
Blob - the fastest of all three due to the bounding hierarchy and it
also avoids the problems that an union of spheres has. Also, each
element gets its media sampled separately (or so it seems) and this
yields a smoother image.
Peter Popov
ICQ: 15002700
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Peter Popov wrote:
>
> On Mon, 26 Jul 1999 01:55:17 -0700, Ken <tyl### [at] pacbellnet> wrote:
> >> Replacing the spheres with the equivalent blob (of threshold 0.0001 or
> >> similar) will result in a much faster and smoother render, and you
> >> won't need to set max_trace_level too high. (You might need the
> >> 'sturm' keyword if there're a lot of elements, but that's all.) I have
> >> too overlooked this method in the past until Chris Colefax opened my
> >> eyes.
> >>
> >> Peter Popov
> >> ICQ: 15002700
> >
> >Why would this be ?
>
> I didn't believe it either before I did the tests. First of all,
> multiple containers for multiple media proved a lot faster and
> smoother than multiple media in a single container. The reason is
> that, as the media are better enclosed each in its own container, a)
> fewer unnecessary calculations are performed and b) media intervals
> are closer together. Or, if we choose a container that's fast and
> tightly fitting the media, then it's ok too. With that said, there are
> three ways to go:
>
> Union of spheres - fast, but has the problem of the high
> max_trace_level needed. Also, if the spheres are closely packed, it
> gets really slow. I think the reason is that every time the ray
> enters/leaves a sphere and leaves/enters another, that segment of it
> gets media sampled. Imagine what happens with 150 closely packed
> spheres.
>
> Merge of spheres - the problems typical for the union of spheres are
> avoided, but merge is really slow as is.
>
> Blob - the fastest of all three due to the bounding hierarchy and it
> also avoids the problems that an union of spheres has. Also, each
> element gets its media sampled separately (or so it seems) and this
> yields a smoother image.
>
> Peter Popov
> ICQ: 15002700
Then as I understand it Pov will treat the blob method as a single blob
entity with multiple cells as opposed to sphere which it must treat as
multiple entities. Yes ?
--
Ken Tyler
mailto://tylereng@pacbell.net
http://home.pacbell.net/tylereng/links.htm
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 26 Jul 1999 03:34:34 -0700, Ken <tyl### [at] pacbellnet> wrote:
> Then as I understand it Pov will treat the blob method as a single blob
>entity with multiple cells as opposed to sphere which it must treat as
>multiple entities. Yes ?
I can't tell more without a) peeking into the source code or b)
speculating. I wish to do neither therefore I will leave these musings
to the more qualified and take it as is.
Peter Popov
ICQ: 15002700
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Peter Popov <pet### [at] usanet> wrote:
: Merge of spheres - the problems typical for the union of spheres are
: avoided, but merge is really slow as is.
Not really true. I wonder why this delusion persists.
See http://www.students.tut.fi/~warp/povVFAQ.html#csgspeed
(Everyone keeps saying that merge is (always) a lot slower than union,
but no-one has ever said why. Or even proved it.)
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Mika wrote:
>
> Peter Popov <pet### [at] usanet> wrote:
> : Merge of spheres - the problems typical for the union of spheres are
> : avoided, but merge is really slow as is.
>
> Not really true. I wonder why this delusion persists.
> See http://www.students.tut.fi/~warp/povVFAQ.html#csgspeed
>
> (Everyone keeps saying that merge is (always) a lot slower than union,
> but no-one has ever said why. Or even proved it.)
I have the following script that shows the merge operation taking 2 times
longer than a union of the same objects. I did recieve similar results as
you did with the example you gave but this example obviously takes longer
though I cannot offer an explaination as to why.
Rendered at 120x100 no AA
union time: min. 3 sec. 9
merge time: min. 6 sec. 21
union {
// merge {
#declare A = 0;
#while ( A < 10)
#declare B = 0;
#while ( B < 10)
#declare C = 0;
#while ( C < 10)
box { -.5, .5
pigment { rgbf .9}
translate<-5,-5,-5>
translate <0.99*A, 0.99*B, 0.99*C>
}
#declare C = C + 1;
#end
#declare B = B + 1;
#end
#declare A = A + 1;
#end
}
global_settings { max_trace_level 85}
camera { location<2.5,5,-15> look_at 0}
light_source { <30,100,100> rgb 1}
light_source { <-0,10,-200> rgb 1}
background { rgb 1}
--
Ken Tyler
mailto://tylereng@pacbell.net
http://home.pacbell.net/tylereng/links.htm
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I tried this scene in this Sparcstation 4 rendering at 160x120 (it's a
very slow machine...). I got these results:
Union:
Total Time: 0 hours 13 minutes 13.0 seconds (793 seconds)
Merge:
Total Time: 0 hours 11 minutes 50.0 seconds (710 seconds)
I also tried with a simplified version of the scene. I scaled the boxes by
2 and added '2' to each index (instead of '1'). Rendering at 320x240 I got:
Union:
Total Time: 0 hours 11 minutes 59.0 seconds (719 seconds)
Merge:
Total Time: 0 hours 4 minutes 25.0 seconds (265 seconds)
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 25 Jul 1999 09:48:00 -0400, Dave Kreskowiak wrote:
>In my experience, coincident surfaces tend to render a jittered imaged of
>both textures, not a black spot.
Black spots (actually transparent spots) are fairly common. They usually
happen when you have an intersection involving coincident surfaces. POV
will find one or the other surface, then determine that that surface is
"outside" the other surface and ignore that intersection. It then goes
on to find another intersection, but because it always starts looking at
a distance of EPSILON along the ray from the last intersection, it misses
the second surface at that point entirely, leaving a transparent spot
that could show up as black under the right circumstances.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 26 Jul 1999 07:48:32 -0400, Nieminen Mika wrote:
> (Everyone keeps saying that merge is (always) a lot slower than union,
>but no-one has ever said why. Or even proved it.)
If we look only at the time to calculate intersections, merge is slower
than union because it has to check each intersection to see if it's inside
another element. Thus merge might be slower than union if you use a simple
texture like "texture {pigment {color rgbt .8} finish{ambient .8}}" with no
or maybe only a single light source.
However, in the real world many of us use very complex textures with
reflection and complex lighting. Calculating the various patterns, and
especially casting all those shadow rays and reflection rays, tends to dwarf
the time it takes to test intersections for insideness.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
