POV-Ray : Newsgroups : povray.unofficial.patches : 32000 radio samples (there we go again) Server Time
29 Jun 2024 00:02:38 EDT (-0400)
  32000 radio samples (there we go again) (Message 1 to 10 of 15)  
Goto Latest 10 Messages Next 5 Messages >>>
From: Apache
Subject: 32000 radio samples (there we go again)
Date: 9 Apr 2003 20:00:47
Message: <3e94b42f$1@news.povray.org>
I have a set of 32000 samples here:
http://24.132.254.156/raddist7_32000.zip. The file contains c-code and .inc
POV-Ray code. The XYZ-samples are normalized non-integer values so the
"resolution" of the values is higher than the shorts of the official
version. I'm just to lazy and weary of compiling POV-Ray now, because there
is a 50% chance or something like that for crashing my system when I try
compiling.


Post a reply to this message

From: Mael
Subject: Re: 32000 radio samples (there we go again)
Date: 10 Apr 2003 02:32:35
Message: <3e951003@news.povray.org>
> http://24.132.254.156/raddist7_32000.zip. The file contains c-code and
.inc
> POV-Ray code. The XYZ-samples are normalized non-integer values so the
> "resolution" of the values is higher than the shorts of the official
> version. I'm just to lazy and weary of compiling POV-Ray now, because
there
> is a 50% chance or something like that for crashing my system when I try
> compiling.

According to Christoph Hormann the future version of megapov will probably
allow you to specify your own samples so you could try your distribution
without compiling povray

M


Post a reply to this message

From: ABX
Subject: Why do you recompile POV (Re: 32000 radio samples (there we go again))
Date: 10 Apr 2003 02:50:57
Message: <9i4a9v4nakj6for3r24ddre7uaatg0knm1@4ax.com>
On Thu, 10 Apr 2003 08:32:40 +0200, "Mael" <mae### [at] hotmailcom> wrote:
> According to Christoph Hormann the future version of megapov will probably
> allow you to specify your own samples so you could try your distribution
> without compiling povray

Own radiosity samples distribution without recompiling.
Own camera type without recompiling.
Own antialiasing without recompiling.
Own patterns via functions.
Own ... This become a trend so I wonder what are other common purposes for
recompiling POV which can be moved from sources to scripts (except completly new
features which can't be anticipated). Are there any other propositions ?

ABX


Post a reply to this message

From: Christoph Hormann
Subject: Re: 32000 radio samples (there we go again)
Date: 10 Apr 2003 04:42:47
Message: <3E952E86.CCDE7B62@gmx.de>
Mael wrote:
> 
> According to Christoph Hormann the future version of megapov will probably
> allow you to specify your own samples so you could try your distribution
> without compiling povray

That's true.  If you supply the method used to generate those 32000
samples i will be happy to include it as a macro.

Christoph

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


Post a reply to this message

From: Apache
Subject: Re: 32000 radio samples (there we go again)
Date: 10 Apr 2003 06:16:14
Message: <3e95446e@news.povray.org>
The method is far from perfect, but here is the c code I wrote. I have been
thinking of a better way, because there there are some faint plateaus in the
distribution and we don't want that. I guess some smart jittering will get
rid of the plateaus. The algorithm is VERY SLOW, so I'm afraid that coding
it in pov SDL is completely useless!

(Code attached to this post. file extension is .cpp, but the code itself is
ANSI C.)


Post a reply to this message


Attachments:
Download 'main.cpp.txt' (11 KB)

From: Christoph Hormann
Subject: Re: 32000 radio samples (there we go again)
Date: 10 Apr 2003 06:27:04
Message: <3E9546F8.B7B3B487@gmx.de>
Apache wrote:
> 
> The method is far from perfect, but here is the c code I wrote. I have been
> thinking of a better way, because there there are some faint plateaus in the
> distribution and we don't want that. I guess some smart jittering will get
> rid of the plateaus. The algorithm is VERY SLOW, so I'm afraid that coding
> it in pov SDL is completely useless!
> 
> (Code attached to this post. file extension is .cpp, but the code itself is
> ANSI C.)

You know you should not post binary attachments in a non binary group...

Apart from that - it looks like a regular distribution.  No matter how
uniform it is this is usually a bad idea.  Most of the computations seems
to be required for sorting the samples - this can be removed when you
generate the precise number of samples you need.

Christoph

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


Post a reply to this message

From: Christoph Hormann
Subject: Re: 32000 radio samples (there we go again)
Date: 10 Apr 2003 08:01:26
Message: <3E955D15.64F8C353@gmx.de>
Apache wrote:
> 
> The method is far from perfect, but here is the c code I wrote. I have been
> thinking of a better way, because there there are some faint plateaus in the
> distribution and we don't want that. I guess some smart jittering will get
> rid of the plateaus. The algorithm is VERY SLOW, so I'm afraid that coding
> it in pov SDL is completely useless!

All right, i have done some tests, the regularity does not seem to be much
of a problem, especially if you use a subset of a generated distribution. 
But the distribution is strongly anisotropic at the lower parts of the
hemisphere.  This has been mentioned in previous discussion on this
matter, it is a problem difficult to avoid if you generate the
distribution in 2d and project it on a sphere.

Thanks for sharing the code anyway.

Christoph

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


Post a reply to this message

From: Christopher James Huff
Subject: Re: Why do you recompile POV (Re: 32000 radio samples (there we go again))
Date: 10 Apr 2003 11:19:46
Message: <cjameshuff-53E838.11183210042003@netplex.aussie.org>
In article <9i4a9v4nakj6for3r24ddre7uaatg0knm1@4ax.com>,
 ABX <abx### [at] abxartpl> wrote:

> Own radiosity samples distribution without recompiling.
> Own camera type without recompiling.
> Own antialiasing without recompiling.
> Own patterns via functions.
> Own ... This become a trend so I wonder what are other common purposes for
> recompiling POV which can be moved from sources to scripts (except completly 
> new features which can't be anticipated). Are there any other propositions ?

Objects. Just specify things like insideness, intersection, and normal 
functions.

Custom texture and interior attributes...just take the function pattern 
a bit further. New patterns, complete control over layered textures, etc.

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

From: Apache
Subject: Re: 32000 radio samples (there we go again)
Date: 10 Apr 2003 12:17:17
Message: <3e95990d$1@news.povray.org>
>this can be removed ...... you need.
What do you mean exactly?

The sorting of samples is required for finding the nearest sample at any
given point withing the disc.


Post a reply to this message

From: Christoph Hormann
Subject: Re: 32000 radio samples (there we go again)
Date: 10 Apr 2003 12:53:00
Message: <3E95A16B.2584B643@gmx.de>
Apache wrote:
> 
> >this can be removed ...... you need.
> What do you mean exactly?
> 
> The sorting of samples is required for finding the nearest sample at any
> given point withing the disc.

If you only generate the number of samples you really want to use their
order does not matter (for every direction a ray is shot, in which order
does not matter) - therefore sorting is unnecessary.

Christoph

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


Post a reply to this message

Goto Latest 10 Messages Next 5 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.