(Sorry for the bad engish if you find any; Please correct.)
The POV-Ray blob object does not preserve it's volume when the components
are moved around.

Is it possible to make a blob-like volume-preserving function for the
isosurface?

How about simulating water drops with surface tension?

btw. Is there other blob-alternatives? IMO blob object is smooth in the
wrong way.(?)

Post a reply to this message

On Fri, 11 Oct 2002 10:00:20 EDT, "Pyry" <fro### [at] suomi24fi> wrote:
> (Sorry for the bad engish if you find any; Please correct.)
> The POV-Ray blob object does not preserve it's volume when the components
> are moved around.
>
> Is it possible to make a blob-like volume-preserving function for the
> isosurface?

There is something made by Rune IIRC, check
http://runevision.com/3d/blobs/blobs.asp

> btw. Is there other blob-alternatives?

http://www-public.tu-bs.de:8080/~y0013390/pov/ic/

> IMO blob object is smooth in the
> wrong way.(?)

you mean they are not smooth ???

ABX

Post a reply to this message

ABX wrote:
> 
> > btw. Is there other blob-alternatives?
> 
> http://www-public.tu-bs.de:8080/~y0013390/pov/ic/
> 

The IsoCSG blob is exactly like the native POV-Ray blob.  There is a
different possibility though described in the POV-Ray docs, section
6.5.4.4.4:

http://www.povray.org/documentation/view/169/#s06_05_04_04_04

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

On Fri, 11 Oct 2002 16:25:20 +0200, Christoph Hormann <chr### [at] gmxde>
wrote:
> The IsoCSG blob is exactly like the native POV-Ray blob

except it holds other shapes

ABX

Post a reply to this message

In article <web.3da6d971ed80a515398d8dbb0@news.povray.org>,
 "Pyry" <fro### [at] suomi24fi> wrote:

> (Sorry for the bad engish if you find any; Please correct.)
> The POV-Ray blob object does not preserve it's volume when the components
> are moved around.
> Is it possible to make a blob-like volume-preserving function for the
> isosurface?
> How about simulating water drops with surface tension?
> btw. Is there other blob-alternatives? IMO blob object is smooth in the
> wrong way.(?)

I know what you mean. A blob is just an isosurface, it only cares about 
the value of a function at a point, not about the volume or surface 
area. This is a problem I've been thinking about for a long time.
One possibility would be a particle system with blob particles. Use 
enough particles with repulsion between particles that are too close, 
and you could get something that does a fairly good job of maintaining 
its volume. You end up with blobs of huge numbers of particles though, 
it is still "lumpy", and the volume isn't very constant for small groups 
of particles. Maybe you could adjust the radius of the components to 
compensate for volume changes, this might give a useable approximation.

Some kind of mesh "stretched over" the volume of particles would be 
better, and I've been trying to think of a good way to do this. I think 
it is a much better approach, it will give smoother results and having 
the actual "surface" data available would make things like water beading 
on and wetting an object more realistic, and would do a much better job 
of avoiding the liquid penetrating the surface of an object. (with 
blobs, you only have component data, you don't really know where the 
surface is)
Maybe particles aren't necessary, some kind of voxel field containing 
"pressure" and "direction" information might be enough. Maybe combine 
the two, computing particle forces on a coarse lattice instead of 
per-particle.
It could also do a much better job of drops separating and merging: blob 
components just stretch towards each other when they are close, and 
merge when they are close enough...nothing like the behavior of real 
liquid drops.
My basic idea would be a closed ball of "cloth" containing particles. 
The cloth-surface interacts with objects and transfers forces to the 
particles, and the particles hold the surface up and control its motion. 
This would do a fairly good job of simulating a single drop. Dividing 
into separate drops or merging separate drops into one could be a much 
harder problem...figuring out which triangles to subdivide, which 
"bonds" to break, and closing the holes in each sub-drop, or knitting 
the surfaces of two drops together...

It would be very slow to compute in POV script, as well as difficult to 
write with the limitations of the language, you would need an external 
program to generate a mesh.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

