Surface Knowledge - An ongoing series on fully procedural materials for Cycles

I’ve created a section in my blog called ‘Surface Knowledge’, specifically devoted to the development and refinement of fully procedural materials in Cycles. I shall be posting there node setups and .blend files with ready-made materials. I’m also open for suggestions for improvement, comments and ideas for new materials.

These are the materials developed so far:

  • Procedural rusty metal v1.5
  • Procedural varnished wood v1.6
  • Procedural orange skin v1.2
  • Procedural stippled finish v1.0

Head here for the goodies and stay tuned for more Surface Knowledge. :wink:

UPDATE 1: There is a problem in recent Blender builds with scaled objects and it’s affecting procedural materials and mesh lights. If you want to use these materials you should stick to r46043 or older until this is fixed by the almighty Brecht. :slight_smile:

UPDATE 2: I’ve upgraded wood material to v1.1. I made some minor adjustments to make finer grains look less solid. The scene in the .blend file is also a lot simpler now so you can do test renders in shorter times. My rustic chair has been re-rendered with the new version.

UPDATE 3: I’ve upgraded wood material to v1.2 and rust material to v1.1. Changes in the rust material are minor. Mainly removal of unused nodes and adjustments in the metal part to reduce the gloss. On the other hand, changes in the wood material are more noticeable. I’ve added an independent controller to adjust the scale of fine grain and an additional controller to adjust the intensity of bump mapping (displacement).

UPDATE 4: I’ve upgraded wood material to v1.3. This update fixes some scaling problems that were affecting procedural textures in recent development builds of Blender.

UPDATE 5: Both Wood and Rust materials have been upgraded to 1.4. This update includes improved gloss controls based on those developed by Mango project for both materials. In the case of Rust material it also has a much improved metal material, and Wood material now has independent bump controls for fine grain.

UPDATE 6: Brand new material on the way. Procedural orange skin will be available soon.

Procedural orange skin is now available for download from my site. This new material will only work on Blender builds supporting per shader bump-mapping and anisotropic shaders.

UPDATE 8: Orange skin material updated to v1.1. Since anisotropic material is very much WIP at the moment and is suffering constant changes, I’v decided to replace it with a simple glossy shader. With very little tweaking, I managed to get the same overall look using it and now it’s future proof to boot. Since there is no anisotropic material in the setup now, controls are also a bit simpler.

New material, procedural stippled finish, and full revision of all materials developed so far.

Thanks and a great idea.

Yeah, great idea. And very cool materials. Tnx.

Edit: Tried your rust material now and holy cr*p it’s computation heavy, hehe, my GTX570 is on it’s knees begging for mercy… And still a lot od noise after 200 samples. How many passes did you do to get a clear image in the original suzanne scene?

To add, for anyone who is having trouble “grasping” Cycles materials, there is some stellar advice in the documentation for Arnold. It recommends that we stop thinking about materials in terms of fake values like specularity, etc., and start to consider things like “What would this material feel like in real life? What real world materials and substances go in to making it look the way that it does?” It makes it a lot easier to get good materials.

These look great - and is along the lines of what I have been trying to achieve with my cycles materials - trying to reproduce how materials actually work in the real world.

That is looking nice JuanJose :slight_smile:

I too have been working on a procedural rust shader, attempting to mimic your original rust texture.

As for how to go about Cycles materials, this is exactly what I do, try and figure out what components they have in real life. I still would like ways to only have specularity, transmission, etc. for making materials that are not supposed to be real (magic, scifi concepts, etc.)

You comments have left me really puzzled. I’ve been doing some tests and found that recent blender builds from buildbot have a serious problem with mesh lights and procedural materials if the object is scaled (which is the case in my .blend file). Does your render look like the one below?

If that’s so, you have two alternatives. One is to go back to official 2.63, or at least as far back as r46043 if you want to enjoy the recent BVH improvements. The other one is to apply scale to the objects where you are going to use procedural textures, but personally I’d rather avoid this and stick to releases prior to this problem.

In any case, if you simply open the .blend file you downloaded from my site and hit F12 you should get this render:

Details for this render are these:

Blender version: 2.63.0 r46043 (fish build for Linux 64)
Resolution: 1920x1080
Passes: 100
Render time: 00:02:31,75
Render device: 2 x GTX580

You also commented in another thread that my file used 1 GB during render. I checked the Blender process during both CPU and GPU renders and it didn’t go above 246 Mb (CPU render) or 235 Mb (GPU render). Can you tell me wich method do you use to measure memory usage during renders? That way I can contrast data and fine tune the material to be more efficient.

Oh yeah, looks like the top one. And I run the daily MinGW build off the buildbot. But then I know and hope this will be solved eventually. For me this is not something I’m in a hurry with, I will at the earliest switch to Blender for production Aug-Sept this fall, hehe, by then either Cycles or you have solved this - but this is a material I’d use, I often work with arch wiz on older (100+ years) industrial buildings, so such a material would really come in handy. :slight_smile:

