> Interesting idea! But in what layer would a reflection of a refraction
> belong to?

we could do this only for primary rays, or have an option to give the trace
level we want

M

Post a reply to this message

Apache wrote:
> 
> Interesting idea! But in what layer would a reflection of a refraction
> belong to?

I think they should be a separate layer.  The whole idea sounds very
interesting but would involve quite significant changes on source level so
it seem a rather large project.

Applications would be things like all kinds of selective blurring, for
example higher quality post processed focal blur (blurring the
reflection/refraction layers separately).

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 31 Dec. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

In article <3e12c8dd$1@news.povray.org>, "Mael" <mae### [at] hotmailcom> 
wrote:

> it also would be great to have an option to output an image as multiple
> layers , a layer for each kind of contribution : diffuse, highlights,
> reflection, refraction, radiosity, photons, media ..etc So we can do
> compositing in post process (blur a reflection, add glow only on highlights,
> increase radiosity brightness, and so on without the need to re render)

That would use huge amounts of memory, and I'm not sure how useful it 
would be. Using accumulation buffers would have big limitaitions, like 
only blurring things on objects seen directly. Storing the ray trees 
would use an impractical amount of memory...maybe in a decade, but by 
then we probably won't need such tricks.

A single precision float usually takes 8 bytes. Assume we are using 
those for everything, sacrificing some precision, a tree node is:

3 floats for ambient
3 floats for diffuse
3 floats for highlights (you could probably combine all types into this 
one color, I don't think separate values for different types would be 
useful)
3 floats for reflection
5(?) floats for pigment and transparency (assuming we keep the current 
system...I think we shouldn't.)
2 node pointers (8 bytes each) for transmitted and reflected rays (it 
could be many more, but I'll assume only two)
1 float for depth
3 floats for intersection point
3 floats for normal
3 floats for ray origin
3 floats for ray direction

30 floats and 2 pointers: 256 bytes for one node. The number of nodes 
possible is 2^max depth. At the default of 7, that's 128 nodes, or 32KB 
for one pixel sample. At 1024*768, that's 32MB a line, 24.6GB total. 
Assuming no antialiasing and a lot of reflective transparent shapes. If 
there is no transparency or reflection, only 192MB. And the overhead of 
managing all that would probably destroy any benefits, especially when 
using antialiasing.

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

> That would use huge amounts of memory, and I'm not sure how useful it
> would be.
> 30 floats and 2 pointers: 256 bytes for one node. The number of nodes
> possible is 2^max depth. At the default of 7, that's 128 nodes, or 32KB
> for one pixel sample. At 1024*768, that's 32MB a line, 24.6GB total.

I wasn't talking about saving the whole rays history.. Just adding options
to output one or more kind of pixel contribution (diffuse, radiosity,
photons, etc) as a separate image. Exactly as in the post-process patch ,
but instead of keeping depth, normal, etc we'll keep diffuse, highlights, or
whatever the user asks for. So i don't think the memory overhead would be
too important.
Now you're right maybe those separate layers will not be that useful

M

Post a reply to this message

In article <3e1331bd$1@news.povray.org>, "Mael" <mae### [at] hotmailcom> 
wrote:

> I wasn't talking about saving the whole rays history.. Just adding options
> to output one or more kind of pixel contribution (diffuse, radiosity,
> photons, etc) as a separate image. Exactly as in the post-process patch ,
> but instead of keeping depth, normal, etc we'll keep diffuse, highlights, or
> whatever the user asks for. So i don't think the memory overhead would be
> too important.

My point was that you do need the ray tree to get full use of it. 
Otherwise you have to accumulate the data in a 2D buffer or only use the 
primary rays...not that helpful, and making it optional would add (a 
little) overhead even when you aren't using the feature.

I think these buffers about strike the right balance:
Raw color values (unclipped, antialiased)
first intersection depth
first intersection point
first intersection normal
first ray origin
first ray direction
object "ID" (internally object pointer)

136 bytes per pixel if all are used, a max of about 102MB for a 1024*768 
image. More reasonable, and enough for almost anything. A minimum of 
18MB for just the color information. (for comparison, a 24-bit 
uncompressed image of the same size would be 2.25MB)
I'm not sure if the other buffers should be antialiased as well...it 
doesn't really make a lot of sense, and would slow rendering.

You could get rid of ray direction and depth or intersection point, 
direction and depth can be calculated from origin and point, point can 
be calculated by direction, origin, and depth. The max memory could go 
down to 78MB. This makes more calculation later on though, keeping them 
means faster filters.
You could also use fixed point, especially for normal and direction, 
where there is a definite range of component values.

-- 
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 <cja### [at] netplexaussieorg> , 
Christopher James Huff <cja### [at] earthlinknet>  wrote:

> A single precision float usually takes 8 bytes.

Not that it changes anything about your valid argument, but (IEEE 754)
single precision floating-point numbers still take only four bytes, not
eight.

    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

In article <3E12B6DE.431E9AC3@gmx.de> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

> Yvo already explained the Mac specialties - it looks fine on:
>
> IE 5 Windows
> Mozilla 1 Windows
> Konqueror 3.0.1 Linux

Indeed, a good selection of browsers for Mac users ;-)

And the W3C once noted that IE 5.x for Mac would be very close to their HTML
and CSS recommendations.  I would provide you with a reference, but somebody
at W3C accidentally or intentionally set the <www.w3.org/MarkUp/> content
type to "application/xhtml-xml", and as IE 5.0 for Mac OS does not support
XML it is successfully locked out from this part of the W3C website...

> but it has serious problems with Netscape 4.x

Of course, as said, I didn't expect it to work.

The real problem is that Mac OS ships with IE and the Apple Help viewer.  So
it is reasonable to expect the help to work properly with at least one of
the two rather than forcing a multimegabyte download.

Besides, if DocBook and XML are so good, why does the official documentation
based on a proprietary system of extended HTML work so much better and on
all browsers?  ;-) ;-) ;-)

    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

