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

On Tue, 20 Nov 2001 16:31:13 +0100, "Rune" <run### [at] mobilixnetdk> wrote:
> Disclaimer: This is not a feature request but a feature idea.

IMO it could be extremly hard to implement in current sources and possible only
with complete rewrite.
IMO it could slow down rendering extremly.
IMO you want something like shader.
IMO you can find workarounds for some parts of it.
IMO it could be nice feature :-)

ABX
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)|_((x+y)*.7,z,.1)|_((x+y+2)*.7,z,.1)|_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35

Post a reply to this message

On Tue, 20 Nov 2001 16:31:13 +0100, Rune wrote:
> 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.

As you probably know, POV 3.5 has a built-in bytecode interpreter that's used
to do functions and isosurfaces and such.  However, it's not limited to just
those uses.  It could easily be used to execute an SL-like language.  The
idea of using it to do the sort of thing you suggest is something that's been
tossed around with the POV-Team, but put off until some other time due to 
time constraints (among other things, the interpreter would have to be beefed
up to have integer numeric types and so on.)

-- 
plane{-z,-3normal{crackle scale.2#local a=5;#while(a)warp{repeat x flip x}rotate
z*60#local a=a-1;#end translate-9*x}pigment{rgb 1}}light_source{-9red 1rotate 60
*z}light_source{-9rgb y rotate-z*60}light_source{9-z*18rgb z}text{ttf"arial.ttf"
"RP".01,0translate-<.6,.4,.02>pigment{bozo}}light_source{-z*3rgb-.2}//Ron Parker

Post a reply to this message

Rune wrote:
> 
> 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:
> 
> [...]
> 
> I think you get the idea - so what do you think?

I think it's definitely an interesting idea, but it would be quite a large
change, strongly influencing the style of the SDL in total.

> 
> 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.
> 

Yes, that's essentially the purpose of shaders.  

Concerning your last sentence also note that compiled shaders are faster,
Povray 3.5 does some kind of 'compilation' with functions too (like Ron
mentioned), but it's done every time during parsing and the syntax of
functions is much more limited.  Extending PovMan for compilation 'on the
fly' during parsing would be a good idea, one could even have the shader
code 'inline' in the POV script.  Alternatively a more SDL-like shading
language would be another possibility.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

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

> 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.

There is already a patch of POV-Ray called POV-Man that allows you do write
shaders in a shader language in separate files that are compiled.

But what I was talking about was a solution in POV-Ray script that could be
written directly in the scene file.

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

Ok. But LUA executes strings of code. Then you can write something like in
POVRAY code
color = lua_color_shader("function color_from_normal(position,normal,...)
return n;", position, normal,...);
LUA is an extension language as Scheme(Like Lisp), ELK, SmallC(Like C), and
SL (RMan)... But it hasn't restrictions so you can use it in many ways. For
example, in procedural animation, or like PHP for creating a new chain of
code.

--
______________________________________________



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

news:3c1b5fd7@news.povray.org...

> > 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.
>
> There is already a patch of POV-Ray called POV-Man that allows you do
write
> shaders in a shader language in separate files that are compiled.
>
> But what I was talking about was a solution in POV-Ray script that could
be
> written directly in the scene file.
>
> 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