vex_101

[Alanw]

numero uno...diffuse BDRF but translucent surface

/*
* also shade OTHER SIDE of surfaces
* so not only FRONTFACE
*/
#include <math.h>

#pragma label Kd_f "Front Face Diffuse Amp"
#pragma label tex_f "Front Face Texture" 
#pragma range Kd_f 0 1
#pragma label Kd_b "Back Face Diffuse Amp"
#pragma label tex_b "Back Face Texture"
#pragma range Kd_b 0 1

surface
RSLG_illum_translucent(float Kd_f = 0.5, Kd_b = 0.3;
					   string tex_f = "", tex_b = "";)
{
	vector c = 0, c_f = 0, c_b = 0;
	vector Ln = 0;

	if(tex_f != "")
		c_f = texture(tex_f);
	else
		c_f = 1;
	if(tex_b != "")
		c_b = texture(tex_b);
	else
		c_b = 1;

	vector Nn = normalize(N);
	vector Nf = frontface(Nn,I);

	//FRONT
	illuminance(P,Nf,M_PI/2)
	{
		Ln = normalize(L);
		c += Cl * c_f *Kd_f * dot(Nf,Ln);
	}
	//BACK
	illuminance(P,-Nf,M_PI/2)
	{
		Ln = normalize(L);
		c += Cl * c_b *Kd_b * dot(-Nf,Ln);
	}	
	Cf = c;
}

my result is a diffuse surface, shaded on the inside too, but

the result of this in the book isa translucent surface...

am i combining the front and back contributions incorrectly?

if i wanted to add the surface color - Cs in RSL - how do i access that in VEX?

thank-you for the input

Hi Suz,

I think the translucent surface shader in question is only for very thin surfaces like a leaf. The trick is to lower the opacity a bit and shade both sides of the surface (N) and (-N) as far as I know. Perhaps you didn't change the opacity?

Also, for your second question I believe you would use Cd in VEX. This would be the primitive attribute found when you add color to your geometry via color SOP, point SOP, VEX Sop, etc.

[_suz_]

Of = {0.5,0.5,0.5};

this does indeed make the current surface translucent,

but,seems i misunderstood the purpose of the shader,

...lets just say it was summer holiday fever...

its a double sided shader - thus both sides of the surface are shaded, and the result is a translucent looking surface

/* 
* shade OTHER SIDE of surfaces
* so not only FRONTFACE
* 
*/
#include <math.h>

#pragma label Kd_f "Front Face Diffuse Amp" 
#pragma range Kd_f 0 1
#pragma label Kd_b "Back Face Diffuse Amp"
#pragma range Kd_b 0 1
#pragma hint uv hidden

vector doubleSided(vector P,Nf,L;
					float Kd_f,Kd_b;)
{
	vector c = 0, c_f = {0,0,0.5}, c_b = {0.5,0.5,0};
	vector Ln = 0;

	//FRONT
	illuminance(P,Nf,M_PI/2)		//consider LIGHTS in the CONE defined by axis: Nf and angle: M_PI/2
	{
		shadow(Cl);
		Ln = normalize(L);

		c += Cl * Kd_f * c_f * dot(Nf,Ln);
	}
	//BACK
	illuminance(P,-Nf,M_PI/2)	//LIGHTS  in the BACK facing CONE
	{
		shadow(Cl);
		Ln = normalize(L);

		c += Cl * Kd_b * c_b * dot(-Nf,Ln);	//FLIP THE NORMALS to get the shading of the BACK face
	}	
	return c;
}


surface
RSLG_fake_translucent(float Kd_f = 0.5, Kd_b = 0.5;
						vector uv=0;)
{
	vector Nn = normalize(N);
	vector Nf = frontface(Nn,I);

	Cf = doubleSided(P,Nf,L,Kd_f,Kd_b);	//get the sum of the front and back colors of the current shading point
}

still incorrect though, since front blue + back yellow is supposed to yield green

Edited January 6, 2009 by _suz_

[DaJuice]

...so is there BDRF data available for look-up - if they can be measured with a super-ultra-meter? --if so, where on the internet?--

Hay Suz. I was reading up on the subject after playing with rendertan's Oren-Nayer-Wolff shader, and came across this:

http://www.graphics.cornell.edu/online/mea...ance/index.html

[Mario Marengo]

still incorrect though, since front blue + back yellow is supposed to yield green

Not in additive colors (which is what we use: i.e: "light"). In additive colors, green itself is a primary, it is not a composite of blue and yellow -- it's the middle letter in 'RGB'.

Anyway, try this:

#include <math.h>

#pragma label Kd_f "Front Face Diffuse Amp"
#pragma label Kd_b "Back Face Diffuse Amp"
#pragma label opac "Opacity"
#pragma hint uv hidden

vector doubleSided(vector p,n; export vector front; export vector back;) {
    vector c = 0;
    front = back = 0;

    // front hemisphere
    illuminance(p,n,M_PI/2) {
        shadow(Cl);
        front += Cl * dot(n,normalize(L));
    }
    // back hemisphere
    illuminance(p,-n,M_PI/2)    {
        shadow(Cl);
        back += Cl * dot(-n,normalize(L));
    }    
    return front+back;
}


surface translucent(
      float Kd_f = 0.5;
      float Kd_b = 0.5;
      float opac = 1;
      vector uv=0;
   )
{
   vector Cfront=0, Cback=0;

   vector Nf   = normalize(frontface(N,I));
   doubleSided(P,Nf,Cfront,Cback);
   Of = opac;
   Cf = Of * (Cfront*Kd_f + Cback*Kd_;
}

There are a whole bunch of changes there. Go through each line and see if it makes sense to you.

Without translucency:

With translucency:

And just in case... yes, red and green do create yellow when mixed (in additive colors).

HTH,

Cheers!

[_suz_]

right gottit...subtractive color...

#include <math.h>

#pragma label Kd_f "Front Face Diffuse Amp"
#pragma label Kd_b "Back Face Diffuse Amp"
#pragma label opac "Opacity"
#pragma hint uv hidden

vector doubleSided(vector p,n; export vector front; export vector back;) {
vector c = 0;
front = back = 0;										 //BLACK

// front hemisphere
illuminance(p,n,M_PI/2) {
shadow(Cl);
front += Cl * dot(n,normalize(L));		  //SCALE the amnt of light that contributes to FRONT by the dot(N,L)
}
// back hemisphere
illuminance(p,-n,M_PI/2) {
shadow(Cl);
back += Cl * dot(-n,normalize(L));		 //SCALE the amnt of light that contributes to BACK by the dot(N,L)
}
return front+back;							   //return the AMNT of illuminance received - FRONT and BACK
}


surface translucent(
float Kd_f = 0.5;
float Kd_b = 0.5;
float opac = 1;
vector uv=0;
)
{
vector Cfront=0, Cback=0;

vector Nf = normalize(frontface(N,I));
doubleSided(P,Nf,Cfront,Cback);

Of = opac;
Cf = Of * (Cfront*Kd_f + Cback*Kd_b);				  
}

--do i understand the code correctly, based on the comments i made?

--laughing gato--

thank-you for the code...it helps me to see whether my coding is on the up &up

quick question...

when writing a shadow shader, which is applied fo a Light Template object,

how/where do i generate the necessary depth map...

since there's no such functionality in the Light Template

i.e the Auto Generate Shadow Map?

Edited January 14, 2009 by _suz_

[kensonuken]

Yeah you need to switch on auto generate shadow map..

[Mario Marengo]

quick question...

when writing a shadow shader, which is applied fo a Light Template object,

how/where do i generate the necessary depth map...

since there's no such functionality in the Light Template

i.e the Auto Generate Shadow Map?

The idea behind the "Light Template" object is that you add whatever shading parameters your shader(s) will need yourself. You can "Edit Parameter Interface" on the light template object and add all the parameters you need to drive your shadow and/or light shaders. ("Auto-Generate Shadow Map" is among them, IIRC).

Those parameters that you see in the "hlight" object are ultimately managed by a Python "wrangler" which assigns them to various shaders (light and shadow shaders) when outputting to the IFD. So, in a sense, there's no "automatic" handling of shadow maps (or anything else) that will be done for you in a "light template" object -- it's up to you to take care of them (along with the shaders).

Another possibility is to simply add (via "Edit Parameter Interface") a "Shadow Shader" parameter to an HLight object. This will override the Python assignment. The thing to watch out in this approach though, is that your shader has to understand the shadow parameters that the default wrangler will pipe to it.

HTH.

[_suz_]

Python "wrangler" which assigns them to various shaders (light and shadow shaders) when outputting to the IFD

python wrangler explained from the OdWiki:

Light wrangling is a technique for customizing lights in Houdini using SOHO: Scripted Output of Houdini Operators

wrangling process allows for a simpler and cleaner interface

When Houdini sends a scene to a renderer, it invokes some python code (SOHO).

This python code asks Houdini to evaluate parameters on objects and outputs then sends the results of the evaluation to the renderer.

A light or camera wrangler sits between SOHO and Houdini and is able to intercept the SOHO requests for parameter evaluation.

Instead of having Houdini evaluate the parameter, the wrangler is able to return any value it chooses.

hi,

here is a light shader and a colored shadow shader both applied to a light template...WIP

...the colored shadow still looks somewhat harsh due to the lack of shadow map...

i've gone to the "edit parameter interface" and added the

1. Auto Generate Shadow Map toggle

2. Shadow Map Image File field

how do i link the Auto Generate Shadow Map toggle to know that it should auto generate into the Shadow Map's file name?

then - i suppose rather cruedly - i copied the Shadow Map parameter to the "Z-depth Map" parameter at the SHOP level,

how else would the shader get the Shadow Map filename?

...i can't find any documentation about this...

thank-you for the input

http://img19.picoodle.com/img/img19/3/1/13/f_ideasm_c523691.jpg[/

coloredShadow_shader.hip

shadow_shader.otl

RSLG_point_light.otl

Edited January 14, 2009 by _suz_

[Mario Marengo]

i've gone to the "edit parameter interface" and added the

1. Auto Generate Shadow Map toggle

2. Shadow Map Image File field

You forgot to embed the RSLG_point_light shader...

Yes, the ROP is generating a separate pass for the shadow map, but it doesn't pick up the "shadowmap_file" property as the destination, so it renders to "ip" just as the main image... possibly a bug... but then again, a light template is just a skeleton with no shading-related "smarts" attached (by design) so maybe not a bug.

Workarounds:

1. Instead of adding the "shadowmap_file" property, add the following two properties: "vm_deepresolver" and "vm_dsmfilename". Set vm_deepresolver to "Deep Shadow Resolver" and use vm_dsfilename as your depthmap's filename.

2. Use an HLight (instead of a Light Template) and add the "shop_lightpath" and "shop_shadowpath" to override the default shaders. ... and make sure to link all the necessary shader parameters.

Here's your file using workaround #1:

coloredShadow_shader1.hip

Also... when using a shadow map, don't forget to look through the light to see what it's viewing. If it's pointing into empty space (like yours was), then you won't get much of a shadow map, no matter what your settings are

Cheers.

[_suz_]

vm_deepresolver to "Deep Shadow Resolver"

explanation from HELP:

When generating an image, mantra runs the sample filter to composite samples to a single color.

Mantra then runs the pixel filter to produce the final color for a pixel. A deep resolver is used to store information about each sample prior to sample filtering.

This allows the image resolver to store information about each individual sample before compositing.

The image:deepresolver property specifies the resolver and any arguments to the resolver.

In the Light context: Lz is the "Z-axis in the space of the light"

does that mean that a light faces down its z-axis, and thus Lz is straight ahead from the Light's POV?

Edited January 14, 2009 by _suz_

[Mario Marengo]

In the Light context: Lz is the "Z-axis in the space of the light"

does that mean that a light faces down its z-axis, and thus Lz is straight ahead?

Yes, "straight ahead", but in camera space.

[_suz_]

--almost there--

__thank-u__

Edited January 15, 2009 by _suz_

[_suz_]

hi!

ANTIALIASED FRACTIONAL BROWNIAN MOTION

from the aanoise() help:

(fractional brownian motion) noise using the derivative information of the incoming position to compute band-limited noise

how do i implement this in vex?

or rather - i guess it would be better to not reinvent the wheel and just use the aanoise VOP...

if so, how do i make my code snippet a VOP with input Parameters and Outputs so i plug it into a VOP network?

__thank-you__

Edited January 20, 2009 by _suz_

[Mario Marengo]

ANTIALIASED FRACTIONAL BROWNIAN MOTION

from the aanoise() help:

how do i implement this in vex?

or rather - i guess it would be better to not reinvent the wheel and just use the aanoise VOP...

if so, how do i make my code snippet a VOP with input Parameters and Outputs so i plug it into a VOP network?

__thank-you__

Put down an Anti-Aliased Noise VOP, RMB on it and select "Type Properties". In the Type Properties dialog, go to the "Code" tab and you'll see that it includes <voptype.h> and <voplib.h> in the "Outer Code" section. This is where those functions are implemented (in VEX). Have a look at the rest of the tabs to see how it was put together -- particularly the "Parameters", "Code" and "Input/Output" tabs.

To look at the actual VEX code which implements it, open the file $HH/vex/include/voplib.h and look at all the functions whose name start with vop_fbmNoise*.

You can use this VOP as a template for learning how to put one together yourself. There are a bunch of subtleties involved in making a VOP, especially one with multiple signatures, so also do a search here and in the Sidefx forum. It's a topic that has been brought up many times so I'm sure you'll find detailed discussions in there (also try old_school's blog.. I think he has something about making VOPs).