Thorsten Froehlich wrote:
> 
> > IE 5 Windows
> > Mozilla 1 Windows
> > Konqueror 3.0.1 Linux
> 
> Indeed, a good selection of browsers for Mac users ;-)

If you buy me a Mac i will also be able to supply information on that...

> 
> The real problem is that Mac OS ships with IE and the Apple Help viewer.  So
> it is reasonable to expect the help to work properly with at least one of
> the two rather than forcing a multimegabyte download.

I really can't help much there.  Have you tried if it is better without
the style sheet?  If yes (like with NS 4.x) this would mean the problem is
in some style sheet definition.

> Besides, if DocBook and XML are so good, why does the official documentation
> based on a proprietary system of extended HTML work so much better and on
> all browsers?  ;-) ;-) ;-)

And it also produces so much better PDF output... ;-)

Chistoph 

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 31 Dec. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

Christopher James Huff wrote:
> 
> [...]
> 
> I think these buffers about strike the right balance:
> Raw color values (unclipped, antialiased)
> first intersection depth
> first intersection point
> first intersection normal
> first ray origin
> first ray direction
> object "ID" (internally object pointer)

As explained in my other post dividing the pixel colors into the different
contributing parts (i.e. reflected, refracted and direct, possibly split
into different parts) would be useful for post processing.

I think you are right to point out the memory problems.  This was a major
problem already in the original post processing patch - post processed
focal blur on a print size render was quite difficult.  Maybe it could be
avoided to have the data for the whole image in memory.  For just writing
the data to a file for processing in external programs this should not be
difficult but for internal operations this is of course quite tricky.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 31 Dec. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

In article <3E134D98.AB151D51@gmx.de>,
 Christoph Hormann <chr### [at] gmxde> wrote:

> As explained in my other post dividing the pixel colors into the different
> contributing parts (i.e. reflected, refracted and direct, possibly split
> into different parts) would be useful for post processing.

And as I explained, I don't think that would be useful enough. Aside 
from the memory problems, it is too special purpose and limited, too 
complex, and has too much impact on other things. I don't see any 
practical use for it. Saving the ray tree would be far more useful, but 
has monstrous memory requirements.

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