Can confirm this, same is true for Color and Power.

Just pulled, it's fixed now.

Possibly solved by rBae6300a8b74b: Fix T66022: crash adding subdivision surface modifier to some meshes, though I could not reproduce the crash.

Apologies for the inactivity. I've been dealing with classes. Once 2.80 releases I'll make sure to get the backwards compatibility finished and address any remaining issues so it can make it into 2.81.

I think I've found out what's the problem.
It was my error - I didn't use the the Narmal Map node to fed the texture into the Shader - it needs that to interpret the Normals in relation to the UV map - once I did it, it's shaded properly.

I tried verifying if the inputs are correct for the camera_world_to_ndc function and I am not sure they are quite correct. One thing I tried doing was changing the variables P and the kernel_data.cam.worldtocamera matrix such that the output moves into the correct position, but I did not get very far with that.

EDIT: Just uninstalled all the drivers for the GPUs and did two rounds of clean-ups using Guru3Ds DisplayDriverUninstaller in Safemode and things work again. Seemed to be an issue on my end, works again right now.

I have the same issue in Blender 2.8, 0fd96b4128ff
I have 4 GPUs installed but blender shows 8 GPUS.

You can post help related questions on https://blender.stackexchange.com

There's no documentation for it that I know of. There's two functions here, which should do the inverse of the other. So unless the input to the functions is somehow wrong, it's a purely mathematical thing where the formulas are just not matching.

I think I see where's the problem, in my case 32-bit float or 8-bit inteer doesn't make a difference.

If you think you found a bug, please create a new report.

I have the same problem with every Normal Map I try to bake.

Please see:
https://wiki.blender.org/wiki/Communication/Contact#User_Feedback_and_Requests

Same problem for me.
I'm in 2.8

In D3743#115097, @Charlie Jolly (charlie) wrote:

@Eneko Castresana Vara (ecv) thanks for the diff. I've left the patch waiting for review. I think that this will be looked at after 2.80 is released. I've also contacted @Omar Ahmad (OmarSquircleArt) to see if he can incorporate this into his new GSOC procedural branch.

@Eneko Castresana Vara (ecv) thanks for the diff. I've left the patch waiting for review. I think that this will be looked at after 2.80 is released. I've also contacted @Omar Ahmad (OmarSquircleArt) to see if he can incorporate this into his new GSOC procedural branch.

In D4993#114932, @Juan Gea (juang3d) wrote:

Looks great,
What are the benefits of this over the @Lukas Stockner (lukasstockner97) dithered sobol implementation?

• Added an option to ignore coherency setting in non-bluenoise mode.
• Added a 128x128 blue noise mask.
• Updated defaults. Seems the setting of coherency that leads to quickest convergence differs from scene to scene.

I was able to trace down some things to direction_to_fisheye_equisolid but I am unsure of how that function was implemented. @Brecht Van Lommel (brecht) is there some documentation on how the equisolid fisheye lense was implemented?

Looks great,

How about to render roughness pass?

It might be useful to find a way to hide the repetition in the 64x64 pattern, since in some cases it can become visible.

Note that we also have D2149. It would be interesting to see renders with 1, 4, 64, 1024 samples to see how it converges and how it compared to the reference. If it works well enough it would be nice to have this in 2.81.

In D4971#113927, @Brecht Van Lommel (brecht) wrote:

It's possible to initialize the strength to 1 only if the color is black. See versioning_cycles.c, there's other code there that does this kind of versioning patches for nodes.

It's possible to initialize the strength to 1 only if the color is black. See versioning_cycles.c, there's other code there that does this kind of versioning patches for nodes.

In D4971#113806, @Alex Strand (astrand130) wrote:

In D4971#113787, @Carlo Andreacchio (candreacchio) wrote:

Can i suggest that the default values follow what the SubSurface inputs are? the emission strength would be 0 and the default emission colour be white (instead of the inverse?)