On Fri, 11 Oct 2002 10:00:20 EDT, "Pyry" <fro### [at] suomi24fi> wrote:

>The POV-Ray blob object does not preserve it's volume when the components
>are moved around.

You are right, they do not.

>Is it possible to make a blob-like volume-preserving function for the
>isosurface?

It probably is, but take my word it won't be easy.

>How about simulating water drops with surface tension?
>btw. Is there other blob-alternatives?

These two questions probably have the same answer. You can use a mesh
to make your blob-like object, and using a mesh, you can make a
physical simulation with surface tension, volume preservation and
whatever else you can think of. Take my word on this as well, it's
even harder :)

>IMO blob object is smooth in the wrong way.(?)

What's the correct way to smooth a blob?


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

Peter Popov wrote:
>What's the correct way to smooth a blob?

I don't know what is the *correct* or the perfect way to smooth a blob, but
I just don't like the way the components react to each other sometimes.
Sometimes there is a visible edge between two spheres that isn't as smooth
as the rest of the blob and usually the appearance of the blob is too
smooth.

Of course one can overcome these anoying things by adding more and more
components...

Oh well the blob object is not made to be the ultimate make-everything from
ten spheres thingie. %) I just need to do what I gotta do whit other
objects. Right now I'm expirimenting on spheres in isosurfaces;Gives very
smooth results but takes time to render.

-And thank you all for the aswers so far!

Post a reply to this message

> I don't know what is the *correct* or the perfect way to smooth a blob,
but
> I just don't like the way the components react to each other sometimes.
> Sometimes there is a visible edge between two spheres that isn't as smooth
> as the rest of the blob and usually the appearance of the blob is too
> smooth.


This is due to the exact same mathematical property that causes a similar
"grid" artifact in the noise function: first derivatives match up, second
ones don't. It's not an easy problem to solve.

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

Hi,

> 
> This is due to the exact same mathematical property that causes a similar
> "grid" artifact in the noise function: first derivatives match up, second
> ones don't. It's not an easy problem to solve.

Hmm, I'm not sure, but is this not because the blob density function is
quadratic? If the blob function was exponential (e.g a mixture of
Gaussian components), wouldn't the second derivative be continuous? e.g
isosurface with a function like

f_gauss = function(x,y,z) { 1.0 - exp(-(x*x + y*y + z*z)/2.0) }

then use a sum of f_gauss at different centers...

But I could be totally wrong about this...

--John

Post a reply to this message

John Williamson wrote:
> Hmm, I'm not sure, but is this not because the
> blob density function is quadratic? If the blob
> function was exponential (e.g a mixture of
> Gaussian components), wouldn't the second
> derivative be continuous?

I don't know exponential functions very well, but I agree that it
shouldn't be that difficult to get smooth blobs, and that it would only
require the individual blob components to use functions whose second
derivatives match up.

Correct me if I'm wrong...

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com (updated Sep 8)
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

> I don't know exponential functions very well, but I agree that it
> shouldn't be that difficult to get smooth blobs, and that it would only
> require the individual blob components to use functions whose second
> derivatives match up.


Not too difficult; you just have to find a polynomial such that

f(0) = 0
f(1) = 1
f(0)' = 0
f(1)' = 0
f(0)" = 0
f(1)" = 0

But it will end up being a pretty high order polynomial, which introduces
slowness and innacuracy.

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

In article <3DA894B0.9FCA901F@dcs.gla.ac.uk>,
 John Williamson <wil### [at] dcsglaacuk> wrote:

> Hmm, I'm not sure, but is this not because the blob density function is
> quadratic? If the blob function was exponential (e.g a mixture of
> Gaussian components), wouldn't the second derivative be continuous? e.g
> isosurface with a function like
> f_gauss = function(x,y,z) { 1.0 - exp(-(x*x + y*y + z*z)/2.0) }

Maybe, but the root solver algorithm might not be able to use that 
equation. A method more like the isosurface primitive wouldn't have any 
problem though...but you would have to use things like max_gradient 
instead of sturm. It might be faster though...

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

