since so long I had the feeling something is off with cycles bump maps… always just assumed its in my mind… thank you so much for this link!! - and the workaround mentioned in the comments (use displacement with bump only)
Now seeing it this clearly i would say this is a showstopper bug (if not for the workaround)
Dang. I never knew about that but also noticed that sometimes the bump maps looks at bit odd at certain angles. And what do you know - I did a quick test and indeed the Displacement method looks better compared to the Bump version. It just catches light better at some angles.
Please fix that. I don’t want to have to adjust my whole material library (and back again).
If you leave the distance value of the bump node at something low and constant (like 0.1) and plug the texture into the height socket instead (using the strength value as well, the strength), then you will get much better results (at least that is what I can see with my work).
The bug report image shows a tree that does it the other way around on the first two values mentioned, except it uses a high value for the constant).
Yes. My understanding is that distance is in Blender units (1 meter in my case, so I usually set it to 0.01 or less, down to 0.001, for human-scale materials), while strength is a generic/artistic/arbitrary value to find the nice spot for the bumpiness
My apologies, someone over on the Right-Click Select feature request forum just clued me in that the Motion Blur option in the Object Properties sidebar disables Volume Motion Blur for an object, so this is already a feature.
The only problem now is that those calculations are still done even if Motion Blur is disabled in the Cycles render settings (the object properties Motion Blur checkbox is slightly greyed out to indicate it isn’t functional, but it actually is)
Hi everyone!
It’s been a while already since Cycles had been updated to Cycles X, a more future-proof renderer, as it was presented.
I don’t complain about the quality, stability, or other new features, but is there a chance we could see OSL support for GPU rendering some day?
There are few renderers out there that do have OSL support for GPU, so I assume it is technically possible.
If not, or not yet, is there any chance Shader editor would get more nodes extending Cycles capabilities and flexibility, likewise, trace function, sample other surfaces, sample SDF volumes, sampling many images at once (decals scattering, texture bombing), etc
Thanks!
Aaaand, I deeply believe it’s time to adopt MaterialX and Hydra delegate rendering in Blender 
Why rendered viewport becomes so laggy when overlay is enabled? Espesially it makes difficulties for scenes with a huge greenery. Could it be improved?
RTX3080 16gb
I think blender need re-write all the viewport for all situations… he really so laggy… why not let the user choose if he want use oc CPU or GPU… i thinks this thing need a thread for a discussion, but is a solution for not anymore laggy viewport.
Sometimes you have to realize the reality of things, Blender needs better performance regarding the viewport (& shading compute) this is where the user has his preview and is extremely necessary and cannot be neglect in terms of performance. A few things needs to be done.
There have been a lot of performance improvements, IMHO the team is not neglecting the performance side of development, the problem that I see is the lack of people to help. Money is not the solution, I mean, it helps a lot, but I think that the dev team needs people committed to help to code and improve blender.
In this particular @nickonimus example there’s a way to get a good performance, and it is just to disable the overlay… boom! You get the performance. He wants to know if it could be improved, I’m not a developer but I imagine that it can be improved and if it can be improved it will be, certainly… but who will actually do this? This is the question…
Do you try to remove anti-aliasing in preferences?
It can be removed for text and viewport models
Yes i tried, anti-aliasing not makes any difference at all.
@Stimes I can’t complain overall about viewport performance, but in this particular case, defenetly should be improved. One of the greatest features of blender is that you can model and render in the same viewport, but because of this problem i usually had two viewports side by side, so it kills great concept.
@EvertonSchneider I think it not only could be improved, but should, since it is daily pain. So this is a soft hint for devs 
Yeah i know that and is the problem… the real team is a little team… and one person work one by one… and not for exemple 5 persons on re-write EEVEE for exemple… and it’s the problems…
And by the way always desactivate options for increase the performance one time you have no more to disable you are stuck… i know a lot of improvement are made in the past… but now it’s time to re-improve the viewport again ! Is the game… always search the newer options and better performances is the same in the society ! I’m pretty sure soon a big works are or make in the future or soonly blender grow up so fast i trust in the blender team Stay up 
i already described this problem in november 2018 year, past almost 4 year - and problem is still there -
this is SAD that such small problems is “still there” remain for years…
You’re more than welcome to donate to Blender fund.
utility of you comments ? is not the money the problems. is simply difficult to find a person for the jobs !! Go look the blender jobs,
I know this is not the right place, but I can’t report this bug in any other way… Long story short: This is what one of my meshes looks in Blender 3.6 (3eff28a158ca) and before
Rendered mode / Cycles:
And this is what it looks like in Blender 3.6 (f54af343f175) and onward. The last version I checked was d3bab78d0540.
Yet, it looks absolutely normal in any other mode incl. Eevee. Triangulation helps, but as you understand, triangulating your meshes is not always an option. I was able to reproduce the bug using new custom geometry, but it was the other way around: it looked normal in the rendered mode, but corrupt in the edit mode.
Here is the link to scene with the mesh.
Pass: 123
Ideally you should make the bug report on blender/blender: The official Blender project repository. - blender - Blender Projects
Also, the file you’ve provided appears to have a password protecting it. So we can’t open it.
The registration works again? Didn’t know that.
PS. Pass is in the name of the file you downloaded: The_Bug.rar_pass_123
Not sure if this is the right place to post, but is the openpgl integration updated automatically / has it been updated to 0.5?
