I have just stopped my IRTC entry render 2 days into a very long render{12 -
48 days!) without thinking I clicked on stop render instead of render
priority. Oh well. Try again and hope!

I've been following the 3dMax thread. Pov can do almost anything any other
program can and almost as well. Many programs do some things faster. Vue
d'esprit for instance produces excellent very fast landscapes and with it's
current import facilities it is posible to produce some very serious work.

But I still prefer Pov it is capable of the unexpected.... part of the joy
of creating. I don't get that with other programs.

The problem with Pov is media.
    1. Very slow when combined with complex CSG contructs. My IRTC entry for
example takes two hours to render without media. the media by itself takes
two hours, together though I'm looking at a very, very long render.
    2. I'm still unconvinced by the noise function correction - yes it's
mathmatically correct but it doesn't produce good clouds, I've tried. If you
have time try rerendering Mike Andrews clouds scene in Megapov 05a. As I've
said before what is needed is user control over the noise function - why not
should be easy to implement.

Radiosity is getting better all the time and I'm sure we'll learn to use it.

Pov is a great tool, fun, suprising, exciting and free...... who could ask
for more.

Me, more speed please.

Mick

Post a reply to this message

In article <399062bf@news.povray.org>, "Mick Hazelgrove" 
<mic### [at] mhazelgrovefsnetcouk> wrote:

> The problem with Pov is media.
>     1. Very slow when combined with complex CSG contructs. My IRTC entry 
> for example takes two hours to render without media. the media by 
> itself takes two hours, together though I'm looking at a very, very 
> long render.

I can't think of a reason media would be much slower in complex CSG's, 
and I haven't experienced this problem myself...


>     2. I'm still unconvinced by the noise function correction - yes it's
> mathmatically correct but it doesn't produce good clouds, I've tried. 
> If you have time try rerendering Mike Andrews clouds scene in Megapov 
> 05a. As I've said before what is needed is user control over the 
> noise function - why not should be easy to implement.

The new noise function is easier to use(because it stays within the 
expected range), and can already be used to simulate the old one. You 
could even make a function which behaves like the old one, hard-coding 
it into the program isn't necessary. 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.

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

Mick Hazelgrove wrote:

> I have just stopped my IRTC entry render 2 days into a very long render{12 -
> 48 days!) without thinking I clicked on stop render instead of render
> priority. Oh well. Try again and hope!

Aargh, sucks to be you! The IRTC period is two months, right? So if you take 48
days to render, that didn't leave much coding time...

--
David Fontaine     <dav### [at] faricynet>     ICQ 55354965
Please visit my website: http://www.faricy.net/~davidf/

Post a reply to this message

48 days is my worst case scenario, I hope that past a certain point it will
speed up again.

took a month to code - have my doubts as to whether it will render in time.

Mick

"David Fontaine" <dav### [at] faricynet> wrote in message
news:399077CA.2F2BB51B@faricy.net...
> Mick Hazelgrove wrote:
>
> > I have just stopped my IRTC entry render 2 days into a very long
render{12 -
> > 48 days!) without thinking I clicked on stop render instead of render
> > priority. Oh well. Try again and hope!
>
> Aargh, sucks to be you! The IRTC period is two months, right? So if you
take 48
> days to render, that didn't leave much coding time...
>
> --
> David Fontaine     <dav### [at] faricynet>     ICQ 55354965
> Please visit my website: http://www.faricy.net/~davidf/
>
>

Post a reply to this message

I hope you didn't restart the render!  Just have it render the missing
portion and put the two parts together with copy and paste.  I had to do
this one round when I had the superpatch continually crashing on me.
All the pixels are raytraced so it's not cheating.

Then again, if it's taking 48 days to render, you really should look
into speeding that sucker up.

-Mike

Post a reply to this message

"Mike" <Ama### [at] aolcom> wrote in message
news:399091E6.91B796C1@aol.com...
| I hope you didn't restart the render!  Just have it render the missing
| portion and put the two parts together with copy and paste.  I had to do
| this one round when I had the superpatch continually crashing on me.
| All the pixels are raytraced so it's not cheating.

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

Bob

Post a reply to this message

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

Mick Hazelgrove <mic### [at] mhazelgrovefsnetcouk> wrote:
: I have just stopped my IRTC entry render 2 days into a very long render{12 -
: 48 days!) without thinking I clicked on stop render instead of render
: priority. Oh well. Try again and hope!

  Why didn't you just use the command line option +C to continue the render?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

I was so shocked at having been so stupid I was even more stupid and just
clicked render again.

Mick

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3991209b@news.povray.org...
> Mick Hazelgrove <mic### [at] mhazelgrovefsnetcouk> wrote:
> : I have just stopped my IRTC entry render 2 days into a very long
render{12 -
> : 48 days!) without thinking I clicked on stop render instead of render
> : priority. Oh well. Try again and hope!
>
>   Why didn't you just use the command line option +C to continue the
render?
>
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Mick Hazelgrove <mic### [at] mhazelgrovefsnetcouk> wrote:
: I was so shocked at having been so stupid I was even more stupid and just
: clicked render again.

  Well, we learn from our mistakes :)

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

I hope so:)
Mick

"Warp" <war### [at] tagpovrayorg> wrote in message
news:39916c02@news.povray.org...
> Mick Hazelgrove <mic### [at] mhazelgrovefsnetcouk> wrote:
> : I was so shocked at having been so stupid I was even more stupid and
just
> : clicked render again.
>
>   Well, we learn from our mistakes :)
>
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <399109b6@news.povray.org>, "Mick Hazelgrove" 
<mic### [at] mhazelgrovefsnetcouk> wrote:

> Ken is right - there's no way on earth I could have come up with 
> that.

I thought it was pretty basic...just remap the values, and clamp to the 
[0, 1] range to produce the plateaus. Isosurface functions were the 
natural choice for this, since they can be used as a pattern and have 
access to the noise function.


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

Yes and no...you could rebuild the patterns in function form, but it 
wouldn't be easy for some. It would be easier to use the pigment_pattern 
for these. However, I think bozo/bumps/spotted were the main 
problem...the other patterns might work fine.

-- 
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 <3990DBEA.BE182729@pacbell.net>, lin### [at] povrayorg 
wrote:

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

I just don't understand why not, pattern functions seemed the natural 
choice, and the function is quite simple. Maybe it would be more easily 
understood this way:


//clamps the value x to the range [y,z]
#declare clamp = function {max(y,min(z,x))}

//old style bozo, complete with plateaus
#declare OldBozo =
function {clamp(noise3d(x,y,z)/0.48985582 - 1.05242 + 0.5, 0, 1)}

Or are you talking about the "noise3d(x,y,z)/0.48985582 - 1.05242 + 0.5" 
part? That was just the mapping copied from Nathans post.

-- 
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, many of us gave up maths a long time ago and even then, in my case, I
didn't go much beyond what was then in England "O"levels. I have spent most
of my life as a painter, sculptor and teacher. I have a longing to go back
and try and catch up and when I retire it will be my first act. Until then I
will have to rely on asking you and others for help. Sorry!

Mick


"Chris Huff" <chr### [at] maccom> wrote in message
news:chrishuff-E4E0EF.12124009082000@news.povray.org...
> In article <3990DBEA.BE182729@pacbell.net>, lin### [at] povrayorg
> wrote:
>
> > It looks like something the "average" POV-Ray user would never be
> > able to come up with on his/her own.
>
> I just don't understand why not, pattern functions seemed the natural
> choice, and the function is quite simple. Maybe it would be more easily
> understood this way:
>
>
> file://clamps the value x to the range [y,z]
> #declare clamp = function {max(y,min(z,x))}
>
> file://old style bozo, complete with plateaus
> #declare OldBozo =
> function {clamp(noise3d(x,y,z)/0.48985582 - 1.05242 + 0.5, 0, 1)}
>
> Or are you talking about the "noise3d(x,y,z)/0.48985582 - 1.05242 + 0.5"
> part? That was just the mapping copied from Nathans post.
>
> --
> 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

