This was done with the G patch I've been talking about on some of the 
other groups. I thought I'd test out G functions with a simple Lissajous 
figure. It currently works, but the G code has to be in a separate file, 
I'm thinking of possible ways to fix that. This demonstrates the use of 
G functions as user-defined vector functions, I'll be working on a way 
to use them in pigments as well, maybe as full-blown shaders.

Here's the G code used (in the file gpovtest.g):

function vector Position(scalar in) {
    scalar t = in*2*pi;
    return [sin(t*9), cos(t*7), cos(t*5)];
};

function vector Color(vector pt) {
    return [sin(pt.x*5)*cos(pt.x*9), sin(pt.x*5)*cos(pt.y*8), 
sin(pt.z*11)*cos(pt.z*7)];
};


And here's the POV code:

global_settings {
    assumed_gamma 1
}

camera {
    location < 0, 0,-5>
    look_at < 0, 0, 0>
    angle 45
}

light_source {<-50, 50,-50>, color rgb 1}
light_source {< 0, 0,-5>, color rgb 0.1}

plane {-z, -1
    texture {
        pigment {checker color rgb 0, color rgb 1}
        finish {ambient 0 diffuse 1}
    }
}

//Compile the G code
g "gpovtest.g"

//hook up POV functions to the G functions
//this just tells POV the name, return type, and parameter types
#declare pointFn = function {g vector Position(scalar)}
#declare colorFn = function {g vector Color(vector)}

#declare J = 0;
#declare N = 3000;
#while(J < N)
    #declare ptA = pointFn(J/N);
    #declare ptB = pointFn((J+1)/N);
    union {
        sphere {ptA, 0.035}
        cylinder {ptA, ptB, 0.05}
        texture {
//            pigment {color rgb ptA/2 + 0.5}
            pigment {color rgb colorFn(ptA.x, ptA.y, ptA.z)}
            finish {
                ambient 0 diffuse 1
                specular 1 roughness 0.01
            }
        }
    }
    #declare J = J + 1;
#end

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Attachments:
Download 'gpovtest.jpg' (31 KB)

Preview of image 'gpovtest.jpg'

"Christopher James Huff" <chr### [at] maccom> wrote in message
news:chr### [at] netplexaussieorg...
> This was done with the G patch I've been talking about on some of the
> other groups. I thought I'd test out G functions with a simple Lissajous
> figure. It currently works, but the G code has to be in a separate file,
> I'm thinking of possible ways to fix that. This demonstrates the use of
> G functions as user-defined vector functions, I'll be working on a way
> to use them in pigments as well, maybe as full-blown shaders.
>
> Here's the G code used (in the file gpovtest.g):

    ........

        Nice to see a Lissajous knot again.

          ~Steve~


> --
> Christopher James Huff <cja### [at] earthlinknet>
> http://home.earthlink.net/~cjameshuff/
> POV-Ray TAG: chr### [at] tagpovrayorg
> http://tag.povray.org/
>
>

Post a reply to this message

Christopher James Huff wrote:

> This was done with the G patch I've been talking about on some of the
> other groups. I thought I'd test out G functions with a simple Lissajous
> figure. It currently works, but the G code has to be in a separate file,
> I'm thinking of possible ways to fix that. This demonstrates the use of
> G functions as user-defined vector functions, I'll be working on a way
> to use them in pigments as well, maybe as full-blown shaders.


Heh, very nice. I know it is a bit early and doing things at parse-time 
isn't what G is targeted for, but could you say something about the speed 
differences between #macros and compiled G functions, for instance in your 
above example?

Post a reply to this message

In article <3dbda450@news.povray.org>,
 Johannes Dahlstrom <sad### [at] tkukoulufi> wrote:

> Heh, very nice. I know it is a bit early and doing things at parse-time 
> isn't what G is targeted for, but could you say something about the speed 
> differences between #macros and compiled G functions, for instance in your 
> above example?

Actually, this was all done at parse time. They do work at render time, 
though I haven't made many tests of this.
About the speed: probably a lot closer to the existing POV functions 
than to parsing. It doesn't do any optimization, but evaluating the 
opcodes will be far faster than interpreting scene code directly. A 
simple loop got about half a million iterations per second on my system, 
POV gets closer to a few thousand (it was just a simple do-nothing loop 
though, so no real measure of speed, and will be faster when increment 
and decrement operations are added).
Replacing macros with G functions for math calculations could gain a lot 
of speed, but you can't manipulate things like POV objects (not yet, at 
least). Also, G functions should handle recursion with no problems (this 
is untested, though). And since POV functions can't take vector 
parameters, you have to split vectors into three float parameters to 
pass them to G functions (since G functions are accessed through POV 
functions).

So compared to POV: very fast. Compared to the existing POV VM: probably 
quite slow for simple things, but since it allows things that can 
eliminate a lot of duplicate computations necessary in POV functions, it 
could be a lot faster for some problems.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message