Cycles Development Updates

(moony) #605

Yep - the modo ones do look very similar.

Given that the only packages these textures have appeared in as far as I can tell are commercial ones (Imagine, Lightwave and Modo) - I suspect the source code for these isn’t open and therefore would be unavailable for Blender.

Those textures coupled with cycles nodes would be incredibly powerful.

I actually don’t think there are as many textures as it looks like. Peened for example simply looks like an inverted version of Dino Skin. Similarly Frog Skin looks like Dino skin but with a different falloff curve on the bump.

Some like lattice 3 are easily reproduceable with nodes and many seem to be derivations on Voronoi or Musgrave.

It’s the more regular textures like Parquet, Spots, Stamped, Hexagonal and Octagonal times, Tri-Tiles. Basket, Layer Properties, counter etc that are interesting.

(Ace Dragon) #606

More procedural textures based on structured patterns would be a nice thing to have (as you can’t do everything with the brick, checker, and wave textures without a lot of work).

There is also that current patch that allows for perfectly even crack patterns with voronoi’s crackle setting, but we can also use a depth setting like the noise texture has.

(Ace Dragon) #607

The Embree integration project (in an initial state at least) is now in code review.

Stefan, in a comment, also gives hard numbers for an Agent 327 scene with motion blur, a >3X performance increase while RAM usage declines from 7.1 GB to 6.1 GB

(stanland) #608

I asked in different thread about caustics, but feel that maybe this is the right place to ask about it. Is there any development to make caustics in cycles better?
I know about Metropolis Sampling but is that project dead?

(doublebishop) #609

yes it is dead.

(Lsscpp) #610

I asked on DevTalk, and this is w hat Brecht answers:

(moony) #611

Dont know whether this is possible in Cycles - but could cycles ever support a ‘black light’ type effect.

The way i’m thinking it would work is that a lamp or an emitter could have a ‘blacklight’ checkbox. If this checkbox were ticked, the lamp/emitter would not illuminate normal materials in the scene.

Material nodes like diffuse could have a ‘fluorescence’ checkbox. The ‘blacklight’ would only affect materials that had ‘fluorescence’ ticked, although a ‘fluorescence’ material would be illuminated by normal lights.

(Simon Storl-Schulke) #612

Isn’t this essentially light-linking? Or are you thinking about an “per-shader” checkbox rather than “per material”?

(moony) #613

Per shader - although thinking about it, would an ‘is blacklight’ option on the lightpath node be better. That way you could mix two materials (e.g. a diffuse and an emission) based on whether the material was receiving blacklight rays or not.

(Ace Dragon) #614

What would be even better is if Cycles had an equivalent of BI’s “light groups” option. Cycles would add a tag to the rays depending on which light they hit.

Then you can have a group of lights called Black or something similar and you can use a node to create a mask.

While on the subject of lighting, I wonder if it would be possible for area lights to have solid shapes (rectangular prism, sphere, cylinder, and more). The idea is that you then can assign a volumetric shader to the lights to give a more natural appearance to the sources seen via reflecting and refracting rays, but with better sampling compared to mesh volumes.

(Ace Dragon) #615

Charlie has been busy, he submitted a new patch that adds some insane functionality to the Voronoi node.

It includes a triangle distance metric, cell coords, cell jittering, rendering as a tiled texture. cell-based coloring, ect…

If the CUDA compiler doesn’t vomit on this level of added code, then it will lead to another big leap in procedural texturing.

(Solvent) #616

Awesome! I’d just been tinkering with that myself, using OSL to expose the cell coordinates to allow things like mosaic effects:

Will be nice to have that available for GPU rendering.

(Stefan Werner) #617

IMHO we need to get OSL to run on the GPU, one way or the other. Some work for PTX/CUDA is in the OSL repository already, and it should be possible (probably not easy though) to get it to OpenCL (or Vulkan/Metal, whatever we’ll be using on non-NVIDIA hardware then).

Just look at it: One one side, you have a shading language. On the other side, you have hardware with programmable shaders. To me it’s obvious that the two should be connected.

(CarlG) #618

New voronoi looks super hot! Could the jitter input function as a 4th coordinate? Allowing it to evolve over time without moving in 3D space. Also, I think the regular noise generator should have repeatable option as well.

(LazyDodo) #619

As long as you’re not doing too crazy things, OSLPY actually does a decent job of translating osl to shader that’ll run on the GPU. Yeah sure it has limitations, but for basic stuff, it does the job rather nicely.

[/shameless plug]

(Charlie) #620

It’s not a periodic input but if you plug in a value node running through a keyframed mapping node you can rotate the jitter to create a periodic effect.

(Ace Dragon) #621

The Gabor noise patch has also been resurrected.

As exciting as all of these new procedural texturing features are though, it would help if each new patch came with examples of real world materials and details that become far easier to make (either via surface shading, volumetric shading, or micro-displacement). I say that because I think the patches are more likely to be accepted if their uses can easily extend beyond abstract or artsy images.

(<== Lost? Click Me) #622

Don’t think it’s trivial to implement something like

but Gabor noise is a component.

(moony) #623

Ace - I think it’s difficult to give real world examples without experimenting.

For example - through expermentation - I came up with a malachite material using the voronoi node.

I would never have guessed I could produce it by looking at what voronoi patterns look like without putting it through various other nodes.

(moony) #624

Interesting video. I wonder how the scattering functions they are using compare to the ones cycles uses. Could there be an opportunity to learn something here and increase the speed of volume rendering?