Toying with isosurfaces (pov v3.5RC6), I found a quite visible grid
artifact... I don't know what to make of it. Should I make a bug report ? It
is so basic [just function{-z+f_noise3d(x,y,z)}] that I find it very
unlikely that it is unknown. But searching with http://news.povray.org
yielded no answer... So, could anyone check this
http://web.wanadoo.be/wbrp0009/pov/main.html and tell me what to do with it.


Povingly,


Philippe

Post a reply to this message

have you played with accuracy settings ?

Post a reply to this message

"Jan Walzer" <jan### [at] lzernet> wrote in message
news:3d14aa3d$1@news.povray.org...
> have you played with accuracy settings ?


Yes. It's one of the first thing I tried after checking the gradient /
avaluate. The grid is visible from accuracy at accuracy 1e-1, 1e-2, ...,
1e-6. I went no further.

Post a reply to this message

"Philippe Debar" <phd### [at] belgacomnet> schrieb im Newsbeitrag
news:3d14a873@news.povray.org...

> So, could anyone check this
> http://web.wanadoo.be/wbrp0009/pov/main.html and tell me what to do with
it.

For what it's worth, I would say: Make a bug report in p.b-t. They will fix
it, or tell you that this is the way they want it to work. There were some
changes to the noise-functions in RC6, as changes.txt tells - maybe
something went wrong. Judging from the web-page you made, f_noise looses a
lot of it's functionality if it stays the way it is - who would want some
noise with a grid?

But I did no own test so, I really don't know what it's worth. At least I
can't remember such artefacts in MegoPov or earlier Versions of 3.5.

Greetings,

Marc-Hendrik

Post a reply to this message

Philippe Debar <phd### [at] belgacomnet> wrote:
> Toying with isosurfaces (pov v3.5RC6), I found a quite visible grid
> artifact... I don't know what to make of it. Should I make a bug report ? It
> is so basic [just function{-z+f_noise3d(x,y,z)}] that I find it very
> unlikely that it is unknown.

  This is known to the team, so no need to report it.
  The exact reason for this is not clear (it might not be a bug at all, but
the noise_generator 3 might just produce that; better alternatives may be
studied).
  Use noise generators 1 or 2 instead (I think it was f_noise_generator()
if you want to use another noise generator instead of the default, which
is 3).

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

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3d14be16@news.povray.org...

>   This is known to the team, so no need to report it.

Mmmh ! I guessed so ;-)

>   The exact reason for this is not clear (it might not be a bug at all,
but
> the noise_generator 3 might just produce that; better alternatives may be
> studied).

I've got the feeling we'll have to wait for 3.5b or MegaPov-the-next-gen.

>   Use noise generators 1 or 2 instead (I think it was f_noise_generator()
> if you want to use another noise generator instead of the default, which
> is 3).

Noise gen 1 and 2 suffer from the same problem, see
http://web.wanadoo.be/wbrp0009/pov/main.html, 5th and 6th images.
:-(


Philippe

Post a reply to this message

In article <3d14a873@news.povray.org> , "Philippe Debar" 
<phd### [at] belgacomnet> wrote:

> http://web.wanadoo.be/wbrp0009/pov/main.html

It would really help if the image source URLs would be valid.  That is
spaces encoded as required so they work outside broken browsers like
Internet Explorer...

    Thorsten

Post a reply to this message

I had no problems with the URL. (IE6, win2k)

--
Apache
POV-Ray Cloth experiments: http://geitenkaas.dns2go.com/experiments/
Email: apa### [at] yahoocom
ICQ: 146690431

Post a reply to this message

"Apache" <apa### [at] yahoocom> wrote:
> I had no problems with the URL. (IE6, win2k)

did you read Thorstens whole answer ?
he said:
> "spaces encoded as required so they work outside broken
>  browsers like..."

Post a reply to this message

Ooops ! Sorry, my first web experience. I plead ignorance. I change that
right away (and I thought I
could go to sleep now...*sigh*). I removed the spaces as I do not know how
they have to be encoded - and right know, I choose sleep over knowledge
;-) I also removed uppercases, just in case <g>.