In article <3da89baa@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

> I don't know exponential functions very well, but I agree that it
> shouldn't be that difficult to get smooth blobs, and that it would only
> require the individual blob components to use functions whose second
> derivatives match up.

I am probably misunderstanding you here because you seem to suggest blobs
are _not_ based on exponential functions?  They are [1]...

    Thorsten


[1] An Introduction to Ray Tracing, page 97/98

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:
> 
> > I don't know exponential functions very well, but I agree that it
> > shouldn't be that difficult to get smooth blobs, and that it would only
> > require the individual blob components to use functions whose second
> > derivatives match up.
> 
> I am probably misunderstanding you here because you seem to suggest blobs
> are _not_ based on exponential functions?  They are [1]...
> 

Well, POV-Ray blobs are not, see the formula in section 6.5.1.1 of the
docs.

A good introduction into this matter can be found on:

http://astronomy.swin.edu.au/~pbourke/modelling/implicitsurf/

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

Hi,

> Maybe, but the root solver algorithm might not be able to use that
> equation. A method more like the isosurface primitive wouldn't have any
> problem though...but you would have to use things like max_gradient
> instead of sturm. It might be faster though...

The partial derivatives of these surfaces are easy (or at least not
impossible, I haven't actually tried working them out!), so it's
probably possible to get away without having a max_gradient because we
already know it. I assume knowing the derivatives could speed up the
isosurface rendering...

Mind you, just testing Gaussian blob iso's with the above function just
now, it seems that they can be quite difficult to control. Still, they
seem smooth.

--John

Post a reply to this message

In article <3DA95BDB.D10F9F8D@dcs.gla.ac.uk>,
 John Williamson <wil### [at] dcsglaacuk> wrote:

> The partial derivatives of these surfaces are easy (or at least not
> impossible, I haven't actually tried working them out!), so it's
> probably possible to get away without having a max_gradient because we
> already know it. I assume knowing the derivatives could speed up the
> isosurface rendering...

That only applies to a single component. When you have multiple 
components with different radii and strengths, the gradient doesn't have 
a limit.

Hmm...the function using exp() is unbounded, isn't it? In addition to 
the root solving possibly being slower from the use of exp(), each 
component would affect every other component in the blob. With a bounded 
function, one that is only used in a certain distance, you only need to 
compute for the components that affect a ray, which could speed things 
up.

Ken Perlin recently updated his perlin noise algorithm with a new 
polynomial S-curve function that eliminated second-derivative 
discontinuities, maybe that could be of some use as a bounded function...

An isosurface algorithm might have some advantages over the current 
solver...it would be easier to add more component types, like plane, 
torus, sphere sweep, etc. It might also be faster. It wouldn't be 
redundant, though you could do the same shape in an isosurface, a blob 
is more specialized and could have some optimizations done.


> Mind you, just testing Gaussian blob iso's with the above function just
> now, it seems that they can be quite difficult to control. Still, they
> seem smooth.

I haven't had a chance to do any experiments, what makes them more 
difficult?

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Hi,

> 
> That only applies to a single component. When you have multiple
> components with different radii and strengths, the gradient doesn't have
> a limit.

That's true, but I think the gradient can be easily _evaluated_ at any
point even 
in a mixture, so it may still be of help (i.e we don't have to
approximate
the gradient numerically -- doesn't the current iso code need to do
something
like this?)
 
> Hmm...the function using exp() is unbounded, isn't it? 

Yep.

> In addition to
> the root solving possibly being slower from the use of exp(), each
> component would affect every other component in the blob. With a bounded
> function, one that is only used in a certain distance, you only need to
> compute for the components that affect a ray, which could speed things
> up.

That's a real problem with using exp, although the influence is
effectively bounded 
since the drop-off is pretty sharp -- cutting off after n standard
deviations from the 
center is an option. 
 
> Ken Perlin recently updated his perlin noise algorithm with a new
> polynomial S-curve function that eliminated second-derivative
> discontinuities, maybe that could be of some use as a bounded function...

Do you have any details of this? Sounds quite interesting...
 
> > Mind you, just testing Gaussian blob iso's with the above function just
> > now, it seems that they can be quite difficult to control. Still, they
> > seem smooth.
> 
> I haven't had a chance to do any experiments, what makes them more
> difficult?

Mainly the problem above; every component has an effect on the whole
thing, 
and it can be quite dramatic. So I found that the blob had a tendency to
dramatically change shape with fairly small adjustments in the
parameters. But I'm not very expert at 
manipulating blobs, so that might be a problem!

I've appended the scene I'm using for testing below...

--John



#version 3.5;

#include "colors.inc"
#include "functions.inc"

global_settings {assumed_gamma 1.0}

camera {
  location  <0.0, 0.1, -4.0>
  direction 1.5*z
  right     x*image_width/image_height
  look_at   <0.0, 0.5,  0.0>
}

sky_sphere {
  pigment {
    gradient y 
    color_map {
      [0.0 rgb <0.6,0.7,1.0>]
      [0.7 rgb <0.0,0.1,0.8>]
    }
  }
}

light_source {
  0*x          
  color rgb <1, 1, 0.6>  
  translate <-30, 30, -30>
}

#declare fn_gauss = function(x,y,z,r) { 1.0 - exp(-(x*x + z*z + y*y) /
r) }  