"Mick Hazelgrove" <mic### [at] mhazelgrovefsnetcouk> wrote...
> 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?

I think the only other affected patterns are wrinkles and (maybe) agate
(maybe granite, too, but I don't think so).  Those are not so easy to change
(especially using functions), but I think that using the pigment_pattern
approach would probably work.

-Nathan

Post a reply to this message

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

> I think the only other affected patterns are wrinkles and (maybe) 
> agate (maybe granite, too, but I don't think so).  Those are not so 
> easy to change (especially using functions), but I think that using 
> the pigment_pattern approach would probably work.

The affected patterns include:
bozo, bumps, spotted, noise3d(), all of which are identical. (well, 
noise3d() can be used as a function pattern, and they aren't identical 
in normals, though bozo, spotted, and noise3d() should be more useful in 
normals now)
dents
agate
crackle(with "solid" on, at least)
granite
wrinkles
And of course, the ridged multifractal functions. In addition, anything 
using turbulence will be affected.

However, "affected" can simply mean the image generated by the pattern 
will change, the difference is probably not very noticeable most of the 
time in the more complex patterns. And there isn't any difference in 
actual use.

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

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

what is the significance of these numbers?

-- 
Anton Sherwood  --  br0### [at] p0b0xcom  --  http://ogre.nu/

Post a reply to this message

"Anton Sherwood" <bro### [at] poboxcom> wrote...
> Nathan Kopp wrote:
> > The mapping is (if I did the math correctly):
> > old_value = (new_value / 0.48985582) - 1.05242 + 0.5
>
> what is the significance of these numbers?

They are a result of some tests that Xander did on the "old" noise3d
function.  The function itself has more flaws (such as a grid pattern that
you can see if you look closely).

Actually, 0.5 should probably have been used instead of 0.48985582 and 1.0
should probably have been used instead of 1.05242.  I don't know enough
about the original function to know details, though.  The issue is that the
range of the original function was incorrect.

-Nathan

Post a reply to this message

"Chris Huff" <chr### [at] maccom> wrote...
> The affected patterns include:
  ...
> crackle(with "solid" on, at least)

Only crackle solid is affected.  The old-style crackle does not use noise.

> And of course, the ridged multifractal functions.

Hmm... I forgot about those.

> In addition, anything
> using turbulence will be affected.

Actually, not everything.  There are two kinds of turbulence in POV.  The
first one, "Turbulence," uses the "Noise" function which is affected.  The
second one, "DTurbulence," which uses the 3D "DNoise" is not affected.  The
following patterns will use "Turbulence" if "classic" turbulence is used.
All other patterns, and all turbulence warps use DTurbulence and are
therefore not affected.

Classic turbulence affected for:
marble
spiral1
spiral2
fog

Also, iridescence uses the "Turbulence" funciton, so it is affected by the
change.

-Nathan

Post a reply to this message

In article <3996dcf0@news.povray.org>, "Nathan Kopp" <Nat### [at] Koppcom> 
wrote:

> Only crackle solid is affected.  The old-style crackle does not use 
> noise.

That is what I meant.


> Actually, not everything.  There are two kinds of turbulence in POV.  
> The first one, "Turbulence," uses the "Noise" function which is 
> affected.  The second one, "DTurbulence," which uses the 3D "DNoise" 
> is not affected.

How is DNoise() different from Noise()? This is something I have never 
figured out. I had just assumed both had the same problem.


> Classic turbulence affected for:
> marble
> spiral1
> spiral2

I thought only agate had a specialized turbulence...why do these 
patterns have a different turbulence from the others?

-- 
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" <chr### [at] maccom> wrote...
> > The affected patterns include:
>   ...
> > crackle(with "solid" on, at least)

Nathan Kopp wrote:
> Only crackle solid is affected.  The old-style crackle does not use noise.

What's crackle solid?  (I *did* rtfm!)

-- 
Anton Sherwood  --  br0### [at] p0b0xcom  --  http://ogre.nu/

Post a reply to this message

In article <3996F67E.1C9E657B@pobox.com>, Anton Sherwood 
<bro### [at] poboxcom> wrote:

> What's crackle solid?  (I *did* rtfm!)

It makes each "cell" of the crackle pattern a different (solid) color, 
and it is documented in the MegaPOV manual, so I suggest you rtfm again. 
Specifically, section 8.3.2 "Crackle types". :-)

-- 
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:
> 
> 
> How is DNoise() different from Noise()? This is something I have never
> figured out. I had just assumed both had the same problem.
> 
As much as I understand, Noise and DNoise should be fairly same
(DNoise's first component has same value as Noise's return value for
same evaluation point), so I think that this fix should be applied there
as well.

Post a reply to this message

"Vahur Krouverk" <vah### [at] aetecee> wrote...
> Chris Huff wrote:
> >
> >
> > How is DNoise() different from Noise()? This is something I have never
> > figured out. I had just assumed both had the same problem.
> >
> As much as I understand, Noise and DNoise should be fairly same
> (DNoise's first component has same value as Noise's return value for
> same evaluation point), so I think that this fix should be applied there
> as well.

The algorithm that produces the fractal pattern for DNoise and Noise is very
similar.  DNoise produces a vector of noise, while Noise produces a single
output.

The algorithm itself basically produces an output in the range of
approximately [-1,1].  This is what DNoise wants for each component, so it
doesn't change anything.  However, Noise needs to change it to [0,1] for use
in a pattern.  However, in the official conversion, the change is incorrect,
and it over-saturates the top end.  MegaPov just fixes the conversion.

The old version simply adds 0.5, while the new version (for all practical
purposes) adds 1 and then divides by two.

-Nathan

Post a reply to this message

> > What's crackle solid?  (I *did* rtfm!)

Chris Huff wrote:
> It makes each "cell" of the crackle pattern a different (solid) color,
> and it is documented in the MegaPOV manual, so I suggest you rtfm again.

Oh: rtwfm; r2fm.

Just started playing with Mega yesterday.  When I get my obligatory
Shiny Sphere (containing an iso) the way I want it, I'll put it on a
plane crackle solid rather than checkered.

-- 
Anton Sherwood  --  br0### [at] p0b0xcom  --  http://ogre.nu/

Post a reply to this message

Nathan Kopp wrote:
> 
> 
> The algorithm that produces the fractal pattern for DNoise and Noise is very
> similar.  DNoise produces a vector of noise, while Noise produces a single
> output.
> 
> The algorithm itself basically produces an output in the range of
> approximately [-1,1].  This is what DNoise wants for each component, so it
> doesn't change anything.  However, Noise needs to change it to [0,1] for use
> in a pattern.  However, in the official conversion, the change is incorrect,
> and it over-saturates the top end.  MegaPov just fixes the conversion.
> 

Ah, so DNoise values are supposed to be between -1 and 1? Indeed, If I
think about it, then in official version its range was not changed
either.

> The old version simply adds 0.5, while the new version (for all practical
> purposes) adds 1 and then divides by two.
By old You mean official version (3.02??) and by new 3.5?
Are those constants, found by Xander and used in MegaPOV, removed in new
version and (+1)/2 used instead?

Post a reply to this message

"Vahur Krouverk" <vah### [at] aetecee> wrote...
>
> Ah, so DNoise values are supposed to be between -1 and 1? Indeed, If I
> think about it, then in official version its range was not changed
> either.

It was changed, but not correctly.

> By old You mean official version (3.02??) and by new 3.5?

Yes.

> Are those constants, found by Xander and used in MegaPOV, removed in new
> version and (+1)/2 used instead?

Yes.  (+1) / 2 will be used.  Remember that the constants Xander found were
very close to that and were determined by sampling a thousand or so points.

-Nathan

Post a reply to this message