MoonRay for Windows Community Starting Points

[kjeffery]

Roadmap for MoonRay under Windows

MoonRay was developed under GNU/Linux without considering other operating systems. There is code written with only POSIX/GNU/Linux in mind, and we have yet to explore what it will take to make MoonRay work under other operating systems. Many required changes will not be found until porting is underway. However, I will list some things needing to be addressed and provide a project workflow. The existence of this document does not mean that the MoonRay team is porting to Windows; it only serves as a guide to the community on getting started.

Project Order

If you want to use a Linux process for rendering while displaying the results on a Windows machine (e.g., through Hydra), you can focus on porting the arras client. In that case, the MoonRay subprojects should be ported to Windows in this order (based on dependencies):

1. moonray_arras/mcrt_messages
2. moonray_arras/mcrt_dataio
3. hydra
4. moonray_arras/mcrt_computation

In order to build a native MoonRay renderer on Windows without support for distributed rendering (arras), the MoonRay subprojects should be addressed in this order (based on dependencies):

1. scene_rdl2
2. mcrt_denoise [optional]
3. moonray
4. moonray_gui [optional]
5. moonshine
6. moonshine_usd

To build the full stack, the dependency order is as follows:

1. moonray_arras/mcrt_messages
2. scene_rdl2
3. mcrt_denoise
4. moonray_arras/mcrt_dataio
5. hydra
6. moonray
7. moonray_arras/mcrt_computation
8. moonray_gui
9. moonshine
10. moonshine_usd

Packages

I have not tried it, but Microsoft’s vcpkg cross-platform package manager seems like a good starting point. Please be aware of the required version number on packages. Using a newer version than specified in the MoonRay build requirements will require further code changes. We welcome updated versions but are often bound by the studio’s use of the VFX Reference Platform.

Known POSIX/GNU/Linux-Specific Features

General

Any ASCII file reads and writes will probably have to be opened using the binary flag. This will force Windows to use the ‘\n’ line ending (compatible with Linux) instead of Window’s “\r\n” line ending.

Aligned Allocation

The aligned allocation calls must be changed. Below is an example of how to change the functions.

/*! aligned allocation */
inline void* alignedMalloc(size_t size, size_t align = CACHE_LINE_SIZE)
{
    // Alignment must be a multiple of sizeof(void*).
    // Since alignment must also be a power of two (checked below), everything
    // greater to or equal to sizeof(void*) is automatically a multiple of
    // sizeof(void*). E.g. if sizeof(void*) == (2*2*2), every following power
    // of two is a multiple of that number: 2*(2*2*2), 2*2*(2*2*2), ...
    MNRY_ASSERT(align >= sizeof(void*));

#if (defined(_POSIX_C_SOURCE) && _POSIX_C_SOURCE >= 200112L) || (defined(_XOPEN_SOURCE) && _XOPEN_SOURCE >= 600)
    void* memptr = nullptr;
#if defined(DEBUG)
    const int error =
#endif
        posix_memalign(&memptr, align, size);
#if defined(DEBUG)
    MNRY_ASSERT(error != EINVAL, "Alignment is not a power of two");
    MNRY_ASSERT(error != ENOMEM, "Insufficient memory");
    MNRY_ASSERT(error == 0, "Some unexpected error");
#endif
    return memptr;
#elif defined(_MSC_VER)
    return _aligned_malloc(size, align);
#endif
}

inline void alignedFree(const void* ptr)
{
#if defined(_MSC_VER)
    _aligned_free(const_cast<void*>(ptr));
#else
    free(const_cast<void*>(ptr));
#endif
}

ELF Files

We use the GNU command objcopy in several places to translate binary data into the ELF file format used on Unix/Linux operating systems. The most notable example is the precomputed sampling data. To use this on Windows, we need to do one of the following:

