Excellent idea Mike!  I for one am hoping to see Micks image, whether he
completes it in time
for the next round or not.

--
Doug Eichenberg
http://www.nls.net/douge
dou### [at] nlsnet

Post a reply to this message

> Why not use +C to continue the trace from where it left off?

Doesn't that only work if you have that set when you begin the render?
I seem to recall never being able to restart a render because I forgot
to do that.

-Mike

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote...
> Or you could just adjust the
> color_maps to simulate the "plateaus" at each end of the map.
> It will produce clouds which are just as good as the old noise, just not
> with the exact same code.

Very true.  In fact, you could use a pigment_pattern with a color_map to
reproduce the old noise (bozo) very easily.  It is just a linear correlation
between the old and the new, except that the old one would clip values, so
you couldn't reverse-transform the old one to the new one.

The following code should work, though it has not been tested at all:

#declare OldBozo = pigment
{
  bozo
  color_map
  {
    [(0-0.5+1.05242 )*0.48985582, 0]
    [(1-0.5+1.05242 )*0.48985582, 1]
  }
}

#declare MyPigmentUsingOldBozo = pigment
{
  pigment_pattern{OldBozo}  // instead of "bozo"
  color_map
  {
    ...your color map goes here...
  }
}

The mapping is (if I did the math correctly):

old_value = (new_value / 0.48985582) - 1.05242 + 0.5

-Nathan Kopp

Post a reply to this message

In article <3990d2af$1@news.povray.org>, "Nathan Kopp" 
<Nat### [at] Koppcom> wrote:

> Very true.  In fact, you could use a pigment_pattern with a color_map 
> to reproduce the old noise (bozo) very easily.  It is just a linear 
> correlation between the old and the new, except that the old one 
> would clip values, so you couldn't reverse-transform the old one to 
> the new one.
> 
> The following code should work, though it has not been tested at all:
...snip...
> The mapping is (if I did the math correctly):
> old_value = (new_value / 0.48985582) - 1.05242 + 0.5

Actually, I was thinking of a function...how does this look?
#declare OldBozo =
function {max(0,min(1,noise3d(x,y,z)/0.48985582 - 1.05242 + 0.5))}

This has the advantage of being a direct replacement for isosurfaces 
which use the old noise3d() function...and it is probably noticeably 
faster than running a pigment through a function, and maybe even faster 
than pigment_pattern.

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

Chris Huff wrote:

> Actually, I was thinking of a function...how does this look?
> #declare OldBozo =
> function {max(0,min(1,noise3d(x,y,z)/0.48985582 - 1.05242 + 0.5))}

It looks like something the "average" POV-Ray user would never be
able to come up with on his/her own.

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

You mean the +X switch I think.  No, I never do anything but use the +C in
the ini dialog (command-line) when I need to start over at the last rendered
line.  Even in animations it will skip all the previous frames and continue
where it left off.  I checked to see if I had something set in the
povray.ini file and nothing there that would relate.  Windows version of
POV-Ray.

Bob

"Mike" <Ama### [at] aolcom> wrote in message
news:39909B88.65729FB6@aol.com...
| > Why not use +C to continue the trace from where it left off?
|
| Doesn't that only work if you have that set when you begin the render?
| I seem to recall never being able to restart a render because I forgot
| to do that.
|
| -Mike

Post a reply to this message

I just hope it's worth the wait!

"Doug Eichenberg" <dou### [at] nlsnet> wrote in message
news:3990972c$1@news.povray.org...
> Excellent idea Mike!  I for one am hoping to see Micks image, whether he
> completes it in time
> for the next round or not.
>
> --
> Doug Eichenberg
> http://www.nls.net/douge
> dou### [at] nlsnet
>
>

Post a reply to this message

Ken is right - there's no way on earth I could have come up with that. Thank
you Nathan for the help and Chris for the iso suggestion. There are other
patterns affected by the change, will the same function work for them?

Mick

"Ken" <tyl### [at] pacbellnet> wrote in message
news:3990DBEA.BE182729@pacbell.net...
>
>
> Chris Huff wrote:
>
> > Actually, I was thinking of a function...how does this look?
> > #declare OldBozo =
> > function {max(0,min(1,noise3d(x,y,z)/0.48985582 - 1.05242 + 0.5))}
>
> It looks like something the "average" POV-Ray user would never be
> able to come up with on his/her own.
>
> --
> Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
> http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Thank you Nathan, for the info and suggestions.

Mick

"Nathan Kopp" <Nat### [at] Koppcom> wrote in message
news:3990d2af$1@news.povray.org...
>
> Chris Huff <chr### [at] maccom> wrote...
> > Or you could just adjust the
> > color_maps to simulate the "plateaus" at each end of the map.
> > It will produce clouds which are just as good as the old noise, just not
> > with the exact same code.
>
> Very true.  In fact, you could use a pigment_pattern with a color_map to
> reproduce the old noise (bozo) very easily.  It is just a linear
correlation
> between the old and the new, except that the old one would clip values, so
> you couldn't reverse-transform the old one to the new one.
>
> The following code should work, though it has not been tested at all:
>
> #declare OldBozo = pigment
> {
>   bozo
>   color_map
>   {
>     [(0-0.5+1.05242 )*0.48985582, 0]
>     [(1-0.5+1.05242 )*0.48985582, 1]
>   }
> }
>
> #declare MyPigmentUsingOldBozo = pigment
> {
>   pigment_pattern{OldBozo}  // instead of "bozo"
>   color_map
>   {
>     ...your color map goes here...
>   }
> }
>
> The mapping is (if I did the math correctly):
>
> old_value = (new_value / 0.48985582) - 1.05242 + 0.5
>
> -Nathan Kopp
>
>

Post a reply to this message

Nathan Kopp wrote:
> 
> The mapping is (if I did the math correctly):
> 
> old_value = (new_value / 0.48985582) - 1.05242 + 0.5
> 
> -Nathan Kopp

I wonder, whether these values are correct too? I followed this
"Wondering about Noise()" thread in programming group and as I
understand, they come from Xander's noise test, where he took several
million samples over a box. But there is no guarantee, that there does
not exist points, where noise value could exceed this range <-1.05242,
0.988997>. So I guess that better would be to just add 1, divide by 2
and clamp into range 0-1. It is easier to understand, as there is no
"Tambov constants" (as we call here constants, which should be added to
value in order to get correct result) and more logical. I guess that
little difference between this approach and current implementation in
unnoticeable.

Post a reply to this message