Cycles Development Updates

Access in BI didn’t do anything useful to me; there are better texture renderers out there if I wanted that approach. This however, allows getting rig of texture repetitions. Below a hybrid approach; bumped (not good, I know) water plane and microdisplaced ground plane, where the color output of the generator is used to randomize image texture positional lookup, rotation, x and y scale. The image texture is repetitive, but see if you can spot it immediately. I was never happy with image texture based flagstone textures and such.

The exponent only ever worked for Minkowski, the version from the screenshot just didn’t properly hide the value.

Yes, they are just specific versions of Minkowski. I already removed Minkowski 1/2 and 4 compared to Blender Internal, Manhatten and Chebychev are redundant as well but perhaps are not bad for discoverability reasons.

The other reason we can do this now is that GPU compilers have improved and we recently dropped support for some older GPUs, and now adding more texture features no longer causes global performance degradation.


So Kepler and up could’ve handled more texturing features, it was Fermi that was holding everything back (including for CPU users) :slight_smile:

Hopefully, the rounding feature for the bricks node can get another look as well.

1 Like

Ok cool - just didn’t want to miss something.

This is good news. Procedurals can be very powerful - especially in conjunction with cycles nodes.

A simple tile texture - allowing different tile shapes would be a pretty useful addition.

1 Like

As I was browsing through the release notes, I discovered that there is also a new Node.
Principled Hair BSDF
Reference/Release Notes/2.80/Cycles

1 Like

Its a GSOC project by Leonardo Segovia, read more about it here:


You can now stack up to 32 volumes in a single space.

Ideally, Brecht would like the stack to be dynamic, but it’s not easy to do on the GPU.

Just one other thing I noticed. The new Voronoi node seems to be clipping when used in conjunction with the colour ramp (see screenshot).

The only difference between the two cubes is that the one on the right has a default colour ramp inserted after the voronoi node. As you can see the detailed highlights are clipped (I would expect these two cubes to look identical).

I tested this with the old voronoi node in official 2.79 and don’t observe this behaviour. The output is identical whether you run it through the colour ramp or not.

I also tested this with the math node (using the greater than function). The old voronoi node seems output values normalised in the 0-1 range (i.e. setting the match node to >1.0 results in a black cube) - whereas the new node outputs values above 1 (i.e. setting the match node to >1.0 results in a pattern up to around 1.5-1.6).

If the colour ramp cannot accept RGB values above 1 (and so clips them) - this may be what is causing the issue.

i have tested this,and increased the white linear color to 5,and no detail comes back.i guess the colorramp has a clamp right at the input.
a math node ,with a normalize function, before the ramp would do the job.would be nice if we would have one.
normalize is a very usefull function.

Yep - that is my suspicion too. Interestingly the RGB curves node doesn’t appear to clamp the input value.

If the colour ramp node didn’t clamp the input value - in linear mode it would in fact act just like a math ‘normalise’ function.

yes could be.i did not noticed or knowing this colorramp behavior before.the best would be to make the clamp optional like in the other we have the choice between clamped and unclamped.
or as sayed a normalize math node would be nice,for every case.

Normalization seems like it would be a complicated function for a shader. @brecht, do you have any info on the feasibility of this?

I’ll look into making the output of the voronoi texture normalized.

Adding an automatic normalize operation is not possible to do efficiently, there is no way to know what the minimum/maximum values of the node network linked into it will be.


Perhaps add a lerp node and leave it up to the user to select appropriate min/max values? Sure you can do it right now with a couple of math nodes , but it’s not super intuitive for artists

1 Like

Yes, we could support the Map Range compositing node for shading.


Please do. Anything to reduce the number of node groups we need for trivial things is a positive!


and threating the datas like bitmaps/image ect ? its datablocks could be used for min max and the function.
something simple like this?

in theory you could feed in every datablock you want.first get the min and max value from the datablock,and then start the function

But when pathtracing ‘every datablock’ is millions of paths, bouncing millions of times, shaded by any possible nodetree. You’d essentailly have to render the entire scene, then do the normalization, and even then it wouldn’t work, since you would need the shaders that use that normalization function to contribute to the scene itself.

As far as I understand it, Normalizing is functionally impossible in a path tracer shader tree.

hm not sure about this.

i have another idea .the normalize function with input value slots,like in the other math nodes,there you could put in min and max value you want for yourself.this way you dont need a data block and you could normalize it right now,with the simple formula.

you only have to get the values with the nodewrangler preview ect

Sounds like @Brecht is aware of it. This is the map range node he refenced in post #300(Cycles Development Updates):

You can set the max and min, for both the input and the output.