 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jerome <ber### [at] iname com> wrote:
: * it's easier to use for those who are used to the old one
: (and it doesn't change anything for the others);
Why should it be easier to make a (new) object with your function than with
the current function? I don't understand.
: * it gives more variation than Nathan's fix
But is it a good thing? You say it as if it was an advantage, but I don't
see why it's that.
AFAIK, what Nathan did was not to fix the function itself, but the scaling.
The function is exactly the same as before only that now the "amplitude" is
correct. So there was nothing wrong with the function itself and thus he
didn't fix anything about the function.
As you said, if one want more variation it can be done with the color map.
What if one does NOT want more variation, but the old regular smooth noise3d?
I think it will be a bit hard to do with your function.
: So I guess, my question is: both changes (mine and
: Nathan's) have advantages and drawbacks
Sorry, I don't see any drawbacks in the corrected noise3d in megapov.
, which would you
: prefer to see included in pov?
I don't think they are mutually exclusive. Both could be included and
allowed to be used at the same time. The question is if it's needed.
I still think that your function should be renamed if included.
I don't see any need for this function to replace the current noise3d,
as well as I don't see any need for keeping the old buggy normal pattern
scale.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> Jerome <ber### [at] inamecom> wrote:
> : * it's easier to use for those who are used to the old one
> : (and it doesn't change anything for the others);
>
> Why should it be easier to make a (new) object with your function than with
> the current function? I don't understand.
>
Well, suppose you want to make an object with a bozo
pigment that goes from red to green to blue, you would
naturally tend to use a color_map like this:
{
[ 0.0 color Red ]
[ 0.5 color Green ]
[ 1.0 color Blue ]
}
With standard pov (or my patch), it gives what you expect,
but in megapov 0.5 the result is mostly green. Granted, you
*can* use a different color_map to get the same effect, but
you need to know how to change it.
> : * it gives more variation than Nathan's fix
>
> But is it a good thing? You say it as if it was an advantage, but I don't
> see why it's that.
Look at the attached pics...
> AFAIK, what Nathan did was not to fix the function itself, but the scaling.
> The function is exactly the same as before only that now the "amplitude" is
> correct. So there was nothing wrong with the function itself and thus he
> didn't fix anything about the function.
He did exactly the same thing I did: he took the result
from the old function before it is truncated and applied a
transformation to it (other than truncating) to force the
result to be between 0 and 1. The only differece between his
patch and mine is that he applied a linear transform and I
applied a non-linear one.
> As you said, if one want more variation it can be done with the color map.
> What if one does NOT want more variation, but the old regular smooth noise3d?
Regular and smooth? Mine is as regular and smooth as the
old one and has as much variation as the old one, whereas
Nathan's has less and therefore is more different from the
old one than mine...
> I think it will be a bit hard to do with your function.
You can do it with mine by changing the color_map too (or
by using a function pigment). On the other hand, once you've
finally mastered the parameters to make a ridged
multifractal mountain range, you won't like it if you're
told that you need to start over because some change in the
bozo pattern (which you don't use) radically alters your
mountain (as posted by somebody recently).
>
> : So I guess, my question is: both changes (mine and
> : Nathan's) have advantages and drawbacks
>
> Sorry, I don't see any drawbacks in the corrected noise3d in megapov.
The statistical distribution is very much in favor of the
middle-range values (around 0.5) to the exclusion of the
others (near 0 or 1). This results in the megapov 0.5 sample
to be mostly green while the color_map tends to suggest
something more evenly distributed.
>
> , which would you
> : prefer to see included in pov?
>
> I don't think they are mutually exclusive. Both could be included and
> allowed to be used at the same time. The question is if it's needed.
I agree.
> I still think that your function should be renamed if included.
I disagree, mine has no more reason to be renamed then
Nathan's. (actually, I think it has less reason to be
renamed since it gives nearly the same results than the
old). Moreover, noise3d is used in a *lot* of places (and
not just in isosurfaces) like bozo, bumps, spotted, ridged
multifractals... Remember that the noise3d function was in
povray long before the function patch allowed the user to
have direct access to it. Therefore simply renaming the
function won't work anyway. The easiest way to allow the
user to choose is with a global_settings parameter (which is
very similar to the way megapov 0.5 chooses between old and
new noise3d according to the version number). I'm not sure
how you could go about implementing the choice on a
per-object (or pattern) basis so that it works in *all*
instances where noise3d is used.
Jerome
--
* Doctor Jekyll had something * mailto:ber### [at] inamecom
* to Hyde... * http://www.enst.fr/~jberger
*******************************
Post a reply to this message
Attachments:
Download 'noise3d.jpg' (10 KB)
Download 'noise3d1.jpg' (13 KB)
Preview of image 'noise3d.jpg'
Preview of image 'noise3d1.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Greg M. Johnson wrote:
>
> Please use my algorithm to compute the vol% vs. threshold for your new
> function. See my algorithm at:
>
> p.b.i
>
> Subject: Volume fraction of noise3d vs threshold vs. mega version 39kbbu)
> Date: Thu, 18 May 2000 13:51:08 -0400
>
I've downloaded it and I'll check it. I'll post the results
later this week.
Jerome
--
* Doctor Jekyll had something * mailto:ber### [at] inamecom
* to Hyde... * http://www.enst.fr/~jberger
*******************************
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Maybe I should have precised: the first image is megapov
0.5, the second one is standard pov. I don't have my patch
at hand here, but I'll post its results later this week.
Jerome
--
* Doctor Jekyll had something * mailto:ber### [at] inamecom
* to Hyde... * http://www.enst.fr/~jberger
*******************************
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jerome <ber### [at] inamecom> wrote:
: Well, suppose you want to make an object with a bozo
: pigment that goes from red to green to blue, you would
: naturally tend to use a color_map like this:
: {
: [ 0.0 color Red ]
: [ 0.5 color Green ]
: [ 1.0 color Blue ]
: }
: With standard pov (or my patch), it gives what you expect,
: but in megapov 0.5 the result is mostly green.
But the latter _is_ the correct behaviour.
Think about the color map:
From 0 to 0.25 the red component is predominant (ie. it's larger than the
other components), from 0.25 to 0.75 the green component is predominant and
from 0.75 to 1 the blue is predominant.
This means that 50% of the pigment should be predominatly green, 25% red
and 25% blue.
Thus, having the result mostly green is the correct behaviour and should
be expected. This should happen with every pattern that has even distribution.
If you want each color component to cover the same percentage of the pigment,
you'll have to set it up so that each of them gets 33.33% of it. For example:
[ 0/3 rgb Red ]
[ 1/3 rgb Green ]
[ 2/3 rgb Blue ]
[ 3/3 rgb Red ]
Now you have an equal amount of each color (ie. 33.33% of each). This should
work with every pattern which has even distribution.
This also means that your pattern does NOT have even distribution, but
prefers some values more than others.
: He did exactly the same thing I did: he took the result
: from the old function before it is truncated and applied a
: transformation to it (other than truncating) to force the
: result to be between 0 and 1. The only differece between his
: patch and mine is that he applied a linear transform and I
: applied a non-linear one.
Multiplying the function with a scalar only changes its amplitude, not
its shape. Your non-linear transformation makes it a completely different
function.
: Regular and smooth? Mine is as regular and smooth as the
: old one and has as much variation as the old one
Nope. The curvature of the surface in some places is higher in your
function than in the old one (if we don't count the plateaus produced by
the clamping). This makes it less smooth.
A sphere is smoother than an ellipsoid.
, whereas
: Nathan's has less and therefore is more different from the
: old one than mine...
Nathan's function is _exactly_ the same as the old one. Only the amplitude
has changed.
A sine wave does not stop being a sine wave if we multiply it by a scalar.
However if we make a non-uniform transform to it, then it stops being a
sine wave.
: The statistical distribution is very much in favor of the
: middle-range values
As I said that happened only because your color_map was in favor of the
green value (50%) and not the others (25% each).
:> I still think that your function should be renamed if included.
: I disagree, mine has no more reason to be renamed then
: Nathan's.
Wrong. Nathan's fix did not change the function. Yours did. Your function
is thus a different one.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> If you want each color component to cover the same percentage of the pigment,
> you'll have to set it up so that each of them gets 33.33% of it. For example:
>
> [ 0/3 rgb Red ]
> [ 1/3 rgb Green ]
> [ 2/3 rgb Blue ]
> [ 3/3 rgb Red ]
>
> Now you have an equal amount of each color (ie. 33.33% of each). This should
> work with every pattern which has even distribution.
>
See the attached result: there is much less red than any of
the others, so this isn't the correct behavior either...
> Multiplying the function with a scalar only changes its amplitude, not
> its shape. Your non-linear transformation makes it a completely different
> function.
>
Both make it a completely different function then. The only
meaningful way yet devised to compute how much two function
f and g differ is to integrate abs(f()-g()) (or some
variants involving exposants). Using that distance, my
function is less different than Nathan's from either the
truncated or the non truncated original functions
> Nope. The curvature of the surface in some places is higher in your
> function than in the old one (if we don't count the plateaus produced by
> the clamping). This makes it less smooth.
> A sphere is smoother than an ellipsoid.
>
You can't really talk about the curvature of a function
that goes from 3D space to 1D... If you want to speak about
the curvature of the isosurfaces of this function, they are
the same as for the old one (possibly less but certainly not
more) and Nathan's has the same behavior too. If you want to
speak about the second order derivatives, I agree that mine
can be more than the non-truncated function but not by much
whereas Nathan's are *a lot* less...
> Nathan's function is _exactly_ the same as the old one. Only the amplitude
> has changed.
See above...
> A sine wave does not stop being a sine wave if we multiply it by a scalar.
> However if we make a non-uniform transform to it, then it stops being a
> sine wave.
That's only a matter of the way a sine-wave has been
defined. Add two polynomials and you get a polynomial, add
two sine waves and you won't always get a sine-wave. Noise3d
is neither a sine-wave (nor a polynomial) so you can't apply
the same rules to it (for example add two noise3ds, what do
you get? I think you get another noise3d, so the strict sine
wave rules don't apply).
> As I said that happened only because your color_map was in favor of the
> green value (50%) and not the others (25% each).
>
The attached pic uses the color_map which you said was
evenly distributed and yet the red is not very present.
Again, I say that Nathan's function is biased towards the
middle values (I'll concede that mine and the old one are
probably biased towards the sides, but Nathan's is no more
correct)
> Wrong. Nathan's fix did not change the function. Yours did. Your function
> is thus a different one.
Again, I say that my function is no more different than
Nathan's and probably even less so.
This isn't going anywhere. I think we should define what
exactly we expect from a noise3d function before we can
start arguing over which one does it better (or whether we
should change it completely). My goal was to change the
original function (plateaus and all) as little as possible
while getting rid of the plateaus, and in this regard it
obviously succeded better than Nathan's. But if we don't
decide first on what the correct behavior should be (without
relation to the old one since the plateaus obviously weren't
correct behavior) we can't really argue over wich is
better...
Jerome
--
* Doctor Jekyll had something * mailto:ber### [at] inamecom
* to Hyde... * http://www.enst.fr/~jberger
*******************************
Post a reply to this message
Attachments:
Download 'noise3d.jpg' (12 KB)
Preview of image 'noise3d.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jerome wrote:
>
> Greg M. Johnson wrote:
> >
> > Please use my algorithm to compute the vol% vs. threshold for your new
> > function. See my algorithm at:
> >
> > p.b.i
> >
> > Subject: Volume fraction of noise3d vs threshold vs. mega version 39kbbu)
> > Date: Thu, 18 May 2000 13:51:08 -0400
> >
> I've downloaded it and I'll check it. I'll post the results
> later this week.
>
Mumble, grumble, damn floppy! When I got home the file was
empty... I'll try again :(
Jerome
--
* Doctor Jekyll had something * mailto:ber### [at] inamecom
* to Hyde... * http://www.enst.fr/~jberger
*******************************
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <395888ED.2795AED3@iname.com>, Jerome <ber### [at] inamecom>
wrote:
> See the attached result: there is much less red than any of
> the others, so this isn't the correct behavior either...
What waveform are you using? You should be using ramp_wave if you want
to compare this sort of thing. Other waveforms will throw it off, I
think the default for bozo is sine_wave.
> Both make it a completely different function then. The only
> meaningful way yet devised to compute how much two function
> f and g differ is to integrate abs(f()-g()) (or some
> variants involving exposants). Using that distance, my
> function is less different than Nathan's from either the
> truncated or the non truncated original functions
No. The function is the same, only the amplitude is different. It is the
same function. Your function is different, and has a very different
distribution. The only reason it resembles the original in any way is
that the original was faulty.
> The attached pic uses the color_map which you said was
> evenly distributed and yet the red is not very present.
Did you use ramp_wave?
> Again, I say that Nathan's function is biased towards the
> middle values (I'll concede that mine and the old one are
> probably biased towards the sides, but Nathan's is no more
> correct)
Nathan's *is* more correct, because it fixes the clipping without
introducing a bias toward the sides. When designing an isosurface using
noise3d() or a pigment function, I expect a nice, fairly linear
function. I often couldn't get the right effect because of the sudden
"clipping" of the old noise3d(), your function would have a similar
(though not as severe) problem. The same goes when I am designing
textures.
Anyway, this looks like it would be better implemented as a pattern
waveform...it sounds like it will work for any values in the 0-1 range.
You could also adjust the "flatness" of the ends this way. And I don't
think the "problems" with functions like multifractals are really as
severe as you say...people won't have to re-learn them, just adapt to
the new, corrected noise3d(). Or use #version.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'd like to have all versions avalaible, with no #version switch necessary.
Either using different names (bumps, bumps2, bumps3, koppbumps, jeromebumps)
or using a "type" keyword {bumps{type 2}}.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Philippe Debar" <phi### [at] hotmailcom> wrote in message
news:3959eb9c$1@news.povray.org...
| I'd like to have all versions avalaible, with no #version switch necessary.
| Either using different names (bumps, bumps2, bumps3, koppbumps, jeromebumps)
| or using a "type" keyword {bumps{type 2}}.
<repetition>
Hmm, and others might call that scripting clutter to have so many keywords
which are basically the same thing having personal distinctions about how they
ought to work. Not that I'm against more additions or anything, just that
there must be a correct way and incorrect way a feature works. For instance
you wouldn't want two 'color' keywords, one that is the way it is now and
another that inverts the rgb into bgr?
Sorry, I realize I'm chiseling at a valid point you're making. The various
ways everything is done should be within reason or it would be out of control
I believe. Priority needs to go to physical correctness and I have no qualms
about that, even if the breaking of old scenes is caused. All this has been
rehashed again and again, sorry for this redundant message.
All keywords being able work together would mean a consolidation of the
programs source I guess. Maybe that could be something planned for version
4.0 at least. Just as long as there isn't straggler code in it like
acceptance of POV-Ray 1.0 or 2.0 syntax. '#version' is obviously only a
compatibility feature, having no redeeming value other than to confine parts
of source code to their respective areas. Anyway, I'm only interested in all
of this from afar, it's not something I know about from the inside.
Bob
</repetition>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
