First Windows build attempt observations

[BrianHanke]

I started chipping away at seeing what might be involved in building MoonRay on Windows. Initial observations:

1. Ran into trouble using an Azure VM for the build as a result of Hyper-V/WSL something something with Docker. Tried a few fixes but no go.
2. Moving on to building locally, things generally work VERY smoothly with Docker up until a point.
3. That point is the relative pathing of include files. I assume this has something to do with a Linux file system not quite being transferrable to Windows (symlinks maybe?). I found a workaround by changing the pathing in the source files, but that's a giant pain and eventually I ran into a path problem that wasn't fixable in the same way. Gave up there.

I assume that building "on Windows" but with a Linux Docker just yields a Linux build of MoonRay anyway? My goal would be to get MoonRay working in Houdini Solaris on Windows. I don't care about the Qt5 MoonRay executables as I assume those aren't needed for hdMoonRay.

I guess this leaves me with a few questions for people smarter than me:

1. Building on Linux and just plopping hdMoonRay into my Windows Houdini wouldn't work, right?
2. If not, then a specific Windows build would be needed. Anybody have ideas what that would entail? Definitely needs a fix for paths. What about the Optix headers? Are the Linux and Windows ones interchangeable with no code changes? What else might be an issue? Just trying to get a sense of just how complicated this might be.

Thanks!

[luxaritas]

Building hdMoonRay on Linux would result in a Linux .so library, which is not something Windows can run. My assessment with my relatively limited knowledge here is that the minimum requirement for integrating with a DCC on Windows would be to get hdMoonray (and its dependencies) compiling natively on Windows, and letting Moonray itself run in a container, treating that container as a "remote" Arras node. That said, hdMoonray seems to have Moonray itself as a dependency, so you probably need to get the whole thing compiling on Windows anyways (and I imagine relying on arras local mode would be more efficient, so regardless that'd be the end goal)

[BrianHanke]

@luxaritas Great insights, thanks!

[rgwilson68]

My assessment with my relatively limited knowledge here is that the minimum requirement for integrating with a DCC on Windows would be to get hdMoonray (and its dependencies) compiling natively on Windows, and letting Moonray itself run in a container, treating that container as a "remote" Arras node. That said, hdMoonray seems to have Moonray itself as a dependency, so you probably need to get the whole thing compiling on Windows anyways (and I imagine relying on arras local mode would be more efficient, so regardless that'd be the end goal)

That's exactly right. hdMoonRay depends on MoonRay directly to support "debug mode", which runs moonray in-process rather than using Arras. It would be quite easy to remove this mode for a Windows build, leaving hdMoonray dependent on a much more limited set of libraries. We have implemented Arras clients on Windows and other non-Linux systems in the past : unfortunately this code has not been maintained, but it is definitely possible. Most of the issues are relatively minor differences in socket support.

Arras local mode is more efficient mainly because it can start the render process in a more direct way, and uses a UNIX domain socket to talk to it. I'm not sure what the performance characteristics of a network socket between native Windows code and a Linux container would be, or whether there is a more efficient option for this case...

[luxaritas]

Are the communication protocols identical between the local and remote Arras mode? I had assumed (presumably incorrectly, not having looked at Arras in more than passing detail) that remote uses HTTP but local just transferred the data directly without sockets at all.

[rgwilson68]

The protocols are the same, local mode uses an IPC socket, remote uses TCP/IP. I've thought about implementing a shared memory transport but (a) this is not necessarily a major performance bottleneck and (b) I'm not sure that I wouldn't end up implementing something quite close to the implementation of IPC sockets anyway...

[kjeffery]

Hi @BrianHanke !

I assume this has something to do with a Linux file system not quite being transferrable to Windows (symlinks maybe?)

The MoonRay source directory does have a few symlinks, so you are right about that. Aside from Windows Shortcuts, Windows does offer its version of symlinks, but we have yet to try building under Windows.

@luxaritas is correct about the Linux library not working on Windows. You could cross-compile, but that does not buy you anything you wouldn't get from compiling on Windows directly.