This article has the MIME type "message/partial", which KNode cannot handle
yet. Meanwhile you can save the article as a text file and reassemble it by
hand.

And you just know that requires way to much effort :P

-- 
Rick

Kitty5 NewMedia http://Kitty5.com
POV-Ray News & Resources http://Povray.co.uk
TEL : (+44) 0845 1083740 - ICQ : 15776037

PGP Public Key : http://pgp.kitty5.com

Post a reply to this message

Rick [Kitty5] wrote:

> This article has the MIME type "message/partial", which KNode cannot
> handle yet. Meanwhile you can save the article as a text file and
> reassemble it by hand.
> 
> And you just know that requires way to much effort :P
> 

Yep. I'm trying it at the moment. Initially tried with Outlook on a
different computer and it wouldn't seem to let me save at all. i didn't
bother tinkering with it. KNode let me save, and I thought it wouldn't be
too hard to save the files and then run uudecode on them. I tried, all i
get is an error from uudecode "No 'begin' line"

so i'm probably not saving the parts seperately correctly, or not saving the
part of the text i need to save... This is my first time trying this, so i
could be going about it the wrong way completely. 

Please, Chris, post in jpeg 2000 instead! ;) just kidding. I'll try some
more later to get the things to decode properly. in the mean time, any
hints?


-ross

Post a reply to this message

Ross Litscher wrote:
> bother tinkering with it. KNode let me save, and I thought it wouldn't be
> too hard to save the files and then run uudecode on them. I tried, all i
> get is an error from uudecode "No 'begin' line"

message/partial has nothing to do with uuencode.

Just save the three parts of the file in order and concatenate them. 
There shouldn't be any need to uudecode them.

If, after you concatenate them and look at it, and it shows up as all 
letters (like undecoded uuencode) rather than an actual binary file, 
rename it to a .MIM extension and feed it into winzip to decode the mime 
encoding.

-- 
Darren New, San Diego CA USA (PST)
   I am in geosynchronous orbit, supported by
   a quantum photon exchange drive....

Post a reply to this message

In article <cjameshuff-D26DDD.14415709042004@news.povray.org> , Christopher
James Huff <cja### [at] earthlinknet>  wrote:

> MIME-Version: 1.0
> Content-Type: multipart/mixed; boundary="------------yrji_igXHWvd"
> Subject: Alternative rendering algorithm
> Message-ID: <D18### [at] earthlinknet>
>
> This is a multi-part message in MIME format.
>
> --------------yrji_igXHWvd
> Content-Type: text/plain; charset=ISO-8859-1
> Content-Transfer-Encoding: 7bit
>
> Some tests of another method for handling reflection and refraction. See
> post in povray.programming for details.
>
> fullrender.png used the traditional algorithm with 16 samples per pixel
> and took about 9 minutes.
>
> rtracecompass256.png used the per-evaluation random method, with 256
> samples per pixel. As I recall, this took 30 minutes.
>
> randompass64 used the per-pass random method with 64 samples, and took a
> little under 5 minutes to render.

Hi Chris,

I have nothing that can decode the message you posted.  You may want to give
the MT-NewsWatcher authors a nice kick in the ass and use a properly
functioning newsreader.  I know MT-NewsWatcher is a popular Mac newsreader,
but as someone who had to write a news message decoder, I can tell you it is
one of the worst newsreaders when it comes to posting what is even remotely
a valid news message <sigh>

A MIME message split using old-style Unset multipart style is definitely one
of the worst possible ideas. This is definitely not supported by any
standard :-(

    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 <40770adb@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

> A MIME message split using old-style Unset multipart style is definitely one
> of the worst possible ideas. This is definitely not supported by any
> standard :-(

The messages weren't even supposed to get sent yet...my screw up, 
getting in a hurry when my ride home arrived. Even then, I don't know 
why it did what it did...
I'm fixing things up, and will re-post later.

-- 
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 <cjameshuff-89DF8C.19212909042004@news.povray.org>,
 Christopher James Huff <cja### [at] earthlinknet> wrote:

> The messages weren't even supposed to get sent yet...my screw up, 
> getting in a hurry when my ride home arrived. Even then, I don't know 
> why it did what it did...
> I'm fixing things up, and will re-post later.

Damn software keeps trying to split them up. JPEG would probably make 
them fit, but the artifacts would get in the way of comparing the 
results. Here's the version using the traditional algorithm, with 16 
passes and a render time of 4m 9.46s:

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

Attachments:
Download 'stdtrace64.png' (106 KB)

Preview of image 'stdtrace64.png'

Post a reply to this message

Attachments:
Download 'stdtrace64.png' (1 KB) Download 'randomtrace64.png' (117 KB)

Preview of image 'randomtrace64.png'

Post a reply to this message

Attachments:
Download 'randomtrace64.png' (1 KB) Download 'randompass64.png' (109 KB)

Preview of image 'randompass64.png'

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

	I'd say that of the two single-path images, this one is better (the
other is too grainy), but I don't really see a difference with the
traditional algorithm. Since it takes about the same time to render
this doesn't show any advantage of the alternative method. Do you have
an example that renders faster with the single-path while keeping a
similar (or better) quality than the traditional?

		Jerome

Christopher James Huff wrote:
| Here's the single-path method, with random choices determined for each
| trace level for the entire image per-pass, with 64 samples and
taking 4m
| 11.16s to render:
|

- --
******************************
*      Jerome M. Berger      *
* mailto:jbe### [at] ifrancecom *
*  http://jeberger.free.fr/  *
******************************
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAd5ZNqIYJdJhyixIRArN9AKCQ5UhmO23MJqRYDeM+K9iEHsP6WwCfXGjK
5hISF+lmHHNLkjs9yLpD+cs=
=oNhP
-----END PGP SIGNATURE-----

Post a reply to this message

Christopher James Huff wrote:

> Here's the single-path, random choices per-path method, with 64 samples
> and taking 4m 5.03s to render:

Hi Christopher

The picture looks ok, but I think it would be possible to reduce the noise,
that is the variance of the sampling. 64 samples should be enough for a
clear picture. 

I have found following thesis with deals with monte carlo integration and
how to keep the variance low:

        http://graphics.stanford.edu/papers/veach_thesis/

It also introduces the "integral over all possible lightpaths" principle
wich I think is a really nice and general abstraction. I have started to
implement the bidirectional path integration method outlined in chapter 10
in my own raytracer but had to stop it due to lack of time.

- Micha

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

Post a reply to this message