That might have been the ideal way to do it, unfortunately I'm afraid that could break older files that only use the emission Color, when the emission strength would default to 0 the material would lack emission. And since this feature seems to be coming post 2.80 that would probably be a much bigger deal then if that change was made during the beta.

In D4971#113787, @Carlo Andreacchio (candreacchio) wrote:

Can i suggest that the default values follow what the SubSurface inputs are? the emission strength would be 0 and the default emission colour be white (instead of the inverse?)

Can i suggest that the default values follow what the SubSurface inputs are? the emission strength would be 0 and the default emission colour be white (instead of the inverse?)

After some troubleshooting I just did a fresh installation of the blender source and applied the patches.

This should be solved by now.

oops accidentally replaced the entire diff. (I don't know how to use git, sorry let me figure this out.)

Fixed hard-coded socket indices.

No, we don't make exceptions, we were already supposed to freeze in mid May.

In D4971#113581, @Brecht Van Lommel (brecht) wrote:

This is a good improvement, we can add it to 2.81.

Ok, I will take a look around and try to find the source of the bug

The assert is most likely unrelated to the bug, just some NaN.

Hello, could you post the output of the assertion that fails? This would be helpful in trying to find the source of the problem

This is a good improvement, we can add it to 2.81.

Edit: cycles socket for emission_strength default value has been updated to 1.0. (doesn't actually seem to have an effect but doing it just to be safe)

Fixed in rB4df66dabb888: Fix T65212: Cycles SSS failing on 32 bit.

found it, the culprit seems to be the ccl_try_align(16) on float3 is a no-op on x86/windows

I have perform a check but the results were far from usable. Compiling the kernels took 40 minutes. Rendering the bmw took several hours. So for now it is not usable at all.

Ok, I think that's fine.

@Brecht Van Lommel (brecht), think easiest solution for now is to explicitly ignore curves when in edit mode. A bit of a shame since we made it to work for 2.70, but currently even strands are not rendered in edit mode.
More proper solution would be to make dependency graph to load edit mesh and put object outside of edit mode for render engines.

This appears to be working now, probably after Sergey's latest depsgraph and mesh API changes.

This is an artificial setup, we are going to drop 32 bit support soon, it's not worth spending time on this.

This is a variation of an existing report: T52680: Alpha difference Viewport/F12

@Kévin Dietrich (kevindietrich) Glad you came back! Could you please update your patch D2388 for the current code, so we could review and make it to the master finally, cause it's very important for fluid rendering.
If there's something I can assist with, let me know. I'm not a coder anymore, but maybe a can help.

We now default to GLSL in most cases, so I'll consider this resolved.

Also I am having problems with sequences again: https://developer.blender.org/T51820

@Kévin Dietrich (kevindietrich) : thx for getting back! will read those...
Also note that T54050 is the same thing...

I am not working on this anymore, although I could resume work. This approach was suggested to me by Campbell as a general way to import custom keyframes from alembic archives. The patch was uploaded for review a few years ago: D2324.

I think the approach is pretty nice, as it'll give us a way forward to animate other properties as well.

@Sybren A. Stüvel (sybren): yep, not for 2.80, but this is the way to go, right? [having a cache-fcurve-modifier]
Or is there another possibility [from the design point of view]?

@Philipp Oeser (lichtwerk) it looks interesting, but too big a feature to put into master for 2.80.

Just wanted to check the status on the import-of-animated-camera-focal-length issue:

Caused by rB40a69b2ad7fc: Animation: treat F-Curves with no keys as if muted/not existing..

Going to do some research into how vertex color baking is done in BI and will formulate a plan on how to adapt it to Cycles code.

I tested sergeys patch with intels sde emulating an avx2 core (test took, 1.5 hours.. yikes..) and it makes most of the tests pass now (the failing ones seem unrelated to this issue and fail on avx/sse as well)

Will commit with some fixes.

I would keep the system utilities as-is and will not do a kernel-specific tweaks in there. Would prefer something like this with a comment that 32bit kernel doesn't do vectorization and hence can not advertise BVH8: