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

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

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

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

Chris Huff <chr### [at] yahoocom> wrote...
> It might be easier for you to use MegaPOV as a code base, it already has 
> intersection information passed to Compute_Pigment.

Also, using MegaPov as your code base will make the port to POV 3.5 easier.

-Nathan

Post a reply to this message

Vahur Krouverk wrote:

> First, current state with my RM SL patch:
> So far most of my efforts have gone to implementation of shader
> compiler.

This looks very interesting and promising. I don't know much about RM
shaders but if we could plug into free shaders libraries (is there such a
thing by the way ?) this could greatly expand pov's texturing abilities.
Could you give examples of things that could be made possible using shaders
and which are currently impossible (or very difficult) to do with pov or
megapov ? For example, would a "patina" shader be possible ?

G.

Post a reply to this message

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

Hi!

I really hope you will finish your patch and add it to megapov..
i ve seen some shaders for non-photorealistic rendering that are very
interesting and almost impossible to adapt to current versions of povray

M

Post a reply to this message

daishi wrote:
> 
> ooh, renderman shaders in pov *drool*
> 
> not sure if it'd be possible, but I'd like displacement shaders...

I've thought about this too, but I'm not sure, whether it is easy to
implement. AFAIK, RM tesselates surfaces into micro-polygons (each 1
pixel in size), then performs displacement (and normal calculation) and
shading. I don't know, whether (and how) it would be possible without
tesselation.

> 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
> 
This requires derivative information, and as I wrote, it is under
consideration. I hope to release first test version soon and most likely
it will be without derivative support, hopefully POV-Ray antialiasing
compensates it a little bit.

Post a reply to this message

Gilles Tran wrote:
> 
> Vahur Krouverk wrote:
> 
> This looks very interesting and promising. I don't know much about RM
> shaders but if we could plug into free shaders libraries (is there such a
> thing by the way ?) this could greatly expand pov's texturing abilities.
For shader examples look http://www.renderman.org/RMR/RMRShaders.html
for various surface shaders (this is what my patch does).

> Could you give examples of things that could be made possible using shaders
> and which are currently impossible (or very difficult) to do with pov or
> megapov ?
>
Hmm, megapov has many additions, of which I'm not quite aware (haven't
POVed long time) so I could give example, which is invalid ;-) How about
anisotropic surfaces? I don't think, that it is supported by megapov. I
try to create number of various examples, when code is evolved enough.

> For example, would a "patina" shader be possible ?
I guess so, but I'm not sure, that I'm able to do it. Writing shaders in
RM SL is not very easy and requires certain skills. But it is required
for writing POVRay patch too. Hopefully when this patch is released,
then concern of some people, that POVRay gets too bloated, will decrease
;-)

Post a reply to this message