In article <38EDD167.140A0456@aetec.ee>, Vahur Krouverk 
<vah### [at] aetecee> 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] yahoocom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Web page: http://chrishuff.dhs.org/

Post a reply to this message