Tom Melly <tom### [at] tomandlucouk> wrote:
> Just out of curiosity, do completely transparent containers (w/o ior, etc) use
> max_trace? If so, why?

  There's no difference between a completely transparent and a semitransparent
surface from the point of view of the raytracing engine.
  How could you make it *not* to increase the recursion level if the surface
is completely transparent? If there was an easy solution, the exact same
solution could be applied always, regardless of the amount of transparency.

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

If the ray does not get refracted you do not need to shoot a new ray and 
can just pass along to the ray's next intersection. Actually if it is 
compleatly transparent and non-reflective and has no highlights you could 
just ignore the intersection at all.

- Micha

-- 
http://objects.povworld.org - the POV-Ray Objects Collection

Post a reply to this message

In article <3d624317@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   AFAIK the stack overlapping with the heap is a problem which happens only
> in Windows (and perhaps MacOS?).

Yes, but the reason is different and I assume the some problem exists on
every operating system!  Why?  Well, both Mac OS and Windows versions use
threading.  Stack space for threads has to be allocated somewhere.  And that
"somewhere" is usually the heap...

>   If I'm not completely mistaken, in most Unix systems the stack of a program
> starts from the maximum memory address which the system supports (which is
> 32-bit systems would be at least 2 gigabytes, if not 4). Since the heap starts
> from a very low memory address (typically some tens of kilobytes) it's highly
> unlikely that they will ever overlap (because usually you run out of memory
> before this happens).

Yes, but it fails with threading unless (which is possible of course, but I
don't think has ever been implemented in a widely used OS) one places the
stack into a separate address space.  This then prohibits passing of stack
variable addresses because those won't be right.  However, usually you have
a limited stack size for threads, at least that is how POSIX threads,
Windows threads and Mac OS threads work.

So all this talk about stack growing from one extreme and heap from the
others is thirty year old OS theory that is no longer relevant for modern
applications, unfortunately :-(

    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

"Warp" <war### [at] tagpovrayorg> wrote in message news:3d6243a1@news.povray.org...
> Tom Melly <tom### [at] tomandlucouk> wrote:
> > Just out of curiosity, do completely transparent containers (w/o ior, etc)
use
> > max_trace? If so, why?
>
>   There's no difference between a completely transparent and a semitransparent
> surface from the point of view of the raytracing engine.
>   How could you make it *not* to increase the recursion level if the surface
> is completely transparent? If there was an easy solution, the exact same
> solution could be applied always, regardless of the amount of transparency.

Well, I really don't know enough about the innards of POV and tracers in
general, but from an outside perspective, there is a lot of difference between
an invisible container, and a transparent surface with any kind of
ior/reflection/partial transparency.

Also, re-reading your message, I think you've misunderstood what I was asking.

I don't mean that the max_trace should or could change for invisible
containers - rather that it should be irrelevant - i.e. if the shape was such
that you would normally need to set a high max_trace, this might not be required
for perfectly transparent objects (because only the media inside the container
has an effect on the scene).

As I said, this might already be the case. Might even test it this evening....

Post a reply to this message

"Micha Riser" <mri### [at] gmxnet> wrote in message news:3d624721@news.povray.org...
>
> If the ray does not get refracted you do not need to shoot a new ray and
> can just pass along to the ray's next intersection. Actually if it is
> compleatly transparent and non-reflective and has no highlights you could
> just ignore the intersection at all.
>

This is what I was asking - are you answering my question, or just asking it
again in a more intelligible fashion? ;)

Post a reply to this message

Micha Riser <mri### [at] gmxnet> wrote:
> If the ray does not get refracted you do not need to shoot a new ray and 
> can just pass along to the ray's next intersection.

  But how do you get the "ray's next intersection" without shooting a new
ray in the same direction as the original ray, starting from the first
intersection point?

  Besides, how does the engine decide that the surface is completely
invisible?
  And even if we had a "completely invisible" type of object, what would
be the use for this kind of object? If it's completely ignored in the
intersection tests, that would be the same thing as not having the object
in the scene at all. What's the use of this kind of non-existent object?

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

Warp wrote:
> What's the use of this kind of non-existent object?

Its use mostly entails messing with your mind...

-- 
Tim Cook
http://empyrean.scifi-fantasy.com
mirror: http://personal.lig.bellsouth.net/lig/z/9/z993126

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------

Post a reply to this message

In article <3d62e0ae@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   But how do you get the "ray's next intersection" without shooting a new
> ray in the same direction as the original ray, starting from the first
> intersection point?

You already found it, you just rejected it because the first 
intersection was closer. Generate a sorted list of the intersections 
instead and step along it until you find a refracting or opaque surface.


>   Besides, how does the engine decide that the surface is completely
> invisible?

No ior specified (this is not the same as an ior of 1), a solid pigment 
of rgbf and/or rgbt 1, and no funny finish stuff. Or a simple 
"is_container" flag.


>   And even if we had a "completely invisible" type of object, what would
> be the use for this kind of object? If it's completely ignored in the
> intersection tests, that would be the same thing as not having the object
> in the scene at all. What's the use of this kind of non-existent object?

Media containers. The intersection wouldn't be totally ignored, ray 
entry/exit would still be tracked, but no texture calculations would be 
done and trace level wouldn't be incremented.
A similar thing would apply to transparent but non-refracting surfaces.

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

Christopher James Huff <chr### [at] maccom> wrote:
>>   And even if we had a "completely invisible" type of object, what would
>> be the use for this kind of object?

> Media containers. The intersection wouldn't be totally ignored, ray 
> entry/exit would still be tracked, but no texture calculations would be 
> done and trace level wouldn't be incremented.

  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?

  And not incrementing the trace level counter does not mean that there
wouldn't be as many recursion levels as intersections.

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

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

Warp wrote:
> Christopher James Huff <chr### [at] maccom> wrote:
>> Media containers. The intersection wouldn't be totally ignored, ray
>> entry/exit would still be tracked, but no texture calculations would be
>> done and trace level wouldn't be incremented.
> 
>   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?

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).

> 
>   And not incrementing the trace level counter does not mean that there
> wouldn't be as many recursion levels as intersections.

I do not understand this sentence.. too many negations in it.

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

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

-- 
http://objects.povworld.org - the POV-Ray Objects Collection

Post a reply to this message