Micha Riser <mri### [at] gmxnet> wrote:
> Ignored in respect to texture calculations and shooting new rays. The 
> intersection calculation has to be made anyways (otherwise you could not 
> know that the invisible object is hit at all).

  No. Intersection calculations don't need "to be made anyways". If you
don't want to test intersections for a certain object, then just ignore
that object when making intersection calculations.

> You already have calculated all intersections for this ray so you need no 
> new intersection calculations for the intersection after the transparent 
> object.

  I think that would be pretty similar to what shadow testing rays do.

-- 
#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 <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

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