New Surfaces Materials?
-
On 18/04/2013 at 07:38, xxxxxxxx wrote:
OK. Thanks a lot for the help Steve.
I have enough information now to start looking at formulas and trying to putting something together.
But I'm a long way from controlling gaps and shapes.Once again. I must make this final plea the the Maxon team (or anyone willing).
Could you please provide us with one example of a procedural shader like the pavement shader?
It doesn't matter what the pattern is, or what the colors are.
Something that shows us how to change the gaps, shapes, and colors of the pattern so we can use it as a guide making our own shaders.If I end up figuring it out myself. I'll share what I come up with.
Thanks,
-ScottA -
On 18/04/2013 at 12:29, xxxxxxxx wrote:
Originally posted by xxxxxxxx
Could you please provide us with one example of a procedural shader like the pavement shader?
// A simple turbulence shader Vector ExampleShader::Output(BaseShader *chn, ChannelData *cd) { Vector p; if (cd->vd) p = cd->vd->p; else p = cd->p; return Vector(Turbulence(p, 3.0, TRUE)); } // Using the turbulence value to output either red or green Vector ExampleShader::Output(BaseShader *chn, ChannelData *cd) { Vector p; if (cd->vd) p = cd->vd->p; else p = cd->p; Real threshold = 0.5; // Introduce a threshold to decide on the output color if (Turbulence(p, 3.0, TRUE) > threshold) return Vector(1.0, 0.0, 0.0); else return Vector(0.0, 1.0, 0.0); } // Or: Displacing the turbulence with a noise Vector ExampleShader::Output(BaseShader *chn, ChannelData *cd) { Vector p; if (cd->vd) p = cd->vd->p; else p = cd->p; Real displace_scale = 0.5; // Introduce a scale for the displacing noise Real displace_intensity = 0.75; // Introduce a value to control the intensity of the displacement effect return Vector(Turbulence(p + Noise(p * displace_scale) * displace_intensity, 3.0, TRUE)); } // Or: a simple 2D checkerboard (without MIP mapping, rather ugly) Vector ExampleShader::Output(BaseShader *chn, ChannelData *cd) { Vector p = cd->p; p *= 0.2; // Introduce a scale to control the size of the squares p.x -= (LONG)Floor(p.x); p.y -= (LONG)Floor(p.y); if ((p.x > 0.5) != (p.y > 0.5)) return Vector(1.0); else return Vector(0.0); }Of course, all the control values I have introduced in the Output() function would normally be retrieved from the shader's BaseContainer in InitRender() and then stored in private class members.
You see, writing a shader is very easy. But it can also get very complex, depending on the pattern you want.
Algorithms for common patterns can be easily found on the web. For example, here are some old Renderman shaders from the 80s
You can open the .sl files in a text editor.http://www.cs.rit.edu/~mrp9521/cg/renderman.html
http://www.renderman.org/RMR/Shaders/BMRTShaders/Cheers,
Frank -
On 18/04/2013 at 12:51, xxxxxxxx wrote:
Thanks Frank,
I think the thing I'm going to have the toughest time figuring out is how to control gap size between shapes. That's probably what I'll really need to see an example of the most.
Also.
After setting up my plugin and getting the basic stuff in place. I came across another issue.
If I use a vector type as a color. I get lots really horrible noises all over the object when I render it.
But If I use an LVector with a value of 125 like the mandelbrot SDK example uses. It fixes that problem.
Example:#define CCOUNT 125 Vector *colors; colors = GeAllocType(Vector,CCOUNT);I'm wondering whats exactly going on with that?
I'm guessing that it maybe has something to do with the amount of bits a standard vector holds?
I'm also wondering what the value 125 means. And what happens if I use a higher of lower number?-ScottA
-
On 18/04/2013 at 23:45, xxxxxxxx wrote:
I don't know what your shader code looks like, and why you would need a Vector array with 125 elements. The Mandelbrot shader needs an array because it calculates a fixed set of colors in InitRender() that it later chooses its result color from in Output(). But that's a special thing and you probably won't need that in your shader.
Vector is the correct type for a single color value, a Vector array would store lots of colors.
I can only imagine you're screwing your results up by doing some stuff in the Output() that might behave strange in a multi-threaded context. Remember, Output() is called for each (sub-)pixel that each thread renders.
And about the gaps, it really would just be a very simple addition to the checkerboard code I have posted. You already know where the seams between the squares are, so you could just introduce a value for gap width, add or subtract it from the position (depending on if you are closer to a lower or a higher border of a square) and fill it with another color.
It is all very basic stuff, you just have to read up on it
Did you have a look e.g. at the Renderman brick shader on the second page I linked to in my previous posting? It shows everything you're just asking for, and it's even commented (well, a bit).
-
On 19/04/2013 at 08:58, xxxxxxxx wrote:
I have only had a chance to briefly look at those Renderman shaders.
I had to get my basic shader plugin working first. But I'll take a close look at them today.I'm a complete newb at this shader stuff. So I copied a lot of the code in the Mandelbrot example to get me started.
I think I might have gotten that noisy result because I used my color vector as a pointer.
Today I removed that color pointer code from my code. And just created a standard color vector. And now it seems to work fine without using an LVector.Your 2D checkerboard example doesn't work for me for some reason. The shader is all black.
The other examples you posted work fine. But for some reason that one doesn't. And I'm trying to figure out why it isn't working correctly.-ScottA
*Edit- I found where the noise problem is coming from.
If I declare the vector (pointer or not) as a class member variable. Then use that vector in my Output() method. I get horrendous noise when rendering.
But if I declare the vector inside of the Output() method. It renders fine.
That seems pretty strange to me...
-
On 20/04/2013 at 00:22, xxxxxxxx wrote:
Originally posted by xxxxxxxx
Your 2D checkerboard example doesn't work for me for some reason. The shader is all black.The other examples you posted work fine. But for some reason that one doesn't. And I'm trying to figure out why it isn't working correctly.
I wrote that out of my memory and didn't test the code. There might be a bug in it.
Originally posted by xxxxxxxx
If I declare the vector (pointer or not) as a class member variable. Then use that vector in my Output() method. I get horrendous noise when rendering.But if I declare the vector inside of the Output() method. It renders fine.That seems pretty strange to me...
The difference is that the Vector pointer in the Mandelbrot example is an array of vectors (see definition of GeAllocType() in the SDK docs).
However, the reason for the noise is exactly the one I have already suspected and pointed out: Your are storing a color as a class member variable, and then all your render threads write to it and read from it simultaneuosly. That can't work, because the threads will overwrite each other's results.
If you really want to store your result color in the class you will have to store it separately for each thread. But there's no reason for it, really. The only reason the Mandelbrot shader does it, is because it's calculating the colors before rendering; and then simply chooses (reads) from the colors during rendering process.
-
On 20/04/2013 at 00:35, xxxxxxxx wrote:
By the way, the checkerboard code works fine, here's a test render.
I simply took the code and pasted it into the Output function of the mandelbrot shader.Of course, it's ugly because it does not yet take the MIP delta into account, but it's exactly what I have promised
_<_img src="http://www.c4d-jack.de/darkside/checkerboard_test.jpg" border="0" /_>_
The reason why the 2D shader preview in the Material Editor is black is: The shader preview is sampled from the UV space (0;0 to 1;1). Since we used a scale value of 0.2 and multiply p with it, the tiles ((p.x > 0.5) == (p.y > 0.5) creates black) are as big as 5 times the single UV space (0;0 to 5;5). Hence, the first black tile covers the entire preview area.
Use a value of e.g. 2.0 instead and you'll see.
-
On 20/04/2013 at 09:05, xxxxxxxx wrote:
Thanks Frank,
This is helping me a lot.-
Q1 : How would I go about adding MIP delta to these shaders to make them look better?
-
Q2 : This is an example I made using the VolumeData method to create a checkerboard shader.
But the problem is. It's in world coords. So the pattern doesn't stick to the object when it moves.
How do I write this kind of VolumeData shader so that sticks to the object?
Vector colors; if(cd->vd && enabled) //"enabled" and "offset" are options in my code to control the pattern with gizmos { Real r,s,t; Bool rs = cd->vd->GetRS(cd->vd->lhit,cd->vd->p,&r,&s); //Use volume data to do the rendering Vector pos = cd->vd->p; if(pos.x < offset && pos.y > offset || pos.x > offset && pos.y < offset) colors = Vector(0,0,0); else colors = Vector(1,1,1); } return colors;-ScottA
-
-
On 22/04/2013 at 15:05, xxxxxxxx wrote:
Originally posted by xxxxxxxx
Q1 : How would I go about adding MIP delta to these shaders to make them look better?
Check the cd->d values and use them to drive your level of detail. The smaller the values, the greater your detail should be. The exact value range depends on your shader and how you design it. Clamp the value into shape
Especially for the checkerboard, you should read something about MIP mapping. You have to come up with a clever idea to blur the checkerboard. The greater the d values, the stronger the blur.
With Noise-based shaders, I usually just reduce the noise octaves with increasing d values.Originally posted by xxxxxxxx
Q2 : This is an example I made using the VolumeData method to create a checkerboard shader. But the problem is. It's in world coords. So the pattern doesn't stick to the object when it moves. How do I write this kind of VolumeData shader so that sticks to the object?
You can use the inverse texture matrix cd->tex->im and multiply cd->vd->p with it. That should transform it into local space. Actually, the local texture space (controlled by the coordinates in the Texture Tag), which is what you want to use in Cinema.
-
On 23/04/2013 at 08:55, xxxxxxxx wrote:
I can't figure out how to use cd->d to do that.
I also can't find anything resembling cd->tex->im in the SDK.
I understand the theory about inverting a matrix to change global to local. I do that fairly often with mesh points.
But I don't see how to write that code for VolumeData textures in the SDK.-ScottA
-
On 23/04/2013 at 09:29, xxxxxxxx wrote:
Originally posted by xxxxxxxx
I can't figure out how to use cd->d to do that.
for the check board shader example you could blend the result color with the
mixed vector of colA and colB with an increasing mip radius. distant points
would become gray for a black / white check board which somewhat reflects
the natural human perception of high contrast patterns.i would like to bring up again Modelling and Texturing : A Procedural Approach.
a really good book, which is worth the money. all topics covered in this thread
are described in the book (procedural patterns, various noise types / fractal
noises, anti-aliasing, mip-mapping and much more). -
On 23/04/2013 at 10:35, xxxxxxxx wrote:
I appreciate the help.
But please don't point me towards anymore Renderman related resources. They aren't helping me.
I can't use these various Renderman resources until I know how to use the C4D SDK code first.
That book does discuss general theory. But it uses Renderman code to explain them. And the Renderman SDK code is very different from the C4D SDK.
Sure. I can convert some of the things like: Renderman: colors == C4D: Vector
But there's far, far too many Renderman specific things (like noises and proprietary methods) these books and websites use that I'm having trouble converting to the C4D SDK.
I do have some Renderman tutorials. Which show me how to do things like sticking a volumetric shader by parenting Maya shader nodes. But C4D doesn't work the same way.At this point in time. I need to see only C4D SDK code to understand how this stuff works.
I know the basic principles Between Renderman & C4D are the same. But the code is just too different for me to make the connection yet.So please guys. I really do thank you for the help.
But these kinds of things do not help me at all:
-Renderman references.
-Broad generalizations like: Mix this color with that color vector. And then invert it's matrix.If you can't provide C4D specific code. Please don't waste your time trying to explain it to me in a lecture form. Because I won't understand how to write it. And you'll be wasting your time on me.
I don't want you guys to waste your valuable time on me.
I'm sure I will be able to use those resources later on to do more advanced things.
But first I need to see the C4D code on how to do these things. Not generalized theories.
Not only to understand the general theory. But to see how to write the actual C4D SDK code.
This is why I share so many plugins with the source code. So people like me who can't understand the SDK can see a working example of how to write the code.
It really does make all the difference in the world to see the actual code used in examples.Looking at the large view count for this thread. I'm guessing that this is something that many people are also interested in. And have lots of questions about how to write the C4D code like me.
-ScottA
-
On 23/04/2013 at 11:40, xxxxxxxx wrote:
Originally posted by xxxxxxxx
I also can't find anything resembling cd->tex->im in the SDK.
Oh, sorry. It's cd->vd->tex->im.
Originally posted by xxxxxxxx
I understand the theory about inverting a matrix to change global to local. I do that fairly often with mesh points.But I don't see how to write that code for VolumeData textures in the SDK.
Just do exactly as I said: Multiply your cd->vd->p with the inverted matrix. It doesn't matter if its the position of a mesh vertex or of a ray hit, the math is the same.
-
On 23/04/2013 at 15:39, xxxxxxxx wrote:
Thanks Frank.
That's got it sticking to the object now.Here's the code I have for people lurking:
Vector MyShader::Output(BaseShader *chn, ChannelData *cd) { Vector colors; if(cd->vd) { Real r,s,t; Bool rs = cd->vd->GetRS(cd->vd->lhit,cd->vd->p,&r,&s); //Use volume data to do the rendering Vector pos = cd->vd->p; //Get the the texture positions Vector localPos = pos * cd->vd->tex->im; //Invert the texture matrix so the texture sticks to the object when it's moved localPos.x *= 2; //The number of times to tile the shader localPos.y *= 2; localPos.x -= (LONG)Floor(localPos.x); localPos.y -= (LONG)Floor(localPos.y); if(localPos.x < offset && localPos.y > offset || localPos.x > offset && localPos.y < offset) colors = Vector(0,0,0); else colors = Vector(1,1,1); } return colors; }-ScottA
-
On 24/04/2013 at 01:07, xxxxxxxx wrote:
Good work! You see, it's not that difficult, once you actually dive into it.
Sorry about all those Renderman examples, but those are really the most suitable examples. It's like learning the Blues scale before becoming a metal guitarist. It makes you understand the basics
Your code can still be optimized. This is how I would do it:
Vector MyShader::Output(BaseShader *chn, ChannelData *cd) { // hard-coded parameters (ideally, you get these from the BaseContainer in InitRender() and store them in private class members) const Real tileX = 2.0; const Real tileY = 2.0; const Real offset = 0.4; const Vector col1 = Vector(0.0); const Vector col2 = Vector(1.0); // Declare (but don't construct) sample position Vector pos(DC); if(cd->vd) { // Sample from 3D space pos = cd->vd->p * cd->vd->tex->im; // Get the sample position } else { // Sample from UV space pos = cd->p; // Get the sample position } // The number of times to tile the shader pos.x *= tileX; pos.y *= tileY; // Get local coordinates inside tile pos.x -= (LONG)Floor(pos.x); pos.y -= (LONG)Floor(pos.y); // Decide color if(pos.x < offset != pos.y < offset) return col1; else return col2; }Changes from your code:
-
Hard-coded parameters: I moved all relevant parameters to variables to make the code more readable.
-
cd- >vd->p vs. cd->p: the shader can now sample both, 2D and 3D space. That way, the 2D shader preview will work. Depending on if cd->vd is NULL or not, only the way how I retrieve 'pos' is changed. The rest of the code is the same for both cases.
-
Vector pos(DC) : I declare the variable, but (via the DC parameter) I don't construct it yet. Wouldn't make sense, as I copy values into it later, anyway.
-
Where is 'Vector colors'? It's gone, you don't need it. Instead of copying the resulting color into 'colors' and then returning 'colors' at the end of the function, I simply return the resulting color immediately.
-
Where are 'Real r, s, t'? Also gone, you don't need those. You didn't even use them in your code.
-
Color decision: I changed that back to the shorter form. It's less comparison work, and you can achieve exactly the same with it.
-
offset: You used the 'LONG offset' from the Mandelbrot example to compare it to the local tile coordinates (which are Reals between 0.0 and 1.0). Does not make much sense. It's now a const Real variable, along with the other parameters. Using a value of 0.5 will create even tiles, other values will change the look.
Now some general notes...
So please guys. I really do thank you for the help. But these kinds of things do not help me at all:
-Renderman references.
-Broad generalizations like: Mix this color with that color vector. And then invert it's matrix.If you can't provide C4D specific code. Please don't waste your time trying to explain it to me in a lecture form. Because I won't understand how to write it.
The thing is, you will never find for exactly your problem. At least the probability is very low. And if you limit your search to C4D specific code, you decrease your changes even more. You need to learn the methodology of all this: Finding *any* example code that is easy to understand (and it won't get any easier than those 80s Renderman examples), use it to learn the maths behind it (because is is always the same), look up the functions you don't know, and then write your own shader code as a Cinema plugin. That is how we all learned it.
And if someone tells you, as you say, to "Mix this color with that color vector" or "And then invert it's matrix", then those things are not at all broad generalizations, but precise descriptions of what you have to do. If you don't know how to mix two vectors, then search for it on the web, or take a look into the SDK documentation. It's just math, there's nothing application specific to it. But you can't expect people to write your shader for you.
Long story short: You have to do research yourself. If you don't know the maths, and don't know the functions you need, and you are not willing to use Google, read code from other systems, use the documentation and generally suck up knowledge like a sponge, you won't get very far.
I know the whole topic of shader programming is not the easiest to grasp. It is complex, and it involves quite some background knowledge that you have to look up and learn. But you must have the patience to do it.
Cheers,
Frank -
-
On 24/04/2013 at 07:43, xxxxxxxx wrote:
Thanks again Frank,
I just put hard values in my example because it's a lot shorter to post a working example that way.
In a normal project I wouldn't hard them like that.
But thanks for pointing it out. Because that brings up another SDK method I'm having trouble with.You removed GetRS() from my example. And I'm still not sure exactly how that method works.
It's not explained properly enough in the SDK for me to understand how it works.This is what the SDK says:
Bool GetRS(const `RayHitID`[URL-REMOVED]& hitid, const `LVector`[URL-REMOVED]& p, Real* r, Real* s) -Calculate the R/S parameters for a point _<_h5_>_ _Parameters_ <_h5_>_/h5> \> _const`RayHitID`[URL-REMOVED]& hitid_ \> \>> The global `RayHitID`[URL-REMOVED]. \> \> _const`LVector`[URL-REMOVED]& p_ \> \>> The point. \> \> _Real* r_ \> \>> The returned R parameter. The caller owns the pointed value. \> \> _Real* s_ \> \>> The returned S parameter. The caller owns the pointed value.>>
>> Based on my prior experiences with GeData. I think what this method does is do some kind of ray sending. And then stores the some data found from the ray into the variable r &s?
> But what the heck is r&s?!Confused[URL-REMOVED]
> The SDK never says what theses data values are. And what they can be used for.
>
> This is why I need to stay talking in C4D SDK terms only as much as possible. Because in addtion to being brand new at shaders theory. I also don't understand many of the methods Maxon is providing to us to use to make them. Once I have the SDK decoded, those Renderman examples will probably come in handy.
>
> -ScottA
>
[URL-REMOVED] @maxon: This section contained a non-resolving link which has been removed.
-
On 24/04/2013 at 08:20, xxxxxxxx wrote:
Hm, just wanted to say "why not use google", but everything I found was saying R and S are
vectors in shading theory. But GetRS() returns two floating point numbers. -
On 24/04/2013 at 13:08, xxxxxxxx wrote:
I agree, it's not really well explained in the SDK docs. However the documentation does contain a little code example, that you didn't quote in your posting (make sure you are using an up-to-date version of the SDK docs). And that does give us a hint of what the function does exactly:
result = [color a] * (1.0-r-s) + [color d]*r + [color c]*sThe following applies: 0.0 <= (r+s) <= 1.0. So r and s are barycentric coordinates that define a position within a polygon (the result of GetRS() tells us if the hit has occurred in the first or the second triangle of a quadrangle).
You can use them to weight any kind of values between the points of a polygon, be it colors or other values (e.g. the values of a vertex map), and construct interpolated values for any position in the polygon. Here is an explanation about barycentric coordinates that might be easier to understand than the article on Wikipedia:
http://mathworld.wolfram.com/BarycentricCoordinates.htmlIf we read on in the docs, the next function mentioned is GetWeights(). And there it is said more clearly:
Returns barycentric coordinates for a point on the surface of a polygon.
...blahblah...
Works similar to GetRS(), but has a higher quality.Barycentric coordinates are useful for a lot of things, from texture mapping, distributing things on polygons, up to physical calculations; and they are not a C4D specific invention, by the way. Anyway, for a simple shader that generates a pattern, they are not needed. You can ignore GetRS().
-
On 25/04/2013 at 08:25, xxxxxxxx wrote:
"r and s are barycentric coordinates that define a position within a polygon"
Thanks. This is the missing information I was looking for.I've picked up quite a lot of good new information. And at this point I think the only thing that I really, really need to know is how to control the MIP samples.
I'm puzzled by what you said before about using cd->d to do that. Because that's a Read-Only function. So I don't understand how that can be of any help. Other than just a means to monitor the d value?Apparently I'm supposed to mix and blend something to do that. But I don't know what.
I do know how to use the math functions in the SDK:
Clamp(LReal a, LReal b, LReal x )
Mix(constLVector[URL-REMOVED]& v1, constLVector[URL-REMOVED]& v2, LReal t)But what values do I plugin to these math functions?
Do I have to somehow sample the colors of the shader...Then somehow blend the colors where I find two different colors?
I have no idea how I could do that.If I can just get the shader code to do the MIP sampling and make them look better. I'll stop pestering you with questions.
At least for a little while.
-ScottA
[URL-REMOVED] @maxon: This section contained a non-resolving link which has been removed.
-
On 25/04/2013 at 11:42, xxxxxxxx wrote:
Originally posted by xxxxxxxx
"r and s are barycentric coordinates that define a position within a polygon"
Thanks. This is the missing information I was looking for. I've picked up quite a lot of good new information.You're welcome.
Originally posted by xxxxxxxx
And at this point I think the only thing that I really, really need to know is how to control the MIP samples. I'm puzzled by what you said before about using cd->d to do that. Because that's a Read-Only function. So I don't understand how that can be of any help.
The SDK sais about d: "The MIP sample radius in UVW coordinates."
So it's what I said: The value tells you how much of the UV space is covered by your ray. That is why the values in d become greater when you move the camera further away from the rendered surface, or when the ray hits the surface in a rather flat angle. And the values get greater when you move closer towards the surface, and/or view it from a steeper angle.
The value does not do any of the work for you, it just gives you an idea of how much you should reduce your shader's output detail.
Let's say, your camera is really far away from the rendered surface. Actually, it is so far away that you recon, your shader should have minimum detail now. You hit render, and watch the d value that is passed to your shader. Let's say, it's 0.005 (just a fantasy value).
Now you move the camera closer to the surface until you think, now would be a good distance to have your shader show full detail. You hit render, watch the d value, and find it's e.g. 0.0000001.
(d is a vector, and its components will most likely not have the exact same value, but I'm trying to keep this example simple).To make it simpler, let's put the values of d into a single Real. Let's just average them. It's less precise and you might be happier with using both values separately, but for this example, it's ok.
Real easy_d = (cd->d.x + cd->d.y) * 0.5;You should now clamp the easy_d values between the two values we looked up before. That will prevent your shader from becoming either unnecessarily detailed or ridiculously dull.
const Real min_delta = 0.0000001; const Real max_delta = 0.005; Real delta = Clamp(min_delta, max_delta, easy_d);Now let's say your shader is based on a noise (easier to explain than with a pattern). If the noise in your shader has an 'octaves' value of 8.0 it looks superb, and with a value of 2.0 it looks rather crappy but still halfway acceptable (again, these are fantasy values. It all depends on your shader.).
You could now control the octaves value with your delta, making it look crappy if it's far away or seen from a flat angle, and making it looks good when it's very near.
For this you could simply map the value of delta from a range of [0.0000001 ... 0.005] to a target range of [2.0 ... 8.0]. The following code is a short form of the Range Mapper code, as shown e.g. here:
http://c4dprogramming.wordpress.com/2012/09/13/range-mapping/const Real min_octaves = 2.0; const Real max_octaves = 8.0; Real octaves = (delta - min_delta) / (max_delta - min_delta); octaves = min_octaves + (max_octaves - min_octaves) * octaves;Voilà , here you have a super simple example of how to use cd->d to control a shader's level of detail. In practice, you would probably still spend some time tweaking the values until the shader looks exactly the way you want.
Originally posted by xxxxxxxx
If I can just get the shader code to do the MIP sampling and make them look better. I'll stop pestering you with questions. At least for a little while.
Only you know what pattern your shader produces, and how it is done. There is no standard way of doing it efficiently. If you write an algorithm that creates a pattern, you have to write it in a way that its level of detail can be controlled.
If you rewrite a shader that already exists and that someone else originally wrote, then you should ask them.
I cannot give you the code of the CINEMA 4D checkerboard shader. First of all, because it's internal code; second, because the code in there is specific to the checkerboard pattern and does not necessarily apply to any other pattern; third, because it is highly mathematical and rather abstract, and I am under the impression that you are still struggling with the basics
There is, however, a good example of a filtered checkerboard shader. You'll probably hate me for that (or you recognize the sweet irony), but it's a renderman example:
http://www.renderman.org/RMR/Shaders/LGShaders/index.html
I found that and many other results that might be helpful with my very first Google search. You should be able to achieve the same. You have probably noticed that none of the code shown in this posting was any C4D specific.