Thanks Ken... I think.  Guess using "noise3d" alone as a search keyword wasn't
so great an idea before or I just didn't look long enough.

Bob

Post a reply to this message

Ken wrote in message <395B9350.2299A357@pacbell.net>...
>noise3d is commonly reffered to as "perlin noise". You can find a good
>description of it at Hugo's site -


noise3d is actually a single octave of perlin noise.  True perlin noise is
the sum of several sets of differently-scaled noise3d.

Mark

Post a reply to this message

Warp wrote:
> 
>   Now tell me honestly: Which one of those images, the second or the third,
> looks better if you think about it as a water surface?
>   If you are completely honest, you will admit that the third image has
> preserved better this feature of the noise3d function. If you imagine the
> second image as a water surface, it looks quite unnatural, while the third
> image looks much better.
>   If it was unclear to you what are the (or my) requisites for noise3d, this
> should give an idea of it.
> 
	Now, I understand better. Yes, you're right that Megapov's
gives a more "watery" surface. OTOH I still think that in
other cases, my version is better (notice that I never said
it was better as an absolute, but only that there were
points where it was doing better ond other where it's not so
good). Now, the question remains: what do other people
think? If I'm the only one to see some good with my
function, I'll just shut up, but if enough people are
interrested, we should discuss how best to include both...

		Jerome
-- 

* Doctor Jekyll had something * mailto:ber### [at] inamecom
* to Hyde...                  * http://www.enst.fr/~jberger
*******************************

Post a reply to this message

"Chris Huff" <chr### [at] maccom> wrote in message
news:chrishuff-66E8D2.10304829062000@news.povray.org...

> Well, the problem with the old noise3d() and bozo was that it was that
> the plateaus were limiting their usefulness in isosurfaces, height
> fields, normals, etc.

> "bumps" isn't standard, but this type of noise is a commonly used
> feature.
> However, it isn't a standard. As far as I know, the only requirement is
> that it is a pseudo-random smoothly changing function which is
> relatively uniform at large scales.

Known and agreed, but I would not say that it was useless. Any great images
were created with the good'ol "faulty" bumps. And many people are used to
use it, and know how to code a map which will give them the result they are
looking for. (And I am still not writing of backward compatibility - oops, I
just did.) SO, please, keep them near at hand (and, no, I do not like using
#version in the middle of a scene).


> Just extend the colors at each end of the color_map(compressing the
> other values toward the center), so there is an area of flat color at
> each end, and you will end up with plateaus just like the official
> version's. Making it more like Jerome's would be a bit more work, but I
> think it could be done easily as a waveform or isosurface function.

So, could we use a #macro mapOldBump(mapValue) that could use the exactly
correct function to switch to different bumps' incarnation. Can anyone with
access to source do this?


> > My own <repetition> I still think that Pov could use some syntax
> > rewritings </repetition>.
>
> You are not alone...I would prefer a completely different way of
> layering textures, and a slightly different syntax for
> patterns...#for(;;) loops, #set, etc would also be nice.

One of the many problem being that everybody has its preferences. We need
pov-team benevolent and knowledgeable dictatorship.

Povingly,


Philippe

Post a reply to this message

On Fri, 30 Jun 2000 02:43:32 -0400, "Mark Wagner"
<mar### [at] gtenet> wrote:

>>noise3d is commonly reffered to as "perlin noise". You can find a good
>>description of it at Hugo's site -
>
>noise3d is actually a single octave of perlin noise.  True perlin noise is
>the sum of several sets of differently-scaled noise3d.

Like the granite pattern?


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] usanet
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

In article <64qpls4m889imjg9002mr03jar85id340o@4ax.com>, Peter Popov 
<pet### [at] usanet> wrote:

> Like the granite pattern?

Or the wrinkles pattern, or turbulence.

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message

In article <395cb293$1@news.povray.org>, "Philippe Debar" 
<phi### [at] hotmailcom> wrote:

> Known and agreed, but I would not say that it was useless.

I didn't say it was useless, just that it was limited by the plateus. I 
ran into them several times, and either abandoned the scene or wasted 
time looking for some way to work around it.


> So, could we use a #macro mapOldBump(mapValue) that could use the 
> exactly correct function to switch to different bumps' incarnation. 
> Can anyone with access to source do this?

Yes, you could probably make a macro to correct the blend map values, 
then all you would have to do is duplicate the end ones...or you could 
use the function pattern and reproduce the older version or both new 
versions without even touching the blend map.

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message

Philippe Debar wrote in message <395cb293$1@news.povray.org>...
>So, could we use a #macro mapOldBump(mapValue) that could use the exactly
>correct function to switch to different bumps' incarnation. Can anyone with
>access to source do this?


The procedure for converting a blend map:
Divide each value by 2 and add 0.25

Mark

Post a reply to this message

"Chris Huff" <chr### [at] maccom> wrote in message
news:chrishuff-97A564.17491930062000@news.povray.org...
> I didn't say it was useless, just that it was limited by the plateus. I
> ran into them several times, and either abandoned the scene or wasted
> time looking for some way to work around it.

I am awfully sorry. I never wanted to put words in your mouth.

I must say I was surprised to find my post a bit harsh when I re-read it
today. I wasn't my intention at all.

All in all, what I wanted to say is that I was a little disappointed that
the old bumps was accessible only through #version, because I thought that
it still has uses in current megapov (future pov?) versions. But as it seems
it is easy to make it work in povscript , all is well.


> Yes, you could probably make a macro to correct the blend map values,
> then all you would have to do is duplicate the end ones...or you could
> use the function pattern and reproduce the older version or both new
> versions without even touching the blend map.

Great. I suppose the corrected-map solution would be the quickest
(render-time-wise). For the function pattern, I suppose you mean wrapping an
"adapter" function around the noise/bumps.

Just for interest's sake: is it possible to re-write the old noise/bumps
function from scratch in povscript? Isn't the noise function iterative? Is
it possible to write iterative functions for the function pattern or
isosurface?


Thank you for your explanations (I _like_ the TAG team),


Povingly,


Philippe

Post a reply to this message

"Mark Wagner" <mar### [at] gtenet> wrote in message
news:395ee45a@news.povray.org...
> The procedure for converting a blend map:
> Divide each value by 2 and add 0.25


Thank you very much, Mark.


Philippe

Post a reply to this message