Hi all, I need to be able to render arbitrary functions easily. In other words,
the following function would draw a sphere by checking a giant 3D grid of
say... 100x100x100 voxels to check if the point is in the sphere:

// Check through multiple x, y and z voxels to draw a sphere:
bool sphere(float x, float y, float z) {    // x, y and z are normalized to 1 or
less.
 float f = sqrt(x^2 + y^2 + z^2)
 if (f<1.0) return 1; // Part of sphere
 else return 0;  // Not part of sphere
}

Is this easy to do in Povray or maybe some other 3D software? An equivalent to
voxels would be to trace rays to see if it intercepts the function. Either way
is fine as long as a sphere is produced from the above 'code'/function.

Post a reply to this message

"twinbee" <twi### [at] skytopiacom> wrote:
> Hi all, I need to be able to render arbitrary functions easily. In other words,
> the following function would draw a sphere by checking a giant 3D grid of
> say... 100x100x100 voxels to check if the point is in the sphere:

There are a couple options.  I would probably recommend isosurfaces if you don't
actually NEED the grid representation.  It just boils down to a root-finding
problem.  That means you can specify an arbitrarily complex function without
the need for grids.  I won't go into much detail since others have said it
better:

http://www.povray.org/documentation/view/3.6.0/73/

If you do need a voxel representation, then df3 is the way to go.  Again, the
following page gives an excellent description.  You can also use it to create
surfaces (i.e. not just volume-rendering), but unless you need more detail
here, I won't get carried away.

http://local.wasp.uwa.edu.au/~pbourke/miscellaneous/df3/

 - Ricky

Post a reply to this message

> There are a couple options.  I would probably recommend isosurfaces if you don't
> actually NEED the grid representation.  It just boils down to a root-finding
> problem.  That means you can specify an arbitrarily complex function without
> the need for grids.  I won't go into much detail since others have said it
> better:
>
> http://www.povray.org/documentation/view/3.6.0/73/
>
> If you do need a voxel representation, then df3 is the way to go.  Again, the
> following page gives an excellent description.  You can also use it to create
> surfaces (i.e. not just volume-rendering), but unless you need more detail
> here, I won't get carried away.
>
> http://local.wasp.uwa.edu.au/~pbourke/miscellaneous/df3/

Hi Ricky, thanks. That page has a sphere function which is very similar to mine
- great stuff.

My only concern is that an isosurface won't be able to support the colour of
each bit of the 3D object. With my function I originally posted, one may be
able to say that for each x/y/z 'voxel', to do some extra processing to
determine the colour for that bit of object (say based on how its y position or
something). Is that not possible with the isosurface approach?

Post a reply to this message

Wasn't it twinbee who wrote:
>> There are a couple options.  I would probably recommend isosurfaces 
>>if you don't
>> actually NEED the grid representation.  It just boils down to a root-finding
>> problem.  That means you can specify an arbitrarily complex function without
>> the need for grids.  I won't go into much detail since others have said it
>> better:
>>
>> http://www.povray.org/documentation/view/3.6.0/73/
>>
>> If you do need a voxel representation, then df3 is the way to go.  Again, the
>> following page gives an excellent description.  You can also use it to create
>> surfaces (i.e. not just volume-rendering), but unless you need more detail
>> here, I won't get carried away.
>>
>> http://local.wasp.uwa.edu.au/~pbourke/miscellaneous/df3/
>
>Hi Ricky, thanks. That page has a sphere function which is very similar to mine
>- great stuff.
>
>My only concern is that an isosurface won't be able to support the colour of
>each bit of the 3D object. With my function I originally posted, one may be
>able to say that for each x/y/z 'voxel', to do some extra processing to
>determine the colour for that bit of object (say based on how its y position or
>something). Is that not possible with the isosurface approach?

You can do that with any type of object, just use a pigment function.

http://www.econym.demon.co.uk/isotut/pigfun.htm

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

> You can do that with any type of object, just use a pigment function.
>
> http://www.econym.demon.co.uk/isotut/pigfun.htm

Many thanks! I'm guessing other attributes such as variable
translucency or specularity throughout the surface of the material
can be set as well.

Post a reply to this message

Wasn't it twinbee who wrote:
>> You can do that with any type of object, just use a pigment function.
>>
>> http://www.econym.demon.co.uk/isotut/pigfun.htm
>
>Many thanks! I'm guessing other attributes such as variable
>translucency or specularity throughout the surface of the material
>can be set as well.

Specularity is tricky. The specular value of any individual texture is 
constant, so if you want to vary the specularity you have to use more 
than one texture combined in a texture map. See the recent "specular 
texture" thread in this group but use a function instead of 
image_pattern to blend them.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Cheers. I may have come across a hurdle or two. I'm going to quote someone from
an email - I'm sure they won't mind:

> The problem is there's no way to incorporate while loops and local
> variables into POV-Ray's isosurface functions. Basically, there are
> functions and there are macros in POV-Ray. Macros can incorporate
> while loops and local variables, but functions cannot. But,
> isosurfaces can only be created using functions.

Is this planned for a future version of POVray?

Post a reply to this message

web.4aa7b81019a8cf54813aa4820@news.povray.org...
>> The problem is there's no way to incorporate while loops and local
>> variables into POV-Ray's isosurface functions. Basically, there are
>> functions and there are macros in POV-Ray. Macros can incorporate
>> while loops and local variables, but functions cannot. But,
>> isosurfaces can only be created using functions.
>
> Is this planned for a future version of POVray?
>
>
I am not an expert but I think it is not like you just had to want it :-/
Maybe one day if Santa joins the POV-team ... :-)

Marc

Post a reply to this message

twinbee schrieb:
>> The problem is there's no way to incorporate while loops and local
>> variables into POV-Ray's isosurface functions. Basically, there are
>> functions and there are macros in POV-Ray. Macros can incorporate
>> while loops and local variables, but functions cannot. But,
>> isosurfaces can only be created using functions.
> 
> Is this planned for a future version of POVray?

The answer is a threefold "yes/no/maybe".

"Yes" because there has been some discussion whether POV-Ray 4.0 should 
be equipped with a brand-new SDL, and in that case, whether it might be 
some bytecode-based language that could be used for scene scripting and 
functions alike.

"No" because isosurface functions would probably still be subject to 
major restrictions, or they might screw up the intersection-finding 
algorithm and/or totally kill performance.

"Maybe" because the people to actually have any say in it did not, to my 
knowledge, participate in the discussion, so their opinion on this is 
currently an unknown variable. There seems to be consensus that the SDL 
should get a major overhaul, but to what degree is not yet clear.

Post a reply to this message

> "Yes" because there has been some discussion whether POV-Ray 4.0 should
> be equipped with a brand-new SDL, and in that case, whether it might be
> some bytecode-based language that could be used for scene scripting and
> functions alike.
>
> "No" because isosurface functions would probably still be subject to
> major restrictions, or they might screw up the intersection-finding
> algorithm and/or totally kill performance.
>
> "Maybe" because the people to actually have any say in it did not, to my
> knowledge, participate in the discussion, so their opinion on this is
> currently an unknown variable. There seems to be consensus that the SDL
> should get a major overhaul, but to what degree is not yet clear.

Thanks. Until then, is there another 3D renderer I can try out which allows
local vars and while loops inside functions like this?

Post a reply to this message