 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi, there is a bug (or "surprising feature", if you will 8-) in the
formula thatPOV-Ray uses for blob objects.
Consider a spherical blob component "sphere{ C, R, S }". According to
the reference manual, its density function at distance "d" from the
center "C" is "F(d) = (1 - (d/R)^2)^2"
By this formula, the second derivative of the density "F(d)" with
respect to "d" does not tend to zero when "d" tends to "R" from below.
This means that the blob's surface is continuous only to the first
order; its curvature changes abruptly as one enters or leaves the
sphere of influence of each component.
Those discontinuities turn out to be far more visible than one might
think. If the object has Lambertian finish, the discontinuities make
the seam between adjacent blob elements look distinctively brighter
than the elements, as in the picture below (left):
http://www.ic.unicamp.br/~stolfi/misc/2009-11-pov-blob-bug/fig_00.png
This is an optical illusion, closely related to the "Mach bands" effect.
If the blob has mirror finish, the 2nd order discontinuities in the
surface create 1st order discontinuities ("kinks") in the the
reflected images of straight lines, as shown here (left):
http://www.ic.unicamp.br/~stolfi/misc/2009-11-pov-blob-bug/fig_01.png
In both images, the object on the left is a blob with two spherical
elements (radius of influence 1.80, center-to-center distance 2.00,
threshold 0.093364). The one on the right is a CSG imitation, where
the seam is a piece of a "torus" surface, computed to give 1st order
surface continuity and approximately the same curvature as the blob's
seam.
These Mach artifacts are apparent even in small blobs. They make the
seams stand out, even on objects that are supposed to be smooth.
The only way to avoid the discontinuities is to increase the element
radii and adjust the threshold so that the entire surface of the blob
lies within the sphere of influence of all its elements. But then the
elements lose their identity, and the user loses control of the shape.
While this is technically a "feature" rather than a "bug", it severely
limits the usefulness of the "blob" primitive. One can fix this
problem by replacing the density formula "S*(1 - (d/R)^2)^2" by the
new formula "S*(1 - (d/R)^2)^N" where N is 3 or more. This function is
continuous to (N-1)th order everywhere.
The following pictures compare the seam produced by the current blob
formula (left) and by this "supersmooth blob" formula with N = 4
(right):
http://www.ic.unicamp.br/~stolfi/misc/2009-11-pov-blob-bug/fig_10.png
http://www.ic.unicamp.br/~stolfi/misc/2009-11-pov-blob-bug/fig_11.png
Note that the new formula yields a visually smooth joint under
Lambertian shading, and removes the kinks from the reflected stripes.
Of course, simply changing N in the formula will shift the blob's
surface inwards and hence break old POV sources. For example, in order
to obtain an N=4 superblob with approximately the same size shape as
the ordinary blob, it was necessary to set the influence radius R to
2.1 (instead of 1.8) and lower the threshold to 0.057552 (instead of
0.093364). To implement this fix in a back-compatibile way,
one could add to the blob primitive an optional parameter
"order N", defaulting to "order 2".
Of course, one can already obtain these "supersmooth blobs" through
the "isosurface" primitive (as I did in the last two images above).
However, the isosurface primitive uses a generic root finder that is
much slower than the blob's specialized root finder. Also, the
isosurface primitive lacks the blob's internal element-bounding hierarchy,
hence it must evealuate all terms of the function, for every probe
along every ray. Thus, for example, the images with the
supersmooth blobs above took about 100 times longer to render
than the images with ordinary or CSG-faked blobs. Clearly, "isosurface"
is not a viable alternative to built-in supersmooth blobs.
Hope it helps. All the best,
--stolfi
PS. The POVRAY sources for those images are in
http://www.ic.unicamp.br/~stolfi/misc/2009-11-pov-blob-bug/sources.tgz
The camera settings assume 8:3 image aspect ratio.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jorge Stolfi <sto### [at] ic unicampbr> wrote:
> Of course, simply changing N in the formula will shift the blob's
> surface inwards and hence break old POV sources. For example, in order
> to obtain an N=4 superblob with approximately the same size shape as
> the ordinary blob, it was necessary to set the influence radius R to
> 2.1 (instead of 1.8) and lower the threshold to 0.057552 (instead of
> 0.093364). To implement this fix in a back-compatibile way,
> one could add to the blob primitive an optional parameter
> "order N", defaulting to "order 2".
I wonder if POV-Ray couldn't transparently calculate the radius and
threshold values from the user-specified ones so as to match the current
blobs.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Warp <war### [at] tagpovrayorg> wrote:
> I wonder if POV-Ray couldn't transparently calculate the radius and
> threshold values from the user-specified ones so as to match the current
> blobs [in case the default N is changed from 2 to 4].
Consider a simple situation, namely the "diatomic molecules" of my images.
There are 2*3 + 3 = 9 major visual shape parameters: the effective radius "r"
of the atoms, the positions "C1,C2" of their centers, the radius "s"
of the smallest circle that goes around the seam, and the
radius of curvature "t" of the seam in the across direction,
at its midline.
The proposed new density formula is "F(p) = S*(1 - (dist(p,C)/R)^2)^N".
Assume "N" is given. The center "C" is fixed ("C1" or "C2"). That
leaves three parameters, the influence radius "R" (same for both atoms),
the strength "S" (ditto), and the overal threshold "T".
But multiplying "S" and "T" by the same factor leaves the shape
unchanged, so there are only two real parameters: "R" and the ratio
"T/S". These are insufficient to match the three remaining visual
parameters ("r", "s", "t").
In this simple situation, one can easily adjust "R" and "S/T" to
keep "r" and "s" fixed as "N" is changed; but then "t" will be
determined and dependent on "N". In this case, as "N" increases
the seams will start out more gently at the edges but will become
sharper at their midline
With a little more effort one could adjust "R" and "S/T" to keep
"r" and "t" fixed. Then the sharpness of seam at its midline
will be preserved, but its girth "s" will increase as "N" increases.
In any case, there are gazillions of POV-Ray
sources out there which use pretty complicated "blob"s and have
been carefully optimized to work with the current formula. A
change in the formula may improve the result of some of those
images, but will surely break many others.
So, merely changing the default "N" is not a viable alternative,
even with implicit adjustments to the other parameters. Changing
"N" must require an explicit user choice.
On the other hand, the automatic ajustments will be very helpful
to users who wish to convert their existing order=2 blobs to order=4
blobs. If the "R" and "S" parameters are adjusted by POV-ray so
as to preserve the efective shape parameters "r" and "s" of a
"diatomic molecule" with "dist(C1,C2) = r", then chances are that
the appearance of the user's blobs too will be improved with little
change to their overall shape.
All the best,
--stolfi
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 26/11/2009 15:54, Jorge Stolfi nous fit lire :
> In any case, there are gazillions of POV-Ray
> sources out there which use pretty complicated "blob"s and have
> been carefully optimized to work with the current formula. A
> change in the formula may improve the result of some of those
> images, but will surely break many others.
>
> So, merely changing the default "N" is not a viable alternative,
> even with implicit adjustments to the other parameters. Changing
> "N" must require an explicit user choice.
>
> On the other hand, the automatic ajustments will be very helpful
> to users who wish to convert their existing order=2 blobs to order=4
> blobs. If the "R" and "S" parameters are adjusted by POV-ray so
> as to preserve the efective shape parameters "r" and "s" of a
> "diatomic molecule" with "dist(C1,C2) = r", then chances are that
> the appearance of the user's blobs too will be improved with little
> change to their overall shape.
>
So, maybe, instead of a replacement for blob, we need a name for the
neoblob (sh*t about any reference to a bad movie), and both could live
together happily in the SDL.
mesh & mesh2 are the same core object, despite the different syntax.
For blob & neoblob, it would be just kind of opposite !
Please, do not stick with "neoblob" naming, find something:
- short ("continuous_blob" is far too long, "fourth_order_blob" too!)
- meaningful (sort of, don't call it "zziau" whatever it might mean)
- without historical aspect (neo = new... so bad naming! as bad as
"revised_blob")
- not a syntax extension of the actual blob (no "blob { smoother ...",
as it would lock together the future evolutions of both mathematical
beasts (every option of one would have to be available on the other,
unless you want to confuse the final user. do we want more confusion ?)
> All the best,
>
> --stolfi
Did you look at the implication on the cylinder-blob ?
Does the new formula works fine too for them ?
Thanks for the illustrating pictures.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> So, maybe, instead of a replacement for blob, we need a name for the
> neoblob [...] not a syntax extension of the actual blob
> (no "blob { smoother ...",
> as it would lock together the future evolutions of both mathematical
> beasts (every option of one would have to be available on the other,
> unless you want to confuse the final user. do we want more confusion ?)
I was thinking of adding a optional parameter "order N" (the second
exponent of the current formula) that defaults to "order 2". That
would be analogous to the "u_steps" parameter of "bezier_patch", or the
"max_intersections" of "isosurface". An alternative would be a simple
keyword "smooth" or "c2_smooth" that would change N from 2 to 4 (or some
fixed higher number; 6 or 8 may work out better.)
Since the value of N is the *only* difference between the current blob
and the proposed one, I do not think that it justifies creating a separate
primitive. That would be confusing to users, too ("which kind of
blob is best for my needs?") and would be cosiderably harder to
maintain and document. Also, locking the future evolution of the
two primitives seems a good thing, precisely to reduce user confusion.
> Did you look at the implication on the cylinder-blob ?
> Does the new formula works fine too for them ?
The cylinder-blob has the same problem, even with a single cylinder.
AFAIK, the current implementation defines the density by parts: an
infinite cylindrical density and two spherical densities, sliced
and joined by two planes perpendicular to the axis.
Therefore a blob with a single cylindrical element
already has a discontinuity in curvature where the side wall meets
the spherical cap. This discontinuity creates the illusion of a
lighter ring adjacent to the seam, and kinks in the reflected
images of straight lines at that seam. (I owe you pictures of that,
but you can easily check it.)
To fix this problem would require a change in the form of the density
function, at least when N is greater than 2. I cannot give the details
now, but basically one needs the product of (1 - (X^2 + Y^2))^N and
(1 - Z^2)^N within the canonical unit cylinder (with Z axis), and
0 outside it.
This function then should be scaled, rotated and translated so
that the two "endpoints" specified by the user lie *inside*
the transformed canonical cylinder, not on its boundary.
Makes sense?
All the best,
--stolfi
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 30/11/2009 17:05, Jorge Stolfi nous fit lire :
> Since the value of N is the *only* difference between the current blob
> and the proposed one, I do not think that it justifies creating a separate
> primitive. That would be confusing to users, too ("which kind of
> blob is best for my needs?") and would be cosiderably harder to
> maintain and document. Also, locking the future evolution of the
> two primitives seems a good thing, precisely to reduce user confusion.
Please note: I'm only a user, no real authority.
But looks at the current syntaxes (yes, *es!) of the current blob.
There is the old syntax, and the new one...
I strongly believe that a new clean syntax (single) for that new
'object' would be simpler, both now and later.
A bit like quadric & quartic: similar but different (order is
different). And all might be done with poly (which might be good...
sometimes).
The point I'm still considering: would we mix both kind of blob elements ?
So far, I believe it might be possible, but I'm afraid of consequences:
your modifier would need to be repeated at the element level...
blob {
sphere { ... order 4 ...}
sphere { ... order 4 ...}
sphere { ... order 4 ...}
cylinder { ... order 4 ... }
cylinder { ... /* order 2 */ ... }
/* also, beware of the older blob syntax */
component ...
component ... order 4
threshold ...
order 2 /* a generic/default order ? ! ? */
}
A bit painful for my taste...
and might be ambiguous with support of component (that's why I first
preferred a new object, easier to be non-ambiguous when you can get ride
of the bogus history)
btw, do you envision of making the order generic (a bit like the
superellipsoid ?)
(I did not look at the blob to see if the mixing is easy or
unrealisting, at the math level of the solver)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 30/11/2009 21:21, Le_Forgeron nous fit lire :
> (I did not look at the blob to see if the mixing is easy or
> unrealisting, at the math level of the solver)
Now, I did.
It won't be simple, if at all possible to change the blob object.
Currently, the density function is strength*(1-(r/rad)^2)^2 and is
turned into solving a quartic as the influence along the ray just have
the right changes rate. (well, in fact, they are quartics)!
(Well, the ray is split in intervals where the various pondered
contributions ends up as solving a quartic for each segment)
Leaving the quartic solver (we already do that when using sturm
keyword), we end up with a general bisecting solver instead of a
"hard-coded" computation. It will take ages.
the actual root: you sample the equation again and again to hunt the
roots (if any)!
It will even take more times as the order N is big... and basic search
on wiki (and initial post) states that N=3 is enough for continuous
reflection (Initial request). Solving a 6th order instead of 4th order
is not going to make thing easier.
And it would required a full rewrite of the coefficient handling, as
currently blob is optimised for 4th order (need to use 2 more, and
updates all the developed formulas, with change of relevant weights.
So, to sum up: the "optimised" blob would be limited to order 2 or order
3 (forget about other values, including fractional ones), it would slow
down order 2 (old ones) even when no order 3 would be there.
Alternative solution could be to keep actual blob as they are, and
adding a new "metaball" object (and its silly solver) for order 2 & 3.
(still able to mix both orders)
Now, looking at some other metaball's software, we could also enjoy some
extra shapes:
- ball for spherical component (and ellipse as today too, with transform)
- tube for cylinder (add a single dimension to the center)
* sheet for rectangle (add two orthogonal dimensions to the center)
* cube (add three orthogonal dimensions)
If any mathgeek has some free time...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
