 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Peter Popov <pet### [at] usa net> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 26 Jul 1999 07:48:32 -0400, Nieminen Mika <war### [at] cctutfi> wrote:
> 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.)
Yeah, I have the VFAQ, Warp. I was referring to this particular case,
namely 100 or more transparent media-filled spheres. I agree that
merge can be faster in the some cases, particularly when there are a
lot of transparent objects close together (like 100-200 transparent
surfaces) and media. This is, you should agree, a rare occasion.
Peter Popov
ICQ: 15002700
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Mika wrote:
>
> I tried this scene in this Sparcstation 4 rendering at 160x120 (it's a
> very slow machine...). I got these results:
I would be interested in seeing your windows comarison. I ran one more
test using the previous test parmeters with the addition of media and
rendered at 640x480 to increase the render time. The difference between
merge and union was less than 5% for a 3.5 hour render time. The merge was
slightly faster.
--
Ken Tyler
mailto://tylereng@pacbell.net
http://home.pacbell.net/tylereng/links.htm
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken <tyl### [at] pacbellnet> wrote:
: I would be interested in seeing your windows comarison.
Yes, it probably is system and/or compiler dependant.
Anyways, with semitransparent objects and lots of inner surfaces (which
are removed when merged), the merge operation is often (although not always)
faster than the union.
I can easyly believe that with non-transparent objects merge may be a little
slower than union.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I just had to laugh inwardly about all this talk in the newusers group.
It sounds so much like some advanced topic going on, for which there is
the appropriate group.
Ron Parker wrote:
>
> 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.
--
omniVERSE: beyond the universe
http://members.aol.com/inversez/homepage.htm
mailto://inversez@aol.com?Subject=PoV-News
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bob Hughes <inv### [at] aolcom> wrote:
: I just had to laugh inwardly about all this talk in the newusers group.
: It sounds so much like some advanced topic going on, for which there is
: the appropriate group.
Perhaps we should learn how to use the followup-to -field.
--
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
|
|
| |
| |
|
|
|
|
| |