Philippe


"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3d14cc87@news.povray.org...
> In article <3d14a873@news.povray.org> , "Philippe Debar"
> <phd### [at] belgacomnet> wrote:
>
> > http://web.wanadoo.be/wbrp0009/pov/main.html
>
> It would really help if the image source URLs would be valid.  That is
> spaces encoded as required so they work outside broken browsers like
> Internet Explorer...
>
>     Thorsten
>

Post a reply to this message

Not yet

--
Apache
POV-Ray Cloth experiments: http://geitenkaas.dns2go.com/experiments/
Email: apa### [at] yahoocom
ICQ: 146690431

Post a reply to this message

All the noise generators suffer from this. It's most easily seen when
they're applied as the function for a height field, viewed at a shallow
angle.

At first I was a bit annoyed by this, but having looked at the 3.1 source in
the past, I know that it's caused by the way the noise functions are
created. They are *based* on a grid pattern of random values, which are
interpolated between. I'm not sure exactly how the new noise generator
works, but since it shows the same artifact, I assume it's similar.

I wish there were a better way to create random noise, but I sure as heck
couldn't come up with one.

The artifact is caused by the fact that while the first derivative of the
function is continuous everywhere, the *second* derivative isn't necessarily
continuous at any of the integral values of x,y, or z.

The best workaround I can think of, if it's causing any problems, is to add
turbulence to the noise.

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

In article <3d151ea4@news.povray.org> , "Philippe Debar" 
<phd### [at] belgacomnet> wrote:

> Ooops ! Sorry, my first web experience. I plead ignorance. I change that
> right away (and I thought I

Ok :-)

> could go to sleep now...*sigh*). I removed the spaces as I do not know how
> they have to be encoded

Using their ASCII code in hexadecimal notation with a percent sign:  %20

____________________________________________________
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 <3d14a873@news.povray.org> , "Philippe Debar" 
<phd### [at] belgacomnet> wrote:

> Toying with isosurfaces (pov v3.5RC6), I found a quite visible grid
> artifact... I don't know what to make of it. Should I make a bug report ? It
> is so basic [just function{-z+f_noise3d(x,y,z)}] that I find it very
> unlikely that it is unknown. But searching with http://news.povray.org
> yielded no answer... So, could anyone check this
> http://web.wanadoo.be/wbrp0009/pov/main.html and tell me what to do with it.

OK, could you either post here or place on the site a short complete sample
scene for at least the first image, please?

    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 <3d154105@news.povray.org> , "Slime" <slm### [at] slimelandcom> wrote:

> I wish there were a better way to create random noise, but I sure as heck
> couldn't come up with one.
>
> The artifact is caused by the fact that while the first derivative of the
> function is continuous everywhere, the *second* derivative isn't necessarily
> continuous at any of the integral values of x,y, or z.

Your obervation might be correct also not worded very well, I have noticed a
similar "defect" and I actually think I know why it is there.

    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 implemented myself Perlin noise and got the same bug. Double/triple check 
the way you interpolate the values on non grid points: the code of the 
s's/t's (or whatever you call the interpolation fractions) is handled 
exactly the opposite on might resonably think (I consider Perlin noise code 
one of the most counterintuive algorithms I have ever implemented/debugged).

By the way, if POV had been a free software project, handled with CVS I 
would have fixed the bug more than one month ago...

Bye

-- 
Alessandro Coppo
a.coppo@<REMOVE_ME>iol.it
www.geocities.com/alexcoppo

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3d158f58@news.povray.org...
> In article <3d14a873@news.povray.org> , "Philippe Debar"
> <phd### [at] belgacomnet> wrote:

> OK, could you either post here or place on the site a short complete
sample
> scene for at least the first image, please?


Done. Zipped scene file in p.beta-test.binaries. Small animation that
renders the following scenes :
0) the simple f_noise3d on a plane
1) the "differenced" (there must be a proper name for this...) f_noise3d on
a plane
2) same with noise gen 1
3) same with noise gen 2
4) the "differenced", noise_gen 3, f_noise3d on a sphere
5) the pure f_noise3d on a sphere

