Building cycles standalone not working for me.?

Seems this has been fixed on Monday. It uses the initialize-before-use model. Pitty that it hasn’t found its way into cycles-standalone branch…
Who is doing that? Brecht?

Hmm…I can’t seem to get it to build on Linux (Ubuntu) with info provided on the Cycles webpage.

I’m just a tinkerer, so I may well be doing something wrong…

It’s real hard to help with that kind of problem description, there’s just nothing there to work with.

Just thinking loud:
One solution to the whole problem might be to make Cycles Standalone directly accessible from the Blender command line. The invocation could look like this, for example:

blender --cycles-standalone [cycles-options] scene.xml

…which would trigger Cycles only, with the same result as cycles [cycles-options] scene.xml

In this way, it would allow Cycles Standalone users to rely on all the Blender pre-built stuff that already exists (binaries, packages etc), saving them the arduous task of building it.

What do you think about this?

If you’re gonna require all of blender anyhow, just write out a .gltf file, and call the stock blender to render it, no need to drag cycles standalone into it.

OK, I can try this, but a question beforehand:
Is Blender gltf support absolutely exhaustive compared to Cycles capabilities, including PBR material, glass material (KHR_materials_transmission extension), IBL (BIT_scene_background extension), sun/sky lighting and so on?

Unsure on the exact support matrix, but even if it doesn’t, you can always use it to get the geometry in and use a python script to create custom materials.

What it is, this should be an alternative to photoview360. You make a cool CAD design press render and you got a nice render to share with your customer or social-media. The latter is also important atm since Freecad needs all the attention it gets. People are already saying it is Blender before 2.8. And it only needs a little push. If we can show awesome renders in Freecad and how easy it is to do this it would surely get lots of attention.

Now I am planning to install Linux on my pc so I at least can play around with it! But still especially for CAD most users use Windows so I feel that this is very important!

Poing-pong between Blender and Freecad is not really a nice solutions. Definitely wouldn’t help the idea of Freecad not being user friendly.

Blender and Freecad should make-out more. :relaxed: :heart_eyes:

I’d prefer a solution where we are not responsible for freecad’s end users, surely someone at freecad can step up to the plate and provide windows builds? Happy to talk that person though the build process if required.

I can try it, not sure what level of competence you are asking?

Fair enough.

The Cycles stand alone website says use the pre-build libs and provides the svn command to get said libs.
It says: “The easiest way to build on macOS, Linux and Windows is to use the Blender precompiled libraries.” and “Checkout the folder for your platform”.

It assumes the reader knows what “platform” refers to. The list of things at “” isn’t particularly obvious. Do I want benchmarks (what platform is that?), darwin?, etc. Maybe there is context I’m missing?

I’d guess since I’m dealing with Ubuntu I’d choose “linux_centos7_x86_64”. And this is what I checked out.

Unfortunately, following the rest of the instructions results in errors about can’t find the libs…

I believe it is noted in this thread that indeed the svn command provided refers to a version of the libs that the standalone Cycles code has not been updated to use.
this maybe right? “

I haven’t had a chance to try it since it wouldn’t build for me the other day.

Again, fair enough.

But, is this really a FreeCAD issue?

As I detailed in my other post the instructions on the “Cycles standalone” website don’t seem to be correct. (I forgot to post which website in the other post: “” )

Don’t take me wrong.

I’m happy to be talked through this and I will create a wiki page with the details and link from the FreeCAD Render workbench wiki to my details.

Think the context that you’re missing is familiarity with the blender build process, we have scripts there that will automatically grab the right set of libs for you, so devs are at least somewhat familiar with what libs they need even if they don’t grab the libs manually normally

If you only want to build cycles standalone the only folders that matter are

all other folders in /lib are blender related can be ignored, if you craft your directory structure like this


cycles build process should automatically pick up on them, they sit one directory up from where your git clone of the cycles repo is.

give it a whirl, and if you run into issues, just holler and i’ll help you out

I’ll give it go tomorrow…but, that’s exactly the structure I had, with cycles and lib on the same level…as noted on the webpage I linked.

Well, it’s tomorrow and I started from scratch:

