Hans-Detlev Fink wrote:
> 
> Halbert wrote:
> >
> > >Shaders are compiled code, dynamically linked (like dll's) to
> > >the rendering engine.  So, implementing shaders in POV-Ray wouldn't
> > >be THAT hard (though not easy-easy), but using them would require
> > >the ability to write C code.
> >
> > Also, if you used the .dll approach, it would exclude most of the platforms
> > that are supported by POV.
> > HH
> 
> No, not per se. Most any of today's OSes have something like
> dll available (MacOS <= 8 ?). All modern Unices have and
> the referred isopatch shared lib ran very well on them.
> 
> Actually, the problem is rather: In order to compile shaders from
> source to dll/shlib you would need some software that is
> often part of development packages only. (Win out of the box
> does NOT contain compilers, linkers, preprocessors and such.)
> I.e. the average (Win) user would not be able to compile such
> shaders. That's where bytecode comes in. Even then re-using
> existing tools (cpp) would help a lot.
> 
Yes. 
BTW, does anybody know portable and free cpp (c preprocessor)
implementation/source code? I'd like to add its support to shading
language compiler, then shaders could use include files and #define-s.
I've found one in lcc package and seems like its copyright conditions
allows to distribute it with my patch, so it may be one option.

> As to "shaders in pov": Implementation of bytecode interpreters
> and source-to-bytecode compilers is one thing. The other thing
> is providing everything a shader needs inside pov. Many
> params needed by shaders are not available when a shader
> is called in pov. Some are, but not in the right place
> (i.e. are not passed down the call chain), some are not
> existing at all. 
Yes, I've noticed this. But this is usual problem, when someone wants to
integrate 2 different "systems". So far I  tried to avoid big changes in
POV-Ray to avoid merging problems, as POV-Ray itself (or more correctly,
MegaPOV) is in changing mode with all these patches. But seems like I
can't avoid some global changes (e.g. there is need to have
transformation matrix for shadable (??) object, in order to implement
transformation functions. But POV objects do not have such method, so I
have to add to each pov object according method. )

>Not to talk about geometry-changing
> displacement shaders.
Displacement shaders would be nice, but seems like only viable solution
is tesselation of surfaces into micropolygons in order to displace them.
And implementation of this for each object type will require much of
changes. Easiest would be to add displacement shader support to already
tesselated objects (and triangle meshes).

Post a reply to this message