• Convert the binary data to a similar file format for Windows (where we have symbols to delineate the start and end of our binary data).
• Use the sampling framework’s already-present ability to read ASCII point data (containerFromFile), which must be generated again through the point-generation scripts.
• Write a simple function that will read the binary data directly at runtime.

Temporary Files

At times, MoonRay creates temporary files. We use Linux-specific commands to do so. If you are not bound to the VFX Reference Platform, using C++17's filesystem library may be a good option, although it only provides a temporary directory and not a temporary file.

[BrianHanke]

Thanks for the roadmap @kjeffery. Running MoonRay on Windows would be a dream come true. I'm not a professional developer by any means, but this sounds like a very large and complex task. I imagine it would take a team working for a long period of time to get it working. Am I off base about that? I'd be interested to hear from experienced devs about their views on this project.

[kjeffery]

It is potentially a large and complex task, but like many software engineering tasks, it's difficult to measure until you're in it. I'm very hesitant to speculate on how much effort it would require, especially since the team has done no investigation. One focused person could do the port.

There is good news, however:

• All of the tasks I mentioned above are easily remedied.
• MoonRay is constantly compiled with different compilers, so there shouldn't be anything too surprising as far as C++/ISPC goes. That said, while Visual Studio is a great compiler, it may be easiest to start with one of the compilers we already use: Clang, GCC, or ICC.
• I have not explicitly investigated this, but I do not think we are using any libraries that are unavailable on Windows.

[BrianHanke]

Very interesting, thanks!

[xXTR0YXx]

Will give it another try in this case. Tried it with Visual Studio 2022, but it's too new for some of the repositories like Boost. Still stuck at compiling some of the repos and tried to find and use a CMAKE version of them. For some, like Random123 there is none and I have to figure how to make it work on Windows

[BrianHanke]

@xXTR0YXx I was looking at building the no-Arras, no mrct-denoise, no moonray-gui version last night since my goal would just be to get it working in Houdini Solaris. I already have concerns about the dependencies for the first step, scene_rdl2. I checked them all out, some have Windows guides, some are available via vcpkg, others don't mention Windows at all. Plus there's the issue of which versions MoonRay needs... I've built Open RV with Boost, I think that uses VS 2015 or 2017.

[kjeffery]

I stumbled upon another Linux-specific area of code: https://github.com/dreamworksanimation/moonray/blob/release/lib/common/mcrt_util/ProcessStats.cc

We use the /proc file system to gather various statistics. The good news is that this can simply be a no-op until it's implemented correctly in Windows because it's not critical to MoonRay (just informational).

[heavyrain266]

Can be done through methods of Process* classes from winrt/Windows.System.Diagnostics.h (docs) or some older APIs like windows.h

I should be able to investigate it once I'm back from vacation in the second half of August.

[kjeffery]

That would be amazing, @heavyrain266 !

[threedslider]

I am an intermediate developer, thought I still learn a lot from programming I would like to port in Windows and better I will like to have to integrate in my 3D software called Blackdot that is inspired from Softimage XSI and it is an open source too :) .

But I would like to have more info from Hydra and RDL ? Where are their documentation about that ?

Because I love to MoonRay for production Renderer, so it looks like to Renderman or Lightwave Renderer all thing in VFX rendering from photorealistic to styled shading... If ever I integrate this MoonRay into in my Blackdot it will be the first to have using it ! It will be awesome really !!

Thanks all to the team from Dreamworks.

[jlanz]

We do have online documentation for rdl2_print and some of the other tools, but it looks like there are still some (like rdl2_convert) that do not yet have documentation other than running the command itself with the --help flag. I've created an issue in our docs repo to make sure we add links to where appropriate.

[threedslider]

Hi again,
I don't found the source codes in moonray_gui and render_profile_viewer ? Where are their source codes ? Especially I am on Windows, it is ok for MoonRay to me, I am stdudy this and I would like to port in Windows.

Thanks in advance for your help.

[kjeffery]

Hi @threedslider !

The logical code for moonray_gui lives here (it's shared with the moonray command-line tool):
https://github.com/dreamworksanimation/moonray/tree/release/lib/application

The interface code for moonray_gui lives here:
https://github.com/dreamworksanimation/moonray_gui/tree/release

The code for the profile viewer lives here:
https://github.com/dreamworksanimation/render_profile_viewer/tree/release

Both moonray_gui and the profile viewer require the Qt development library.

Good luck with your porting efforts! I encourage you to share incremental improvements so that others may benefit from and collaborate with your work.

[threedslider]

Hi @kjeffery :)

Ok understood and thank you for pointing at me to these links. A problem arise, when I push this Openmoonray source code in my remote repository, so it doesn't work, any tips or help from that ? I work in command line for Bash to github. Thanks.

Hint : I would like to put in src/rndr_moonray/openmoonray

[kjeffery]

You won't be able to push to the OpenMoonRay repository; you will have to fork the code.

If you're having trouble pulling, make sure that when you clone you're specifying --recurse-submodules.

[BrianHanke]

I'm going to start chipping away at this in my spare time. What I lack in dev experience I make up in persistence!

I figured I would tackle things in this order. I don't care about Arras or denoise.

scene_rdl2
moonray
moonray_gui
moonshine
moonshine_usd

Starting with scene_rdl2, it looks like all the dependencies are easily downloadable in the required versions. My first round of questions:

1. Boost, Lua and TBB have prebuilt Windows binaries in the correct versions. Would these work?
2. What version of OpenSSL is required?

[kjeffery]

1. I have every reason to believe those would work. You need the development headers as well.
2. I do not see anything specific to any version of OpenSSL.

[NeedsMoar]

Boost has a full config system Windows that allows auto-building only the libraries needed once (the first time you build a project) and IIRC is integrated fully with CMake, so it's a fast build. That would likely be preferable to using pre-built binaries since boost keeps their most widely used libraries very stable at the API level but pushes bugfixes in nearly every release... Since half of the people working on it tend to be C++ committee members nothing really gets deprecated unless the feature is in a ratified C++ revision and supported by the major compilers. If some of the functionality didn't make it into the standard they'll usually keep it around anyway to avoid breaking people.

[kjeffery]

Here's another section of code that may cause trouble: https://github.com/dreamworksanimation/moonray/blob/release/lib/common/mcrt_util/Atomic.h

We use a lot of GCC intrinsic functions for atomic operations. The portable solution is to move to std::atomic, but that would require a lot of work with potential performance implications. The easiest solution is to use Windows intrinsic functions if there are comparable functions. If there aren't, a stop-gap solution is to use static mutexes within the functions, which will be very bad for performance.

[heavyrain266]

Hmm, I think this Pull Reuqest with Windows port of DNEG's xSTUDIO review tool may be helpful as reference (also Apache 2.0).

I mention this as they had similar Linux specific and GCC specific intristics in the code. MoonRay itself is much easier to port so far, because of Qt being optional component, where Qt on Windows is not any nice to work with, and sometimes causes issues, especially when you're porting Linux specific code.

[heavyrain266]

A little progress update from me: I was able to succesfully build MoonRay using MinGW (GCC for Windows) + MSYS2 but XPU mode doesn't work too well with 4gb of VRAM in my Nvidia GTX 1650ti...

Once I finish some small scene for testing endering, I will head over to MSVC + vcpkg with native intristics instead. Next step in testing the port is hdMoonRay in Nuke.

[shotalot]

Hey, did you modify the install_packages bash script to use packman packages or did you land up installing them manually?

[heavyrain266]

I build them manually, and I'm not a fan of package managers really.

[shotalot]

Thanks! Fun experiment, dont see this working for houdini builds though

[heavyrain266]

I was using it with Blender and Katana for a while, but the project was canceled. Current structure with lots of submodules makes it rather hard to properly contribute all my patches back to MoonRay.

[threedslider]