#declare fn_blob = function(x,y,z) { 
(fn_gauss(x,y,z,0.7) + fn_gauss(x+1, y+1, z, 0.7)  +
fn_gauss(x-1,y,z,0.7) + fn_gauss(x, y+2, z, 0.7) +
fn_gauss(x-0.3,y+0.3,z-1,0.7)+fn_gauss(x,y,z,0.1)) / 7.5  }  //Six
component blob

isosurface {
  function { fn_blob(x, y, z)  }        
  contained_by { box { -4.0, 4.0 } }  
  threshold 0.75
  accuracy 0.01                      
  max_gradient 1                      
  scale 0.3  
  translate 1*y
  texture
  {
   pigment { color rgbt <1.0, 1.0, 1.0> }
   finish
   {
     ambient 0
     diffuse 0.8
   }
  }
}

Post a reply to this message

> I am probably misunderstanding you here because you seem to suggest blobs
> are _not_ based on exponential functions?

They're based on the function

density = strength * (1-(distance/radius)^2)^2

which, I believe, is a "power" function, not an exponential one. A
non-constant would have to be in one of the powers for it to be exponential.

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

In article <3da9aaa2$1@news.povray.org> , "Slime" <slm### [at] slimelandcom> wrote:

>> I am probably misunderstanding you here because you seem to suggest blobs
>> are _not_ based on exponential functions?
>
> They're based on the function
>
> density = strength * (1-(distance/radius)^2)^2

Yes, yes, because POV-Ray blobs are not the original blobs (Blinn 1982) but
a variation of blobs (Wyvill 1986) and this confuses me every time I think
about blobs.  Essentially all what needs to be done is to implement the Binn
blobs and allow switching between the methods.  Oh, and btw, somebody should
really add complete quadric support...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <3DA99C87.2980A601@dcs.gla.ac.uk>,
 John Williamson <wil### [at] dcsglaacuk> wrote:

> That's true, but I think the gradient can be easily _evaluated_ at 
> any point even in a mixture, so it may still be of help (i.e we don't 
> have to approximate the gradient numerically -- doesn't the current 
> iso code need to do something like this?)

Hmm, I'm not sure...


> That's a real problem with using exp, although the influence is 
> effectively bounded since the drop-off is pretty sharp -- cutting off 
> after n standard deviations from the center is an option. 

I did something similar with my glow patch, it was hard to get the 
radius large enough to make the cutoff invisible and small enough to be 
useful for bounding. It was still of use there because it resembled a 
lens flare with sharp edges, but that doesn't apply to blobs.