I will post the others soon, but I have to tidy the code up and my parents
are waiting me for dinner at their place + I still have to complete my
income declaration :-(, so no Pov nor post for some hours...


Povingly,

Philippe

PS : I made a copy of the web page
http://web.wanadoo.be/wbrp0009/pov/qbugs/noisegrid/main.html at, in order to
be able to free pov/main one day... at the time being (and for some long
time I think), the two urls work.

Post a reply to this message

Alessandro Coppo <a.c### [at] iolit> wrote:
> By the way, if POV had been a free software project, handled with CVS I 
> would have fixed the bug more than one month ago...

  Hmm... What stops you from posting a full report of the suggested fix
to this news server?

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

In article <3d159249$1@news.povray.org> , Alessandro Coppo <a.c### [at] iolit>
wrote:

> By the way, if POV had been a free software project, handled with CVS I
> would have fixed the bug more than one month ago...

If you had looked at the Perlin noise function code available for years now
in 3.1 and previous versions you should have been able to notice the same
bug and could have tried to fix it...

    Thorsten

Post a reply to this message

...
> At first I was a bit annoyed by this, but having looked at the 3.1 source
in
> the past, I know that it's caused by the way the noise functions are
> created. They are *based* on a grid pattern of random values, which are
> interpolated between. I'm not sure exactly how the new noise generator
> works, but since it shows the same artifact, I assume it's similar.

You're right.
Supposing f_noise3d is an implementation of Perlin noise, it belongs to a
class of noises called "gradient lattice" noises in which the noise values
at fractional positions are calculated interpolating "pseudorandom slope
vectors" precalculated at the intersection of an integer grid. At integer
position the value of the noise should be zero.
A deeper and more complete explanation can be found on the book "Texturing
and Modeling, a procedural approach" by Ebert et al. where D.Peachey
explains the teorethical basegrounds and shows several noises of that kind.
...
> The artifact is caused by the fact that while the first derivative of the
> function is continuous everywhere, the *second* derivative isn't
necessarily
> continuous at any of the integral values of x,y, or z.

That is infact the "bad situation" which makes the integer lattice visible.
I've made a little texturing application in Java
(http://www.falappa.net/alessandro/apps/jtexcreator/index.html if you're
interested) which uses an implementation of Perlin noise and I got those
gridding artifacts too.

Alessandro

Post a reply to this message

Warp wrote:

>   Hmm... What stops you from posting a full report of the suggested fix
> to this news server?

I do NOT contribute to non-free software.

Bye

P.S.: I am currently trying out Art Of Illusion (AoI) 
http://www.artofillusion.org/. If it is as good as it looks it is likely 
that I will say goodbye to POVRay and switch (and contribute to) AoI.

-- 
Alessandro Coppo
a.coppo@<REMOVE_ME>iol.it
www.geocities.com/alexcoppo

Post a reply to this message

> I do NOT contribute to non-free software.
Is there a chance that future versions of POVRay (beyond 3.5) will get
released under the GPL or the LGPL, and why not?
What are the problems with such a license? I don't have a problem to
contribute to "non-free software" if there are good reasons for not
releasing it under such a license. POVRay is in fact not comercial. Why not
support it?
BTW is a Java Raytracer not slower by nature?
Florian

Post a reply to this message

Alessandro Coppo <a.c### [at] iolit> wrote:
>>   Hmm... What stops you from posting a full report of the suggested fix
>> to this news server?

> I do NOT contribute to non-free software.

  Hmm... Since when POV-Ray has not been free?

  (AFAIK the only definition of "free software" is that it costs no money,
and POV-Ray perfectly fits this definition. Moreover, the source code of
POV-Ray is available, and you can make modifications to it and distribute
modified versions, which pretty much makes it fit inside the "open source"
definition. What else do you want? LGPL? LGPL is very nice, but not feasible
currently. GPL? No thanks.)

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

> I do NOT contribute to non-free software.


*thinks*

POV-Ray isn't non-free. It's free. I don't get what you're saying.

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

Florian Pesth <fpe### [at] compuservede> wrote:
> Is there a chance that future versions of POVRay (beyond 3.5) will get
> released under the GPL or the LGPL, and why not?
> What are the problems with such a license?

  The GPL license has its own problems. In some ways it's so anarchist, that
it can actually be a totalitarian license.
  LGPL is really nice (and a sign of this is that many GPL guys hate it),
however, it can be a bit *too* free (eg. publishing POV-Ray under LGPL would
allow anyone to make money by selling a program which has POV-Ray linked
in it, for example being the main renderer in the program; it's not very
nice that people would exploit POV-Ray in this way).

> I don't have a problem to
> contribute to "non-free software" if there are good reasons for not
> releasing it under such a license.

  I don't understand how POV-Ray is "non-free". Could someone explain?

> BTW is a Java Raytracer not slower by nature?

  There's no way an interpreted language can be as fast as a compiled and
highly optimized language.
  Compiling the Java code to native machine code *might* make it reach
the same speed, but I doubt that it will ever do that.

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

Alessandro Coppo <a.c### [at] iolit> wrote:
> P.S.: I am currently trying out Art Of Illusion (AoI) 
> http://www.artofillusion.org/. If it is as good as it looks it is likely 
> that I will say goodbye to POVRay and switch (and contribute to) AoI.

  It's really funny that Java hype is so strong that people don't even
care that the program is 10 times slower than one written in C++.
  In most programs it doesn't matter, but in a high-end raytracer it
certainly matters quite a lot. Why spend 10 hours rendering a scene
which could be rendered in 1 hour?

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

On Fri, 28 Jun 2002 22:07:13 +0200, Alessandro Coppo <a.c### [at] iolit> wrote:
> I do NOT contribute to non-free software.

So only using CVS makes program free ?

> P.S.: I am currently trying out Art Of Illusion (AoI) 
> http://www.artofillusion.org/. If it is as good as it looks it is likely 
> that I will say goodbye to POVRay and switch (and contribute to) AoI.

I'm also for more opened developemnt model but I fell in love with POV.
Seems it could be nice renderer for such modeler like AoI ;-)

