step 3 select the same function from the math menu again make it active.
sry, could upload only one image in a post
maybe you have inactive nodes too?i am not sure, if this behavior is wanted or a bug.
I’ll look if there’s an issue involving that. However, I actually tried separating out just parts of the material. It’s not just some nodes being inactive. For instance, as said, a spectral blackbody node with color temperature 1500K will, in that file, somehow render as blue. (Clearly this is a pretty low temperature and should look solidly orange)
Tried clicking into every single field that isn’t directly connected to something. No change.
Here’s the blackbody thing I mentioned:
This is just an emission shader with a texture that controls a specral blackbody’s color and emission strength
same thing with exposure of 10 for clearer visibility.
The blackbody’s color goes from 0 to 1573 linearly based on the texture.
Clearly none of this is even remotely the right color.
That being said, this only happens on this safe file (and if you append the material to another safe, though it somehow also transfers the island as said)
A fresh safe will show the correct thing.
In fact you don’t even need a new safe. A new object with a blackbody will behave correctly.
So somehow just that one material got seriously corrupted and appears not to recover.
1 Like
The selection bug introduced Thursday and fixed on Friday IIRC in master.
2 Likes
Thanks for all the testing, that’s a lot of bugs you found there. Here’s some stuff I figured out:
I can’t reproduce this one.
I got 3 different types of crashes:
- OCIO crash. Happens when using EEVEE or opening image viewer. For some reason, it tries to find
filmic_false_color.spi3dLUT that is not available in the builds. I can’t identify where this LUT is referenced inside the file.
OpenColorIO Error: The specified file reference 'filmic_false_color.spi3d' could not be located. The following attempts were made: C:\BLENDE~1\BUILD_~2\bin\2.90\DATAFI~1\COLORM~1\LUTs\filmic_false_color.spi3d - Path tracing crash. Usually happens when modifying node tree. I suspect there’s out of bounds memory access somewhere that breaks BVH tree, or maybe that’s EMBREE + displacement bug.
# backtrace
Exception Record:
ExceptionCode : EXCEPTION_ACCESS_VIOLATION
Exception Address : 0x00007FF656953C38
Exception Module : blender.exe
Exception Flags : 0x00000000
Exception Parameters : 0x2
Parameters[0] : 0x0000000000000000
Parameters[1] : 0x0000024F0BAC0F90
Stack trace:
blender.exe :0x00007FF656953C20 embree::avx2::TriangleMi<4>::loadTriangle
blender.exe :0x00007FF6570C48C0 embree::avx::BVHNIntersector1<4,1,1,embree::avx::ArrayIntersector1<embree::avx::TriangleMiIntersect
blender.exe :0x00007FF656BFD730 embree::avx2::InstanceIntersector1::intersect
blender.exe :0x00007FF656BFD730 ?intersect@?$BVHNIntersector1@$03$00$0A@U?$ArrayIntersector1@UInstanceIntersector1@avx2@embree@@@av
blender.exe :0x00007FF655FFD380 rtcIntersect1
blender.exe :0x00007FF654F9BEE0 ccl::kernel_path_trace C:\blender-git\blender\intern\cycles\kernel\kernel_path.h:698
blender.exe :0x00007FF654F92850 ccl::kernel_cpu_avx2_path_trace C:\blender-git\blender\intern\cycles\kernel\kernels\cpu\kernel_cpu_impl.h:99
blender.exe :0x00007FF654B087E0 ccl::CPUDevice::render C:\blender-git\blender\intern\cycles\device\device_cpu.cpp:914
blender.exe :0x00007FF654B09640 ccl::CPUDevice::thread_render C:\blender-git\blender\intern\cycles\render\session.cpp:1268
blender.exe :0x00007FF654B03A30 std::_Func_impl_no_alloc<<lambda_d884e08a7877f415f05ce8ffda8f97b4>,void>::_Do_call C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.25.28610\include\functional:926
blender.exe :0x00007FF6550E64D0 tbb::internal::function_task<std::function<void __cdecl(void)> >::execute C:\blender-git\lib\win64_vc15\tbb\include\tbb\task.h:1049
tbb.dll :0x00007FF8BF8D37A0 tbb::recursive_mutex::scoped_lock::internal_try_acquire
tbb.dll :0x00007FF8BF8D37A0 tbb::recursive_mutex::scoped_lock::internal_try_acquire
blender.exe :0x00007FF6547D8830 tbb::internal::task_group_base::wait C:\blender-git\lib\win64_vc15\tbb\include\tbb\task_group.h:168
blender.exe :0x00007FF6550E6BD0 ccl::TaskPool::wait_work C:\blender-git\blender\intern\cycles\util\util_task.cpp:46
blender.exe :0x00007FF654B553D0 ccl::Session::run_cpu C:\blender-git\blender\intern\cycles\render\session.cpp:742
blender.exe :0x00007FF654B54F90 ccl::Session::run C:\blender-git\blender\intern\cycles\render\session.cpp:869
blender.exe :0x00007FF6550EB440 ccl::thread::run C:\blender-git\blender\intern\cycles\util\util_thread.cpp:53
blender.exe :0x00007FF654630110 std::thread::_Invoke<std::tuple<void (__cdecl ceres::internal::ThreadPool::*)(void),ceres::internal C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.25.28610\include\thread:44
ucrtbase.dll :0x00007FF8C7F114B0 configthreadlocale
KERNEL32.DLL :0x00007FF8C8806FC0 BaseThreadInitThunk
ntdll.dll :0x00007FF8CA65CEA0 RtlUserThreadStart
Stack trace looks different every time, but it always ends in the EMBREE intersection code. I also experienced this strange bug. Different parts of the mesh were disappearing between samples.
- UI crash. I have no idea what caused this one and cannot reproduce it, but I think it’s worth keeping it here.
# backtrace
Exception Record:
ExceptionCode : EXCEPTION_ACCESS_VIOLATION
Exception Address : 0x00007FF653FC57D2
Exception Module : blender.exe
Exception Flags : 0x00000000
Exception Parameters : 0x2
Parameters[0] : 0x0000000000000000
Parameters[1] : 0x0000000000000008
Stack trace:
blender.exe :0x00007FF653FC57C0 rna_NodeSocketStandard_float_range C:\blender-git\blender\source\blender\makesrna\intern\rna_nodetree.c:2812
blender.exe :0x00007FF653FA60B0 RNA_property_float_ui_range C:\blender-git\blender\source\blender\makesrna\intern\rna_access.c:1529
blender.exe :0x00007FF654368520 ui_set_but_soft_range C:\blender-git\blender\source\blender\editors\interface\interface.c:3118
blender.exe :0x00007FF654365DC0 ui_but_update_ex C:\blender-git\blender\source\blender\editors\interface\interface.c:3488
blender.exe :0x00007FF65437A920 button_activate_exit C:\blender-git\blender\source\blender\editors\interface\interface_handlers.c:8219
blender.exe :0x00007FF654383D40 ui_handle_button_event C:\blender-git\blender\source\blender\editors\interface\interface_handlers.c:8898
blender.exe :0x00007FF65438A700 ui_region_handler C:\blender-git\blender\source\blender\editors\interface\interface_handlers.c:10668
blender.exe :0x00007FF653D93F60 wm_handlers_do_intern C:\blender-git\blender\source\blender\windowmanager\intern\wm_event_system.c:2743
blender.exe :0x00007FF653D935B0 wm_handlers_do C:\blender-git\blender\source\blender\windowmanager\intern\wm_event_system.c:2857
blender.exe :0x00007FF653D90AF0 wm_event_do_handlers C:\blender-git\blender\source\blender\windowmanager\intern\wm_event_system.c:3360
blender.exe :0x00007FF653D7C540 WM_main C:\blender-git\blender\source\blender\windowmanager\intern\wm.c:478
blender.exe :0x00007FF653AED6D0 main C:\blender-git\blender\source\creator\creator.c:534
blender.exe :0x00007FF655EF5F88 __scrt_common_main_seh d:\agent\_work\4\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288
KERNEL32.DLL :0x00007FF8C8806FC0 BaseThreadInitThunk
ntdll.dll :0x00007FF8CA65CEA0 RtlUserThreadStart
World object is used inside the material, so it loads as a dependency. You can see that it has 2 users.
There’re probably some issues with shader tree updating. @pixelgrip mentions them and I’ve experienced something similar too.
Just wanted to say, that water looks so good 
Seems like a lot of those crashes are from master and will probably be resolved with a future rebase, yeah?
I’m starting to look into wavelength importance sampling now but not sure how I’m going to tackle generating the CDF for wavelength sampling (or the function which takes in equally distributed samples and spits out the numbers weighted across the wavelengths) from a known continuous function of the importance of each wavelength. Anyone who has experience with this, it would be greatly appreciated.
2 Likes
Oh! Of course it’d need the object if it’s in the nodes. Nice, didn’t realize that but that makes a lot of sense. No bug there then.
Weird that the blackbody just works for you. I thought it might be kinda stable since it also looks that way when appending to a different file. (though note that was just an example. All the colors went wrong. The first image I put in the post above is what I’d expect.)
On that note, could we get, like, a weekly-or-so build, even without big changes to the branch? 'cause if it were to take weeks and weeks for a new build to appear with these bugs still in it, it’d make testing further a lot harder.
Though at least the EEVEE/Image Editor crash is certainly on the Spectral branch.
Yeah, I was under the assumption the builds LazyDodo was doing were still happening but I’ll try to make an effort to create a build every few weeks. They’ll be CPU only for now, though. I don’t have the time to look into getting the GPU build up and running on this machine.
CPU only isn’t an issue for me since my GPU isn’t powerful enough regardless 
Do you think it’d be feasible to have a duplicate “Nishita (Spectral)” sky model within the same build, seeing as it’s so much slower? It’d also make directly comparing the two easier. Just use the same file and switch to/from the spectral model.
Same idea as with the spectral/regular blackbody node.
I updated the build on GraphicAll. Spectral sky is now a separate node along with the latest Blender.
3 Likes
Early look at wavelength importance sampling. This one is obviously very colour biased since I’m not accounting for the importance sampling, but if you just look at the noise performance (this is 2 samples per pixel) you can see the difference in the aesthetic of the noise. It should be more weighted towards more colour noise and favouring less brightness noise, but in this colour-biased image, we won’t see the colour noise come through.
I don’t have the math know-how to actually do what I want properly yet, and it’s not a fair comparison until I re-introduce the extra colour noise by scaling up the under-sampled wavelengths, but I think it’s a promising idea.
This scene is also probably not a great test scene since it contains a lot of blues and reds which are getting de-prioritised here so the noise performance might not differ much at all. I’ll have to try some more varied scenes once I correct the colour.
Unweighted
Weighted
6 Likes
I’m trying to reproduce the spectral sensitivity of film to light as a little test of the spectral rendering, but I’m wondering if I’m using the nodes as intended…
Here is my setup - an emissive quad with a pre-rendered scene in front of the camera, multiplied against a spectral curve. The first shot is without the result of the multiply, the second shot is after.
In this case, I expect most red and oranges to be completely blown away, which appears to be what happens. However, I would expect a much darker sky given how much red is in it, but it seems rather to shift instead. Overall luminance doesn’t really take a hit at all.
Is this in fact what I should be seeing? It’s hard to tell if the output from the “Spectral Math” node is an actual color, or if multiplying a spectral curve against RGB data will do what I’m expecting it to do.
To further confuse matters, if I try to desaturate the image after (using the dot product node), it doesn’t quite give m the results I’m expecting - but I don’t know enough to say if I’m wrong or I’m using something incorrectly. In this case, the desaturated image doesn’t seem to change much even if I really crank the spectral curve around a lot, even if the RGB image changes quite a bit, which indicates that I’m getting more of a shift than luminance changes when I do this multiply.
1 Like
The difficulty with this is that something fundamental to the render engine has to change in order to properly emulate the spectral sensitivity of film. Instead of converting from spectra to RGB using the CIE CMFs (which are centered around human vision), you’d need to know the spectral response of each layer in the film, among other things in the rest of the film developing pipeline.
If this CMF was read from a file in Blenders config, it could be changed to match different film stocks. When you save an RGB image, you lose all the information needed to emulate the behaviour of the film.
From the node setup and image I see, they seem to make sense next to each other but it isn’t accurately emulating film stock for a number of reasons. Happy to talk more about it if you like.
1 Like
Here’s a comparison of spectral vs. RGB sky. Unsurprisingly there isn’t a whole lot of difference (aside of the RGB sky being roughly 2.5 EV brighter than the spectral sky)
Spectral:
RGB (same exposure):
RGB (exposure reduced by 2.5 EV)
To really test this, a scene relying more on indirect lighting is going to be necessary.
1 Like
Good to see they’re looking pretty much the same. I doubt there will be much difference between them because I assume the spectra coming from the sky model will be very smooth.
Is the exposure difference due to the updated sky code (resulting in an overall brighter sky) not being reflected in the spectral version yet?
If so, the diff with the update is here: https://developer.blender.org/D8285
After a few weeks I tried to build the most recent version of this branch on Ubuntu. Unfortunately it crashed quite early. Probably due to the new Sky Texture, but there are other issues as well:
- There appears to be some issue with subrepos. Calling
make updatecrashes with:
Updating Submodules
git submodule update --init --recursive
Submodule 'release/datafiles/locale' (https://github.com/sobotka/blender-translations.git) registered for path 'release/datafiles/locale'
Submodule 'release/scripts/addons' (https://github.com/sobotka/blender-addons.git) registered for path 'release/scripts/addons'
Submodule 'release/scripts/addons_contrib' (https://github.com/sobotka/blender-addons-contrib.git) registered for path 'release/scripts/addons_contrib'
Submodule 'source/tools' (https://github.com/sobotka/blender-dev-tools.git) registered for path 'source/tools'
Cloning into '/content/blender/release/datafiles/locale'...
Cloning into '/content/blender/release/scripts/addons'...
Cloning into '/content/blender/release/scripts/addons_contrib'...
Cloning into '/content/blender/source/tools'...
Submodule path 'release/datafiles/locale': checked out 'cea10833f63298651de1fdcc3a8975316871ecfd'
Submodule path 'release/scripts/addons': checked out '0657e99e1f4ff01118591d19ffc740694869ba96'
Submodule path 'release/scripts/addons_contrib': checked out 'f2f4a8b3bfa36ee49f7bdb3a1acb40ef4b39ee3a'
fatal: remote error: upload-pack: not our ref 6a252de776d0b9dca3167c30a7621a4f1e9bc911
fatal: The remote end hung up unexpectedly
Fetched in submodule path 'source/tools', but it did not contain 6a252de776d0b9dca3167c30a7621a4f1e9bc911. Direct fetching of that commit failed.
GNUmakefile:505: recipe for target 'update' failed
make: *** [update] Error 1
- Then after starting the build I get plenty of these warnings at the very beginning:
CMake Warning at /usr/local/lib/python2.7/dist-packages/cmake/data/share/cmake-3.12/Modules/FindBoost.cmake:847 (message):
New Boost version may have incorrect or missing dependencies and imported
targets
Call Stack (most recent call first):
/usr/local/lib/python2.7/dist-packages/cmake/data/share/cmake-3.12/Modules/FindBoost.cmake:959 (_Boost_COMPONENT_DEPENDENCIES)
/usr/local/lib/python2.7/dist-packages/cmake/data/share/cmake-3.12/Modules/FindBoost.cmake:1618 (_Boost_MISSING_DEPENDENCIES)
build_files/cmake/platform/platform_unix.cmake:305 (find_package)
CMakeLists.txt:830 (include)
- and the whole build crashes somewhere here:
[ 5%] Generating node_geometry.oso
/content/blender/intern/cycles/kernel/../kernel/svm/svm_sky_nishita.h(26): error: dynamic initialization is not supported for a __constant__ variable
1 error detected in the compilation of "/tmp/tmpxft_0000133b_00000000-6_kernel.cpp1.ii".
[ 5%] Generating node_glass_bsdf.oso
intern/cycles/kernel/CMakeFiles/cycles_kernel_cuda.dir/build.make:392: recipe for target 'intern/cycles/kernel/kernel_sm_30.cubin' failed
make[3]: *** [intern/cycles/kernel/kernel_sm_30.cubin] Error 1
CMakeFiles/Makefile2:1400: recipe for target 'intern/cycles/kernel/CMakeFiles/cycles_kernel_cuda.dir/all' failed
make[2]: *** [intern/cycles/kernel/CMakeFiles/cycles_kernel_cuda.dir/all] Error 2
make[2]: *** Waiting for unfinished jobs....
The master branch compiles fine, crashes at linking, but that’s a different issue.
I had some issues when recently building, too, on Linux. You can manually go in your source/tools directory and stash whatever changes the make update did, and then manually pull the latest.
As for your other errors, it’s always safe to first delete your previous build directory to compile with a clean slate when switching branches, did you do that? At the very least you can delete your cmake cache file in your build directory.
I have a start on hacking in spectral sensitivity for monochrome film. First up is a test of orthochromatic film, which was popular around the turn of the century and was mainly insensitive to wavelengths greater than 600nm.
That’s a normal color chart ^, note where the red is.
There’s a render where all the reds are cut off. I had to hack the Cycles build to do this, so it isn’t default behavior, but looks like it’ll work nicely for my experiments. You can actually get a very quick and easy result using simple RGB mixers for about the same thing, but I want some ground truth renders to base my fooling around on.
7 Likes