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

Rafal 'Raf256' Maj <spa### [at] raf256com> wrote:
> This looks exciting imho :)

  But you shouldn't go down that road. As said elsewhere, starting to
discuss the new scripting language goes nowhere and will most probably
only cause endless threads with people fighting each other.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

ABX <abx### [at] abxartpl> wrote:
> On 15 Feb 2005 10:38:38 -0500, "Rafal 'Raf256' Maj" <spa### [at] raf256com> wrote:
> > Plugins

> Can I ask you about writing in points in shortest possible words advantages
> and disadvantages of using plugins including what needs to be done or added to
> the current state of the sources. Something like:

>   advantages:
>     - custom patterns
>     - portable when in bytecode
>   disadvantages:
>     - additional packages
>     - not portable when precompiled

  You are not talking about plugins here. I would call them *libraries*.

  Plugins (those .dll plugins which some programs support) are a
completely different thing.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

abx### [at] abxartpl news:hd7411hv5mm9bair56pgc4j0g4qd2m9i3i@4ax.com

> Can I ask you about writing in points in shortest possible words
> advantages and disadvantages of using plugins including what needs to
> be done or added to the current state of the sources. Something like:


By "plugins" I ment this advanced shader-thingies as described in previous 
post, ok, IMHO Pov-RAY with support of such shaders:

- precompiled shaders not portable
+ but they can be compiled from source in *.pov
+ can be parsed into some bytecode and then execute (slower)

* can be parsed into C/C++ code and linked with "main" Pov-RAY while 
executing a render 
  - need to create executable, access to compilers, to POV source
  - longer parsing time
  + very fast render time 
  + can be cached, as in shader1.c shader1.md5 shader1.o md5 is digest of 
    .c and .o, if they match then the code will not be compiled again, if 
    not, then it will be compiled and re-linked
  - more work
  + can use make/gcc (I suggestt using it on all platforms, not to use 
    MSVC on win32, because of legal - everyone can download MinGW for free)
  - it will require probably to recompile povray from source using same     
    compiler, or to have PovRAY for win32 compiled in mingw/gcc not MSVC 

+ give greate flexibility
+ no need to write a patch to do some more advanced things
+ easy way to conert a shader into a patch and perhaps use it in mainstrem 
Pov-RAY in future versions
+ encourages to develop POV-Ray, new effects, patterns
+ will force to clean Pov-Ray code, since most elements must be accessible 
using Shader functions
- wil need a lot of work

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

Post a reply to this message

war### [at] tagpovrayorg news:42124c80@news.povray.org

>   But you shouldn't go down that road. As said elsewhere, starting to
> discuss the new scripting language goes nowhere and will most probably
> only cause endless threads with people fighting each other.

I dont see any fighting here, just reasonable discussion that can give some 
fresh ideas to developers of new SDL. Ofcourse, if noone appriciate it, I 
(and others) can spend free time helping other OpenSource to develop.

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

Post a reply to this message

Rafal 'Raf256' Maj <spa### [at] raf256com> wrote:
> >   But you shouldn't go down that road. As said elsewhere, starting to
> > discuss the new scripting language goes nowhere and will most probably
> > only cause endless threads with people fighting each other.

> I dont see any fighting here

  "will" means future, not present.

> just reasonable discussion that can give some 
> fresh ideas to developers of new SDL.

  Fresh ideas? Where?

> Ofcourse, if noone appriciate it, I 
> (and others) can spend free time helping other OpenSource to develop.

  Good luck.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

war### [at] tagpovrayorg news:42124f9f@news.povray.org

>> just reasonable discussion that can give some 
>> fresh ideas to developers of new SDL.
> Fresh ideas? Where?

Was identicaly or very simmilar to mine idea of shaders already discussed? 
Sorry for dupliace then.

>> Ofcourse, if noone appriciate it, I 
>> (and others) can spend free time helping other OpenSource to develop.
> Good luck.

Good luck as in: go away and good luck? I find attitute of developers not 
vey friendly recently, in comparsion to some OS products in with I try to 
help (by bugmozilla currently)



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

Post a reply to this message

In article <4211f8f9@news.povray.org>, war### [at] tagpovrayorg says...
>   I'm quite certain that if there was a public discussion group about
> the new scripting language of POV-Ray, it would get filled with tousands
> and thousands of articles and megabytes and megabytes of text with people
> just fighting each other in stupid endless wars about what features are
> or are not ok. The end result will most probably be that those thousands
> of articles will have no effect whatsoever on whether the feature will
> be implemented or not, so why not save everyone the trouble?

While this is true, it also means that someone paying attention and 
willing to trudge through the mess could develop it. If never discussed, 
it never gets implemented at all. Sort of a two edged sword imho, but I 
see your point.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

In article <42121e1e@news.povray.org>, war### [at] tagpovrayorg says...
>   While one could call an #include file a "plugin", I would call it
> a library, not a plugin. Even if a future version of POV-Ray with a
> much more elaborated and powerful scripting language (supporting eg.

> not plugins (in the same sense as dll plugins are).
> 
Which makes a lot of sense. And as I mentioned, there is nothing to 
prevent a special directive like <library "name">, to explicitly make it 
not just a simple include, thus allowing it to also be added to a global, 
'allow all scenes access automatically' type feature.

There is no real reason to go for full plugins if the SDL can manage it, 
but some way to explicitly prevent name collisions and allow global use 
'would' be nice. It simplifies usage of any such things a lot.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

Lance Birch wrote:
> 
> To my knowledge none of them use fractal-based formulas, they are based on
> patterns that aren't fractal in nature, or am I mistaken?

That depends on how you define 'fractal' - if you do so via a recursive 
definition they might not be (although every recursion can be replaced 
by a loop as you might know).  If you do so via the property of 
self-similarity they certainly are (a lot of POV-Ray's builtin patterns 
/functions as well as turbulence warps have self-similar properties).

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 23 Sep. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message