 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>Should I instead I do:
> function {y}- function{pigment {bumps}}
>Or:
> #declare yikes= function{pigment {bumps}};
> isosurface {
> function {y-yikes}
The second one.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3899AA1F.C9FA0F9E@my-dejanews.com>,
gre### [at] my-dejanews com wrote:
> Actually, the bumps pigment in an isosurface looks more like what I
> want than the noise3d.
They are the exact same thing. They both use the Noise() function to
calculate the result...the only difference is that bumps is calculated
differently in texture normals. You should get the exact same results if
you use either bumps, bozo or spotted in the pigment.
> Is there a way to do mathematical operations on pigments?
>
> I've tried with failure:
> function { y- pigment {bumps}}
> Should I instead I do:
> function {y}- function{pigment {bumps}}
> Or:
> #declare yikes= function{pigment {bumps}};
> isosurface {
> function {y-yikes}
The second one is closest, try
#declare yikes= function{pigment {bumps}};
isosurface {
function {y - yikes(x, y, z)}
...
}
I think the (x, y, z) part is a default in the MegaPOV version, but it
has caused trouble for me before and it seems to be a good idea to
include it anyway. It is better for readability, and if you want to
modify the function later, could make it easier.
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Yeah, just discovered this last night.
Is there/ will there EVER BE a flat-plateau-free noisy function? From my
ignorant perspective, I wonder if it is as simple as changing one or two
lines of codes?
Chris Huff wrote:
> In article <3899AA1F.C9FA0F9E@my-dejanews.com>,
> gre### [at] my-dejanewscom wrote:
>
> > Actually, the bumps pigment in an isosurface looks more like what I
> > want than the noise3d.
>
> They are the exact same thing. They both use the Noise() function to
> calculate the result...the only difference is that bumps is calculated
> differently in texture normals. You should get the exact same results if
> you use either bumps, bozo or spotted in the pigment.
>
> > Is there a way to do mathematical operations on pigments?
> >
> > I've tried with failure:
> > function { y- pigment {bumps}}
> > Should I instead I do:
> > function {y}- function{pigment {bumps}}
> > Or:
> > #declare yikes= function{pigment {bumps}};
> > isosurface {
> > function {y-yikes}
>
> The second one is closest, try
> #declare yikes= function{pigment {bumps}};
> isosurface {
> function {y - yikes(x, y, z)}
> ...
> }
>
> I think the (x, y, z) part is a default in the MegaPOV version, but it
> has caused trouble for me before and it seems to be a good idea to
> include it anyway. It is better for readability, and if you want to
> modify the function later, could make it easier.
>
> --
> Chris Huff
> e-mail: chr### [at] yahoocom
> Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This has been discussed in the past (with no resolution found). The problem
is that POV's Noise() function is not "correct". A solution has been
proposed which would, unfortunately, not be completely backwards compatible.
My personal preference would be to provide an option to allow backwards
compatibility but by default use a "correct" Noise().
-Nathan
Greg M. Johnson <gre### [at] my-dejanewscom> wrote...
> Yeah, just discovered this last night.
>
> Is there/ will there EVER BE a flat-plateau-free noisy function? From my
> ignorant perspective, I wonder if it is as simple as changing one or two
> lines of codes?
>
> Chris Huff wrote:
>
> > In article <3899AA1F.C9FA0F9E@my-dejanews.com>,
> > gre### [at] my-dejanewscom wrote:
> >
> > > Actually, the bumps pigment in an isosurface looks more like what I
> > > want than the noise3d.
> >
> > They are the exact same thing. They both use the Noise() function to
> > calculate the result...the only difference is that bumps is calculated
> > differently in texture normals. You should get the exact same results if
> > you use either bumps, bozo or spotted in the pigment.
> >
> > > Is there a way to do mathematical operations on pigments?
> > >
> > > I've tried with failure:
> > > function { y- pigment {bumps}}
> > > Should I instead I do:
> > > function {y}- function{pigment {bumps}}
> > > Or:
> > > #declare yikes= function{pigment {bumps}};
> > > isosurface {
> > > function {y-yikes}
> >
> > The second one is closest, try
> > #declare yikes= function{pigment {bumps}};
> > isosurface {
> > function {y - yikes(x, y, z)}
> > ...
> > }
> >
> > I think the (x, y, z) part is a default in the MegaPOV version, but it
> > has caused trouble for me before and it seems to be a good idea to
> > include it anyway. It is better for readability, and if you want to
> > modify the function later, could make it easier.
> >
> > --
> > Chris Huff
> > e-mail: chr### [at] yahoocom
> > Web page: http://chrishuff.dhs.org/
>
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>My personal preference would be to provide an option to allow backwards
>compatibility but by default use a "correct" Noise().
Great, then, it's decided. MegaPOV v0.5 will come with this fix. Right? :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Yes, please offer a "correct" noise.
If you messed with "bumps", then it might upset generations of old coders who
had made clouds, etc. I doubt that many people have gotten that far into
noise3d, and I bet that a bunch of them have gotten frustrated with the flat
plateaus and set it aside. (The difference being that noise3d is probably played
with by more dabblers in isosurfaces, where I have found it somehow "more
bothersome" than it was in pigments. [But then again, I'm no texture king].)
Anyway, here are proposals:
1) Just fix noise3d and I'll bet you'll get few complaints.
2) Make a correct nosie and call it "noiseg3d", "2noise3d," "bumps2",
"noisenp3d" etc. . .
In any case, thanks greatly for this program. If we appreciate the pov team,
somehow we appreciate the developers of these "bleeding edge" upgrades even
more, as the toys therein are fancier......
Nathan Kopp wrote:
> This has been discussed in the past (with no resolution found). The problem
> is that POV's Noise() function is not "correct". A solution has been
> proposed which would, unfortunately, not be completely backwards compatible.
> My personal preference would be to provide an option to allow backwards
> compatibility but by default use a "correct" Noise().
>
> -Nathan
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I would like to add my name to the list of people who want a better
Noise() function. Although I think a better way would just be to have it
controlled by the version. If the version is 3.1 or earlier at the time
of parsing, set the texture to use the older noise function as the
pattern. Otherwise use the new one. I don't think there will be a
problem with isosurfaces, but you could do something similar with them.
Basically, parse the patterns/function as a different thing depending on
the version. This would allow older textures/etc to appear exactly the
same while still allowing the newer version to be used.
I would fix it myself if I knew anything about noise functions.
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 4 Feb 2000 12:50:49 -0500, Nathan Kopp wrote:
>This has been discussed in the past (with no resolution found). The problem
>is that POV's Noise() function is not "correct". A solution has been
>proposed which would, unfortunately, not be completely backwards compatible.
>My personal preference would be to provide an option to allow backwards
>compatibility but by default use a "correct" Noise().
Why does noise3d() clamp? Is there some reason it should?
--
These are my opinions. I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker <ron### [at] povrayorg> wrote...
> On Fri, 4 Feb 2000 12:50:49 -0500, Nathan Kopp wrote:
> >This has been discussed in the past (with no resolution found). The
problem
> >is that POV's Noise() function is not "correct". A solution has been
> >proposed which would, unfortunately, not be completely backwards
compatible.
> >My personal preference would be to provide an option to allow backwards
> >compatibility but by default use a "correct" Noise().
>
> Why does noise3d() clamp? Is there some reason it should?
The big problem is that it doesn't clamp correctly. Or, rather, it doesn't
scale the output properly before it clamps. Honestly, I don't think it
really is that necessary that it clamps, either.
-Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Stepping above my area of expertise:
Wasn't the idea that instead of using an interval of 0 to 1, it went from
-0.5 to 0.5?
Nathan Kopp wrote:
> Ron Parker <ron### [at] povrayorg> wrote...
> > On Fri, 4 Feb 2000 12:50:49 -0500, Nathan Kopp wrote:
> > >This has been discussed in the past (with no resolution found). The
> problem
> > >is that POV's Noise() function is not "correct". A solution has been
> > >proposed which would, unfortunately, not be completely backwards
> compatible.
> > >My personal preference would be to provide an option to allow backwards
> > >compatibility but by default use a "correct" Noise().
> >
> > Why does noise3d() clamp? Is there some reason it should?
>
> The big problem is that it doesn't clamp correctly. Or, rather, it doesn't
> scale the output properly before it clamps. Honestly, I don't think it
> really is that necessary that it clamps, either.
>
> -Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
