Trademarks: Studio & BrickLink are trademarks of the LEGO Group.

Disclaimer: This howto is provided as is, without any warranty.  My patches and sources are at least under the same licence as the sources they modify (so Apache 2.0 or (L)GPLv2 or more), and otherwise free to use and modify and re-distribute.

Building

Everything is done on the command line.  I didn’t try QtCreator or 😱 Visual Studio.

You first need to download Eyesight’s sources.  Go to Studio’s download page, scroll down a bit and expand the “Photorealistic renderer” section in the features, you want the last “here” link.  (Or click here but the link may die…)

Needed space:

Needed RAM:

Make a working directory

  1. mkdir BuildEyesight
    cd BuildEyesight
    export WORKING_DIR=`pwd`
    mkdir libs
    
  2. Install NVidia’s CUDA toolkit.
  3. Install the needed dependencies (mostly, Blender’s, except for ffmpeg and OpenCOLLADA that have modified versions for Eyesight, and except it’s Blender 2.79b, not the latest version).
    Sorry, it’ll be a painful process but I haven’t noted all that’s needed, especially as I already had some -dev packages installed. So, besides the list below, check the result of Eyesight’s ‘cmake’ step (its whining about OpenGL or AntTweakBar are of no consequence). For cmake errors / missing packages, you need to clean and restart cmake. For linking errors (at 99% completion of step ‘make’), you just need to restart make.
    In no particular order, on a Debian-based distribution, non-exhaustive:
    nvidia-cuda-toolkit
    build-essential
    cmake
    git
    git-lfs
    nasm
    python3
    libpython3.12-dev
    libboost-date-time-dev
    libboost-filesystem-dev
    libboost-regex-dev
    libboost-system-dev
    libboost-thread-dev
    libopenexr-dev
    libopenimageio-dev
    libsdl2-dev
    libx11-dev
    libxext-dev
    libxfixes-dev
    libxi-dev
    libxmu-dev
    libxrender-dev
    libxv-dev
    libxxf86vm-dev
    libasound-dev
    libbz2-dev
    libjpeg-dev
    liblzma-dev
    libpng-dev
    libpugixml-dev
    libsndio-dev
    libtiff-dev
    libxcb-dev
    libxcb-shape-dev
    libxcb-shm-dev
    libxcb-xfixes-dev
    libxcb-xv-dev
    libxml2-dev
    libz-dev
    libglut-dev
    libosd-dev
    libicu-dev
    libgl-dev
    libglew-dev
    libglu-dev
    
    Notes: not sure Python is even used but it’s still in the cmake file.

Every step below starts back in that ‘BuildEyesight’ directory.

It’s supposed that every file you download is placed in this directory too.  (Otherwise, adapt the commands.)

Download, extract, and (optional) gitify to be able to revert

(don’t forget to ’git add‘ / ‘git commit’ your successful changes)

cd "$WORKING_DIR"
7z x eyesight.zip
cd Eyesight
git init .
git add .
git commit -m "Official release"

Build (modified) AntTweakBar

