Reopening, not related to T66844. This is a regression from June 2020 in 2.90, when many basic translations were removed from .pot, likely, due to a bug in bl_extract_messages.

As on my computer, bl_extract_messages.py fails with

Fixed in svn, thanks

Fixed in rBTS5222, thank you for report!

@Artyom Sobolev (Woolpit) , I've added you to transifex, welcome!

I added Michael to https://www.transifex.com/translateblender/blender-ru/ and we agreed to wait for 2.8 and discuss translation improvements meanwhile. So I guess the task is solved now.

@Michael Soluyanov (crantisz) , glad to see you, you are an awesome guy! I'll contact you today in vk.

@Denis Bryukhanov (dennyishere) , check out weblate website https://translateblender.ru/ - you can register there and submit your own translations, which I'll upload to Blender SVN.

Fixed in rB88acb3c5

Hi! I would like to download Blender 2.74(***), but it downloads 2.74, same for all other versions. Please check this problem. I downloaded here: http://www.blender.org/features/past-releases/

Reproduced this problem with no ocio, added an inline comment with possible fix here: rB4fc318811

For T44707

Superseded by completely another more complex approach. Still experimenting, but new patch has nothing common with this patch, so closing this one.

Based in the fact, that no rotation/shear transformations are used with rastertocamera transform, and perspective coefficient is never zero (how could it be?).

Fix if() formatting and add pad3.

@Thomas Dinges (dingto), it seems to me that current implementation is affected by "off-by-one" mistake somewhere around here: https://developer.blender.org/diffusion/B/browse/master/intern/cycles/render/blackbody.cpp$96 . I've already noticed that our current implementation gives different colors from OSL and my approximation is based on unbiased function.

For CUDA (7.0) the difference is smaller, 00:52.86 (lut) and 00:51:91 (approx).

Quick test on CPU with plane gave 25.45s (lut) vs 20.26s (approx). Input socket is obviously connected.

Difference between original (non-lut) function and approximation:

I've checked rB5ad79b83afae again with NVidia and it doesn't compile on my computer anymore even with ADV shading disabled. The compile process looks similar to nvcc, clBuildProgram works for 1 minute or so and then eats up all available RAM and crashes. I guess this is related to @varunsundar08@gmail.com (varunsundar08) report.

Common diff in PTX (same for SASS), 92 replacements:

< 	mov.f32 	%f6781, 0f00000000;
< 	max.ftz.f32 	%f6782, %f1500, %f6781;
< 	mov.f32 	%f6783, 0f3F800000;
< 	min.ftz.f32 	%f10110, %f6782, %f6783;
---
> 	cvt.ftz.sat.f32.f32	%f10029, %f1500;

I've tested this patch (the original one from D1200) on Ubuntu 14.10 x86-64 and NVidia GTX 690 with MikePan BMW scene.

Sorry, I don't understand your proposal.

Animation works too:

Added sergey as reviewer.

@Thomas Dinges (dingto) yes, the report is here: https://github.com/embree/embree/issues/30

Committed an actual fix. This problem comes from embree, both nmadd and nmsub functions in avxf and ssef are incorrect there.

This patch affects BTS repo, adding @Bastien Montagne (mont29).

Tables for common benchmark files:

For future references: this procedural texture could be used for recreating stars. Unfortunately, it is not so easy to use, but this approach is more flexible and can be applied in cycles too.