a shader each day

[rdg]

I want to learn this shading stuff.

So I try to dabble in a shader per day.

Small steps, probably without any recognizable pattern.

Day 1:

I think it's good to explore different shaders before trying to invent my own.

So I googled around and found this funny shader:

Constant Width Shaders! by Mach Kobayashi from Pixar Animation Studios [1]

The shader extracts a line with constant width from a noise field.

I got the - maybe false impression - that there is much more renderman information out there - so being able to convert a renderman shader to mantra vex surely cannot hurt.

Don't think I understood what's happening inside this shader.

There were few stumbling blocks:

* the renderman dPdu and dPdv - a deep look in the often underestimated Houdini help brought up:

vector dPdu = dPds/Du(s); and vector dPdv = dPdt/Du(t);

* renderman ^ and . - the . is a dot() and - thanks eetu! - the ^ is a cross()

I guess there is no need for guessing once I read the "Advanced Renderman" past page 133.

* mix() - Though a VOP VEX shader used mix() in the generated code I couldn't use it in mine.

This mystery will be solvable in the near future and in the meantime: a * (1 - m) + b * m mixes as well.

The orignal shader doesn't take any lights into account.

To be not just copying I added two lighting models: One for the base and one for the Tubes.

I also added an offset for the generated line. This allows growing patterns.

Using rest instead of P as base for the noise fixed the object moving through the noise.

The original shader creates a fake tube by bumping the tubes - this was lost somehow at some step ...

Animated: http://www.medikalesha.de/aShaderEachDay/20080422/

20080422_constant_width.hip

OPcustom_constant_width.otl

[1] http://renderman.org/RMR/Examples/srt2006/mach2006.ppt.gz

[mark]

one a day is a good idea

you might want to search for some siggraph PDF docs on renderman shaders, theres one with a mango and (i think) banana shader which seem to convert ok.

[Jason]

Some info which might help you bridge the gap to Renderman, look at $HFS/houdini/vex/include/prman.h - which doesn't help with dot() and cross() due to limitations of the cpp preprocessor, but can provide insight to further mappings:

...

#define faceforward frontface

#define mix(aa,bb,cc) lerp(aa,bb,cc)

#define step(min,value) ((value) > (min))

#define smoothstep(aa,bb,cc) smooth(aa,bb,cc)

#define round(aa) rint(aa)

#define spline cspline

#define illuminate(xx,yy,zz)

#define solar(xx,yy) { L = -Lz; }

#define xcomp(aa) (aa.x)

#define ycomp(aa) (aa.y)

#define zcomp(aa) (aa.z)

#define cellnoise(aa) random(aa)

...

[kumpa]

Some time ago i had same idea, so i went to www.highend3d.com, downloaded few interesting shaders and recreated them in vex with various success.I ll try to find them, they hid somewhere.

[edward]

rdg, you mean you recreated the shader using RSL VOPs? As Jason, mentioned, $HH/vex/include is a good resource. There are files in there that get included with VOP generated shaders.

[rdg]

banana shader

There is already a Banana VOP node.

rdg, you mean you recreated the shader using RSL VOPs?

No, No - I created a VEX type surface shader Operator and crawled myself through the code in Mach's powerpoint presentation.

The main task in this exercise was to distinguish pattern vs shading and like Jason mentioned finding the correct mappings between RSL and VEX.

This lead to reading pages in the help that I would usually skip.

Now I know that points and normals need different transforms as they are not the same type of vector.

[rdg]

Day 2: A CMYK aware Shader

This shader allows you to input the color values in cmyk instead of RGB.

Was surely inspired by the announcement of Mario's speech about color spaces.

As sphere/box swatches look rather boring on the long run - I decided to do a homage to Richard Minh Le's "Architecture of Color and Identity" [1]

The probably interesting part of this shader is the conversion of cmy to rgb in VOPs.

No color profiles are used.

20080423_cymk.hip

PBR - somwhat better lighting - hm -somewhat

[1] http://www.richardml.com/

Edited April 23, 2008 by rdg

[cellchuk]

nice renders.

