This paper presents MoonRay, a high performance production rendering architecture using Monte Carlo path tracing developed at DreamWorks Animation. MoonRay is the first production path tracer, to our knowledge, designed to fully leverage Single Instruction/Multiple Data (SIMD) vector units throughout. To achieve high SIMD efficiency, we employ Embree for tracing rays and vectorize the remaining compute intensive components of the renderer: the integrator, the shading system and shaders, and the texturing engine. Queuing is used to help keep all vector lanes full and improve data coherency. We use the ISPC programming language to achieve improved performance across SSE, AVX/AVX2 and AVX512 instruction sets. Our system includes two functionally equivalent uni-directional CPU path tracing implementations: a C++ scalar depth-first version and an ISPC vectorized breadth-first wavefront version. Using side by side performance comparisons on complex production scenes and assets we show our vectorized architecture, running on AVX2, delivers between a 1.3Ă— to 2.3Ă— speed-up in overall render time, and up to 3Ă—, 6Ă—, and 4Ă—, speed-ups within the integration, shading, and texturing components, respectively.
I thought there would be a website for a newly available render engine (instead, we get a paper about a specific programming technique for the engine used by Dreamworks with little information about anything else).
Without much info, there’s not much regarding Moonray that we can talk about.
It’s their proprietary rendering engine, and one they apparently have no desire to make available to third parties so why would they create a website for it?
They have written a publication detailing their research, just like what you would expect coming out of universities. Adding in the source code or even a working executable is actually uncommon.
We can debate whether that’s a good way to go about things (it isn’t), but it’s standard procedure.
It is standard practice because it has nothing to do with end users or even immediate implications for development. And it is the best way to do things in a scientific community where you want to a) share information (for the greater good with others) that you do not intend to patent b) be acknowledged for having invented it or developed the concepts c) prevent others from staking a claim on your inventions or ideas (copyright or otherwise) and finally legally, d) preventing anyone from developing a patent on this technology (by having stolen the ideas some way or even by coincidently having developed it simultaneously), and thus preventing you or others from moving forward with producing products from the patented technology.
In patent law you can not patent anything that has been described publically, or published in some way.
The antithesis to this is what Joe Alter did with his hair technology. He kept quiet, and made a patent. This gave him legal grounds to come after other similar technology. I don’t believe he ever won anything in court. But he did sue and he did get a pay off out of court, if memory serves. This is his right of course. And more power to him.
But it is not how these large studios, Pixar/Disney, DreamWorks and others think.
They have always looked at this as open scientific discovery. The very technology we use in 3D was developed exactly like this. Papers started coming out in the late seventies.
Subdivision Surface technology started out as a white paper. And eventually developed into Catmull Clarke we have today, which is currently open source.
But it does not have to be open source to satisfy the legal requirements to keep information flowing, exchanging ideas and removes the option for a Joe Alter to pop up and sue you later over a patent. 
So that is why white papers happen. Every year. Been this way since the start. And it has given us what we have now.
2 Likes
Obviously Intel would have an advantage here because of its AVX-512 registers… But then again CUDA and OpenCL often have the advantage because of their thousands of cores and we see a lot more render engines built to run on the latter rather than built to use Vector units of CPUs.
Now, we can talk about it. 
Here is the link
They are preparing the files and release it soon on GitHub.
And this is the announcement
DreamWorks intends to make MoonRay available under the Apache 2.0 license. Further
information and updates will be available at OpenMoonRay.org
1 Like
I’ve already started working on an addon to implement it into Blender. Hopefully it’ll be easy enough to hook things up in a similar way to RenderManForBlender and BlendLuxCore.
12 Likes
Wow great, thanks for that!
Hi, I have received some complaints (Brian Savery & Ian Hsieh 謝文彥), about that you have used codes made by others, from the source of the add-on code, for RenderMan, you should probably avoid such use, but at least try to do that little extra effort to make adjustments in such a way as to make it original in part.
This might be a good way to do things, and you could recive an help for this add-on by asking to them, and you gain experience and grow as a developer.
Greetings
Ah yea I have based most of the addon from RenderManForBlender and BlendLuxCore. The licenses for both of the addons allow me to use and modify the code without legal repercussions so I assumed it was alright.
I’ll make some changes to avoid future copy complaints, but I’ll probably end up changing most of the code once the actual source for MoonRay is released.
I should probably edit a few things to make sure I’m in agreement with the licenses.
Thanks for the heads up, and give my apologies to Brian & Ian 
Please, note, I’m not complaining that you’re using parts of the code from RenderMan for Blender (in fact, I feel honored that you would use the code as a starting point). But, you really should attribute where the code is coming from.
RenderMan for Blender isn’t really home grown, either. If you look at our github page, our README acknowledges who the original author is i.e.: Matt Ebb. The repo is also a fork off of Matt’s repo. I believe Brian even went the extra step and contacted Matt to get his permission to release it.
I don’t know how the LuxCore folks feel, but looking at their license I believe it says that you have to keep their license and copyright notice if you’re using their code (I’m not a lawyer).
3 Likes
Yea I just finished changing the code and licenses. I’m not sure If I credited RenderManForBlender and BlendLuxCore properly in the README.md, but other than that I think it should all be ok now.
What is the complaint? People use code made by others all the time when such licenses permits, as far as I know the MIT license is a liberal one. They need to be clear about their complaint. Is there an intellectual property issue here?
Are you just creating a template add-on for now?
Yes. Right now it’s just setting up nodes and creating UI panels. Can’t really do anything big until the source is released.
2 Likes
From a previous Pixar developer bsavery:
he should cite the original authors when copying code first. Open source doesn’t mean steal code without attribution.
And the main developer has already answered, on a previous comments
So that is.
Greetings
1 Like
Was more a comment than a complaint. Happy to see more rendering addons!
Btw as a side note it should be clear from this that many rendering addons for blender are doing basically the same thing. Seems silly to duplicate the code many places. That’s why I’m pushing for Hydra support in blender to make this process easier
Anyway happy to see what moonray brings and I’m sure Ian and I mightcomment on the plugin
5 Likes
Yooooo, the just made it open source!