Very interesting,

this could open new door for povray!
I have no idea of how it should be integrated inside pov
but I am quite interested :).

Fabian.


> 
> 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