Pass it through a noise node (42.5, 0, 42.5), then separate HSV and separate RGB -> 6 outputs. May want a contrast node in there though. I use this often, although I usually use random instead of objectID.
Think I read that wrong. I welcome the object color of course. I’m just not sure I would use it for “random” variations. But yeah, I guess it is one more way.
Why these specific numbers?
As far as I’ve understood, both CPU and GPU rendering benefit from small buckets in the latest versions of Cycles, but it makes sense that it fluctuates with certain scenes.
Just a starting point. Low scale gives you little variation in color when distortion is there, and distortion is required to get a colored output. Detail 0 (no octaves) because not required at all for stuff like this.
42 because, well, it’s the answer to everything 
The fraction is not actually needed, but there was a time I couldn’t get this to work in some cases without fractions being used. So I just settled on 42.5 as a starting point. The distortion can be your “seed” value.
Here is using that mechanism to drive semi-different materials on some dice:
Awesome. Thanks for the explanation.
What I mean is, I often have the same type of material duplicated several times, only to have it in different colours. Different shades of leather for example, or different colours of car paint. Now with this, I could use only one base car paint or leather material, and control the colour per object. Not random variation.
This change does makes it easier to do now, but it was something the object id node could do before this was added. You can even have different shaders for different objects that share the same material.
If you just need to change the color depending on the object then you can use this setup. Divide the object index by the highest index number, and add stops for each different result (example: 1/3 is .333 so add a stop with the color you want to that “pos” value). If you need multiple objects to have the same color, then just give them the same id:
If you need each object to have a completely different shader, then you can use the object id to create different masks for each object, and feed them into the factors of mix shaders:
Heres the blend file for these examples if you want to take a look at them:
object filter.blend (494.8 KB)
Yes, since one of versions we had much better situation for gpu rendering of small tiles, but right now it’s clearly scene dependednt and gpus like >128 in general.
Did the gsoc bring sockets for color ramp stops by the way ? I remember it was mentioned at some point.
This often mentioned but I think it’s difficult due to the way the stops work. Once a position changes the order of stops is also changed if one stop moves past another.
There has to be a socket for stop position as well
Ah I see, never thought of this. Thanks for the examples! But a bit of a roundabout solution, when adding a new colour for example you have to reposition all the colourramp stops.
Another option, it would be to add an input dropdown near the stop color, with the options [‘Color’, ‘Socket’], and if Socket selected, change the color prop to a text prop for a socket name, and add a socket with that same name to the UI.
Can you Share that scene Maybe , for to see how this works
Well, this is the node setup:
https://blenderartists.org/uploads/default/original/4X/6/d/e/6de4b948416a34057d3b916172b744a0b4ad302b.jpeg
How it works is covered in the top right. The rest is the individual material setups and mechanics to drive these. I’m using some custom nodes to make things easier for myself. But it’s basically using the random 0-1, where I also plug in how many variants I should get out of it. Think random x 6 -> floor -> /6 -> splitter with same n x 1/6 intervals.
Yes, this is true. The new output for the object info node does make that sort of material easier to adjust.
Just a heads up, a lot of commits have been making their way into Cycles to get the code ready for the Optix implementation (from Brecht and Patrick Mours)
Many of these are in the area of small optimizations, general refactoring, and better code generation (with the latter for GPU rendering), there may or may not be some small performance improvements for CUDA and even the CPU as a result.
There’s a much easier way now: The object info node’s color slot. Pablo Vasquez showed it on Blender Today. It’s in the daily builds.
Not in this case. I want it random, and the mixer is to mix completely different materials, some of which are also affected by random. I don’t know a better way to do it lacking a case select node.