@heavyrain266 : Yes I ask why they make this so as separate for submodules, it is quite hard to patch them as well as you say :/
I love MoonRay but we need to port in Windows properly and attract a lot of user base too (?) !
I have an idea maybe we need to remove all git and make in one source for all files without separate, good or bad thing ? For change we use KDiff3 as internal for patch, that make to work good. Hope that help in something.

[xXTR0YXx]

So we are close to the first year after making MOONRAY open to public and beside a handful enthusiasts trying to make it run under LINUX or docker environments there wasn't much happening in terms of gaining track on a wider audience. At least that's the impression that I have.

Wondering what the current resume of going open-source is. Is everything running as expected and planned?

As far as I remember part of the plan was to get hands on more artists that are confident using Moonray, but haven't run into ANY rendered image using MOONRAY outside the demo-scenes, no matter what platform

[BrianHanke]

I gave up on MoonRay. I like the renderer, I like the look and I love that it's open source.

But it's way too limited as is. Linux only, Houdini only... For wider adoption MoonRay needs to work on Windows and it needs to exist in a non-Hydra version. In theory, there's nothing stopping anybody with the necessary skills from making that happen, the code is all there, but practically speaking it requires a genius programmer and would probably take years even then.

It's disappointing, but also understandable. MoonRay was built for a very specific pipeline and there's no reason to expect it to work outside of that.

[rgwilson68]

Thank you for the comments!

Some observations, and maybe new information ...

We obviously want as many people as possible benefit from the Open MoonRay releases, but we are not expecting rapid wide adoption, certainly not within a year. As more people use and contribute to developing and supporting MoonRay, it will become more attractive and, if it is useful, bring in more contributors. We're still near the beginning of the curve, where contribution is more difficult. We're grateful to the people who have tried MoonRay and posted their experience or advised others, even at this stage.

MoonRay is under continual development, in terms of new features : every feature we add for our in-house production goes into the next open source release. We have limited resources to port or support additional platforms, but I think there is still significant progress in that area. Apple has contributed a port to Mac, which is working and showing good performance numbers on Apple hardware. We need to complete merging of this code, but the Mac version should not be far away.

Porting to Windows is a larger task. MoonRay builds quite easily in Windows Subsystem for Linux (WSL). This allows you to run a command-line render on Windows, but not to integrate with a native Windows app (through Hydra, for example). However, Arras also allows MoonRay clients to use a backend render process on a different platform. If the Hydra client code is ported to Windows, then it can run inside a native Windows application and use a backend render process in WSL. We have a prototype Windows port that supports this, but there is more work to make it releasable, so it will likely arrive some time after the Mac version. I think this approach will work for most people who want to run MoonRay on Windows. If someone does want to take on a full port, we already know quite a lot about what needs to be done...

We think that Hydra offers the best way of supporting multiple different DCCs. I believe Maya and Nuke already support it, as well as Houdini, and Blender support is coming. The Hydra system itself is still at a fairly early stage : we expect more DCCs to support it over time. DCCs may also supply better support for building compatible Hydra plugins -- for example, Houdini doesn't currently supply a CMake config for their custom USD libraries, but may well add this in the future.

Unfortunately we are not able to supply pre-built binaries (or installers) of MoonRay for specific platforms, but I believe someone else could build and distribute them within the terms of the license.

Regarding OSL, OpenPBR, MaterialX and so on : MoonRay is designed to be a render engine that can work with technologies like these. We may add support ourselves for some of these in the future, when the technology is suitable for adoption by DWA production. Otherwise, we can certainly provide advice on how to integrate them with MoonRay.

[xXTR0YXx]

I am having a hard time understanding the open-source community at all. I mean it's neat that companies are providing their source code, but it's the same like xSTUDIO from DNEG. You have to assemble everything from scratch and first have to download and search for all the repositories. I can see that some TD and tech guys see this as an asset or a feature. Me not so much and I think a lot of the people aimed to actual use the programs in the future not so much. Maybe that's intentional. It has nothing to do with users being lazy to compile the programs. Some like me are simply not capable or lack the knowledge of using cmake and other tools used in software development. I am an artist. Not a technician. I am a user and not an engineer. These are two complete different type of people and users. I just got rid of 200 GB of programs and code snippets and dozens of applications I had to install to try to compile MOONRAY for windows and leave this task to more skilled people somewhere in the distant future.

