I am trying to build cycles standalone in Windows so I can use it with Freecad.
And I am a total noob in building on windows.
I got git working and use windows powershell to invoke the commands. I installed TortoiseSVN to pull it, then I tried to build it using the make command in Powershell, but I get an error for which I have no idea what do do with. I am following these instructions: Developer Portal - developer.blender.org
And I got this error (error 128):
Nobody? is this standalone version for windows dead? I mean if you cannot build it then who is using it?
I missed this topic.
From the error message it seems to be using some kind of make command from MingW, which I imagine is not going to work well in Powershell.
Probably it’s easiest to use the CMake GUI to create the build directory and configure the build, and then build in Visual Studio.
Looking at the FreeCAD integration, it seems more of an experimental feature though and I’m not sure it’s kept up to date with latest Cycles releases. There may be better options than using Cycles here.
Thanks for you reply!
There are no better options, every option is outdated. 
This probably doesn’t work either, but it’s annoying not to know!
Also blender is awesome so putting a piece of Blender in Freecad is cool!
I tried to use cmake gui but no success (no clue what I am doing…), is there any manual that I can follow?
Is there no option to upload binaries anywhere? I don’t need the latest build, juist one.
Hello,
If you may allow me a comment, as I am one of the developers for this FreeCAD feature (FreeCAD-render):
Yes, the feature is kept up to date with last Cycles release, as we don’t embed a particular version of Cycles: we rely on Cycles Standalone and we let the user build the executable on his/her own, from the latest sources.
What MisterMaker reports here is that Cycles Standalone build process seems presently a bit tricky (or maybe not completely working?) on Windows - although I can confirm it works fine on Linux and MacOS.
So, it would be great if someone in Cycles devs/maintainers could have a look at Cycles Standalone build process on Windows (I have personally no access to such a build platform…), and fix and/or document the tricky points!
Our users have other options for their rendering engine (LuxCore, Appleseed, Intel Osp-Ray, and we plan to extend the list), but Cycles is a very popular choice, so we would be much grateful to have your support for our Windows users…
Thanks!
So sorry that I said it was all outdated and broken 
I hope I can help to make it work on Windows!
Also windows users and compiling programs is a bad combo, this is probably why I am the first here to tell it doesn’t work anymore!
I’d say the cycles standalone repo is aimed at C++ developers at this moment in time, the XML style demo it ships with only scratches the surface of what cycles can do, I would not consider it as a stand- alone product. It has been suggested to retire the XML based demo, devs tend to start using it, after a little while they run into limitations and end up using the C++ API directly, wasting weeks if not months of development time on the XML based example. It’s best seen as an “hello world” rather than something ship to your users as is.
Building software of this size, IS tricky regardless of platform, over many years we have fine tuned the blender build scripts and documentation to account for the most common problems. The cycles standalone repo has more “rough edges” there and devs are somewhat expected to work those out on their own. We were not planning on having to support our end users on building it, let alone yours.
Had a quick look, builds out of the box with no issues, with one rather huge caveat : To make building easier we provide prebuilt versions of all libraries blender depends on in SVN. However… the cycles standalone repository usually gets updated when a blender release is done (With the last release being blender 2.92) so it will rarely work with the blender libraries we have in SVN for blender master.
If you want to currently build cycles standalone you’ll need to use the 2.92 libraries from here to successfully build. (this applies for all platforms btw, cycles standalone just cannot handle the ocio 2 libraries we have in svn master for all platforms)
It’s also worth noting (And this is the issue MisterMaker ran into) that by default windows ships without a compiler, you can install one, but by default it will not get added to the path, devs are expected to know to start a shortcut in the start menu Developer Command Prompt for VS 2019 to setup the compilers and the environment. Added complexity is make is not a thing for MSVC, if you’re unlucky and have mingw or some wonky git installer that included it, it may give the indication it might work (but it won’t for cycles) leading the user further in a direction where nothing good will happen.
What it comes down to, cycles is a tough cookie to build for developers, it’s a large piece of software, with lots of dependencies, there’s lots of things that can go wrong, asking your end users to build it seems “less than ideal” for all parties involved.
1 Like
Wow thanks for the extended answer!
So I might was a bit tricked by the easy looking “how to manual”
It’s not like typing in 6 commands ;).
I use blender a lot, and I know a lot of Freecad users use Blender a lot. If we can use the cycles stand alone render in Freecad. We can keep using the same materials. My workflow now is:
Freecad > export
Blender < Import
Blender > add materials
Blender > render
And now the issue with this workflow:
I want to modify something.
I do this in Freecad.
Then I have to somehow merge the modifications in Blender, either by just delete the outdated design and import the complete new design. Or manually place the modified mesh in the old design.
What would be ideal:
Add cycles materials light and camera in Freecad.
Import in Blender > use default world settings > press render.
Or just for a quick render, press render in Freecad.
You know lots of big CAD companies are making their own included render program, like key-shot and Photoview360. This works like the way I described, users of Keyshot do not use it because it is better than Blender they use it because it is integrated with their CAD software.
If Freecad and Blender can work together we have a very powerful package to counter this. So I hope that answers Blender user vs Freecad users.
@LazyDodo Thanks a lot for this extensive answer! I agree asking users to build Cycles Standalone on their own is not the easiest thing, but it works rather fine for MacOS and Linux (I even packaged something for Arch Linux).
You should not decry the XML interface, it is really more than an “Hello World” feature from our point of view. We were able to develop a very satisfying piece of code to export xml from FreeCAD to Cycles, exploit a good deal of its power while making the integration seamless for our users (once Cycles is installed…). Please note we have deliberately steered away from the C++ APIs of renderers (not only Cycles), as this is the type of interface that is difficult to maintain and not very adaptable. So,it is our dearest wish that you keep this valuable xml interface alive!
And finally, thank you for having taken time to test Windows build; I hope MisterMaker will take benefit from your indications.
How invested are you in the current incarnation of the XML API? In my experience working with it, I found it has certain limitations (such as only one shader per mesh - no per-triangle material indices). I wrote patches to work around that twice, and I’d be happy to make those available with the goal of merging them, but they’d be breaking compatibility.
In essence, Cycles has moved almost all of its internal data structures to a node/socket system. It is fairly easy to write XML from those nodes and to parse XML back into those node structures.
I encounter at least one issue that I consider a bug. I can’t believe, that this isn’t a problem on any platform:
The declaration in util_param.h:
static constexpr TypeDesc TypeFloatArray4(TypeDesc::FLOAT,
TypeDesc::SCALAR,
TypeDesc::NOSEMANTICS,
4);
is inproperly used in attribute.cpp (in a debug build) as
Attribute::Attribute(
ustring name, TypeDesc type, AttributeElement element, Geometry geom, AttributePrimitive prim)
: name(name), std(ATTR_STD_NONE), type(type), element(element), flags(0)
{
/ string and matrix not supported! */
assert(type == TypeDesc::TypeFloat || type == TypeDesc::TypeColor ||
type == TypeDesc::TypePoint || type == TypeDesc::TypeVector ||
type == TypeDesc::TypeNormal || type == TypeDesc::TypeMatrix || type == TypeFloat2 ||
type == TypeFloat4 || type == TypeRGBA);
where …Array… is missing and also in geometry.cpp in all build.
else if (type == TypeFloat4)
How can anybody compile that successfully?
The most problems as stated is however the use of many dependent libraries. Some of them can hardly be compiled on Windows. We have used Cycles in the recent years with a minimum set of libraries like OpenImageIO but didn’t update these libraries as it wasn’t necessary.
The recent checkins for the standalone Cycles broke most of the compatibility with those libraries.
As far as I understood, the reason was to get rid of some of the dependencies like boost and pthreads in favor of TBB. In general I would support such withdraw of using too many depending libraries as the benefit of such dependencies hardly pays out the cost of supporting the dependecy, but then it should properly be done and the depending libraries should be compileable on any platform.
I have to admit that the “modern way” of supporting configuration for different platforms with cmake is something I hardly have ever seen working on Windows with MS VisualStudio, so most of the configuration needs to be sorted out manually anyways.
I am willing to offer some support for sorting out some show-stoppers for compiling Cycles on Windows if we find a way to make this a long-term solution, so we don’t have to sort this out over and over again on each change in the original code.
Thomas
TypeFloat4 is defined by OpenImageIO, TypeFloatArray4 is something else. Maybe you are using an old OpenImageIO version.
We only add libraries for a particular reason, if we do consider it to have a significant benefit. Of course it depends on the use case, but we mainly think about Cycles as integrated in Blender.
Compiling all these library dependencies is indeed hard, but not sure what you mean by saying some libraries are not compilable. The easiest solution is of course to use the Blender precompiled libraries.
I’d be happy to see improvements to the Cycles standalone build system. I guess the simplest way to make the Windows build easier would be add similar scripts as for Blender. A make.bat that works on Windows, and a make update command that downloads the appropriate libraries branch to match the current code.
If TypeFloat4 is supposed to be from OpenImageIO I think it should be qualified with the struct TypeDesc:: qualifier, right?
I tried to use the latest OpenImagIO 2.2.12.0 and of course cmake didn’t work. I admit the author mentions something about not being checked for Windows…
But even after editing the oiioversion.h file manually, I couldn’t compile. There are includes of some …/fmt/iostream and others. I don’t know what this is supposed to come from, so I gave up…
I prefer creating Visual Studio solution (.sln) and project files. If you know how to deal with them it is not too difficult. You could then use these solution files with the batch devenv command. AFAIK there was an option to create (n)make files out of solution files, but I’m not sure if this is still available. But the solution files are a good deal, as you can use them in the Visual Studio GUI to edit and debug the code…
Not anymore in the latest OpenImageIO, the ones within the namespace have been deprecated. We should actually remove TypeDesc:: from all the other ones.
OpenImageIO does test Windows builds with continuous integration. But of course there could be an issue with some particular configuration or environment.
The Blender make.bat script generates .sln, so copying that behavior should be ok.
That’s why we provide them pre-built for developers, don’t get me wrong they are still hard to build but doing it this way settles just one person with that icky job of building them rather than every single developer.
for all blender developers this change was an svn update and they were up and running again, if you are determined to build all deps from source your self, yeah… I can imagine you will not have a super great time every time we do large library changes.
@StefanW
At the moment, we are able to export meshes, cameras, various lights (point, area, mesh, IBL, sun-sky) and a selection of shaders, notably including Principled and Glass (yet without textures, at this stage).
Indeed, we used the nodes/sockets structure to understand the expected xml syntax and write our exporter. It was quite easy, thanks to the node design and also to Cycles’ great code quality, I must say.
It makes it possible to render quickly a CAD model directly from FreeCAD (without swapping with Blender):
I am excited about the amount of work people has put in already! Is Only I could help out a bit…
If some one already has binaries files I can download, I can try it out write a tutorial and some example images!!
I’m not sure if this message should go into a now thread - anyway:
I have been able to configure, compile and link all depending libraries and cycles itself. Cycles at least starts correctly.
In our application I had to do some minor changes due to the changes since last summer, nothing difficult.
However our application crashes instantly when trying to add shaders to a mesh, actually when calling Mesh::get_used_shaders().
My colleague took the challenge to identify the problem. He found, that there is a problem with the static initialization of objects, namely Mesh (mesh.cpp:126) and Geometry (geometry.cpp:49).
The sequence of the call of static initializers in different compile units is not defined according to the C++ standard.
While in Cycles the sequence of these initializations is appropriate, i.e. first Geometry and then Mesh. In our application however, the sequence is the other way round, which we can not control.
This is a serious design flaw. I remember the warnings of Stroustrup in his C++ book to not use static initializers, rather than to do initialization explicitly by functions.
Is there anyone willing and able to fix that? I/we do not have enough insight into Cycles to do that quickly.
I think I should mention this here:
Realthunder who is working on the very promising Link3 branch of Freecad, has plans to incorporate better rendering in his build: