Warp wrote in message <3a092379@news.povray.org>...
>  #declare Fact = function { x<1 ? 1 : x*Fact(x-1) }


I don't know whole architecture of source code
but perhaps this is impossible to call to name which
declaration is not finished
but perhaps this could be done with function "self"
which means pointer to currently declared function
this is known pointer during declaration I think
or if not it could be recived during trace,
am I wrong ?

ABX

Post a reply to this message

Guess what?  This works just fine in MegaPOV 0.5a!

#declare Fact = function{ 1 }
#declare Fact = function { x<1 ? 1 : x*Fact(x-1) }

--
Mark

Post a reply to this message

Chris Huff wrote:

> <snip>
> And of course, functions allowing different numbers of parameters...

Why not just use shaders to specify the isosurface funcs?

--
Bye
Pabs

Post a reply to this message

Pabs wrote in message <3A0B61CC.86B37226@hotmail.com>...
> Chris Huff wrote:
> > And of course, functions allowing different numbers of parameters...
> Why not just use shaders to specify the isosurface funcs?


I don't know shaders but I think
is better to learn and use one language instead of two
but what's more important isosurface will be in 3.5 and shaders not
I have an idea how to include parameters and locals to functions
I work on it

ABX

Post a reply to this message

In article <3A0B61CC.86B37226@hotmail.com>, Pabs <pab### [at] hotmailcom> 
wrote:

> Why not just use shaders to specify the isosurface funcs?

I assume you mean replace functions with shaders...that would most 
likely be slower. Isosurface functions are designed to take a simple 
equation and return a float value, shaders take all sorts of 
instructions and calculate a color. It would also be harder to write the 
scene code...functions are a lot simpler than shaders.
I think a syntax like this would be most useful:

#declare Sphere =
function(x, y, z, Px, Py, Pz, R)
{
    r - sqrt((x-Px)^2 + (y-Py)^2 + (z-Pz)^2)
}

The "x, y, z" variables would be the default, but you could specify your 
own variables to use instead.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Mark Wagner <mar### [at] gtenet> wrote:
: Guess what?  This works just fine in MegaPOV 0.5a!

: #declare Fact = function{ 1 }
: #declare Fact = function { x<1 ? 1 : x*Fact(x-1) }

  Looks like a kludge (I suppose that the first line is to fool the parser
to not to issue an error for the 'Fact()' call in the second line) :)

  I suppose that this kind of recursion is not speed-optimized in the current
code.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Chris Huff wrote:

> In article <3A0B61CC.86B37226@hotmail.com>, Pabs <pab### [at] hotmailcom>
> wrote:
>
> > Why not just use shaders to specify the isosurface funcs?
>
> I assume you mean replace functions with shaders...that would most
> likely be slower. Isosurface functions are designed to take a simple
> equation and return a float value, shaders take all sorts of
> instructions and calculate a color. It would also be harder to write the
> scene code...functions are a lot simpler than shaders.
> I think a syntax like this would be most useful:
>
> #declare Sphere =
> function(x, y, z, Px, Py, Pz, R)
> {
>     r - sqrt((x-Px)^2 + (y-Py)^2 + (z-Pz)^2)
> }
>
> The "x, y, z" variables would be the default, but you could specify your
> own variables to use instead.

I agree with all that but what if you need a pattern that cannot be
generated by a mathematical formula but by an algorithmn of some sort. -
s'pose you would just have to recompile the src with your pattern built in.
--
Bye
Pabs

Post a reply to this message

Warp wrote in message <3a0bef9d@news.povray.org>...
>Mark Wagner <mar### [at] gtenet> wrote:
>: Guess what?  This works just fine in MegaPOV 0.5a!
>
>: #declare Fact = function{ 1 }
>: #declare Fact = function { x<1 ? 1 : x*Fact(x-1) }
>
>  Looks like a kludge (I suppose that the first line is to fool the parser
>to not to issue an error for the 'Fact()' call in the second line) :)


Yes, that's why it's there.

Post a reply to this message

Pabs wrote in message <3A0F8C00.5FC694EB@hotmail.com>...
> I agree with all that but what if you need a pattern that cannot be
> generated by a mathematical formula but by an algorithmn of some
sort. -
> s'pose you would just have to recompile the src with your pattern
built in.


you can still do this if you want, but ...
1. not everybody know C even if he know algorithm for such pattern
2. you can test your pattern before coding
3. you can make box as box{} as isosurface{} as csg{} and as own patch

imagine that you can write one function to create isosurface
for body of plant and to place flowers and leafs in while loop

ABX

Post a reply to this message

In article <3A0F8C00.5FC694EB@hotmail.com>, Pabs <pab### [at] hotmailcom> 
wrote:

> I agree with all that but what if you need a pattern that cannot be
> generated by a mathematical formula but by an algorithmn of some sort. -
> s'pose you would just have to recompile the src with your pattern built 
> in.

I think it would be a good idea to have things like loops, a "real" if 
statement, etc. available in functions. I don't think it would 
noticeably slow things down in functions that don't use these features, 
but could expand the pattern possibilities even more. And if the ability 
to use functions in the scene file is added, you could move some of the 
math-intensive calculations into functions for a small parsing speed up. 
This would only work for floating-point or integer numbers, no objects, 
colors, or vectors...but it would still be useful.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message