Cycles Requests

[lsscpp]

@brecht

Eevee to add displacement support

Yeah, that sounds cool

[lsscpp]

To get the same result you should connect bump/normalmap to all of the BSDF normal inputs

[lsscpp]

as @Josephbburg says, displacement used in “bump mode” is a kind of shortcut*

edit: *which I like and use by the way…

[Bobo_The_Imp]

@MetinSeven

This is not completely Cycles-related, but it would be really great if we could use all available Cycles textures in the Displace modifier as well, instead of only rendertime micro-displacement.

This is certainly nice, but I would love it even more if we could create any network of nodes in the shading tab and output it to be accessible by modifiers. I think pablo dobarro wants to do this with scultping brushes.

[MetinSeven]

That’d be even better indeed. I’m sure the Everything Nodes project will bring the goods.

[Fuxna]

Would be cool if you could expose dFdx, dFdy, fwidth functions as nodes, both in Cycles and Eevee. Would be very useful for custom bump map mixing, or generating mipmap levels when UV continuity is broken when using fract(uv) and similar. Assuming you also add a way to select proper texture LOD. What do you think?

[Charlie]

The Dxyz, filterwidth, area, calculatenormal etc functions are available in OSL, have you tested them there?

[Fuxna]

I have seen that those are available in OSL language spec document, but i haven’t done much with OSL shaders so far. It kinda seemed slow last time i played with it. IMO they could be nodes why not? Similar nodes exist in other shader graph editors, and are very useful. Don’t get me wrong, i would rather look at code than at node tree. But OSL is really slow. Don’t know if much has changed since last time i used it. Is it still on CPU?

[Jason_C]

This neglects the “both” (auto-bump) mode. In fact, the “bump” option is basically auto bump for displacement without any actual displacement.

[lsscpp]

you can still send one (or many) bump/normalmap to both normal BSDF inputs and material displacement output, if needed

[vasiln]

@Josephbburg

Is it ever “correct” to use the displacement socket as a bump map? I thought it was merely a convenience for people too lazy to use the Normal Map node…

There are a couple of reasons to use displacement for normals. It’s a hell of a lot easier to make and understand than snaking normal links all over the place, for one-- if you use displacement output, you can make much cleaner “code”. It’s also good for baking bumps to tangent space normals, and for rendering a normal pass for use in compositing.

That said, it also creates a mess of dependencies, since this output is also an input-- definitely some confusing behavior when trying to do something like, say, triplanar projection on a bump map, since your geometry/normal is dependent on your displacement output…

It seems to me that a normal output (for compositing if nothing else) and a “defaults” node, that let you set default values for normal, tangent, procedural texture coord, image texture coord inputs, would probably be the ideal way to handle it, and would leave you without the potential for any dependency loops, if I’m thinking it through correctly.

[MetinSeven]

I’d love to request two new defaults for the Principled BSDF:

1. Default to Multiscatter GGX.
   As far as I know Multiscatter GGX is more physically accurate than GGX, so why not set it as the default?

2. Default to Random Walk SSS.
   Random Walk is a more effective SSS algorithm than Christensen-Burley, so why should users have to switch every time they use SSS?

This would save users four clicks every single time a new Cycles material is created.

Thanks!

[Josephbburg]

Random Walk is slow and Multiscatter GGX is noiser (and very subtly different from what I’ve seen).

[MetinSeven]

That can be countered using the recently added AI denoising options.

[3di]

Would it be possible to include a particle rendering feature set similarly to Nurulize (recently purchased by Sony). The main thing is the render time auto filling algorithm, saving a huge amount of memory as there’s no need for verts, edges, or faces (just points).

This can also be useful for uv-less shading, and also topology independant curvature/shading.

It would also introduce a whole new way of modelling/painting, with no need for retopology.

Check it out:

Atom View

If you then combine that with a mechanism for only loading the required points for any given frame, then you could potentially have an unlimited number of points per scene with very fast performance in viewport. Something similar to Euclideon (it only ever loads the same amount of points as the screen pixels):

[realeyez]

The Cycles Bevel shader cannot be reliably baked to a normal map texture without artifacts.

Here is a link to the post in yesterdays thread where discussion about the artifacts in question began: https://blenderartists.org/t/baking-issues-with-the-bevel-shader/1209197/16

Attaching an image of the artifacts in question here for clarity:

The primary issue which results in baking artifacts can be found in this specific reply here: https://blenderartists.org/t/baking-issues-with-the-bevel-shader/1209197/38

This has potential to be an invaluable and game changing workflow solution for high -> low normal map baking, but it needs to be consistent.

[chippwalters]

The split edge modifier is your friend in these cases. Use it before your bake, then remove it afterwards. Be sure and give your islands plenty of padding. Also, please post your file and I can take a look at it.

FWIW, that density of a mesh does not seem like a game asset.

Here’s a successful bevel bake off a rather complex model:

[realeyez]

Split edge modifier is a deprecated and unnecessary tool for baking normal maps. You only need to mark your UV boundaries as sharp.

Mesh density doesn’t matter. That mesh could be 3x the scale of a person, in which case it could be perfectly fine. Or it could be for a cinematic first person shot, or a million other reasons. That being said, you can reduce the density if you like, but if either side of the booleaned cube has a different amount of edges, the bake will fail and create artifacts.

The issue is prevalent regardless of how perfect or padded the UVs are, and stems entirely from the geometry itself.

If you can bake the .blend from that thread perfectly without artifacts or errors, then we can consider this not an issue, but my guess is that you unfortunately won’t be able to due to a limitation of either the bevel shader itself or Cycles baking ability (or a combination)

The .blend in question: https://blenderartists.org/t/baking-issues-with-the-bevel-shader/1209197/18

Re-UV that however you please, but keep the topology the same. That shape and that topology should work fine unless there’s an issue with the shader or Cycles baking. I can bake that object with other versions of the rounded edge shader without issues in other packages.

[Jason_C]

Would it be possible to add some kind of texture coordinate noise/displacement to the principled volume shader? Currently it’s possible to do this with point density by mixing noise with the texture coordinates, but it’s not possible for smoke simulations or OpenVDB files. It can really help for adding details that are smaller than the voxel resolution.

[lsscpp]

Dear devs, you guys rock!
Recently adaptive sampling was added and it looks awesome. One thing I noticed though is that rendertime estimation now goes nuts! I understand how impossible it is for cycles to know how long it will take to clear a tile until it gets there, and how it tries to make an estimation making math with pending tiles and current render time. Rough. And now with AS it gets even more difficult to know if a tile will be finished fast or not. I think it could be the time to revamp a proposal I made a while ago on RCS: “A better estimation of rendertime”. This method, or anything better, could be a nice addition on top of what Cycles is nowadays.