|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3d635bd4@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> First it's "the intersection with an invisible object should be ignored"
> and now it should not be ignored, but taken into account.
> Can you people decide whether to make the intersection calculation or not?
It is ignored as far as texturing and lighting is concerned, only the
media matters. Or you could extend it to work with non-refracting
transparency, in which case it simply wouldn't cast extra rays for
intersection calculations it has already done.
> And not incrementing the trace level counter does not mean that there
> wouldn't be as many recursion levels as intersections.
Depends on what you mean by "recursion levels". Non-refracting
transparency would not require any new rays to be traced, so the
overhead will be much lower.
> > A similar thing would apply to transparent but non-refracting surfaces.
>
> You still need the intersection points. In order to get the intersection
> points, you need to trace rays.
Of course. Avoiding the calculation isn't the point, avoiding
recalculation of the same intersections is.
As I said above, make a list of intersections instead of throwing away
the farther ones. Do this once instead of recomputing them for every
transparent non-refracting surface. For scenes with a lot of media
containers (particle system smoke being a good example) this would be a
lot faster. All the intersections would be found the first time around,
and the code would step through the list instead of tracing additional
rays.
This would be easy without the bounding, but I don't know how well it
could be integrated with the bounding tree code. One possible problem is
that it seems to ignore objects whose bounding boxes are further than
the nearest intersection point, this logic would need to be extended to
only ignore objects with bounding boxes further than the nearest opaque
and non-refracting intersection, and it will have to return a list of
all valid intersections instead of just the nearest one.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <chr### [at] netplexaussieorg>,
chr### [at] maccom says...
> You already found it, you just rejected it because the first
> intersection was closer.
Something (nearly) unrelated wich just came to my mind while reading this
sentence:
Does POV do some kind of depth sorting?
That means, first check for intersections with the object wich bounding
box is nearest, and if an intersection is found and the intersection
point is outside the second-nearest bounding box, then don't test for
intersections with any other objects?
Lutz-Peter
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Lutz-Peter Hooge <lpv### [at] gmxde> wrote:
> Does POV do some kind of depth sorting?
> That means, first check for intersections with the object wich bounding
> box is nearest, and if an intersection is found and the intersection
> point is outside the second-nearest bounding box, then don't test for
> intersections with any other objects?
I think that the problem would be knowing which bounding box is the nearest.
This isn't necessarily an unambiguous thing.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3d754df9$1@news.povray.org>,
Lutz-Peter Hooge <lpv### [at] gmxde> wrote:
> Does POV do some kind of depth sorting?
> That means, first check for intersections with the object wich bounding
> box is nearest, and if an intersection is found and the intersection
> point is outside the second-nearest bounding box, then don't test for
> intersections with any other objects?
I don't think it does exactly what you are asking. If I recall
correctly, it does something close (and practically equivalent) though:
if the bounding box intersection is further than the best (nearest)
intersection, the object is ignored.
For this optimization, that rule would have to be changed to "further
than the nearest refracting or opaque surface".
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3d755b14@news.povray.org>, war### [at] tagpovrayorg says...
> I think that the problem would be knowing which bounding box is the nearest.
> This isn't necessarily an unambiguous thing.
The intersections with all bounding boxes will have to be computed anyway
I think?
So the idea is not to check one bounding box, then the object, then the
next bounding box etc, but first check ALL bounding boxes, then sort the
list of objects according to the proximity of the bbox intersections to
the camera, then check intersections with the objects, starting with the
first in the list.
Only additional operation would be the sorting, but if it eliminates at
least one computation intensive object it might be worth the efford I
think...
Lutz-Peter
Post a reply to this message
|
|
| |
| |
|
|
From: Lutz-Peter Hooge
Subject: Re: depth sorting (was: Re: max_trace_level)
Date: 3 Sep 2002 21:51:09
Message: <3d75670d$1@news.povray.org>
|
|
|
| |
| |
|
|
In article <chr### [at] netplexaussieorg>,
chr### [at] maccom says...
> correctly, it does something close (and practically equivalent) though:
> if the bounding box intersection is further than the best (nearest)
> intersection, the object is ignored.
Thats better than no such optimisation at all, but chances are that some
computation intensive object (isosurface landscape for example) in the
background will get unnecessary checked for intersections...
with my "algorithm" it is guarantied that this won't happen if its
bounding box is behind any other (opaque) object.
Lutz-Peter
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Lutz-Peter Hooge <lpv### [at] gmxde> wrote:
>> I think that the problem would be knowing which bounding box is the nearest.
>> This isn't necessarily an unambiguous thing.
> The intersections with all bounding boxes will have to be computed anyway
> I think?
The problem is that even when bounding box A has one side closer to
the initial point of the ray than any of the sides of bounding box B, the
intersection of the ray with the object inside B could be closer than the
one inside A (although I think this can be the case only with overlapping
bounding boxes or a bounding box containing another bounding box).
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3d757b4d@news.povray.org>, war### [at] tagpovrayorg says...
> The problem is that even when bounding box A has one side closer to
> the initial point of the ray than any of the sides of bounding box B, the
> intersection of the ray with the object inside B could be closer than the
> one inside A
This can happen, but I don't see the problem with that.
of course the optimisation won't help in this case, but it won't miss the
correct intersection either.
Only bounding boxes with their nearest intersection farther away than the
nearest intersection point of an object (NOT it's bounding box) can be
ignored.
For massively overlapping bounding boxes there won't be any speed
advantage.
Lutz-Peter
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3d757b4d@news.povray.org>, war### [at] tagpovrayorg says...
> The problem is that [...]
Also note that this "problem" is already there in the current
implementation (I looked into the source and it seems it really currently
is implemented as Christopher said -> see Intersect_BBox_Tree in
bbox.cpp). The only difference in my proposal is the sorting before
testing against any object itself.
Lutz-Peter
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3d75807d@news.povray.org>, lpv### [at] gmxde says...
> implementation (I looked into the source and it seems it really currently
> is implemented as Christopher said -> see Intersect_BBox_Tree in
> bbox.cpp).
Oops. I should have looked more carefully.
In priority_queue_insert there already is something as a sorting
algorithm. While I don't understand exactly how it works from my quick
look at it, it propably just does what I suggested...
Lutz-Peter
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |