 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Why does this work:
isosurface {
function {
(2*x^2+y^2+z^2-1)^3 - (0.1)*x^2*z^3-y^2*z^3
}
threshold 0
accuracy 0.0001
max_gradient 20
max_trace 2
contained_by { sphere { 0, 7 } }
pigment {
color Grey
}
}
but not this:
#declare Heart =
function {
(2*x^2+y^2+z^2-1)^3 - (0.1)*x^2*z^3-y^2*z^3
}
isosurface {
function {
Heart(x, y, z)
}
threshold 0
accuracy 0.0001
max_gradient 20
max_trace 2
contained_by { sphere { 0, 7 } }
pigment {
color Grey
}
}
TIA
5k.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I have asked this same question before. No-one seems to know.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Simen Kvaal wrote:
> Why does this work:
> but not this:
>
Why it doesn't work I don't know, but adding "method 1" makes it work.
threshold 0
accuracy 0.0001
max_gradient 20
method 1
G.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Simen Kvaal" <sim### [at] student matnatuiono> writes:
> Why does this work:
> isosurface {
> function {
> (2*x^2+y^2+z^2-1)^3 - (0.1)*x^2*z^3-y^2*z^3
>
> }
[...]
> }
>
> but not this:
>
>
> #declare Heart =
> function {
> (2*x^2+y^2+z^2-1)^3 - (0.1)*x^2*z^3-y^2*z^3
> }
>
> isosurface {
> function {
> Heart(x, y, z)
> }
[...]
> }
I dont' know, but this works (at least with MegaPOV 0.4):
#declare Heart =
function { (2*x^2+y^2+z^2-1)^3 - (0.1)*x^2*z^3-y^2*z^3 }
isosurface {
function {
Heart
}
etc.
Thomas
--
http://thomas.willhalm.de/ (includes pgp key)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wasn't it Simen Kvaal who wrote:
>Why does this work:
>
>
>
>isosurface {
> function {
> (2*x^2+y^2+z^2-1)^3 - (0.1)*x^2*z^3-y^2*z^3
>
> }
> threshold 0
> accuracy 0.0001
> max_gradient 20
> max_trace 2
> contained_by { sphere { 0, 7 } }
> pigment {
> color Grey
> }
>}
>
>but not this:
>
>
>#declare Heart =
> function {
> (2*x^2+y^2+z^2-1)^3 - (0.1)*x^2*z^3-y^2*z^3
> }
>
>isosurface {
> function {
> Heart(x, y, z)
>
> }
> threshold 0
> accuracy 0.0001
> max_gradient 20
> max_trace 2
> contained_by { sphere { 0, 7 } }
> pigment {
> color Grey
> }
>}
The problem is related to the fact that you have lied about the
max_gradient value, and Megapov has trusted your value. If you replace
the line "max_gradient 20" by "eval" (and render a very small image,
otherwise it takes forever) then Megapov will calculate the true
max_gradient and log it in the statistics output.
What's probably happening is that it starts looking for your surface by
guessing that it might be close to the surface that contains it, and
then goes hunting up and down the ray looking for a location where the
function gets close to the threshold value.
If we consider a ray that approaches your object from the -z direction,
it probably starts its search from the point <0,0,-7> on the
contained_by sphere. At that point, your function evaluates to 110592.
Now, you've told it that the max_gradient is 20, and if that were true,
then there can't be a position within 5530 units where the function
evaluates to zero. So Megapov believes that there can't possibly be such
a point anywhere along the ray from <0,0,-7> to <0,0,7>.
Actually, the correct max_gradient is about 584035, however, if you try
using that value you'll find that it takes several years to render your
image at a reasonable size. Your contained_by surface is ridiculously
large, and your function is sixth order, so you're telling Megapov to go
looking in areas where the value of the function is of the order of 7^6,
i.e. 117649. Try containing the surface in the sphere {0,1.5} where the
function is of the order of 1.5^6, i.e. 11.39.
I don't know why there's no problem with the first version, but I do
notice that eval doesn't cause any isosurface function stats to be
logged. I guess that the way it locates the surface must be completely
different and, for some reason, it doesn't use your max_gradient value.
--
Mike Williams + #
Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Using the suggested solution by Gilles Tran, simply by adding method 1, the
scene renders perfectly in both cases. I understand what you say about
max_gradient and such, but my experience with isosurfaces (and unofficial
patches in general) is to never expect the expected.
>The problem is related to the fact that you have lied about the
>max_gradient value, and Megapov has trusted your value. If you replace
>the line "max_gradient 20" by "eval" (and render a very small image,
>otherwise it takes forever) then Megapov will calculate the true
>max_gradient and log it in the statistics output.
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thank you! The scene renders flawlessly just by adding method 1.
5k.
>Why it doesn't work I don't know, but adding "method 1" makes it work.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wasn't it Simen Kvaal who wrote:
>Mike Williams wrote:
>>The problem is related to the fact that you have lied about the
>>max_gradient value, and Megapov has trusted your value. If you replace
>>the line "max_gradient 20" by "eval" (and render a very small image,
>>otherwise it takes forever) then Megapov will calculate the true
>>max_gradient and log it in the statistics output.
>>
>Using the suggested solution by Gilles Tran, simply by adding method 1, the
>scene renders perfectly in both cases. I understand what you say about
>max_gradient and such, but my experience with isosurfaces (and unofficial
>patches in general) is to never expect the expected.
Aha. What threw me was that the help files that I've got clearly state
that method 1 is the default. It looks like what's happening is that if
you use the syntax "function {foo(x,y,z)}" the method is defaulting to
2, but if you use "function {<expression>}" the method defaults to 1.
When using method 2 you must give it a correct max_gradient.
I observe that explicitly specifying "method 2" in your first example
causes it to fail in the same way as your second example was doing. So
that supports my contention that it was defaulting to method 1, and the
second example was defaulting to method 2.
I reckon that the way it's defaulting is a bug, and it's what's been
causing much of the unexpected behaviour from isosurfaces.
--
Mike Williams * ##
Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The thought struck me too, but I have so little expirience with such things
you know.
There are several other things that I find odd, too. Such as: What's the
difference between:
#declare Tooth = function { niceonehere }
isosurface { Tooth(x, y, z) }
and
#declare Tooth = function { niceonehere }
isosurface { Tooth }
Another one:
isosurface {
function {
Tooth(x, y, z) + 0*SomeDistortion(x, y, z)
}
}
versus:
isosurface {
function {
Tooth(x, y, z) //+ 0*SomeDistortion(x, y, z)
}
}
(see my other post.)
So: I wonder if there exists some extensive documentation on Isosurfaces?
Are there bug fixes? Should we send reports to NathanKopp? Someone else?
5k.
>
>I observe that explicitly specifying "method 2" in your first example
>causes it to fail in the same way as your second example was doing. So
>that supports my contention that it was defaulting to method 1, and the
>second example was defaulting to method 2.
>
>I reckon that the way it's defaulting is a bug, and it's what's been
>causing much of the unexpected behaviour from isosurfaces.
>
>--
>Mike Williams * ##
>Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Simen Kvaal wrote:
> So: I wonder if there exists some extensive documentation on Isosurfaces?
> Are there bug fixes? Should we send reports to NathanKopp? Someone else?
>
My 2 cents, from an "old", empirical user of isosurfaces, since they were
implemented in Ryoichi Suzuki's patch in 1996
- They were never fully documented, though the current doc is the best there
ever was. I remember testing the functions one by one trying to guess what each
parameter did !
I think that it's said in the current Megapov doc that what we know about the
iso were either derived from the original Suzuki docs, or guessed from people
clever enough to understand the code and the theory behind it.
- The syntax and the code was never streamlined, and never seemed very
consistent. For instance, some of the functions accepted in the function{}
statement are specific to it, like "^" instead of pow(), while other are not
supported. The use of commas, <,> and quotes never seemed very logical to me,
and neither was the use of "bounded_by" (now replaced by "contained_by"). This
is partly explained by the fact that this patch implemented functions that
didn't exist in POV back then (it started as a POV 2 patch).
- There was always strange things happening with them, like crashes and black
dots, or parts of the picture disappearing, or the render getting impossibly
slow, or shapes actually changing between version updates. Again, this works
much better now.
- My guess is that there is a lot of work to be done by the POV team before the
isosurfaces can be as reliable as the rest of the pov objects. Unless I'm
mistaken, they have been working on it (at least Chris Young talked about it in
his message "POV-Ray plans for v3.1 and beyond" of 2/2/99).
- However I'm in no position to complain about the isosurfaces because in spite
of their problems they've been absolutely fundamental in my POV work !
G.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
