> 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

In article <3e1345e3$1@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

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

Thanks for the correction, I knew I should have double-checked it...

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

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

	Not really: see for instance page 19 of the current PDF docs,
there are not PDF hyperlinks and no thumbnails in the file.
	Use PDFLaTex  ;op

	- NC

Post a reply to this message

On Tue, 31 Dec 2002 21:43:19 -0500, Christopher James Huff
<cja### [at] earthlinknet> wrote:
> I've been thinking about this for a while...one thing I've always wanted 
> was a way to create different "buffers" for filter input and output. 
> That way, you could run two different filters on the raw image, and 
> combine them with another filter, or output multiple processed versions 
> of the same image.

Yes, that's exactly I have in mind. I also want to made is as pre-process for
image-maps. Not talking about connecting it with function VM.

ABX

Post a reply to this message