I think that your idea it's possible and can be made now. There is an
extension language with it's byte code very simililar to VB and
cross-platform, it's name is LUA. The only thing you need to do is link its
lib and call the code as an string or as a compiled file. Then you can
retrieve the retur values as a vector, a single float, etc.

LUA was tested in a lot of enviroments without problems. It's used by ILM
among others.

I have no problem in make it now but LUA authors will force POVRAY to
include it's logo in the Povray application.

--
______________________________________________



Email: ult### [at] yahoocom
Personal page: http://www.geocities.com/thecopyright
______________________________________________

news:3bfa7761@news.povray.org...
> Disclaimer: This is not a feature request but a feature idea. What I hope
to
> accomplish is to spawn thoughs in other people's heads and start
discussion
> on the subject.
>
> Something I've been thinking of for some time is how extremely powerful it
> would be if functions could be used for any float value found inside a
> texture statement. I have no idea if this would be possible, so anyone who
> might have an idea, please let me know if the idea is completely
impossible,
> or if it's just your regular very-difficult-thing-requiring-total-rewrite.
>
> Say for example that you have a function called F(x,y,z) and another
called
> G(x,y,z). All the following examples would then be valid:
>
> pigment {
>    bozo
>    color_map{
>       [0, rgb F(x,y,z)]
>       [1, color <1,G(x,y,z),1>]
>    }
> }
>
> pigment {
>    bozo
>    color_map {
>       [F(x,y,z), color Color1]
>       [F(x,y,z), color Color2]
>    }
> }
>
> normal {wrikles F(x,y,z) turbulence G(x,y,z)}
>
> normal {crackle 0.5 rotate y*360*F(x,y,z)}
>
> finish {ambient F(x,y,z), diffuse 1-F(x,y,z) reflection G(x,y,z)}
>
> finish {phong F(x,y,z) phong_size G(x,y,z)}
>
> I think you get the idea - so what do you think?
>
> Another part of the suggestion is expanding the number of variables that
> textures make available to functions. Currently the intersection point is
> avaiable as x,y,z.
>
> I suggest the following:
> Intersection point as x,y,z or perhaps something like px,py,pz
> Normal at intersection point as nx,ny,nz
> Vector of incoming ray as vx,vy,vz
>
> And possible other information. I'm not so sure about this part, and
> especially not the details, but as I said I just wanted to share the
> thoughts. Other suggestions of how to accomplish extreme user-control of
> textures would have my interest. I've already heard of shaders using
> POV-Man, but I think that an approach more natural to the POV-Ray
scripting
> language, and which wouldn't require compiling would be better.
>
> Rune
> --
> 3D images and anims, include files, tutorials and more:
> Rune's World:    http://rsj.mobilixnet.dk (updated Nov 5)
> POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
> POV-Ray Webring: http://webring.povray.co.uk
>
>

Post a reply to this message