> > Ken Perlin recently updated his perlin noise algorithm with a new
> > polynomial S-curve function that eliminated second-derivative
> > discontinuities, maybe that could be of some use as a bounded function...
> 
> Do you have any details of this? Sounds quite interesting...

The new polynomial is "1 - r*r*(3 - 2*r)".

Here are some tests I've done. The new polynomial is "fn_scurve", but 
seems to cause some odd bulges. fn_gauss is yours, fn_oldblob is an 
isosurface implementation of the function used in the blob primitive, 
and fn_cos is a cosine function that seems to work pretty well. There 
are other differences between the results, but I don't have time to 
adjust them further.

#declare fn_gauss = function (x, y, z, r) {1.0 - exp(-(x*x + z*z + 
y*y)/r)}

#declare scurve = function (r) {1 - r*r*(3 - 2*r)}
#declare fn_scurve = function (x, y, z, r) {scurve(min(1, sqrt(x*x + z*z 
+ y*y)/r))}

#declare oldblob = function (r) {pow(1 - r*r, 2)}
#declare fn_oldblob = function (x, y, z, r) {oldblob(min(1, sqrt(x*x + 
z*z + y*y)/r))}

#declare fn_cos = function (x, y, z, r) {cos(min(1, sqrt(x*x + z*z + 
y*y)/r)*pi)*0.5 + 0.5}

#declare fn_blob =
function (x, y, z) {
/*  (fn_gauss(x - 1, y, z, 1.75)
    +fn_gauss(x + 1, y, z, 1.75)
    +fn_gauss(x, y - 1.7, z, 1.75))/2*/
    
/*   fn_oldblob(x - 1, y, z, 1.75)
    +fn_oldblob(x + 1, y, z, 1.75)
    +fn_oldblob(x, y - 1.7, z, 1.75)*/
    
/*   fn_scurve(x - 1, y, z, 1.75)
    +fn_scurve(x + 1, y, z, 1.75)
    +fn_scurve(x, y - 1.7, z, 1.75)*/
    
     fn_cos(x - 1, y, z, 1.75)
    +fn_cos(x + 1, y, z, 1.75)
    +fn_cos(x, y - 1.7, z, 1.75)
}

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

> > > Ken Perlin recently updated his perlin noise algorithm with a new
> > > polynomial S-curve function that eliminated second-derivative
> > > discontinuities, maybe that could be of some use as a bounded
function...
> >
> > Do you have any details of this? Sounds quite interesting...
>
> The new polynomial is "1 - r*r*(3 - 2*r)".


Uh, this polynomial doesn't elliminate second derivative discontinuities.
It's the same one currently used for the noise function in POV-Ray. The
second derivative at zero is 6, and the second derivative at 1 is -6.

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

On Sun, 13 Oct 2002 22:25:55 -0400, Christopher James Huff
<chr### [at] maccom> wrote:

>The new polynomial is "1 - r*r*(3 - 2*r)".

That looks like the -2*x^3+3*x^2 evaluated in [0;1] - isn't that what
has been used for cubic interpolation for ages now? I've seen this
formula in the source code in a few places, I think cubic_wave is
based on it as well.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

Christopher James Huff wrote:
> In article <3DA99C87.2980A601@dcs.gla.ac.uk>,
>  John Williamson <wil### [at] dcsglaacuk> wrote:
>
>>> Ken Perlin recently updated his perlin noise algorithm with a new
>>> polynomial S-curve function that eliminated second-derivative
>>> discontinuities, maybe that could be of some use as a bounded
>>> function...
>>
>> Do you have any details of this? Sounds quite interesting...
>
> The new polynomial is "1 - r*r*(3 - 2*r)".

That's the "old" function, often referred to as "smoothstep function".
That function has a derivative of 6-12*t.
The new function is
  6*t^5 - 15*t^4 + 10*t^3
or
  t*t*t*(10+t*(6*t-15))
This function has zero first and second derivatives at t=0 and t=1
Details can be found in Ken Perlin's paper at
  http://mrl.nyu.edu/~perlin/paper445.pdf