And I use GPU Meter, from - nothing fancy or exact, it’s not what I use it for, but as I had a driver crash during a render I checked it out and saw the mem usage jumped up to 1+ GB’s, not continuously, but jerky. Very weird. Maybe also a bug in Cycles then…

Hmmm, I really need to get an OEM Windows 7 license and set a dual boot in my machine. There are quite a few monitoring tools that have no real counterpart in Linux (at least none that I know of). Anyway, I checked that my render peaked 105,90 Mb according to Blender, but I don’t know if this information is reliable. Anyway, I will keep tweaking and see if I can find a balance between looks and speed.

Use Windows 8 CP. I do. It’s also free. Not sure how long, but at least 6-12 months. And I use it for production, it’s that stable. Also it’s Windows 7 in all that is important, drivers a.s.o… :slight_smile:

Nooo, check the VRAM usage… 1+ GB’s… Maxing out the driver crashes and takes Blender with it (though not bluescreening which is pretty cool, hehe)

But the texture itself is absolutely awesome. My screenshot is 7 (!) samples, it clears right up. That it also doesn’t with the newer builds. I Also heard this from others, the last couple of builds seem noisier too… :stuck_out_tongue:

Edit: LOL - ‘screenshit’ changed to ‘screenshot’… xD

LOL. :smiley: That’s insane. Out of curiosity. Have you tried to do a CPU render? Theoretically, it should only use system RAM in that case. It would be interesting to check RAM and VRAM usage in that situation.

Heh, as it turns out, Nvidia drivers for Linux come with a command line utility to monitor your GPU usage. Theoretically it should be able to show GPU usage, power consumption, etc, etc… but a majority of the indicators are only supported for Quadros and Teslas. However, what is in fact supported for Geforce GPUs is memory usage monitoring (hooray! :D). You just open up your CLI and type ‘nvidia-smi’ to get your GPU’s current status. If you want the utility to keep monitoring your GPU, you then type ‘nvidia-smi -l 1’. To stop the utility you just have to press ctrl-c in your CLI window.

Armed with this little tool and the system monitor I did some tests with the rust material .blend file and this is what I came up with:

And as bonus I did a single GPU render which confirmed my previous estimation:

So there you have it. The .blend file as it is right now shouldn’t require more than 292 Mb to render succesfully.

I kinda agree - however with the current version of cycles - some materials seem to be beyond its capabilities owning to the way the material is made up in the real world.

Particularly difficult is anisotropic reflection. Materials that exhibit this are usually fibrous in nature (e.g. tigers eye) and could only be simulated accurately if we had a volumetric element to cycles.

I have also been trying for the last few days to try and accurately simulate brushed metal displaying anisotropic reflections using a stretched out noise texture in the displacement slot - trying to simulate how it works in real life Although I can get some anisotropy in the reflections - its a long way off looking like real brushed metal.

This is the effect i’m after

Hmmm, have you tried mixing your stretched noise texture with wave texture? Maybe stretch it too, play with bands or rings, see which works best… Might be worth a try.

Yes - that is the approach I have been taking. Tried noise, waves combinations - none are satisfactory so far.

In many real world cases, you cant really see the tiny grooves that are causing the anisotropy - most are microscopic. If you scale down the procedural textures too much however - you start getting really bad moire patterns.

The best result I have got so far has been using a gray scale image texture for the displacement and multiple glossy shaders with varying levels of roughness. Below is the best result I have so far. To get procedural textures to work - we’d probably need some sort of blur filter to help prevent the moire patters becoming an issue.

i like this thread, and i’m really impressed with your procedural rust textures. i’m just posting to say “Like” and so that i’ll get subscribed to the thread :slight_smile:

You are more than welcome. :slight_smile: Be sure to check version 1.1 of my wood material. I also have some ideas for the next version of my rust material which I might try to implement this weekend. After that I will probably move on to try and create some believable rock material. My general plan is to start with more common materials and once I have a sufficient grasp of the process, try to create more exotic ones.


Blender uses 62 Mb - just started it & opened the rust scene. When rendering on CPU it jumps to 146-148 Mb’s mem use. Unbeliavably low, hehe… ;D

But there is obviously something weird going on in regard to memory use in Windows. Might be my driver, I’ll revert to the official Windows 8 driver and see if it makes a difference. :slight_smile:

Edit - Update:

Downgraded to the official Win8 driver & tried Blender official 2.63 release + todays buildbot 64 bit + todays buildbot MinGW 64 bit… Same memory usage no matter what build, 1+ Gb rendering on the GPU. In Cpu rendering the mem. usage is just under 150 Mb, just as before…

@ @moony

in the nodes set up for anisotropic metal
you are using generated instead of UV for an image texture
is it appropriate or need to use UV and unwraping ?

and what type of image do you use for this any example ?

i think we should get one anisotropic node soon in cycles i hope !