|
![](/i/fill.gif) |
In article <38EDD167.140A0456@aetec.ee>, Vahur Krouverk
<vah### [at] aetec ee> wrote:
> First, current state with my RM SL patch:
> So far most of my efforts have gone to implementation of shader
> compiler.
> I've considerably improved shader compiler from POVMAN version and now
> it could compile almost everything from RM 3.8 specification (one of
> biggest missing parts is transformation matrixes, others are some
> built-in functions), althogh it has several shortcomings and requires
> more work and cleanup.
>
> However, now I intend to focus my efforts to implementation of POV-Ray
> shading VM (virtual machine), which will interpret compiled code. For
> this I'd like to hear (err, read) some opinions:
Well, looks like there is no more need for me to work on my shader
patch(which would have been nothing like RenderMan anyway, it would be
much more limiting. Even if I did get it to do more than solid
colors...).
> Which functionality should shader patch have? Easiest would be to allow
> only change of color and opacity, i.e. it is like pigment replacement in
> texture. Actual color of object is still determined by the light
> sources, their position with respect to camera etc, and this will be
> calculated by POV-Ray.
...
The way I did it was to implement the shader as a pigment type, like
image_map or my blob pigment patch. That way, you could use ambient 1
diffuse 0 in the finish, and get nothing but the results from the
shader, but you could also add in reflection, etc.
I had planned for my patch to eventually have access to a list of light
source positions and colors, camera position, trace functions, etc.
> For now I've plugged shader's call to the function Compute_Pigment and
> added to it some parameters (e.g. normal vector in intersection). This
> allows to use some simple shaders e.g. slope or normal dependent
> texture, bumps, texture, which depends from intersection position,
> opacity modification etc. This accords to the first (easiest) solution.
It might be easier for you to use MegaPOV as a code base, it already has
intersection information passed to Compute_Pigment.
> Is it good enough for use or should I shoot for more complete
> implementation? Or can someone propose good alternative between VM and
> POV-Ray (i.e. which part of resulting rgb should be rendered by pure-pov
> and which part by SL VM)?
I think implementing it as a pigment type would give the most
flexibility...but I don't really know anything about shaders and
especially not RenderMan shaders.
--
Christopher James Huff - Personal e-mail: chr### [at] yahoo com
TAG(Technical Assistance Group) e-mail: chr### [at] tag povray org
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
![](/i/fill.gif) |