--
Alessandro Falappa
web: http://www.falappa.net/alessandro

Post a reply to this message

In article <3daa35f2$1@news.povray.org>, "Slime" <slm### [at] slimelandcom> 
wrote:

> Uh, this polynomial doesn't elliminate second derivative discontinuities.
> It's the same one currently used for the noise function in POV-Ray. The
> second derivative at zero is 6, and the second derivative at 1 is -6.

Copy/paste error. I thought that looked wrong, but forgot to go back and 
check it out...that is the one used in the old noise function, the 
correct one is:
#declare scurve = function (r) {6*pow(r, 5) - 15*pow(r, 4) + 10*pow(r, 
3)}

This will also work, and may be faster in C, though probably not for POV 
functions:
#declare scurve = function (r) {((6*r - 15)*r + 10)*r*r*r}

It is bounded, making it more controllable and possible to optimize, and 
seems to do fine at eliminating visible discontinuities.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

> the
> correct one is:
> #declare scurve = function (r) {6*pow(r, 5) - 15*pow(r, 4) + 10*pow(r,
> 3)}


Sweet. Since this will probably also elliminate the problems with 3D noise,
maybe I'll implement it as a noise_generator option in my patch.

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

In article <3daaf81e@news.povray.org>, "Slime" <slm### [at] slimelandcom> 
wrote:

> Sweet. Since this will probably also elliminate the problems with 3D noise,
> maybe I'll implement it as a noise_generator option in my patch.

Just replace the SCurve() function in texture.cpp with this 
implementation. There are some other optimizations that can be done to 
offset the more expensive s-curve function. It will be duplicate work, 
since the POV Team is aware of this and probably already has an 
implementation, but I don't know of any patches that have been publicly 
released.
However, this won't fix all the problems with Perlin noise. The function 
still goes to 0 at regular intervals...since the POV version is 
re-scaled to the [0, 1] range, it goes to 0.5. If you use a function 
with something like "fabs(f_noise() - 0.5)" in it, you will see a grid 
pattern. This occurs in POV's implementation (though it doesn't go to 
0.5 exactly, probably because of the seed used), my own implementation, 
and is visible in Ken Perlin's sample images (use the threshold filter 
in some image processing program to see it). This is a result of the way 
it is calculated, you can't really get away from it.
There are other noise algorithms, for example, Lewis sparse convolution 
noise doesn't have any annoying artifacts that I can find. The drawback 
is that it is slower, about half to 1/3 as fast in normal usage from my 
experience. (this is normal usage, it has parameters that can make it 
arbitrarily slow)
I've done a patch with Lewis noise, I can release it publicly if there 
is interest (the POV Team already has it).

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Well, the point isn't to elliminate the fact that the pattern is *based* on
a grid, it's just to elliminate the 2nd derivative artifact that is most
visible when the function is used as a normal pattern. This definitely does
the trick, though the grid is, of course, still visible, but less visible
and less intrusive.

I'll post a picture as soon as I get this working.

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

In article <3dab0ca2$1@news.povray.org>, "Slime" <slm### [at] slimelandcom> 
wrote:

> Well, the point isn't to elliminate the fact that the pattern is *based* on
> a grid, it's just to elliminate the 2nd derivative artifact that is most
> visible when the function is used as a normal pattern. This definitely does
> the trick, though the grid is, of course, still visible, but less visible
> and less intrusive.
> I'll post a picture as soon as I get this working.

I've done enough looking at pictures of noise. ;-)
I spent a couple days looking for the problem before I figured out the 
grid artifacts weren't a problem with my implementation.
My point was that this doesn't fix all the problems. Most of the time 
when these changes are mentioned, it is implied that they remove all 
grid artifacts.
I could do some more work on Lewis noise and release the patch if you 
are interested.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Slime wrote:
>> I don't know what is the *correct* or the perfect way to smooth a blob,
>but
>> I just don't like the way the components react to each other sometimes.
>> Sometimes there is a visible edge between two spheres that isn't as smooth
>> as the rest of the blob and usually the appearance of the blob is too
>> smooth.
>
>
>This is due to the exact same mathematical property that causes a similar
>"grid" artifact in the noise function: first derivatives match up, second
>ones don't. It's not an easy problem to solve.
>
> - Slime
>

