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

Rafal 'Raf256' Maj wrote:
> abx### [at] abxartpl news:pag1115prp4beqv17lf3e4kpi931ei1opm@4ax.com
> 
> [I started a new thread because its quite different subject then innitialy]

And one - as you know - that has also been discussed to death numerous times 
before.  It also been said numerous times before that something along these 
lines is in consideration for some future version of POV-Ray.

	Thorsten

Post a reply to this message

tho### [at] trfde news:42113ed8@news.povray.org

> And one - as you know - that has also been discussed to death numerous
> times before.  It also been said numerous times before that something
> along these lines is in consideration for some future version of
> POV-Ray. 

OK, so that was some random ideas, sugestions, etc - or other group is 
better for such discussions?

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

Post a reply to this message

Having looked up what shaders are, the question springs to mind:  why do 
you need a plugin to work with the texture{} or material{} code, which 
afaik can do what these other applications' shaders do?

-- 
Tim Cook
http://home.bellsouth.net/p/PWP-empyrean

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------

Post a reply to this message

"Tim Cook" <z99### [at] bellsouthnet> wrote in message
news:42117769$1@news.povray.org...
> Having looked up what shaders are, the question springs to mind:  why do
> you need a plugin to work with the texture{} or material{} code, which
> afaik can do what these other applications' shaders do?

Well, shaders allow greater control over what can be done... they allow you to
implement new patterns and surface interactions that aren't currently supported
as inbuilt patterns and finishes, etc.

For example, you might want to create a special "matte" shader that "punches
through" other objects to the background.

Lance.

thezone - thezone.firewave.com.au
thehandle - www.thehandle.com

Post a reply to this message

On 14 Feb 2005 18:40:11 -0500, "Rafal 'Raf256' Maj" <spa### [at] raf256com> wrote:
> 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).

Really? Let's order page for lightwave shaders:

http://www.shaders.org/ifw2_textures/order.htm

Why there are separated orders for different architectures? Must be because
Lightwave has very portable shaders.

ABX

Post a reply to this message

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

> Really? Let's order page for lightwave shaders:
> http://www.shaders.org/ifw2_textures/order.htm

Heh, typo, I ment light _Works_,
http://download.graphisoft.com/ftp/techsupport/documentation/developer_docs
/BasicLibraryDoc/LightWorksIntegration/LW_Parameters.html

http://www.lightwork.com/lw_home.htm



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

Post a reply to this message

On 15 Feb 2005 05:20:19 -0500, "Rafal 'Raf256' Maj" <spa### [at] raf256com> wrote:
> Heh, typo, I ment light _Works_,
> http://download.graphisoft.com/ftp/techsupport/documentation/developer_docs
> /BasicLibraryDoc/LightWorksIntegration/LW_Parameters.html
>
> http://www.lightwork.com/lw_home.htm

"Cross-platform plug-in shaders are supplied as platform-independent bytecode
that is executed by the LightWorks bytecode interpreter and will therefore
work on all the platforms supported by LightWorks. Native plug-in shaders are
provided in ‘object code' form compiled for a particular platform, for example
DLLs for Windows or Bundles for Macintosh."

Well, this is behind POV-Ray standard which distributes shaders in one unified
and portable form of source of functions and translates it to bytecode or
machinecode at runtime. And we don't have to buy any SDK to write own shader.
Is this that opensource advantage you refered earlier?

ABX

Post a reply to this message

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

> Well, this is behind POV-Ray standard which distributes shaders in one
> unified and portable form of source of functions and translates it to
> bytecode or machinecode at runtime. And we don't have to buy any SDK
> to write own shader. Is this that opensource advantage you refered
> earlier? 
> 

LightWorks is not OpenSource. 

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

Post a reply to this message

Lance Birch wrote:
> "Tim Cook" <z99### [at] bellsouthnet> wrote in message
> news:42117769$1@news.povray.org...
>> Having looked up what shaders are, the question springs to mind:
>> why do you need a plugin to work with the texture{} or material{}
>> code, which afaik can do what these other applications' shaders do?
>
> Well, shaders allow greater control over what can be done... they
> allow you to implement new patterns and surface interactions that
> aren't currently supported as inbuilt patterns and finishes, etc.
>
> For example, you might want to create a special "matte" shader that
> "punches through" other objects to the background.

Or a pigment that changes colour depending on the angle between the surface
normal and the viewer.

Post a reply to this message