POV-Ray : Newsgroups : povray.general : Understanding isosurface, difference between negative and positive Server Time
29 Jul 2024 00:34:04 EDT (-0400)
  Understanding isosurface, difference between negative and positive (Message 1 to 9 of 9)  
From: Louis
Subject: Understanding isosurface, difference between negative and positive
Date: 28 Dec 2013 08:45:00
Message: <web.52bed4f3fa5e84cdcbe7ea7c0@news.povray.org>
After reading some tutorials and viewing examples I thought I understood
isosurfaces, however when trying to create them myself, I run into problems.

I understand that function {(x*x + y*y + z*z - 1)} would create a sphere, but
why doesn't function {(x*x + y*y + z*z + 1)} (plus instead of minus)?

According to my reasoning it should generate exactly the same sphere, using plus
or minus should not make any difference in this formula, it only mirrors the
coordinates which results in the same sphere right?

What am I missing?


Post a reply to this message

From: Le Forgeron
Subject: Re: Understanding isosurface, difference between negative and positive
Date: 28 Dec 2013 09:20:20
Message: <52bede24@news.povray.org>
Le 28/12/2013 14:41, Louis nous fit lire :
> After reading some tutorials and viewing examples I thought I understood
> isosurfaces, however when trying to create them myself, I run into problems.
> 
> I understand that function {(x*x + y*y + z*z - 1)} would create a sphere, but
> why doesn't function {(x*x + y*y + z*z + 1)} (plus instead of minus)?
> 
> According to my reasoning it should generate exactly the same sphere, using plus
> or minus should not make any difference in this formula, it only mirrors the
> coordinates which results in the same sphere right?
> 
> What am I missing?

The fact that the whole formula is evaluated to find the frontier of the
shape at the value of threshold (default to 0.0).

So, x*x + y*y + z*z - 1 threshold 0 is identical to x*x + y*y + z*z + 1
threshold 2.

Indeed, the simplest sphere is x*x + y*y + z*z, threshold r*r.
(r being the radius of the sphere).


Post a reply to this message

From: clipka
Subject: Re: Understanding isosurface, difference between negative and positive
Date: 28 Dec 2013 09:56:07
Message: <52bee687$1@news.povray.org>
Am 28.12.2013 14:41, schrieb Louis:
> After reading some tutorials and viewing examples I thought I understood
> isosurfaces, however when trying to create them myself, I run into problems.
>
> I understand that function {(x*x + y*y + z*z - 1)} would create a sphere, but
> why doesn't function {(x*x + y*y + z*z + 1)} (plus instead of minus)?
>
> According to my reasoning it should generate exactly the same sphere, using plus
> or minus should not make any difference in this formula, it only mirrors the
> coordinates which results in the same sphere right?
>
> What am I missing?

The isosurface's surface is the set of all points satisfying f(x,y,z)=0. 
(That is, unless a different threshold than 0 is specified.)

The set of solutions to the equation

     x^2 + y^2 + z^2 - 1 = 0

is the set of all points having a distance of 1 to the coordinate origin 
- in other words, the surface of the unit sphere.

The equation

     x^2 + y^2 + z^2 + 1 = 0

has no solutions at all (in the domain of real numbers, to be precise), 
as any number squared is >= 0, so the left side of the equation is 
always >= 1.


Post a reply to this message

From: William F Pokorny
Subject: Re: Understanding isosurface, difference between negative and positive
Date: 28 Dec 2013 10:21:55
Message: <52beec93$1@news.povray.org>
On 12/28/2013 09:20 AM, Le_Forgeron wrote:
> Le 28/12/2013 14:41, Louis nous fit lire :
 >> ...
>> According to my reasoning it should generate exactly the same sphere, using plus
>> or minus should not make any difference in this formula, it only mirrors the
>> coordinates which results in the same sphere right?
>>
>> What am I missing?
>
> The fact that the whole formula is evaluated to find the frontier of the
> shape at the value of threshold (default to 0.0).
>
> So, x*x + y*y + z*z - 1 threshold 0 is identical to x*x + y*y + z*z + 1
> threshold 2.
>
> Indeed, the simplest sphere is x*x + y*y + z*z, threshold r*r.
> (r being the radius of the sphere).
>

I'll add if you are looking for the inverse function, to mirror about 
the 0.0 threshold of your first equation, the function would be :

-((x*x + y*y + z*z) - 1)

This will look like your container unless you set up your container 
definition to cut across the inverted sphere. Or put your camera and 
light inside the inverted sphere. However, the latter will be hard to 
see as anything but a background color without noise or patterning on 
the isosurface too.

Perhaps as another aid to understanding, I'll throw in that you can 
create an isosurface, spherical, shell shape by setting up both your 
sphere and inverted sphere function with a small offset then 
intersecting the two function's slightly overlapping negative coordinate 
spaces with max(). This would look like:

#declare F0     = function (x,y,z) {  ((x*x+y*y+z*z)-1)-0.025 }
#declare F0_inv = function (x,y,z) { -((x*x+y*y+z*z)-1)-0.025 }
#declare F = function (x,y,z) { max(F0(x,y,z),F0_inv(x,y,z)) }

with F as the final isosurface function and the threshold at 0.0.

Bill P.


Post a reply to this message

From: Louis
Subject: Re: Understanding isosurface, difference between negative and positive
Date: 28 Dec 2013 11:45:01
Message: <web.52befed0b61b6914cbe7ea7c0@news.povray.org>
clipka <ano### [at] anonymousorg> wrote:
> The equation
>
>      x^2 + y^2 + z^2 + 1 = 0
>
> has no solutions at all (in the domain of real numbers, to be precise),
> as any number squared is >= 0, so the left side of the equation is
> always >= 1.

Thanks! that cleared it up! I looked over the fact that squared dimensions are
always positive. Ouch.


Post a reply to this message

From: Doctor John
Subject: Re: Understanding isosurface, difference between negative and positive
Date: 28 Dec 2013 17:24:49
Message: <52bf4fb1@news.povray.org>
On 28/12/13 16:39, Louis wrote:
> 
> Thanks! that cleared it up! I looked over the fact that squared dimensions are
> always positive. Ouch.
> 

We've all done it (or something similar)

John
-- 
Protect the Earth
It was not given to you by your parents
You hold it in trust for your children


Post a reply to this message

From: Louis
Subject: Re: Understanding isosurface, difference between negative and positive
Date: 4 Jan 2014 20:30:01
Message: <web.52c8b427b61b6914cbe7ea7c0@news.povray.org>
Doctor John <j.g### [at] gmailcom> wrote:
> On 28/12/13 16:39, Louis wrote:
> >
> > Thanks! that cleared it up! I looked over the fact that squared dimensions are
> > always positive. Ouch.
> >
>
> We've all done it (or something similar)
>
> John
> --
> Protect the Earth
> It was not given to you by your parents
> You hold it in trust for your children

I must be doing something similar again, I've spent some hours looking, but I
can't spot my error:

// Rotate a position 1 km above earths surface to some coordinate
#declare test=vrotate(<0,0,-6372>, <35.201352,111.639249,0>);

#debug concat("position = <",str(test.x,0,3),
",",str(test.y,0,3),",",str(test.z,0,3), ">\n")

#debug
concat("height=",str(pow(pow(test.x,3)+pow(test.y,3)+pow(test.z,3),(1/3)),0,3),
"\n") // This should be 6372, rotating about the origin <0,0,0>

The result is:
position = <-4839.809,3673.150,1920.052>
height=-1.#IO

I'm not sure why height is printed out like that (-1.#IO), is it trying to use
imaginary numbers? Any way, if I calculate it on a calculator:

cube(4839.809) + cube(3673.15) + cube(1920.052) = 170003198137.853207737
cuberoot(170003198137,853207737) = 5539,6929949498910498665819311567

So how did my altitude get burried down under the earths crust in hot lava? I'd
expect the length of the vector to stay 6372, regardless of how it rotates.

Am I misunderstanding vrotate? When I do:
{
translate <0,0,-6372>
rotate <35.201352,111.639249,0>
}
It does end up at the expected location.

The reason I want to use vrotate, is because I want the camera's look_at
position to be at that location (and I can't translate and rotate the look_at
position without translating and rotating the entire camera).

What am I missing?


Post a reply to this message

From: clipka
Subject: Re: Understanding isosurface, difference between negative and positive
Date: 5 Jan 2014 01:42:12
Message: <52c8fec4$1@news.povray.org>
Am 05.01.2014 02:23, schrieb Louis:
> Doctor John <j.g### [at] gmailcom> wrote:
>> On 28/12/13 16:39, Louis wrote:
>>>
>>> Thanks! that cleared it up! I looked over the fact that squared dimensions are
>>> always positive. Ouch.
>>>
>>
>> We've all done it (or something similar)
>>
>> John
>> --
>> Protect the Earth
>> It was not given to you by your parents
>> You hold it in trust for your children
>
> I must be doing something similar again, I've spent some hours looking, but I
> can't spot my error:
>
> // Rotate a position 1 km above earths surface to some coordinate
> #declare test=vrotate(<0,0,-6372>, <35.201352,111.639249,0>);
>
> #debug concat("position = <",str(test.x,0,3),
> ",",str(test.y,0,3),",",str(test.z,0,3), ">\n")
>
> #debug
> concat("height=",str(pow(pow(test.x,3)+pow(test.y,3)+pow(test.z,3),(1/3)),0,3),
> "\n") // This should be 6372, rotating about the origin <0,0,0>
>
> The result is:
> position = <-4839.809,3673.150,1920.052>
> height=-1.#IO
>
> I'm not sure why height is printed out like that (-1.#IO), is it trying to use
> imaginary numbers?

No; the "-1.#IO" is probably a failed attempt to round either "-1.#INF" 
or "-1.#IND" to 3 fractional digits. Printing the height to a precision 
of at least 4 fractional digits should give you more information (you 
can specify "-1" as the number of fractional digits to let POV-Ray decide).

> Any way, if I calculate it on a calculator:
>
> cube(4839.809) + cube(3673.15) + cube(1920.052) = 170003198137.853207737
> cuberoot(170003198137,853207737) = 5539,6929949498910498665819311567

Note that you're not doing exactly the same thing, as you're dropping 
the sign of the first value. As you're raising it to a power of 3, the 
sign is kept. Moreover, the sum of all three cubes is also negative.

POV-Ray's implementation of pow() is based on the standard C math 
library, which doesn't like raising a negative value to the power of any 
non-integer, even if the exponent is the reciprocal of an integer (not 
to mention that the binary floating-point representation of 1/3 isn't 
exactly 1/3 due to rounding).


> So how did my altitude get burried down under the earths crust in hot lava? I'd
> expect the length of the vector to stay 6372, regardless of how it rotates.
>
> Am I misunderstanding vrotate?

No, but you're misunderstanding distance computations in 3D space ;-)

You probably thought that with distance computations in 2D space using 
squares and square roots, 3D space would call for cubes and cubic roots, 
but this is not the case at all; the proper formula should indeed be:

   #declare length = sqrt(pow(test.x,2)+pow(test.y,2)+pow(test.z,2));

or, even simpler yet (and less prone to errors ;-)):

   #declare length = vlength(test);


Post a reply to this message

From: Louis
Subject: Re: Understanding isosurface, difference between negative and positive
Date: 6 Jan 2014 13:40:01
Message: <web.52caf857b61b6914cbe7ea7c0@news.povray.org>
clipka <ano### [at] anonymousorg> wrote:
> Am 05.01.2014 02:23, schrieb Louis:
> > Doctor John <j.g### [at] gmailcom> wrote:
> >> On 28/12/13 16:39, Louis wrote:
> > Am I misunderstanding vrotate?
>
> No, but you're misunderstanding distance computations in 3D space ;-)
>
> You probably thought that with distance computations in 2D space using
> squares and square roots, 3D space would call for cubes and cubic roots,
> but this is not the case at all; the proper formula should indeed be:
>
>    #declare length = sqrt(pow(test.x,2)+pow(test.y,2)+pow(test.z,2));
>
> or, even simpler yet (and less prone to errors ;-)):
>
>    #declare length = vlength(test);

Thanks,

Finally found the error, using coordinates as positions somewhere.

I should have been able to reason squares instead of cubes, guess Pythagoras
used some more time to think about it than I did :-)

Cheers,
Louis


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.