CMake Error at /usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:146 (message):
Could NOT find OpenImageIO (missing: OPENIMAGEIO_LIBRARY
Call Stack (most recent call first):
/usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:393 (_FPHSA_FAILURE_MESSAGE)
src/cmake/Modules/FindOpenImageIO.cmake:63 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
src/cmake/external_libs.cmake:231 (find_package)
CMakeLists.txt:101 (include)

CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
used as include directory in directory /home/mac/cycles-git/cycles
used as include directory in directory /home/mac/cycles-git/cycles

– Configuring incomplete, errors occurred!
See also “/home/mac/cycles-git/cycles/bin-opt/CMakeFiles/CMakeOutput.log”.
See also “/home/mac/cycles-git/cycles/bin-opt/CMakeFiles/CMakeError.log”.
make: *** [Makefile:13: release] Error 1

then you should be off to the races, building blender really isn’t that hard given you use our libs (use the links I gave in my last post though, so you’ll end up with a compatible set of libs, do not use the libs from trunk)

That doesn’t look good, hopefully @LazyDodo can help!

As a newbie I also just installed Visual studio with linux toolset. How hard can it be…

That’s not windows for which I am the maintainer for, so i’m not sure how much assistance i can offer here, I notified someone more familiar with mac to this thread though.

umm…it’s ubuntu

mac is the user name

can’t seem to repro that behavior on my debian in WSL just to confirm you have the right folder layout here’s my setup:

root@SRV:/mnt/k/cycles-git# ls -al
total 0
drwxrwxrwx 1 root root 512 Mar 24 18:50 .
drwxrwxrwx 1 root root 512 Mar 23 17:22 ..
drwxrwxrwx 1 root root 512 Mar 24 19:10 cycles
lrwxrwxrwx 1 root root  26 Mar 23 17:23 lib -> /mnt/k/blendergit/libs_292
root@SRV:/mnt/k/cycles-git# cd lib
root@SRV:/mnt/k/cycles-git/lib# ls -al
total 0
drwxrwxrwx 1 root root 512 Mar 24 19:07 .
drwxrwxrwx 1 root root 512 Mar 24 18:17 ..
drwxrwxrwx 1 root root 512 Mar 24 18:17 .svn
drwxrwxrwx 1 root root 512 Mar 24 18:45 darwin
drwxrwxrwx 1 root root 512 Mar 24 19:07 linux_centos7_x86_64
drwxrwxrwx 1 root root 512 Mar 24 18:30 resources
drwxrwxrwx 1 root root 512 Mar 24 18:29 tests
drwxrwxrwx 1 root root 512 Mar 24 19:14 win64_vc15
root@SRV:/mnt/k/cycles-git/lib# cd ../cycles
root@SRV:/mnt/k/cycles-git/cycles# make
mkdir -p bin-opt
cd bin-opt && cmake  -DCMAKE_BUILD_TYPE=Release ../ && make
-- The C compiler identification is GNU 9.3.0
-- The CXX compiler identification is GNU 9.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found OpenGL: /usr/lib/x86_64-linux-gnu/
-- Found GLUT: /usr/lib/x86_64-linux-gnu/
-- Found ZLIB: /mnt/k/cycles-git/lib/linux_centos7_x86_64/zlib/lib/libz.a (found version "1.2.11")
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Found OpenImageIO: /mnt/k/cycles-git/lib/linux_centos7_x86_64/openimageio/lib/libOpenImageIO.a
-- Found PugiXML: /mnt/k/cycles-git/lib/linux_centos7_x86_64/pugixml/lib/libpugixml.a
-- Found JPEG: /mnt/k/cycles-git/lib/linux_centos7_x86_64/jpeg/lib/libjpeg.a (found version "80")
-- Found OpenJPEG: /mnt/k/cycles-git/lib/linux_centos7_x86_64/openjpeg/lib/libopenjp2.a
-- Found TIFF: /mnt/k/cycles-git/lib/linux_centos7_x86_64/tiff/lib/libtiff.a (found version "4.1.0")
-- Found PNG: /mnt/k/cycles-git/lib/linux_centos7_x86_64/png/lib/libpng16.a (found version "1.6.37")

This should not happen if other libs are found. You can add some message statements to see whether the *_ROOT_DIR is correct and the lib exists at that location.

See _set_default(OPENIMAGEIO_ROOT_DIR "${_cycles_lib_dir}/openimageio") in src/cmake/external_libs.cmake

See if updating CMake helps.

Proposed a patch to fix that.