 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
By curiosity I've rendered some images to visualize the distribution of
samples for focal blur and radiosity in povray 3.5. And also I've tried a low
discrepancy sequence (Halton sequence, it's really easy to generate)
http://195.221.122.126/samples/samples.html
M
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
1.
Should the focal blur distribution be divided in a circular area instead of
a rectangular one?
2.
I like the radiosity distribution, but maybe it would be nice to have some
more samples than 1600. What about 32768 samples? If it's just a matter of
precomputing the distribution, why not?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Apache" <apa### [at] yahoo com> wrote...
> 1.
> Should the focal blur distribution be divided in a circular area instead
of
> a rectangular one?
>
> 2.
> I like the radiosity distribution, but maybe it would be nice to have some
> more samples than 1600. What about 32768 samples? If it's just a matter of
> precomputing the distribution, why not?
Does that really look like your every-day probability distribution funciton
to you? To me it looks like the points are much more evenly spaced than any
distribution funciton I've ever seen. Notice how at samples=50, the samples
are in almost perfect rings, almost like a geodesic dome. The points are
also considerably more evenly spaced than in the Halton sequence, which
itself is intended to be low-discrepancy.
Also, as far as I know, we don't have the source code that generated the
existing 1600 samples. The file "rad_data.cpp" containing the data is
credited to Jim McElhiney.
-Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nathan Kopp wrote:
>
> Does that really look like your every-day probability distribution funciton
> to you? To me it looks like the points are much more evenly spaced than any
> distribution funciton I've ever seen. Notice how at samples=50, the samples
> are in almost perfect rings, almost like a geodesic dome. The points are
> also considerably more evenly spaced than in the Halton sequence, which
> itself is intended to be low-discrepancy.
>
> Also, as far as I know, we don't have the source code that generated the
> existing 1600 samples. The file "rad_data.cpp" containing the data is
> credited to Jim McElhiney.
>
As discussed in the thread:
Subject: Radiosity flouroescent lighting troubles
Date: Tue, 19 Nov 2002 18:43:42 EST
From: "Rohan Bernett" <rox### [at] yahoocom>
Newsgroups: povray.advanced-users
it seems to be generated by projecting a distribution on a disc onto the
hemisphere. I have made first tests with using Sim-POV to generate a
better distribution, some first results:
http://www.schunter.etc.tu-bs.de/~chris/files/samples_internal.png
http://www.schunter.etc.tu-bs.de/~chris/files/samples_simpov.png
Note that the new distribution has slightly more samples (1850) and i did
not test how well it follows the cosine theta distribution.
Another thing i have been thinking of is if it would not be better to have
a uniform distribution but weight the sample rays according to cosine
theta. At least it could be worth trying if that diminishes radiosity
artefacts in some situations. Although it seems logical that you need
less samples where the samples have not much importance the density
approaching zero at the bottom rim of the hemisphere leads to an extremely
nonuniform distribution along the rim.
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 <3E155F55.1A237A45@gmx.de> , Christoph Hormann
<chr### [at] gmxde> wrote:
> Another thing i have been thinking of is if it would not be better to have
> a uniform distribution but weight the sample rays according to cosine
> theta. At least it could be worth trying if that diminishes radiosity
> artefacts in some situations.
Keep in mind that such a method will very likely require more samples to be
taken. Most pseudo-random functions simply don't give you too nice values
for a small set of samples (like the 35 default). My guess (or hope?) is
that the current table has been tweaked accordingly for small sample sets.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I remember reading that the Mersenne Twister algorithm (and I think there
are various improvements to it now) is supposed to be a very good, fast
pseudorandom generator. Has anyone looked into it yet?
George
"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3e157f92$1@news.povray.org...
> In article <3E155F55.1A237A45@gmx.de> , Christoph Hormann
> <chr### [at] gmxde> wrote:
>
> > Another thing i have been thinking of is if it would not be better to
have
> > a uniform distribution but weight the sample rays according to cosine
> > theta. At least it could be worth trying if that diminishes radiosity
> > artefacts in some situations.
>
> Keep in mind that such a method will very likely require more samples to
be
> taken. Most pseudo-random functions simply don't give you too nice values
> for a small set of samples (like the 35 default). My guess (or hope?) is
> that the current table has been tweaked accordingly for small sample sets.
>
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Here is the MT homepage: http://www.math.keio.ac.jp/~matumoto/emt.html
>
> I remember reading that the Mersenne Twister algorithm (and I think there
> are various improvements to it now) is supposed to be a very good, fast
> pseudorandom generator. Has anyone looked into it yet?
>
> George
>
>
> "Thorsten Froehlich" <tho### [at] trfde> wrote in message
> news:3e157f92$1@news.povray.org...
> > In article <3E155F55.1A237A45@gmx.de> , Christoph Hormann
> > <chr### [at] gmxde> wrote:
> >
> > > Another thing i have been thinking of is if it would not be better to
> have
> > > a uniform distribution but weight the sample rays according to cosine
> > > theta. At least it could be worth trying if that diminishes radiosity
> > > artefacts in some situations.
> >
> > Keep in mind that such a method will very likely require more samples to
> be
> > taken. Most pseudo-random functions simply don't give you too nice
values
> > for a small set of samples (like the 35 default). My guess (or hope?)
is
> > that the current table has been tweaked accordingly for small sample
sets.
> >
> > 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> http://www.schunter.etc.tu-bs.de/~chris/files/samples_simpov.png
it looks good, does it take a long time to create this distribution ?
Anyway, as far as radiosity speed is concerned it would be more interesting to
find a way to make better use of the existing directions rather than adding
more call to trace() :) For example would it be possible to use an adaptive
number of samples ? it seems that when we specify "count 1600" povray will
always shoot 1600 rays at samples locations, although there are probably some
places where less rays are needed... The focal blur uses confidence/variance
to decide when to stop sending rays. Do you think we can do something like
this for radiosity ?
M
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3e15944c$1@news.povray.org> , "George Pantazopoulos"
<the### [at] attbicom*KILLSPAM*> wrote:
> I remember reading that the Mersenne Twister algorithm (and I think there
> are various improvements to it now) is supposed to be a very good, fast
> pseudorandom generator. Has anyone looked into it yet?
Well, finding a good random number algorithm isn't the main problem if one
ignores performance. But performance is the main catch here! And the
implementations I have seen clearly leads to terrible performance.
Completely unsuitable for the expected use:
After all the algorithms to be used have to compete against one single plain
memory access. And an Mersenne Twister implementations need more than five
times 623 (the dimensional equidistribution property) memory accesses. In
short it is roughly more than 3000 times(!!!) slower than the current
implementation! :-(
So in the time to compute one Mersenne Twister algorithm random number, for
most scenes* a whole ray can be traced...
Thorsten
* "most" because intersections with a certain object types can take almost
infinitely long - an isosurface. And note that really only one intersection
needs to be computed per ray when proper bounding is used and all objects
are bound.
____________________________________________________
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mael wrote:
>
> > http://www.schunter.etc.tu-bs.de/~chris/files/samples_simpov.png
>
> it looks good, does it take a long time to create this distribution ?
I did not write down the time for that one but i later did some tests with
4000 points and it needed at least 1 hour to reach a usable state.
> Anyway, as far as radiosity speed is concerned it would be more interesting to
> find a way to make better use of the existing directions rather than adding
> more call to trace() :) For example would it be possible to use an adaptive
> number of samples ? it seems that when we specify "count 1600" povray will
> always shoot 1600 rays at samples locations, although there are probably some
> places where less rays are needed... The focal blur uses confidence/variance
> to decide when to stop sending rays. Do you think we can do something like
> this for radiosity ?
I have made some tests with adapting the count dynamically before:
http://www-public.tu-bs.de:8080/~y0013390/simpov/docu04.html
but the problem is to find a fast criteria for the adaptation. As
explained concentrating the sample rays at a certain area might seem
logical but would be really tricky and possibly slow. The method i used
just checks the distances of the intersection points which have to be
calculated anyway.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
>
> > Another thing i have been thinking of is if it would not be better to have
> > a uniform distribution but weight the sample rays according to cosine
> > theta. At least it could be worth trying if that diminishes radiosity
> > artefacts in some situations.
>
> Keep in mind that such a method will very likely require more samples to be
> taken. Most pseudo-random functions simply don't give you too nice values
> for a small set of samples (like the 35 default). My guess (or hope?) is
> that the current table has been tweaked accordingly for small sample sets.
Methods based on repulsion/minimizing potential energy should work equally
well with both high and low number of samples. But for using the same set
for both low and high number of samples is important to have a good way of
sorting them. It has been mentioned before that the set of samples right
now in POV-Ray is only quite uniform at certain numbers of samples.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The distribution of the focal blur samples is fine to me, but shouldn't the
total area be a circle instead of a rectangular area?
And about the radiosity samples, I think that the distribution is just fine.
We just need some MORE samples :-) I think I'm going to find a way to get
more samples this weekend. The more the better :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> samples for focal blur
As Apache, I'm surprised to see the distribution fills a square
and not a circle. Actually the first 20 samples clearly show that
the circle is the target, which is logical (I kinda remind that
the 3.1g source code tells it).
Could you just explain how you obtain those pictures for
the focal blur distribution ?
On another hand, assuming the distribution is really in a
circle, I guess it could be worth using a Halton sequence when more
than 50 samples (or 37 according to hexgrid4size in render.cpp) are
requested.
- NC
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I have made some tests with adapting the count dynamically before:
> http://www-public.tu-bs.de:8080/~y0013390/simpov/docu04.html
I see you have already explored all this a lot, I better stop looking at
radiosity I guess :)
M
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3e157f92$1@news.povray.org>,
"Thorsten Froehlich" <tho### [at] trfde> wrote:
> Keep in mind that such a method will very likely require more samples to be
> taken.
Probably...but it looks like many artifacts are due to low sample
density in the "low" areas: a couple near-tangent samples hit a bright
source, but no others do. At that point, you could already have enough
near-perpendicular samples for a good approximation, but increasing
samples mainly adds more there. It might be worth it to add some kind of
switch. Maybe combine the two...the even distribution method would
probably be slower, because it has to weight the samples. You could use
some samples on the variable distribution, and use any left over on the
even distribution to fill in any gaps, keeping some benefit from each.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> As Apache, I'm surprised to see the distribution fills a square
> and not a circle. Actually the first 20 samples clearly show that
> the circle is the target, which is logical (I kinda remind that
> the 3.1g source code tells it).
> Could you just explain how you obtain those pictures for
> the focal blur distribution ?
I output the Sample_Grid array to a text file for a focal blur of 300
samples.
(and if you look into the mlpov documentation at bokeh_pigment you will see
an image that clearly shows that pov uses a uniform distribution in a
square)
M
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> (and if you look into the mlpov documentation at bokeh_pigment you will see
> an image that clearly shows that pov uses a uniform distribution in a
> square)
Yes-yes, I mostly read this part of the mlpov-0.81 docs a few
days ago when you put them online - it's in french but so am I :o)
I (tried to) study the focal blur method in POV about two
years ago an could not get a better result. In particular to avoid
the grainy effect that appears on solid color textures even with
high sample count and all samples taken, i.e. 'variance 0' AFAIR.
Nowadays I don't remember the details of the implementation, but
I was pretty sure the samples would be all contained in a disc
(without jittering), since a camera diaphragm/aperture is made of
lamels which approximate a circle. Now I'm maybe confusing with
the need to sample the whole pixel area...
I suppose this is what you wanted to test, using an hexagon
pattern in mlpov. You're setting max. 4000 samples so it's impossible
to see the effect on grainyness on your images (could you setup some
test image which is easier to read, with focusing on a particular
sphere ?). On the demo page you presented on this thread, the original
POV method clearly shows "defects" near the diagonals at 300 samples.
I believe that the Halton distribution would help reducing this effect.
Is it already included in mlpov ?
- NC
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I suppose this is what you wanted to test, using an hexagon
> pattern in mlpov. You're setting max. 4000 samples so it's impossible
> to see the effect on grainyness on your images (could you setup some
> test image which is easier to read, with focusing on a particular
> sphere ?). On the demo page you presented on this thread, the original
> POV method clearly shows "defects" near the diagonals at 300 samples.
> I believe that the Halton distribution would help reducing this effect.
> Is it already included in mlpov ?
no it's not, but it's not complicated to add if wanted. The sampling for the
bokeh patch is also really badly done I think, so if I have time I may try
to correct this too in a future version
M
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christoph Hormann" <chr### [at] gmxde> wrote...
>
>
> Mael wrote:
> >
> > > http://www.schunter.etc.tu-bs.de/~chris/files/samples_simpov.png
> >
> > it looks good, does it take a long time to create this distribution ?
>
> I did not write down the time for that one but i later did some tests with
> 4000 points and it needed at least 1 hour to reach a usable state.
ouch. that's a long time! :-(
The sample points look great, though.
...although though it doesn't look like it is exactly the same distribution
as POV's original sample list.
-Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christoph Hormann" <chr### [at] gmxde> wrote...
>
> Methods based on repulsion/minimizing potential energy should work equally
> well with both high and low number of samples. But for using the same set
> for both low and high number of samples is important to have a good way of
> sorting them. It has been mentioned before that the set of samples right
> now in POV-Ray is only quite uniform at certain numbers of samples.
True. It seems POV's sample list has been optimized for specific numbers of
samples. Does anybody know which sample counts produce the most evenly
distributed samples?
Also, this brings up a good point that if we can find a fast way to generate
a new set of samples for each render, we could theoretically come up with
better distributions for all sample counts. The key here is to be able to
generate a good sample list quickly. Another benefit to creating a custom
sample list for each render is that we could create sample lists for things
other than the standard lambertian cos-theta distribution. This would
potentially allow us to produce more realistic results for a wider range of
surface materials.
Also note that such sample-generating code could be useful for photon
mapping. The current photon mapping implementation creates a fake
distribution by shooting photons in a spiral and jittering the results.
While this generally produces good results, it can also lead to artefacts if
the jitter value is too small, and can also lead to uneven samples if the
jitter value is too large.
-Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nathan Kopp wrote:
>
> Also, this brings up a good point that if we can find a fast way to generate
> a new set of samples for each render, we could theoretically come up with
> better distributions for all sample counts. The key here is to be able to
> generate a good sample list quickly.
I doubt that such a 'fast and good' algorithm is possible. Apart from
that you have the problem that it is not known in advance which samples
from the table are used (see the 'while(rayOk...' loop in radiosit.cpp).
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I have made some first actual renders with new distributions, here are
some results:
http://www.schunter.etc.tu-bs.de/~chris/files/rad_test.html
The sample sets i generated have 300 samples which are sorted afterwards
for best results at lower count values. The scene uses a count of 50.
Sorting is somewhat tricky with non uniform distributions so the 50
samples are probably quite different from a perfect cosine theta
distribution.
The first two images are the old and the new distribution. It can be seen
that the differences are not that strong but i think that the second one
is somewhat better. Testing with a distribution optimized for exactly 50
samples could be worth trying too.
The third image shows the result when using a completely uniform
distribution and weighting the samples according to cosine theta. The
result seems worse although a final conclusion would require further
tests. The interesting thing is that turning off the different weighting
strongly weakens the artefacts (fourth image).
The final image shows the same settings with randomly rotated sample set
(based on an idea by Michael Andrews:
Subject: Fluorescent strip radiosity test scene (22K + 24K)
Date: Thu, 28 Nov 2002 13:25:06 +0000
From: Michael Andrews <m.c### [at] readingacuk>
Newsgroups: povray.binaries.images
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann wrote:
> I have made some first actual renders with new distributions, here are
> some results:
I'm curious -- could you also try random sampling, without using precomputed
tables?
Anders
--
#macro E(D)(#if(D<2)D#else#declare I=I+1;mod(pow(.5mod(I 6))*asc(substr(
"X0(1X([\\&Q@TV'YDGU`3F(-V[6Y4aL4XFUTD#N#F8\\A+F1BFO4`#bJN61EM8PFSbFA?C"
I/6 1))2)<1#end)#end#macro R(D,I,T,X,Y)#if(E(D))R(D-1I,T,Y/2X)R(D-1I,T+Y
/2Y/2X)#else box{T T+X+Y pigment{rgb E(2)*9}}#end#end R(10,5z*3-1v*2u*2)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Anders K. <and### [at] kaseorgcom> wrote:
> I'm curious -- could you also try random sampling, without using precomputed
> tables?
I would guess that this might add more graininess to the lighting, as the
amount and color of the light will change more randomly from one sampling
point to the next. This might also make it slower as the algorithm can't
reuse old values so often (because now they change more than the error bound
threshold more often).
(Naturally I can't know for sure as I only have a vague idea about how
Ward's stochastic global illumination algorithm works. This was just a
guess.)
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> The third image shows the result when using a completely uniform
> distribution and weighting the samples according to cosine theta. The
> result seems worse although a final conclusion would require further
> tests. The interesting thing is that turning off the different weighting
> strongly weakens the artefacts (fourth image).
there is an error in the comment in povray source code, the samples are
distributed according to cos(theta)*sin(theta) (we can also confirm this by
looking at the illuminance integral)
I've made a graph with the distribution for the pov samples (compared to cos
and cos*sin) at http://195.221.122.126/samples/proba.jpg
M
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mael wrote:
>
> there is an error in the comment in povray source code, the samples are
> distributed according to cos(theta)*sin(theta) (we can also confirm this by
> looking at the illuminance integral)
> I've made a graph with the distribution for the pov samples (compared to cos
> and cos*sin) at http://195.221.122.126/samples/proba.jpg
I am not sure what you measure in that graph but when i talk about 'cosine
theta distribution' i mean the density of the samples (i.e. the inverse of
the mean distance between samples). Of course there are very few samples
at small theta because the region of the hemisphere with small theta is
small - none the less the density is high.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I am not sure what you measure in that graph
This graph shows the probability to have a ray for a given theta (theta =
deviation / normal)
M
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
And the same for the halton sequence :
http://195.221.122.126/samples/proba2.jpg
M
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I am not sure what you measure in that graph but when i talk about 'cosine
> theta distribution' i mean the density of the samples (i.e. the inverse of
> the mean distance between samples). Of course there are very few samples
> at small theta because the region of the hemisphere with small theta is
> small - none the less the density is high.
ok, i understand, if I divide by the area for a theta, I will get the
cos(theta) distribution
this is more clear now :)
M
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mael wrote:
>
> > I am not sure what you measure in that graph
>
> This graph shows the probability to have a ray for a given theta (theta =
> deviation / normal)
This is of course something different. I think the sin(theta) factor is
logical then.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I was thinking about computing the discrepancy (for different numbers of
samples), to see what are the best values for count with the current samples
data in pov
I found a description to compute the star discrepancy, but only for uniform
distribution in a unit square
http://mathworld.wolfram.com/StarDiscrepancy.html
http://ina.eivd.ch/Collaborateurs/etr/research.html
As i don't know how to adapt it for a disc, I decided to map the disc to a
square
(x,y) the sample in the disc gives nx=x*x+y*y and ny=atan2(y,x)/(2*pi)+.5 in
the square unit
But when applying this transformation to povray samples I get those bad
looking results (at least for small N)
http://195.221.122.126/samples/rad_square010.jpg
http://195.221.122.126/samples/rad_square020.jpg
http://195.221.122.126/samples/rad_square050.jpg
http://195.221.122.126/samples/rad_square100.jpg
So I wonder if it's a good way to measure the discrepancy
Or is the povray distribution not that good ?
M
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mael wrote:
> As i don't know how to adapt it for a disc, I decided to map the disc to a
> square
That would distort the disc in all sorts of ways, so the bad results aren't
surprising.
Anders
--
#macro E(D)(#if(D<2)D#else#declare I=I+1;mod(pow(.5mod(I 6))*asc(substr(
"X0(1X([\\&Q@TV'YDGU`3F(-V[6Y4aL4XFUTD#N#F8\\A+F1BFO4`#bJN61EM8PFSbFA?C"
I/6 1))2)<1#end)#end#macro R(D,I,T,X,Y)#if(E(D))R(D-1I,T,Y/2X)R(D-1I,T+Y
/2Y/2X)#else box{T T+X+Y pigment{rgb E(2)*9}}#end#end R(10,5z*3-1v*2u*2)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
