ooh, renderman shaders in pov *drool*

not sure if it'd be possible, but I'd like displacement shaders...and having
the ability to anti-alias a specific shader would be oh so nice...but if
their is some technical limitation that I am not understanding no biggie

and as for the VM thing, I was kinda thinking the same thing, but more in
regards to the talks I read about pov-ray's (upcomming?) plugin system, I
thought it would be super cool to use a VM for the plugin system....(maybe
in java or C or some other cross platform language)

Vahur Krouverk wrote:

> Hi!
>
> 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:
>
> 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.
>
> Other option would be to use full power of SL and use it to fully
> describe object properties i.e. it's final color, as seen on picture
> (taking into account ambiency, reflectance, illuminance, diffuse etc),
> POV-Ray wouldn't modify it.
> This will be more complicated to implement and its integration with
> other pov-ray code will be more complicated. E.g.
> 1. how will SL shaded object interact with photons or media? One
> possibility is to use to maximum extent pov-ray texture variables in
> shader, but this requires rewrite of RM shaders and I'm afraid, that all
> properties could
> not be mapped easily between 2 products (RM and POV-Ray)
> 2. There is need to get information from light sources in order to
> implement illuminance loops.
> 3. Many of shaders use surface derivatives in order to antialias
> textures. This means that some reasonable implementation for derivatives
> should be created. Ron Parker gave link to paper, which could help
> ("Tracing Ray Differentials"), but I haven't studied it very much.
> (Confession: I'm afraid, that my math ain't good either, so if someone
> is willing to help here...)
> 4. Message passing: some mapping between POV-Ray object attributes and
> RM attributes should be made.
>
> 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.
> 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)?
>
> For an example output look to article with same header in
> binaries.images.
>
> P.S. Considering uv information: for some objects uv mapping is already
> created, hopefully for others it will be done as well (Nathan, is
> someone working on it?). It would be good, if this follows more or less
> RM convention for uv-mapping.

Post a reply to this message