I really hope they transfer a few of the blender internal procedural textures over to cycles.
Brecht is actively working on this project.
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.
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.
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)
Hopefully, the rounding feature for the bricks node can get another look as well.
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.
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 nodes.so 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
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!