 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3da89baa@news.povray.org> , "Rune" <run### [at] mobilixnet dk>
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]...
>
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
|
|
| |
| |
|
|
|
|
| |
|
|