HTH.

P.S: To actually understand the algorithms in those functions, you'll need to pick up a copy of a book like "Texturing and Modeling, A Procedural Approach" and read through it. Looking at the code won't give you any insights into why it's doing the things it's doing. It'll just look like a bunch of weird loops, I'm afraid.

[_suz_]

CREATE a VOP from VFL code

you could go thru Jeff Wagner's Create VOP tutorial

where u build your own VOP by hand and place your VEX code in the outer code section,

the code needs to be in a function form, not a surface shader:

i.e

surface foo(float Kd = 0.04;)
{
...."Cf = ...;
}

becomes

vector foo(float Kd;)//no default parameter values
{
....return C;
}

OR

you can merrily develop your code and test it ina VEX Type OP,

and when you're done, save your code ina .vfl and:

vcc -m my.otl my.vfl

will create a VOP with all its inputs and outputs for u - HOORAY!

here's an example, with a synopsis of the do's and don'ts:

it contains the VOP_SOP from Jeff Wagner's tutorial

and a VOP_cook_torrance that implements the cook_torrance BRDF

...i will add the eg file later - South Africa's internet access is failing miserably 2day...at least we have great weather!

..back in business:

making_VOP.hip

cook_torrance.otl

Edited January 27, 2009 by _suz_

[_suz_]

SPARKLES FROM NOISE

FAT_CAR ... the artist says his next project is fat ex-girlfriends..

working thru the Odforce Car Shader Post

i've implemented the car shader, but i'm having trouble getting *fine* random noise for the sparkles, as in:

only rendering my noise, with frequency up to 1000's, the noise still isn't fine enough:

another problem is that up'ing the frequency might make the sparkles smaller, but also much more dense,

such that they almost disappear, is there another way?

UPDATE: i think i managed - today it worked...WHOOP-WHOOP

...added the updated sparkly.hip

cook_torrance.otl

sparkly_v01.hip

Edited January 29, 2009 by _suz_

[old school]

Check out this OdForce Thread:

http://forums.odforce.net/index.php?showto...paint&st=48

and this shader on the Side Effects Exchange:

http://www.sidefx.com/index.php?option=com...&Itemid=146

[_suz_]

Check out this OdForce Thread:

http://forums.odforce.net/index.php?showto...paint&st=48

and this shader on the Side Effects Exchange:

http://www.sidefx.com/index.php?option=com...&Itemid=146

hi

yip, thank-you for the reply

....that's where i've been camping out...

alas this is the render i get from the downloaded otl

and having implemented it again in my sparkly.hip, i still can't seem to get that fine grain in the Vray render in the previous post

Edited January 27, 2009 by _suz_

[_suz_]

i've added the making_a_VOP.hip and shiny.hip mentioned in my previous 2 posts

[Raymond Chua]

i've added the making_a_VOP.hip and shiny.hip mentioned in my previous 2 posts

Interesting stuff!

Did you start with the advance renderman book straight away or did you read other renderman books before this?

I am thinking of getting a book on renderman, so I am considering between this and the renderman shading language guide.

I hope to see more of your posts soon! =)

regards,

Raymond