Actually, I was bothered by this as well, and came up with my own equation
that matches 1st AND 2nd derivatives to 0 at the center and the edge of the
blob component.

In the documentation, they list the blob falloff equation as (1-r^2)^2.
This results in the following values (assuming radius of 1):
Distance from center:
           0.0    0.5     1.0
"density"  1.0    0.5625  0.0
1st der.   0.0   -1.5     0.0
2nd der.  -4.0   -1.0     8.0

As you can see, the second derivatives are quite large.

My function uses the following equation:
1.0 - (6*r^5 - 15*r^4 + 10*r^3)

This equation yeilds the following values:
Distance from center:
           0.0    0.5     1.0
Value      1.0    0.5     1.0
1st der.   0.0   -1.875   0.0
2nd der.   0.0    0.0     0.0

Note that this function has two main advantages over the standard function.
First, it reaches a threshold of 0.5 at exactly half the radius.  This
makes calculating the size of your components very precise.  Second, the
curvature (i.e. 2nd derivative) is 0 at 0, 0.5, at 1 times the radius.  The
benfit of this is that when two components touch, the curvature at the
contact points does not abruptly change (easily noticed if you have a good
eye, but even easier to notice if the surface is reflective/refractive!).

To see this for yourself, calculate the 1st and second derivatives in
symbolic form:
1st: 30*r^2*(r-1)^2
2nd: 120*r*(r-0.5)*(r-1)

Note that the 1st derivative has zeroes (roots) at 0 and 1, whereas the 2nd
derivative has zeroes at 0, 0.5, and 1.  Also note that this equation is
symmetric around r=0.5, whereas the standard formula is not.  This means
that negative blobs can be used more effectively when placed with the
center at the edge of another component, with the same radius.  The
symmetric equations will exactly cancel along the line between the two
components!

Post a reply to this message

>Actually, I was bothered by this as well, and came up with my own equation
>that matches 1st AND 2nd derivatives to 0 at the center and the edge of the
>blob component.
>.......
>My function uses the following equation:
>1.0 - (6*r^5 - 15*r^4 + 10*r^3)
>

I didn't realize that there were more replies after the first page of ten
(I'm new to this newsgroup thing), and apparently I'm not the first that
came up with this particular equation.  That being said, I think it would
be worth hardcoding this particular equation for speed, the way the
standard blob function is hardcoded and optimized.  We could call it blob2!
 Or smooth_blob!

Post a reply to this message

In article <web.3e6fc2684cdcaf4d2a3ff2e70@news.povray.org>,
 "Retsam" <nomail@nomail> wrote:

> My function uses the following equation:
> 1.0 - (6*r^5 - 15*r^4 + 10*r^3)

Sorry to disappoint you, but not only is this an old, long dead thread, 
this equation has already been mentioned in it. I even posted a few 
images in povray.binaries.images using it in isosurface blobs.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

In article <web.3e6fcf6e4cdcaf4d2a3ff2e70@news.povray.org>,
 "Retsam" <nomail@nomail> wrote:

> I didn't realize that there were more replies after the first page of ten
> (I'm new to this newsgroup thing), and apparently I'm not the first that
> came up with this particular equation.  That being said, I think it would
> be worth hardcoding this particular equation for speed, the way the
> standard blob function is hardcoded and optimized.  We could call it blob2!
>  Or smooth_blob!

I am actually working on a blob2 primitive, which will use this function 
and a solving method similar to that of the isosurface primitive. 
Dropping it into the existing blob primitive is probably possible, but I 
don't understand the code nearly well enough, and it would be more 
limited than what I plan. The blob2 primitive will support far more 
component types, and will be faster than the equivalent isosurface, but 
probably slower than the equivalent blob.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message