Claude Mench <c.m### [at] adilinstrumentscom> wrote ...
>     Thank's for your answer, I read your papers about the photon mapping
> in UVPov and also Jensens original one. I have one question, You are use
> your own sampling method for light ray with your spiral sampling and said
> that Jensens methods gives noisy results. But the images i've seen from
> Jensen are not noisy. Does your sampling method give an performance hurt
> compared to Jensen's ?

I have been able to get OK results with pure random shooting, but I always
had to shoot a very large number of photons.  Using my jittered spiral
technique, I am able to get very good results with few photons.  If
anything, it should offer better performance than a totally random method
(or even a weighted monte-carlo method).

I still don't know exactly how Jensen got the good results that he got with
his monte-carlo photon tracing.

-Nathan

Post a reply to this message

Sorry, I can't spent much time thinking about this here at work... :(
I'll "work" on this this week-end.
On first read, I didn't quite follow the math, but I think it will become
much clearer tomorrow (I have quite important work things on my mind right
now)

Please hold <Vivaldi's Dmin concerto> Ta di da ta tii tadaa tee daa...



Philippe

Post a reply to this message

<Vivaldi's Dmin concerto> Ta di da ta tii tadaa tee daa...
</Vivaldi's Dmin concerto>
Sorry, I had very little time this week-end (and I still had no time to try
other newsreaders either)
:-(

And I have no time now... :-( :-( :-(

<Vivaldi's Dmin concerto> Ta di da ta tii tadaa tee daa...

Philippe

Post a reply to this message

On Mon, 6 Dec 1999 15:42:52 +0100, "Claude Mench"
<c.m### [at] adilinstrumentscom> wrote:

>        - Is there an official binary format of scene file
>          planned ?
>

Well, a .zip compressed archive with filenames taken with a bit of
care (8+3 lowercase names) seems (at least for me) pretty standard
between platforms. ;-)

Post a reply to this message

In article <sbvf5sgo1utia3vic03fgnad8ohe86gb8g@4ax.com>, Joaquin Hierro 
Diaz <jhi### [at] cticsices> wrote:

> Well, a .zip compressed archive with filenames taken with a bit of
> care (8+3 lowercase names) seems (at least for me) pretty standard
> between platforms. ;-)

Hmn, would it be useful or feasible to allow POV to read .zip files 
directly? Are there any license restrictions on .zip compression, or any 
other reason this wouldn't be done?

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

> Hmn, would it be useful or feasible to allow POV to read .zip files
> directly? Are there any license restrictions on .zip compression, or any
> other reason this wouldn't be done?

I don't know if there are any license restrictions on the zip format
(which, I believe, was invented by PKWare in their PKZip product).
However, if PKZip (and the zip file format) uses LZW compression,
there is indeed a huge legal stink going on. Unisys is claiming that
anyone who uses, creates, downloads, or otherwise even thinks about
any software that reads, writes, translates, or otherwise processes
practically anything that even touches LZW needs a written license
from them. Their Web site includes in this blanket statement such things
as the PDF file format used by Adobe Acrobat, Postscript-2, the
V.42bis modem technology, and others. If one were to add the ability
to read LZW-compressed material into POV-Ray, the way the Unisys site
reads, the authors of the code, the users of the resultant program,
and anyone who downloaded an image created with the code would be
liable for patent infringement litigation.

Read all about it at http://www.unisys.com/unisys/lzw

(BTW, according to the GNU Web site, this whole stink is why GNU
zip was created, to get around legal entanglements with the
compress program, which uses LZW. This is also why their site
boasts of using no GIF files, as GIF files use LZW compression.)

Post a reply to this message

Steve Martin wrote:
> 
> > Hmn, would it be useful or feasible to allow POV to read .zip files
> > directly? Are there any license restrictions on .zip compression, or any
> > other reason this wouldn't be done?
> 
> I don't know if there are any license restrictions on the zip format
> (which, I believe, was invented by PKWare in their PKZip product).
> However, if PKZip (and the zip file format) uses LZW compression,
> there is indeed a huge legal stink going on. Unisys is claiming that
> anyone who uses, creates, downloads, or otherwise even thinks about
> any software that reads, writes, translates, or otherwise processes
> practically anything that even touches LZW needs a written license
> from them. Their Web site includes in this blanket statement such things
> as the PDF file format used by Adobe Acrobat, Postscript-2, the
> V.42bis modem technology, and others. If one were to add the ability
> to read LZW-compressed material into POV-Ray, the way the Unisys site
> reads, the authors of the code, the users of the resultant program,
> and anyone who downloaded an image created with the code would be
> liable for patent infringement litigation.
> 
> Read all about it at http://www.unisys.com/unisys/lzw
> 
> (BTW, according to the GNU Web site, this whole stink is why GNU
> zip was created, to get around legal entanglements with the
> compress program, which uses LZW. This is also why their site
> boasts of using no GIF files, as GIF files use LZW compression.)

POV-Ray already uses LZW (support for GIF's as heightfields).  I'm not
sure we have a written agreement with Unisys, since that feature
predates my joining the team.  I'll ask.  If it becomes a serious
problem, we also support PNG heightfields.

POV-Ray also uses (as part of PNG support) zlib, which includes
functions that provide support for GNU zipped files.  The gzip manual
page says that gzip and PKZip both use Lempel-Ziv rather than LZW, so
that should be completely clear of problems.

That handles feasibility.  So, how useful do people think such a thing
would be?

-Mark Gordon

Post a reply to this message

Mark Gordon wrote:

> POV-Ray also uses (as part of PNG support) zlib, which includes
> functions that provide support for GNU zipped files.  The gzip manual
> page says that gzip and PKZip both use Lempel-Ziv rather than LZW, so
> that should be completely clear of problems.
> 
> That handles feasibility.  So, how useful do people think such a thing
> would be?
> 
> -Mark Gordon

I know one suggestion comes up from time to time and that is the ability
to zip image files on the fly for animation work. This is especialy true
for file types like .tga and .bmp which do not offer built in compression
methods. I have heard a couple of people mention that this can already
be done with shell commands but it would be nice if it was done internaly
to reduce cycle times during high frame count animations.

-- 
Wishing you Seasons Greetings, A Merry Christmas, and A Happy New Year !

Post a reply to this message

Zip Magic can do it.
Anyway, if someone is curious and doesn't know of it yet Zip Magic is at
www.mijenix.com
Not only programs in Windows but DOS utilities can see the zip "folder" as
well.  Just made a quick check and it was about a 5 times difference from
uncompressed tga files and pretty much a unnoticeable background occurance.
I don't need to save disk space at the moment but if I ever do this will do
fine I believe.

Bob

"Ken" <tyl### [at] pacbellnet> wrote in message
news:385862C6.C5CC87EA@pacbell.net...
>
>
> Mark Gordon wrote:
>
> > POV-Ray also uses (as part of PNG support) zlib, which includes
> > functions that provide support for GNU zipped files.  The gzip manual
> > page says that gzip and PKZip both use Lempel-Ziv rather than LZW, so
> > that should be completely clear of problems.
> >
> > That handles feasibility.  So, how useful do people think such a thing
> > would be?
> >
> > -Mark Gordon
>
> I know one suggestion comes up from time to time and that is the ability
> to zip image files on the fly for animation work. This is especialy true
> for file types like .tga and .bmp which do not offer built in compression
> methods. I have heard a couple of people mention that this can already
> be done with shell commands but it would be nice if it was done internaly
> to reduce cycle times during high frame count animations.
>
> --
> Wishing you Seasons Greetings, A Merry Christmas, and A Happy New Year !

Post a reply to this message

Mark Gordon wrote:

> POV-Ray already uses LZW (support for GIF's as heightfields).  I'm not
> sure we have a written agreement with Unisys, since that feature
> predates my joining the team.  I'll ask.  If it becomes a serious
> problem, we also support PNG heightfields.

Unisys' claims are fairly extensive, but many in the field believe that their
patent only applies to creation, not to using. Thus, viewing GIF might be fine
even though you need a license from them to create them. Of course, if you
belonged to a large company with some decent pockets you could actually test
this in court. Just because you are right, doesn't mean it would be cheap :-(

(Remember, I am not a lawyer. Consult your attourney for actual advice)

--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.

Post a reply to this message