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

[I started a new thread because its quite different subject then innitialy]

> Could you name all those modern raytracers which are written in C++,
> support lodable plugins compiled to machine code, exists in builds for
> Mac, Windows nad *nixes and support all the possible CPU architectures
> where mentioned OS-es are working? Best with similar set of features
> as in POV-Ray. There must be many of them which draw the standard you
> refer here. 

Most (all "big" ?) rayteracers allow plugins, in example LightWave on with 
I had worked for a short while AFAIR allowed own shaders and it worked on 
Win32 and Linux (and probably also on other architectures, simmilar to 
Pov-RAY).

Why not take example from in example OpenGL and implement own C-based 
shading language?

And yes, this *will* be *portable*. 100% portable - such shader would be 
just ordinarly interpreted (simmilary as #macro's are now), and 
in *addition* it *might* be also pre-compiled while parsing scene to 
speedup rendering.

That way Pov-RAY could expand rapidly, probably better then with just 
macros - such "shaders" could be much much more flexible, would work 
faster, will be portable etc.

Collections of them could be a part of MegaPOV, and perhaps after some 
testing and standarization they could be precompiled and placed in official 
PovRAY as new pigment functions, better radiosity algoritms and so on.

In general - I fell that current core Pov-RAY code discouraged users to 
donate code more advanced then pigments or macros. "Shaders" could be 
natural way to add much more.


In example, to write AOI pigment, one dont have to dig into "raw", quite 
poor documented C code with now HOWTOs (for beginners, or developers that 
just dont have so much time to study entire code for days).

He just write simple function that returns a float based on normal of 
surface in that point etc.

Or to write blurring shader, example source might look somewhat like this:

#shader MyBlur type "pigment-shader"
PovColor Function(texture tex) 
{
  PovColor c;
  c += tex.pigment.getColor(tex + x);
  c += tex.pigment.getColor(tex - x);
  c += tex.pigment.getColor(tex + y);
  c += tex.pigment.getColor(tex - y);
  c += tex.pigment.getColor(tex + z);
  c += tex.pigment.getColor(tex - z);
  return c / 9; 
}
#end
sphere { 
  0 10 
  pigment { bozo shader{MyBlur} } 
}

So this is a shader that works on top of pigment. There could be several 
shaders, we can write additional two:

#shader Invert type "pigment-shader"
  PovColor Function(texture tex) {
    return PovColor(1,1,1) - tex.pigment.getColor(tex);
  }
#end

and then use

object { MyObject pigment { crackle shader{Blur} shader{Invert} } }

Then crackle pigment would be blurred, and then inverted.
Ofcourse the shader can create pigment, not just modify it:

#shader Invert type "pigment-shader"
  PovCol Function(texture tex) {
    PovColOne r = // ... here goes Apache's / Slime's formula 
      // for neat 4D noise function, or some improved noise generator 
    
    return PovCol(r,g,b);
  }
#end

Also shaders could be used for normals. Next step would be to allowe them 
in more places, like to define rays from camera, to use them in shadow 
calculations, and so on and so on.

So - plugins do not have to be unportable precompilled platform dependent 
.dll's that Thorsten is so "afraid of".

That way it would gave greate flexibility, without need to hard-code every 
such idea into source code of POV-Ray, with will be faster to 
test/develope, and... more portable (that is - peoples could share such 
code same as code of #macro currently)


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

Post a reply to this message