ABX

Post a reply to this message

In article <3d1cc175$1@news.povray.org> , Alessandro Coppo <a.c### [at] iolit>
wrote:

> I do NOT contribute to non-free software.

Oh, how clever to first complain about not having the source code and
claiming you fixed the bug and then say you never planned to contribute it.
So the obvious conclusion is that your claim that you fixed it a month ago
is nothing more than a lie, and your only intention of this post was to
start some flame-war.  Really nice attitude! :-(

Now do us all as you promised and waste your time ray-tracing with Java than
wasting our time reading your nonsense!

    Thorsten

Post a reply to this message

Thorsten Froehlich wrote:

> Oh, how clever to first complain about not having the source code and
> claiming you fixed the bug and then say you never planned to contribute
> it. So the obvious conclusion is that your claim that you fixed it a month
> ago is nothing more than a lie, and your only intention of this post was
> to
> start some flame-war.  Really nice attitude! :-(
> 
> Now do us all as you promised and waste your time ray-tracing with Java
> than wasting our time reading your nonsense!

If you go to my website, download my JXL java library and have a look at 
the jxl.num.rng package, you will find correct implementations of Perlin 
noise in 1, 2 and 3 dimensions (omit if seeing Java code harms your 
reproductive capabilitis...;). Before releasing that code I checked its
behaviour creating test images and debugging it (strange practise, isn't 
it?)

I did not fix any POV bug, I simply discorvered it and laughed about such 
silly thing still laying around in a 10 years old program!

I did not want to start a flame war... I just do not care!

-- 
Alessandro Coppo
a.coppo@<REMOVE_ME>iol.it
www.geocities.com/alexcoppo

Post a reply to this message

W³odzimierz ABX Skiba wrote:

> So only using CVS makes program free ?

No... 

STOP: SYSTYEM DETECTED FLAME BAIT. DO NOT RESPOND

-- 
Alessandro Coppo
a.coppo@<REMOVE_ME>iol.it
www.geocities.com/alexcoppo

Post a reply to this message

Warp wrote:

> Alessandro Coppo <a.c### [at] iolit> wrote:
>> P.S.: I am currently trying out Art Of Illusion (AoI)
>> http://www.artofillusion.org/. If it is as good as it looks it is likely
>> that I will say goodbye to POVRay and switch (and contribute to) AoI.
> 
>   It's really funny that Java hype is so strong that people don't even
> care that the program is 10 times slower than one written in C++.
>   In most programs it doesn't matter, but in a high-end raytracer it
> certainly matters quite a lot. Why spend 10 hours rendering a scene
> which could be rendered in 1 hour?
> 

Just have a look at this URL:

http://tilde-hoschek.home.cern.ch/~hoschek/colt/index.htm

(do you notice the domain? CERN... these idiots use Java for particle 
physics, poor stupid boys, aren't they?)

-- 
Alessandro Coppo
a.coppo@<REMOVE_ME>iol.it
www.geocities.com/alexcoppo

Post a reply to this message

Slime wrote:

>> I do NOT contribute to non-free software.
> 
> 
> *thinks*
> 
> POV-Ray isn't non-free. It's free. I don't get what you're saying.
> 
>  - Slime
> [ http://www.slimeland.com/ ]
> 
> 
> 

It is free as beer, not as speach. Unfortunalety english uses the same word 
for two extremely different concepts. For more explanations, have a look at 
www.gnu.org site.

Bye!!!

-- 
Alessandro Coppo
a.coppo@<REMOVE_ME>iol.it
www.geocities.com/alexcoppo

Post a reply to this message

Warp wrote:

>   (AFAIK the only definition of "free software" is that it costs no money,
> and POV-Ray perfectly fits this definition. Moreover, the source code of
> POV-Ray is available, and you can make modifications to it and distribute
> modified versions, which pretty much makes it fit inside the "open source"
> definition. What else do you want? LGPL? LGPL is very nice, but not
> feasible currently. GPL? No thanks.)

Fascinating: first you talk as if you did not know anything about Free 
Software then you dissert upon different OSI licences... what about 
deciding what position to take?

-- 
Alessandro Coppo
a.coppo@<REMOVE_ME>iol.it
www.geocities.com/alexcoppo

Post a reply to this message

Alessandro Coppo <a.c### [at] iolit> wrote:
> (do you notice the domain? CERN... these idiots use Java for particle 
> physics, poor stupid boys, aren't they?)

  Yes, they are. They must have too much spare time to wait.

  I can give you a version of POV-Ray which is 10 times slower than usual.
Would you use it?

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Warp wrote:

>   The GPL license has its own problems. In some ways it's so anarchist,
>   that
> it can actually be a totalitarian license.
>   LGPL is really nice (and a sign of this is that many GPL guys hate it),
> however, it can be a bit *too* free (eg. publishing POV-Ray under LGPL
> would allow anyone to make money by selling a program which has POV-Ray
> linked in it, for example being the main renderer in the program; it's not
> very nice that people would exploit POV-Ray in this way).

So stick to GPL which is EXACTLY meant to prevent your fears! LGPL is just 
a stepping stone to smuggle Free Software into the commerical world then... 
he he!!!

>> BTW is a Java Raytracer not slower by nature?
> 
>   There's no way an interpreted language can be as fast as a compiled and
> highly optimized language.
>   Compiling the Java code to native machine code *might* make it reach
> the same speed, but I doubt that it will ever do that.

For your information it is years that Java is just-in-time compiled and, as 
I wrote on another post, benchmarks show that it can be a competitor to 
Assemebler for numerical tasks.

By the way, just to show you what a mature just-in-time compile technology 
can do, there are benchmarks on the net which show Scheme (a dialect of 
LISP) to be consistently faster than C!

-- 
Alessandro Coppo
a.coppo@<REMOVE_ME>iol.it
www.geocities.com/alexcoppo

Post a reply to this message

Warp wrote:

> Alessandro Coppo <a.c### [at] iolit> wrote:
>> (do you notice the domain? CERN... these idiots use Java for particle
>> physics, poor stupid boys, aren't they?)
> 
>   Yes, they are. They must have too much spare time to wait.

Well, when discussion sinks to this level, it is time to log out.

-- 
Alessandro Coppo
a.coppo@<REMOVE_ME>iol.it
www.geocities.com/alexcoppo

Post a reply to this message

In article <3d1f6d06$1@news.povray.org> , Alessandro Coppo <a.c### [at] iolit>
wrote:

> http://tilde-hoschek.home.cern.ch/~hoschek/colt/index.htm
>
> (do you notice the domain? CERN... these idiots use Java for particle
> physics, poor stupid boys, aren't they?)

Oh, sure, nobody said you cannot _use_ Java for it!   Maybe you should have
read the page first:

>>>
May 15 - Version 1.0.1 is here - and just broke the 200Mflop barrier. Due
too further library tuning, benchmarks now show the 100% pure Java
matrix-matrix and matrix-vector multiply running only about 2.5 times slower
than the algorithms from the Intel® Math Kernel Library.
<<<

200 MFlops I can do that on my five year old computer easily, you know...

    Thorsten

Post a reply to this message

Alessandro Coppo <a.c### [at] iolit> wrote:
> For your information it is years that Java is just-in-time compiled and, as 
> I wrote on another post, benchmarks show that it can be a competitor to 
> Assemebler for numerical tasks.

  Apparently I am unable to run Java in JIT-compiled mode because whatever I
do, it's slow as hell. Apparently JRE 1.3.1 does not do this. I don't know
what else could I do than download the latest JRE.

  I once found a factorization program in the net made in Java, which
factorized arbitrarily large numbers using the elliptic curve method.
I gave it a really large number, which was composed of three very large
primes, and it factorized it in something like 2 minutes in my 1.2GHz Athlon.
I thought that "wow, that was fast!".
  Well, then I found the pari/gp library and utility, which is written in C
(with some parts optimized in assembler). It also supports arbitrarily sized
numbers and factorization using the elliptic curve method.
  I run it in a 500MHz UltraSparc, which is about half fast than my Athlon
(of not even slower than that). The program factorized the same number in
less than 10 seconds.
  I have been laughing at the Java program since then.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Alessandro Coppo <a.c### [at] iolit> wrote:
> Fascinating: first you talk as if you did not know anything about Free 
> Software then you dissert upon different OSI licences... what about 
> deciding what position to take?

  Why are you trolling?

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

Alessandro Coppo <a.c### [at] iolit> wrote:
>>   Yes, they are. They must have too much spare time to wait.

> Well, when discussion sinks to this level, it is time to log out.

  From the page: "benchmarks now show the 100% pure Java matrix-matrix and
matrix-vector multiply running only about 2.5 times slower than the
algorithms from the Intel® Math Kernel Library."

  "Only"? Yes, the *do* have too much spare time. I don't.

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

On Sun, 30 Jun 2002 22:34:14 +0200, Alessandro Coppo <a.c### [at] iolit> wrote:
> I did not fix any POV bug, I simply discorvered it and laughed about such 
> silly thing still laying around in a 10 years old program!

It is laying around becouse people prefer laughing than reporting. They prefer
free software without their possibility of help.

ABX

Post a reply to this message

On Sun, 30 Jun 2002 22:43:52 +0200, Alessandro Coppo <a.c### [at] iolit> wrote:
> Just have a look at this URL:
>
> http://tilde-hoschek.home.cern.ch/~hoschek/colt/index.htm
>
> do you notice the domain? CERN...

domain doesn't say anything about author. java skills of one of the authors
are for example described at http://wwwinfo.cern.ch/support/java/utilities/:

  "I thing that it is a nice job, even though as a begginer in Java
  (I am using Java a few weeks only), I'm not quite sure that I've
  used the best way to do it."

ABX

Post a reply to this message

W³odzimierz ABX Skiba wrote:
> It is laying around becouse people prefer laughing than reporting. They prefer
> free software without their possibility of help.


And maybe also because it wasn't visible before isosurfaces ?



Philippe

Post a reply to this message

On Tue, 02 Jul 2002 09:56:58 +0200, Philippe Debar <phd### [at] wanadoobe> wrote:
> > It is laying around becouse people prefer laughing than reporting. They prefer
> > free software without their possibility of help.
>
> And maybe also because it wasn't visible before isosurfaces ?

Wasn't isosurfaces originally written for POV 2.2 ?

ABX

Post a reply to this message

W³odzimierz ABX Skiba wrote:
>>>It is laying around becouse people prefer laughing than reporting. They prefer
>>>free software without their possibility of help.
>>
>>And maybe also because it wasn't visible before isosurfaces ?
> 
> Wasn't isosurfaces originally written for POV 2.2 ?


Oops, yes... I forgot about that (I began to discover isosurfaces with 
Megapov...).


Anyway, the point I wanted to convey (I wonder why I always try the very 
roundabout way instead of writing what's on my mind...) is:
Why allow a lone laughing troll to depreciate your opinion of all free 
software users? The POV team itselfs, the Tag Team and most people on 
this news server (yourself included) is ample proof that many are ready 
to help :-)



Povingly,



Philippe

Post a reply to this message

From: "Slime"
> At first I was a bit annoyed by this, but having looked at the 3.1 source
in
> the past, I know that it's caused by the way the noise functions are
> created. They are *based* on a grid pattern of random values, which are
> interpolated between. I'm not sure exactly how the new noise generator
> works, but since it shows the same artifact, I assume it's similar.

Is the interpolation cubic like in sp_lines or cosine based? (
http://freespace.virgin.net/hugo.elias/models/m_perlin.htm has decription of
the funtions that I'm writing) I tried to look at the source myself but my C
skills are pretty bad. If it is cosine based the grid could be natural part
of the function. I'm thinking this because the small lines that cause the
grid are visible even when using one dimentional version of the function.
(just change f_noise3d(x,y,z) to f_noise3d(x,0,0) ) Sorry if this is too
newbie question for advanced-users.

Klaus Lehtonen

Post a reply to this message

In article <3d22036d@news.povray.org>,
 "Klaus Lehtonen" <leh### [at] hotmailcom> wrote:

> Is the interpolation cubic like in sp_lines or cosine based? (
> http://freespace.virgin.net/hugo.elias/models/m_perlin.htm has decription of
> the funtions that I'm writing) I tried to look at the source myself but my C
> skills are pretty bad. If it is cosine based the grid could be natural part
> of the function. I'm thinking this because the small lines that cause the
> grid are visible even when using one dimentional version of the function.
> (just change f_noise3d(x,y,z) to f_noise3d(x,0,0) ) Sorry if this is too
> newbie question for advanced-users.

If I remember correctly, that page describes a very different algorithm 
than what is usually called "Perlin noise". It uses a bitmap filled with 
random values and then interpolated to get the basic noise, which is a 
very simple and direct way of doing it but doesn't give great results. 
The algorithm Ken Perlin came up with was quite different and more 
complex, I don't understand all of it and can't explain it here, but it 
doesn't rely on a 2D or 3D bitmap.

http://www.mrl.nyu.edu/~perlin/doc/oscar.html
http://students.vassar.edu/mazucker/code/perlin-noise-math-faq.html
http://www.threedgraphics.com/texsynth/

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

"Christopher James Huff" <chr### [at] maccom>

> http://www.mrl.nyu.edu/~perlin/doc/oscar.html
> http://students.vassar.edu/mazucker/code/perlin-noise-math-faq.html
> http://www.threedgraphics.com/texsynth/

Thanks for the links. I think I understand what is causing the grid. I've
made a web page that explains it. http://koti.mbnet.fi/lehtkl/f_noise3d.htm
What do you think does this make some sense or am I just dreaming here?

Post a reply to this message

Philippe Debar wrote:

>>OK, could you either post here or place on the site a short complete
>> sample
>>scene for at least the first image, please?
> 
> Done. Zipped scene file in p.beta-test.binaries. 
<snip>
> I will post the others soon,


e-hem... I did not... Would they be useful? If yes, I'll try to post 
them this week-end. If no, well...

Philippe

Post a reply to this message