|
![](/i/fill.gif) |
Chris Huff wrote:
> 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...).
Sorry to disturb your plans...
> 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 did same (i.e. new pigment) here.
> I had planned for my patch to eventually have access to a list of light
> source positions and colors, camera position, trace functions, etc.
>
Well, RM shading language (SL) has same capabilities and I hope, that my
patch will support this eventually. Time will tell.
> It might be easier for you to use MegaPOV as a code base, it already has
> intersection information passed to Compute_Pigment.
>
I already use it. I don't have code here (at work), so I'm not sure,
what I've changed (this has been couple of months ago, when I patched
POVRay, SL compiler was primary target in the meantime).
> > 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.
Hmm, sounds like good idea.
Post a reply to this message
|
![](/i/fill.gif) |