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

Greg M. Johnson wrote:
> 
> Please use my algorithm to compute the vol% vs. threshold for your new
> function. See my algorithm at:
> 
	I've done it, I get exactly the same results with my
changes than the standard version.

		Jerome
-- 

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

Post a reply to this message

Chris Huff wrote:
> 
> 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.
> 
	I used the default, but there were no changes when I
specified ramp_wave...

> 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.
> 
	From the instant the values taken by the function is
different, then it is a different function, period. It may
be in the same class of functions but it's not the same.
Sine-waves are a class of function that have certain
properties, polynomials are another with different
properties and so are C0, C1, C2... Noise3d is *not* a
sine-wave, so what properties should it have?

> >       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?
> 
	I did, and I've attached another:
  pigment {
    bozo
    color_map {
      [ 1/4 color rgb <1, 0, 0> ]
      [ 1/4 color rgb <0, 1, 0> ]
      [ 3/4 color rgb <0, 1, 0> ]
      [ 3/4 color rgb <1, 0, 0> ]
    }
    ramp_wave
  }
	Which should be equally distributed too, shouldn't it? (the
standard pattern does much better in that respect, see the
second image)

> Nathan's *is* more correct, because it fixes the clipping without
> introducing a bias toward the sides.
	It introduced a bias towards the middle... Now, I can
probably adapt mine to get a more evenly distributed effect
(but I probably won't have time before the end of next week)

> 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.
	What do you mean by fairly linear?

> 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.
	In fact it works with anything in the minus infinity - plus
infinity range, which is exactly the point since it's used
to bring the values that are outside the 0-1 range inside
it.

> 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().
	Which is exactly what I meant, it's hard enough to find the
right parameters for the effect you want, if everything you
learned by trying to adjust the parameters stops working
because the function was radically altered, you lose a lot
of time.

> Or use #version.
> 
	#version shouldn't be used that way. #version should only
be used to render old scenes that were written for a former
version of pov. The correct way if we want to allow several
noises to coexist is to add a keyword to choose.

		Jerome

PS: I keep asking for your criteria for the noise3d, but I
didn't give mine... Here they are:
- it should be at least C1 (continuously derivable);
- its gradient should be majored (to avoid too abrupt
changes);
- its gradient should be minored (to guarantee some change);
- it should be relatively evenly distributed
	Both Nathan's and mine verify all four criteria. Standard
isn't C1. However I think mine does better on the 3rd and
4th point...

PS2: Does anybody know why the original noise was clipped
rather than being scaled (like Nathan did) or any other
continuous transform? My guess (and it *is* just a guess, I
haven't got a scrap of evidence) would be that it was to
ensure a reasonably even distribution (and anyway the
clipping wasn't really a problem for the bozo pigment...)
Anybody has more info?

-- 

* 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' (9 KB) Download 'stdnoise3d.jpg' (12 KB)

Preview of image 'noise3d.jpg'

Preview of image 'stdnoise3d.jpg'

In article <395B382C.6739148A@iname.com>, Jerome <ber### [at] inamecom> 
wrote:

> > 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.
> 	In fact it works with anything in the minus infinity - plus
> infinity range, which is exactly the point since it's used
> to bring the values that are outside the 0-1 range inside
> it.

What is the exact math you are using? I am interested in adapting this 
as a waveform...there are a few other patterns that could use something 
like this. My blob pattern for instance.


> PS2: Does anybody know why the original noise was clipped
> rather than being scaled (like Nathan did) or any other
> continuous transform? My guess (and it *is* just a guess, I
> haven't got a scrap of evidence) would be that it was to
> ensure a reasonably even distribution (and anyway the
> clipping wasn't really a problem for the bozo pigment...)

My guess is that they didn't know how much it went out of range, and 
just used clipping as a temporary workaround. Or they didn't notice it 
went out of range until it was already released...it mostly shows up in 
fine-tuned textures, height fields, and isosurfaces. Too bad...it has 
certainly caused enough trouble since then. :-(

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