cd "$WORKING_DIR"
cd libs
7z x ../Eyesight/libSrc/AntTweakBar-1.16-mod.zip
cd AntTweakBar/src
make
cd ../include
ln -s ../src/*.h .

Build (modified) OpenCOLLADA

cd "$WORKING_DIR"
cd libs
7z x ../Eyesight/libSrc/OpenCOLLADA-1.6.62-mod.zip

Edit OpenCOLLADA-1.6.62/CMakeLists.txt and add at line 168:

# Is an error now…
ADD_CHECK_CXX_COMPILER_FLAG(CXX_WARNINGS CXX_WARN_NO_DANGLING_REFERENCE -Wno-dangling-reference )

Update June 2025: OpenCOLLADA doesn’t compile any more with the system’s libpcre (too recent).  CMakeLists.txt needs to be edited to allow the use of the embedded copy in “externals” by commenting the test on line 264, like this:

	#if (WIN32 OR APPLE)
		message("WARNING: Native PCRE not found, taking PCRE from ./Externals")
		add_definitions(-DPCRE_STATIC)
		add_subdirectory(${EXTERNAL_LIBRARIES}/pcre)
		set(PCRE_INCLUDE_DIR ${libpcre_include_dirs})
		set(PCRE_LIBRARIES pcre)
	#else ()
	#	message("ERROR: PCRE not found, please install pcre library")
	#endif ()

Update June 2025: There’s also a couple files to edit to add “#include <cstdint>”, as indicated by gcc: DaeValidator.cpp & XmlDoc.cpp

mkdir OpenCOLLADA_build
cd OpenCOLLADA_build
cmake ../OpenCOLLADA-1.6.62

If there’s errors, it’ll be missing dependencies….

make
sudo make install

Files are installed in /usr/local, which should be okay… unless you also have your distribution’s OpenCOLLADA installed.

Build FFMPEG 4.4

Download the patch to allow to build FFMPEG with new ASM tools, and place it in your working directory.  (It’s a patch picked from more recent versions of FFMPEG.)

cd "$WORKING_DIR"
cd libs
git clone https://git.ffmpeg.org/ffmpeg.git
cd ffmpeg
git checkout n4.4
patch -p1 < ../../ffmpeg44_new_nasm.patch
./configure --prefix="$WORKING_DIR"/libs/ffmpeg_inst
make
make install

‘--prefix’ defines where the files will be installed.  We don’t want them in the system (we already have more modern versions there).

If there’s errors, it’ll be missing dependencies.  Install them and relaunch ‘make’.

Build Eyesight

Apply my patch

Download and edit the file 0001-Prepare-for-Linux-build-and-with-some-updated-libs.patch: search for “/home/sylvain” and replace the paths with your paths.  There’s one for AntTweakBar and one for FFMPEG.

cd "$WORKING_DIR"
cd Eyesight
patch -p1 < ../0001-Prepare-for-Linux-build-and-with-some-updated-libs.patch

What the patch does:

Build

cd "$WORKING_DIR"
mkdir build
cd build

Use the correct version of gcc/g++, the same as CUDA toolkit

export CC=/usr/bin/gcc-13
export CXX=/usr/bin/g++-13
(the correct version is pulled as a dependency when you install the toolkit).

Prepare the compilation:

cmake ../Eyesight/EyesightSrc

First small hack: cmake can find the .h but not the .a, go figure….

cd "$WORKING_DIR/build/lib"
ln -s ../../libs/ffmpeg_inst/lib/*.a .

Small hack: due to the other hacks, to not using cmake files for every dependency, and to other more obscure reasons, some dependencies are missing / wrong / out-of-order.  This file adds them… and maybe too many:

cd "$WORKING_DIR/build"
cp ../intern_cycles_app_CMakeFiles_eyesight.dir_link.txt intern/cycles/app/CMakeFiles/eyesight.dir/link.txt

Now we can compile:

make -j 8

‘8’ is the number of processing units (“cores”) to use.  Use ‘nproc’ to know how many you have.  (8 is half my nproc number, I wanted to continue using the PC.)

make install

Eyesight and all its files are in build/bin now.  You can move that bin directory elsewhere or rename it….  Only what’s in there is necessary for running Eyesight, you can archive all the rest.

Copy the .xml files from the latest Studio (otherwise, you’ll have missing colours):

cp "${WINEPREFIX:-~/.wine}"/drive_c/Program\ Files/Studio\ 2.0/PhotoRealisticRenderer/win/64/*.xml "$WORKING_DIR"/build/bin

WINEPREFIX is the directory for your Wine installation.  If you used the default, then it’s ~/.wine (and the command above works), otherwise, adapt the command!

Running Eyesight on Linux

Now you can run Eyesight from the command line.

Type ‘eyesight --help’ to get a list of options.

You’ll need to get COLLADA files from your models.  You have two options:

  1. Using Studio’s “Export to COLLADA” may work… but getting the options (windingorder, handedness…) right isn’t straightforward and, anyway, you’ll need to change the view/camera, because it’s inside the .dae 🤪
  2. “Intercept” the .dae file that Studio prepares for Eyesight when you use the Render feature in Studio.

How Studio works with Eyesight

We want to replace the Windows version of Eyesight with our native version.  But there’s a few problems:

  1. We need to convert the Windows filenames (C:\…) to Unix filenames (/…).
  2. It’s a native executable, it needs to be wrapped (called by) a shell script because Wine can’t execute it directly.
  3. In Wine, when a Windows program starts a native program (via ‘cmd’ and/or a shell script), it’s “fire and forget”: the Windows program can’t wait for the native program.

So, our option 2 earlier can be “makeshift” or “streamlined.”

Makeshift:

We replace Studio’s eyesight.exe with a script to get the parameters and launch our native Eyesight.

Because of problem 2 above, that means Studio thinks Eyesight didn’t succeed, so the result image won’t be moved to its final location.  So we need to do it ourself.

Good news: Studio is still waiting for Eyesight to finish, so the temporary files won’t be deleted until Studio is closed.

Bad news: rendering with the Queue does’t work, because, for Studio, the first job never finishes.

The script is eyesight_native_wrapper.exe.

How to

First, edit and modify the script to your environment:

cd "${WINEPREFIX:-~/.wine}"/drive_c/Program\ Files/Studio 2.0/PhotoRealisticRenderer/win/64
mv eyesight.exe eyesight_orig.exe
cp "$WORKING_DIR"/eyesight_native_wrapper.exe eyesight.exe
chmod +x eyesight.exe

See the note about WINEPREFIX above.

Streamlined

We need to replace Studio’s eyesight.exe with a proper Windows program that will start a script (we still need to go through a script for reasons 0 and 1 above), and then wait for the rendered image before quitting.

The needed program is eyesight_win_wrapper.cc.

The needed script is (still) eyesight_native_wrapper.exe.

How to

First, install mingw, that’s the package g++-mimgw-w64 or similar.

cd "${WINEPREFIX:-~/.wine}"/drive_c/Program\ Files/Studio 2.0/PhotoRealisticRenderer/win/64
mv eyesight.exe eyesight_orig.exe
cp "$WORKING_DIR"/eyesight_native_wrapper.exe .
chmod +x eyesight_native_wrapper.exe
x86_64-w64-mingw32-g++ -o eyesight_win_wrapper.exe -static "$WORKING_DIR"/eyesight_win_wrapper.cc
cp eyesight_win_wrapper.exe eyesight.exe

See the note about WINEPREFIX above.

Remaining problem(s)

Slight problem: Eyesight whines about not finding the images to fake scratches (textures/LEGO_ScratchTexture_[BS].JPG).  It loads them correctly when it loads settings.xml but complains when it loads C:\ProgramData\Studio\CustomColorSettings.xml (Studio always adds both files as parameters).  It seems the path changes when Linux version loads CustomColorSettings while it doesn’t change on the Windows version.  Both versions use the full path, so I’m not seeing what’s wrong in the code 🤔

Anyway, a very simple solution is to link the ‘textures’ folder in ‘C:\ProgramData\Studio\CustomColors\’ 😁

cd "${WINEPREFIX:-~/.wine}"/drive_c/ProgramData/Studio/CustomColors
ln -s "$WORKING_DIR"/build/bin/textures .

Animations: The wrapper is very simple and waits for the file as indicated in its arguments.  When doing animations, that’s not the result file.  So Eyesight does its work correctly and quits but the wrapper is still waiting.  The proper solution would be to parse the arguments more smartly and to wait for the correct file (animation or last .png).  My solution is to close the wrapper when Eyesight quits 😝