:thumbsup:

[Mario Marengo]

Hey! Those look really nice, rdg. Nice job!

[Allegro]

Is that a typo on your parameters? cymk?

[rdg]

Is that a typo on your parameters? cymk?

Oh! You are right - it's CMYK - but forward ever backward never.

Day 3: A Silkscreen Shader

This Shader simulates a silkscreen printed piece.

You feed it an image and it generates the colour seperation.

This interesting part was the RGB -> CMYK seperation.

It is a two step process: RGB -> CMY -> CMYK [1]

Again these process doesn't take any ICC or other profiles into account but does a good job for my purpose.

I used the inlineVOP as building a network for this function turned out to be too tedious.

Some matrix fun to rotate the four layers. Well, not that funny if you live in the matrix.

I guess this shader is going to play a major role in my new music video.

20080424_rdg_silkscreen.hip

[1] http://easyrgb.com/math.php?MATH=M13#text13

[Marc]

Fantastic. Nice work Georg.

[LEO-oo-]

Cool! Weiter so

[stevenong]

As always, good stuff Georg!

Thanks for sharing!

Cheers!

steven

[pagefan]

Nice work Georg. Sesi soon has a nice online library for their material palette.

[rdg]

Day 4

Todays shader drove me crazy.

I tried to build a texture bombing shader.

Instead of just compiling the one I found in the codex [1] I tried to rebuild it using additional information from the GEMs book [2]

It's definitely time for me to return to a texpad/vim/whatever based approach as connecting those boxes is really boring.

Especially if it doesn't work like expected.

Luckily Rob explained some mystery about tiling [3] but I couldn't figure out why I still get those annoying artifacts as soon as I try to add some random offset to my textures.

By now I tracked it down to the random function.

If I "manually" add a valid offset everthing is fine, if the offset is generated procedurally it wrecks.

I remember a section about random and vex and that there are some differences to real life ...

well, what was started as a "quick shader today" ended in

20080425_lettermatrix.hip

letters.rat.tar.gz

Far from bombing.

Need a break.

[1] http://odforce.net/happy_rendering_with_vex/

[2] http://developer.download.nvidia.com/books...ugems_ch20.html

[3] http://forums.odforce.net/index.php?showtopic=6990&hl=

[rdg]

Day 5:

Tried to solve the dirt issue in my tiled shader.

I tried to blame rounding and/or float vs int but it didn't help.

Reducing the filter width in my textureVOP to zero removes the dirt.

I don't think it's good to jump over this issue as it will surely crush me from behind in the next days.

This is a simplified version of the shader:

http://forums.odforce.net/index.php?s=&amp...ost&p=47044

[rdg]

Day 5.1:

I tried to use 5 textures (letter.[1-5].rat) instead of one containing all 5 letters.

But this doesn't work, too.

the only explanation I have so far is:

Somehow my repeating uv coordinates run out of sync with the generate unique cell ID:

[Jason]

Day 5.1:

I tried to use 5 textures (letter.[1-5].rat) instead of one containing all 5 letters.

But this doesn't work, too.

the only explanation I have so far is:

Somehow my repeating uv coordinates run out of sync with the generate unique cell ID:

Are you getting a wrap-around on your uv's per cell? Perhaps each cell is 0 - 1 instead of 0 - 0.9999.

[rdg]

Are you getting a wrap-around on your uv's per cell? Perhaps each cell is 0 - 1 instead of 0 - 0.9999.

Aha. To be honest I am not sure what to say.

I always thought uvs ought to be 0..1 - but if they are 0..0.9999 this changes everything.

[world crumbles down]

it could also explain why printf() outputs something like this if I print the cell IDs:

11111 22222 33333

44434 55545 66656

77777 88878 99989

---

eetu suggested to use colormap() instead of texture() ... something I tried to avoid as I don't know what's the difference.

But if I do so the shader behaves like I want it to behave:

It takes an image like this:

and tiles it randomly to the object:

20080428_lettermatrix_working.hip

I'd rather understand why this is like it is.

But now I move on to the second level of "texture bombing"