[heavyrain266]

Problem with pre-built binaries is not only potential issues with safety and security risk, but also the fact that many tools have various compile-time options to choose from (applies to MoonRay, it's dependencies and xstudio as well).

I assume that you don't know why the software used by film industry is desigmed for Limux and doesn't really work on Windows or Macs. Historically, studios never really used Windows or Apple's machines, they were using IRIX, then switched to Linux few years ago (IRIX was discontinued in 2017). They're using Linux not only on servers but also workstations for privacy reasons.

[xXTR0YXx]

Yet still 95% and more of the userbase of 3D software in general is running under Windows these days. Single artists, smaller studios, freelancers.

Initially studios used IRIX and Solaris since also their SGI workstations were way more performant than their x86 equivalent in that time.
So I guess that was more the main reason since the Internet was not established to such an extend like it was today and privacy and data-security were less of an issue. Switching over to LINUX was easier for them, since the code-base was similar and the infrastructure already set-up.

In the end it's about which market you aim for with your software. What are your goals for going open-source with your software and what are you expecting from the community to contribute to the code.

[boberfly]

Hi all I'm almost done with a scene_rdl2 port here for windows MSVC build. I've made implementations with C++17 where possible, before needing to use Windows/NT-specific implementations. Having the macOS changes in-place makes this a bit easier due to things like the alternative ISPC CMake building approach.

The port required some of the following:

• Log4Cplus wchar (UTF-16/8) abstractions brought in with appropriate conversions
• DSO loading with abstractions
• AtomicFloat implementation without needing C++20 (wrappers around the GCC built-in functions to what MS STL's atomic would use)
• std::filesystem/std::chrono use instead of posix functions
• Floating-point exception-handling (needs testing)
• Endian conversion abstractions
• Winsock2 porting over from sockets (needs testing)

It's quite extensive so I think perhaps to upstream it, it's best to split it like the following - prioritising changes that affect the existing platforms:

1. Merge in CMake changes to openmoonray, cmake_modules and scene_rdl2 and verify it doesn't break Linux/macOS builds eg. MSVC/ISPC compiler support
2. Merge in C++17 implementations and refactors of the code that would affect Linux/macOS builds eg. <filesystem> for dirname/basename/scandir re-implementations, <chrono> for gettimeofday/usleep replacements, some macros/defines that conflict with windows ones, attributeKey symbol exporting/DSO loading abstraction, etc. - I can test on Rocky8/9 but not on CentOS7/macOS so I'll need help here
3. Merge in Windows-specific implementations and verify that the unit tests are passing, or skip the ones which can't be done eg. ShmFootmark

A preview with the commits in this rough order:
https://github.com/boberfly/openmoonray_cmake_modules/tree/windows
https://github.com/boberfly/openmoonray_scene_rdl2/tree/windows

Some questions I have that I am not too sure what to do:

1. Extracting symbols via objcopy/xxd - I'll leave this for now as scene_rdl2 doesn't need it, but can xxd be used here on windows too?
2. variableLengthEncodingSize for CacheUtil, MSVC doesn't know what to do with floats/doubles in the unit-test and figure out what function to use, do these cast into uint32_t/uint64_t ? I am not too familiar on how this works exactly but the unit tests are failing

After scene_rdl2 I'll probably tackle moonray itself and hydra after, and leave the arras stuff until last or for someone else to have fun with. Going through these I'm sure scene_rdl2 would probably need tweaks for unforeseen issues.

Cheers!

[BrianHanke]

Whoa, amazing work Alex!

[rgwilson68]

Very exciting ... good work!