war### [at] tagpovrayorg news:42121e1e@news.povray.org

>   I wonder if you understand what a plugin is.
>   What you are describing above is basically just the same thing as
>   the 
> #include files of the current SDL being distributed out there are
> (except for support for compilation to bytecode, which in itself has
> nothing to do with plugins).
>   What you are describing above is basically a library written in the
> same scripting language as the native POV-Ray scripting language.

And it assumes much more advanced language then current SDL, that is, meany 
things can be done with crurrent function/pattern/#macro but are very hard, 
in example I can write a procedural texture using serveral if's as a huge 
function formula with select(..) inside, but the code would be quite ugly.
 
>   While one could argue that's also a "plugin", it's not the same
>   thing 
> as the dll plugins in most windows software.
>   A dll plugin would be written in C++ (or C) and would need to be
> compiled with a C++ compiler. POV-Ray itself couldn't compile these
> plugins unless it had a full-fledged C++ compiler inside it (which
> doesn't make sense, of course). In fact, it doesn't really matter
> which language the plugin is originally written in, what matters is
> the end result: A dll containing native machine code with a certain
> structure.

Yes, I think that pure-plugins are not so badly needed. Using own language 
that can be both interpreted or parsed into C and then pre-compiled to 
speedup,would be much better (ofcourse also - quite harder to implement).

One of ideas was that shader could access most parts of the scene, of ini 
settings, and so on, not just basic x,y,z variables (for pigment shader).

>   The correct solution is to create a scripting language for POV-Ray
> as its main SDL which allows making the things which are not currently
> possible. Requiring users to know C++ and have a C++ compiler in order
> to create platform-specific dlls is not the answer.

I agree. IMHO, language could give access to all things using C-structure-
style syntax, like 
  ThisObject.Pigment.Shader[3].Calculate(x,y,z); 
  // return color of 3-th shader in pigment shader list for current object

The other goal of such language (and additional work) - making developing 
Pov-RAY easier. A while before I had idea to write patch that will have 
keyword for stripping an object from all textures (with allows then to 
assign a new texture). It would be not so easy probably, the Pov-RAY source 
code is unfortunetely not so clear and documented IMHO (or rather - it is 
missing one general HOWTO for developers simmlar to HOWTO/manual for 
users).

Doing it with shaders would be easy:

#shader StipTexture
target "object" // on what type of entity it will be used on

function Strip(PovObject &Obj) {
  Obj.Texture = NULL; // no texture
  for (int i=0; i < obj.Children.Count ; i++) Strip(obj.Children[i]);
}

function void Main() { // main Shader in a #shader block is called Nain()
  Strip(Object); // recursively strip this object and all of it sub-objects 
  // from textures
}
#end

#shader AssignTexture
target "object" // on what type of entity it will be used on
function Main(PovTexture tex) {
  obj.Texture = tex;
}
#end


object { SomeObject shader { StripTexture, AssignTexture(MyTexture) }  }


// We need additional AssignTexture, since all shaders are implementd to 
// object *after* shaders, so example:
//   object { SomeObject shader { StripTexture } texture{ MyTexture } }
// would not work - it would 1. add new top-level texture that will apply
// to all parts of SomeObject with do not have defined texture, then it 
// will call shader to strip down all previous textures

shader { SHADER_1 , [ SHADER_2 ... SHADER_N ] }

defines list (array) of shader that work on current entity (object, 
pigment, texture, or even entire scene), are called after applying all 
"normal" atributes/settings of this entity (like in Pov-RAY 3.6), and are 
called in same order - from 1 to N.

To make it easier there is include file that is for shaders same as 
functions.inc was for shader/isosurfaces - it defines all basic SDL 
elements as shaders, in example:

object {  
  MyObject 
  shader { ShaderTest1 }
  shader { sh_pigment( bozo ) } // <--- this
  shader { ShaderTest2 }
}

same as thanks to functions.inc one can use f_bozo and dont have to write 
code to declare function acting just like bozo pattern.

If there are several shader{} statements in one entity they will be marged 
togeather preserving their order, simmilar as in example when muliply warps 
are used.


  * * *

This looks exciting imho :)


-- 
http://www.raf256.com/3d/
Rafal Maj 'Raf256', home page - http://www.raf256.com/me/
Computer Graphics

Post a reply to this message