Building Blender on Windows 7 64 bit

Recently, I feel I’ve reached the point with my programming where I can begin to tackle bigger projects. So I took the first step on the road of becoming a Blender developer and built Blender from source. My experience quickly became a long and frustrating process, fraught with difficulties from the outset. To days post is going to focus on those problems and how, with help, I managed to overcome them.

I never thought that building Blender would be easy. But I didn’t think that it would be this difficult either. It took around a week of frustrated posts on the BA forums, trail and error, and guidance from my friend and programming sensei to finally get a stable build. The Blender docs give the basics of the steps required to build Blender. But building a large program is not always a straightforward task and there aren’t many resources covering what to do when things go wrong. This is not aimed as a comprehensive guide to building Blender, but an account of my experience building Blender for the first time. It’s not meant as a stand alone guide, but as something to read alongside the official documentation if you’re building on Windows. Hopefully there will be something useful in here that can help others who are experiencing difficulties getting Blender built-in a Windows environment.

I started out using TortoiseSvn as my SVN client, CMake as the build system and MS Visual Studio Express 2008 (VC9) as the compiler.

Even setting up TortoiseSvn was not without problems. It turns out that if you’re running Windows 7 you need to run the installer twice to get the context menus to appear. I have seen issues reported with other versions of windows as well and a second, or repair install is usually given as the fix. There are other SVN programs out there, but I’ve yet to try any of them.

I don’t have much to say about CMake other than I prefer it to Scons. It installed and ran first time (the only thing that did in this whole process!) and uses a simple GUI for setting up the build. It generates project files for many common IDE’s and auto-detects libraries and compilers. It’s easy to use and I’d recommend it to anyone doing their first build.

So, with the source code downloaded, I used CMake’s default settings to create the VC9 project files. I opened VC9, loaded the project files and hit compile. I got a load of warnings in the build log, particularly linker warnings, but none of them meant anything to me and the Blender .exe built fine. I opened up Blender and everything seemed to be going well.

Then as soon as I exited the game engine Blender would crash. No warnings, no error messages, just a straight-up hard crash. When trying to use Recast and Detour I kept getting messages in the console about recast not being able to generate a navmesh. Any attempt to change the steering actuators behaviour through Python produced an error saying that the steering actuator had no attribute called behaviour. All very strange, as it works perfectly in my 2.62 release copy of Blender.

I thought this could be something to do with the warnings I got while compiling, so I thought that a different compiler might resolve the issue. I tried to use MS Visual Studio Express 2010 (VC10) but that wouldn’t even compile. Finally, I tried using Visual Studio 2011 beta, but had problems just loading the project files. Finally, I tried MinGW, but the build just failed right at the end when I came to creating the final .exe.

I spent the day rebuilding Blender with each of the compilers, but by the end of day one I had gotten nowhere.

The next day I learnt that it is possible to get a 64 bit compiler for VC10 Express by downloading and installing the Windows 7.1 SDK, so I gave that I try. This time Blender successfully built. However, the same problems existed as when using VC9 32 bit. I had posted up on the BA forums asking for help, but it had yet to yield anything useful other than Windows being a difficult build environment and that I should use Linux.

The next few days were days of constantly recompiling with different compilers with the same results. I posted up dumps of build logs, but no one had anything to say about them. I tried googling the various errors and warnings that popped up. But google only returned my own build logs on Pastebin. I tried downloading a fresh copy of the repository and reinstalling all the compilers – sometimes a reinstall fixes things on Windows. After reading a forum post where someone overcame similar difficulties by switching to Scons I thought I’d give it a try.

Just setting it up was a pain. Scons requires that you have a 2.x version of Python equal to, or above 2.4. It will not work with Python 3.x So I grabbed Python 2.7 only to find that the Scons installer couldn’t find any copies of Python on my laptop. Odd, since I now have two versions of Python. What the documentation doesn’t tell you is that the Scons installer only looks for 32 bit installations of Python.  Even with Python 2.7 32 bit the installer still chucked up errors. The installer doesn’t check if it’s being run as a user or administrator, so unless it’s run as an administrator it will not install properly. Switching to Scons didn’t solve any of the problems anyway, so I quickly moved back to CMake. There are many other things I didn’t like about Scons and to be honest, I can’t see myself wanting to use it anytime soon.

The first breakthrough came from a post by Ideasman42 on the BA forums who suggested that I disable all the build options in CMake then try building with MinGW.  Blender actually built this time! But my joy was short-lived because as soon as I tried to run Blender it crashed complaining of Runtimes having to stop in an unusual way. So I started adding options back in one at a time until eventually I got a stable build of Blender with the following options:

CMAKE_GNUtoMS
WITH_BULLET
WITH_GAMEENGINE
WITH_PYTHON_INSTALL
WITH_SDL
WITH_IMAGE_OPENJPEG
WITH_OPENAL

I’ve also identified WITH_IMAGE_TIFF as an option that stops Blender from building on my system.

However, the problem with the steering actuator and recast still existed. The solution to this one came from my friend and programming guru, who pointed out that it’s because I’m using the latest version of the trunk – a working copy of the source code that’s not always stable. It turns out that a recent change in the trunk has caused recast and the steering actuator to break. I downloaded the 2.61 release version of the source code to find that while it compiled fine with MinGW and all my original problems were gone, but when I ran the BGE I’d be confronted with a grey screen. Moving to the 2.62 release version of the source seemed to fix everything!

I never got anywhere with getting a stable build with any version of Visual Studio. I don’t think I’ve found the right build options yet. Anyway, I’m happy using MinGW and now I can get involved with Blender’s development.

Advertisements

~ by Jay on March 22, 2012.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

 
%d bloggers like this: