Cycles Development Updates

[oaschwab]

I really hope they transfer a few of the blender internal procedural textures over to cycles.

[SterlingRoth]

Brecht is actively working on this project.

[oaschwab]

That would be awesome. I thought I had read a while back that they were not looking to add any new procedural texutres or make changes to any of them.

[SterlingRoth]

They were resistant to add more pressure to the Cycles kernel, but with the full removal of BI, there needs to be access to some of the features that BI used to have, so now it is a priority project.

[CarlG]

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.

[brecht]

@moony

I downloaded the latest build - but that version doesn’t contain the exponent value for Manhatten. In fact the only option that has the exponent value exposes is Minkowski.

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

(incidentally - Minkowski with an exponent of 1 looks identical to Manhatten - and with an exponent of 30 looks identical to Chebychev). It therefore seems that both Manhatten and Chebychev are redundant options since both results can be achieved by using Minkowski with different exponents.

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.

@SterlingRoth

They were resistant to add more pressure to the Cycles kernel, but with the full removal of BI, there needs to be access to some of the features that BI used to have, so now it is a priority project.

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.

[Ace_Dragon]

@brecht

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)

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

[moony]

@brecht

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

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

@brecht

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.

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.

[pafurijaz]

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

[rbx775]

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

Cycles's GSoC 2018 project: new hair shader! Expectations?

Hello everyone, As you may be aware (if not, please read on!), Google accepted 5 Summer of Code projects for Cycles this year, among them mine, “Implementing a Hair Shader for Cycles”. My project intends to port Zootopia’s hair shader (doi:10.1111/cgf.12830) to Cycles. There is already a basis available in PBRT’s version, and also a WIP patch by Lukas Stockner that may also be of use. I’d like to take this opportunity to ask you all about your expectations for the project. In particular, I w…

[Ace_Dragon]

You can now stack up to 32 volumes in a single space.
https://lists.blender.org/pipermail/bf-blender-cvs/2018-July/112292.html

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

[moony]

@brecht

the only option that has the exponent value exposes is Minkowski.

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

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.

[pixelgrip]

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.

[moony]

@pixelgrip

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.

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.

[pixelgrip]

@moony

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 nodes.so we have the choice between clamped and unclamped.
or as sayed a normalize math node would be nice,for every case.

[SterlingRoth]

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

[brecht]

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.

[LazyDodo]

@brecht

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

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

[brecht]

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

[SynaGl0w]

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