 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] iname com
* 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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.
>
atan(x*M_PI_2)/M_PI_2
Everything is brought into the [-1, 1] range. Order is
preserved and it is very near identity around 0...
Jerome
--
* Doctor Jekyll had something * mailto:ber### [at] inamecom
* to Hyde... * http://www.enst.fr/~jberger
*******************************
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This thread has been turned into an almost-flame-war when discussing about
which method is better.
I would like to give an additional point of view besides the ones I have
already made. And it's related to those images.
If we think about it, the regular noise3d gives smooth bumps and it can be
used, for example, to get a water surface with little waves. I have used
bozo (which uses the noise3d function) many times when making water.
The noise3d in the official povray is scaled too big, so it has been scaled
correctly in megapov. Noise3d can still be used to get the same water effect
than before, but without the possible plateaus.
Your patch, however, tries to keep the height of the original noise3d but
"smoothing" those plateaus. This, of course, changes the smoothness of the
function.
Now tell me honestly: Which one of those images, the second or the third,
looks better if you think about it as a water surface?
If you are completely honest, you will admit that the third image has
preserved better this feature of the noise3d function. If you imagine the
second image as a water surface, it looks quite unnatural, while the third
image looks much better.
If it was unclear to you what are the (or my) requisites for noise3d, this
should give an idea of it.
--
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" <war### [at] tagpovrayorg> wrote in message news:395b531e@news.povray.org...
| Which one of those images, the second or the third,
| looks better if you think about it as a water surface?
I wasn't asked, directly anyway, but I have to agree that Jerome's method is
different and that the most water-worthy is the currently used noise3d in
MegaPov, plus a little scaling up of y and not x and z.
It really comes down to the wire when you need a definition of what noise3d is
actually supposed to be in the first place, which I assume is a common pattern
algorithm(?). A quick search and I found a web page listing many patterns:
http://www.cinegrfx.com/tour/opbox-descriptions/Patterns.html for a program
called GenShade which outputs shaders for Renderman, BMRT... too bad they
don't list the equations :-)
Anyhow, I have to say that the "bump-like" quality of Jerome's patch is a
different animal--- for all I know about it, which is nothing. noise3d seems
to be soley based on fairly even-sloping undulation.
Bob
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bob Hughes" <per### [at] aolcom?subject=PoV-News:> wrote in message
news:395a1633@news.povray.org...
> 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.
I perceive the mathematical correctness you refer to, but in this case that
has nothing to do with what you do with the pattern. The way I see things,
there is no "correct" way to behave for patterns/functions : they are just
tools you use to model. The more tools you have, the better (but I prefer
one tool with much flexibility to a clutter of near identical specialised
ones). Even for features for which physical/mathematical correctness is
important (imho), like highlights, lighting model or radiosity, some variety
is good.
Now, there is one thing I do not know and which may invalidate to my own
eyes what I just wrote : is bumps a standard keyword/function with a
excepted and well defined behaviour in the cg world? If so, it would be
better if the bumps keyword was reserved for that behaviour. Otoh, modifiers
or other keywords would still be a bonus for other sorts of bumps.
> 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?
<g> there are two color keywords : "color" & "colour" </g>
I think there is a very important difference here : if someone has a bgr
colour, he does not have much work to do to use the standard (in pov and in
the cg world) rgb colour; but I do not know how one could easily use
Megapov's corrected bumps to make a pov's bumps or a Jerome's bumps.
> Sorry, I realize I'm chiseling at a valid point you're making.
mmh
So am I, so am I.
> 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.
Many things are rehashed forever, and people do not seem to bore (I speak of
people as a whole, not of particular individuals). (Things like art, death,
beauty, moral, gun control, God(s), MSWindows vs. Linux, bumps, ...)
> 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.
My own <repetition> I still think that Pov could use some syntax rewritings
</repetition>.
Povingly,
Philippe
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <395b6115@news.povray.org>, "Philippe Debar"
<phi### [at] hotmailcom> wrote:
> I perceive the mathematical correctness you refer to, but in this
> case that has nothing to do with what you do with the pattern. The
> way I see things, there is no "correct" way to behave for
> patterns/functions...
Well, the problem with the old noise3d() and bozo was that it was that
the plateaus were limiting their usefulness in isosurfaces, height
fields, normals, etc.
> ...is bumps a standard keyword/function with a excepted and well
> defined behaviour in the cg world? If so, it would be better if the
> bumps keyword was reserved for that behaviour.
"bumps" isn't standard, but this type of noise is a commonly used
feature.
However, it isn't a standard. As far as I know, the only requirement is
that it is a pseudo-random smoothly changing function which is
relatively uniform at large scales.
> ...I do not know how one could easily use Megapov's corrected bumps
> to make a pov's bumps or a Jerome's bumps.
Just extend the colors at each end of the color_map(compressing the
other values toward the center), so there is an area of flat color at
each end, and you will end up with plateaus just like the official
version's. Making it more like Jerome's would be a bit more work, but I
think it could be done easily as a waveform or isosurface function.
> Many things are rehashed forever, and people do not seem to bore (I
> speak of people as a whole, not of particular individuals). (Things
> like art, death, beauty, moral, gun control, God(s), MSWindows vs.
> Linux, bumps, ...)
You forgot MSWindows vs. Macintosh. And the meaning of the answer to the
Ultimate Question. :-)
> My own <repetition> I still think that Pov could use some syntax
> rewritings </repetition>.
You are not alone...I would prefer a completely different way of
layering textures, and a slightly different syntax for
patterns...#for(;;) loops, #set, etc would also be nice.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Philippe Debar" <phi### [at] hotmailcom> wrote in message
news:395b6115@news.povray.org...
|
| > 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?
|
| <g> there are two color keywords : "color" & "colour" </g>
You cornered me on that one :-)
| My own <repetition> I still think that Pov could use some syntax rewritings
| </repetition>.
Sigh. No doubt all the more as time goes on. I'm content to try any changes,
but I'll never hack at the POV-Ray source code to make changes like 'phong'
into "gloss" and 'phong_size' into "gloss_size" ever again. That was pretty
bad having to change a lot of my previously done scenes and break so many
others.
Bob
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bob Hughes wrote:
> It really comes down to the wire when you need a definition of what noise3d is
> actually supposed to be in the first place, which I assume is a common pattern
> algorithm(?). A quick search and I found a web page listing many patterns:
> http://www.cinegrfx.com/tour/opbox-descriptions/Patterns.html for a program
> called GenShade which outputs shaders for Renderman, BMRT... too bad they
> don't list the equations :-)
noise3d is commonly reffered to as "perlin noise". You can find a good
description of it at Hugo's site -
http://freespace.virgin.net/hugo.elias/models/m_perlin.htm
A web search will un doubtably return other good results. If you are
really interested in noise functions I also recomment searching through
the RTNews archives at -
http://www.acm.org/tog/resources/RTNews/html/
--
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
|
|
| |
| |
|
|
|
|
| |
|
|
