Unfortunately, I get a building error ( Ubuntu 16.04 )
https://pastebin.com/4S2CKdXd
( I removed first part of the build.log to be below pastebin limit of 512k )
Note: regular Blender master builds fine on this machine
Hey @sc3sc3, it seems like a compiler issue, but I’m not savvy enough to be able to tell you what’s wrong. What’s concerning to me is you’re getting a whole bunch of stuff related to code I haven’t touched, only a few lines are erroring from my code.
What’s your gcc --version?
sc3sc3 tried compling troy’s version if I understand right. Maybe he touched more?
We’re essentially collaborating on the changes in Troy’s fork now, since Troy has the OCIO prowess that I don’t, and it’s making my life a heck of a lot easier! 
I have the same problem as @kram1032 with the dll, except it didn’t start after restarting. 2.83 Is working for me.
I’m looking into whether I’m doing the build and package wrong over here, thanks for the patience and feedback guys.
@sc3sc3 you might try building this branch with an attempt at resolving the errors which came up, most of them looked like warnings but there were a few errors coming from my code.
Forum does not let me post here anymore ( limit of posts for new user reached 
) , so I have to edit this message.
building: Smilebags float-fix branch
The compiling seemed to succed but install failed:
CMake Error at source/creator/cmake_install.cmake:53 (file):
** file INSTALL cannot find**
** “/home/rana/git/smilebags/blender/release/datafiles/locale/languages”.**build.log is not complete due to Terminal ‘scrolling’ limit:
When it comes to responding, I’m stuck now. I can’t post more than 2 urls in 1 post
and I can’t add posts to this thread anymore
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: …/src/configure -v --with-pkgversion=‘Ubuntu 5.5.0-12ubuntu1~16.04’ --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.5.0 20171010 (Ubuntu 5.5.0-12ubuntu1~16.04)
Sounds like it didn’t grab the sub modules properly, by default they are relative to the blender repository so i had some issues there as well.
@smilebags people will have an easier time building if you change your .gitmodules to include the full paths to the blender repository
[submodule "release/scripts/addons"]
path = release/scripts/addons
url = git://git.blender.org/blender-addons.git
branch = master
ignore = all
[submodule "release/scripts/addons_contrib"]
path = release/scripts/addons_contrib
url = git://git.blender.org/blender-addons-contrib.git
branch = master
ignore = all
[submodule "release/datafiles/locale"]
path = release/datafiles/locale
url = git://git.blender.org/blender-translations.git
branch = master
ignore = all
[submodule "source/tools"]
path = source/tools
url = git://git.blender.org/blender-dev-tools.git
branch = master
ignore = all
Thanks for that, I’ll make that change tomorrow. I haven’t worked too much with submodules before.
The sub modules should all be there and be pulled as I sync those as well at GitHub once per hour.
Unless @smilebags changed the sub modules, it should have just worked.
EDIT: Ah he forked his own repository for the test patch.
Your status is shifted from new user to basic user. You should be able to post again, but beware: many links to the same domain risk triggering the system regarding spam.
2 Likes
I just pushed the head of your branch with one extra change to a branch on my repo, so I’d imagine the submodules would be retained in that, no? Maybe I’m misunderstanding them.
@brecht is there an existing way to take a series of values representing an ideal distribution of samples in the range 0 to 1 and create a function which maps evenly distributed samples to one which distributes them according to the curve?
If not it isn’t too hard to build but I thought I’d see if such a thing already exists.
I’d also like to know the best place to be adding stuff to KernelGlobals before render (such as CMFs, lookup tables and the aforementioned wavelength PDF), ideally in a way where they could be read from disk (or other configuration such as through the Blender UI), this will make the system much more flexible and I think is the right way to be doing a lot of the things I’ve hacked into the system for now.
I was playing around with the latest build from GraphicAll and found that, when having set the point-light color in the RGB widget by entering 0 [tab] 0 [tab] 1 [tab], pressing tab again will change the entered value into 0.00273, 0.0, 1.00079. Then I found that it also happens for the base color of the Principled BSDF on a sphere and in fact on any RGB colour picker. I guess that shouldn’t happen?
See util_math_cdf.h, it’s used for sampling pixel filters for example.
Depending on what you need to store, you can use either LookupTables (for simple float tables) or add vectors in DeviceScene.
I’m not sure what you would read from disk, the OpenColorIO configuration along with some built-in tables should be enough as far as I know.
Yeah, i think it has to do with the new OCIO config, you can trust the RGB values I think, but hopefully we can resolve the issue so the colour picker works as expected.
Not specifically loaded from disk, but I just want to make sure any of the data I’m relying on for conversions can be changed from config (hence either files or through the UI) rather than needing rebuilding.
@brecht what are your thoughts on how to best account for the differing contributions of each wavelength when using a PDF for wavelength? I’m guessing I’ll need a function which will give me the probability of a wavelength which I can divide by before converting back to XYZ, but how would you suggest fitting that into the existing system? How do existing PDFs get handled?
I have learnt from looking at util_math_cdf that the integral of a PDF normalised to 1 is a CDF.
Given a CDF, is there a standard function for sampling it to retrieve a weighted sample?
Good eyes.
The reason they shift is that the rendering working space in Spectral Cycles is currently BT.709 adapted to a white point of Illuminant E. That mumbo jumbo means that the rendering RGB lights are not sRGB D65, which is what an sRGB display uses, so the values shift when taken “to” the working rendering space.
Why? Because the assumption is that the spectral rendering components ingest equal energy white point based RGB, do their magic, then round trip back. This keeps the compositor etc. working space in a sane RGB encoding for further work, and then let’s OpenColorIO handle the to and from particular display outputs accordingly.
The current nature of the two types of displays in the configuration, being sRGB-like commodity displays (extremely common) versus more expensive sRGB proper displays, are brute force ugly. Due to the nature of spectral, it requires a proper gamut mapped approach from top to bottom to avoid that skewed purple @kram1032 has in his excellent sample with the blue eggs.
Gamut mapping needs to happen by default, just as with Filmic Blender, only the source gamut is the spectral locus now, instead of the BT.709 based constrained gamut in Filmic Blender.
TL; DR they are likely round trip residue and accumulation of minor things. I have curves generated via more idealized values about to land. Should reduce the errors.