Everything related to Maxwell network rendering systems.
I think I found a bug, but I'm not sure. Nothing shows up in the log referring to missing assets or anything like that, so I'm assuming this is a bug. If it's user error, I'd love to know what I did because I'm completely and utterly stumped by this one.

3ds Max Design 2015
3ds Max plugin 3.2.4

I have a scene the renders fine on my local machine (when rendered from 3ds Max), but when I export it and submit it to the network using the Maxwell Monitor, it comes out missing the floor and any GI related to the floor (which is basically a mirror). It doesn't matter if I send it to one machine or 10, it still misses the floor over the network. I've collected the scene using Pack N Go and have it available for password protected download (there are some images in there that are proprietary). Please PM me for login credentials. FYI, the file is about 360MB in size, so it's not gigantic. You may want to dial down the resolution though for testing. It's set to render a region, so if you do change the resolution, you'll also need to update the region in Maxwell Studio.

http://csimages.c-sgroup.com/external_f ... etwork.zip

I've included a screen print of each version so you can see the issue ahead of time.



Thanks Next Limit!
I just wanted to revisit this. I updated MR to and it appeared that the problem persisted. I found out what the issue was and it's a mix of user error and the way that Maxwell Render & its UI work (not to be confused with Maxwell Studio).

I was under a tight deadline when the problem appeared, so to reduce render time, I disabled 2 of the "Render Layers" through the 3ds Max Plugin within the "Render Layers" group, namely "Direct Caustics: Refraction" and "Indirect Caustics: Refraction". I assumed that since my scene had no transparent objects that refraction wouldn't be necessary to include. I also changed the "Render Type" under the "Render Channels" group to "Diffuse + Reflections". The combination of those settings removed the reflective appearance on some surfaces. In my original post, the surface was 100% reflective with a very slight blur. That's why it was solid black in my final render.

Here's the really weird part and where I got confused. Nowhere in the Maxwell Render interface does it open up controls similar to the "Render Layers" group in the 3ds Max plugin. I assumed that the "Channels -> Render Type" presets were various combinations of the "Render Layers" settings, but I'm sure that's not the case now. The documentation for MR only really discusses the "Channels -> Render Type" options:

http://support.nextlimit.com/display/mx ... er+channel

The only place I found documentation on the "Render Layers" was in the 3ds Max Plugin Docs, but it was very generic and didn't explain each option.

http://support.nextlimit.com/display/mx ... r+Settings

In short, the only way I was able to get the subtle reflections and glare that I needed was to set the Render Channels Type to "All". Even if I had all of the "Render Layers" enabled, I wouldn't get the reflections that I expected if I set the Type to anything except "All", even if I picked "Reflections + Refractions".

  • The "Render Layers" options should be reviewed to make sure they do what they say they do. If I disabled all but the Direct and Indirect Lighting, my render (which didn't have any caustics anyway) looked identical to one that had all 6 enabled. If I disabled those too so that none of the 6 were enabled, It appeared to render only the 1st bounce of light. I half expected it to render a black screen or report an error saying there was no light to compute.
  • The "Render Layers" group should be defined in the docs more specifically by listing exactly what each of the six layers is and an example of what would be on each layer.
  • The Channels -> Render Type parameter should be reviewed to make sure it does what it says it does. It's odd that I lost my reflections for every Type except "All".
I still think there's a bug somewhere, but my guess is that it's in the plugin and not the MR engine or application. I'll post a link back to this topic in the 3ds Max Plugins section.

Thanks Next Limit!
Ok, so I think I figured out where the bug is and I believe it's actually somewhere in the mxnetwork.exe program and has nothing to do with the 3ds Max plugin. If you start a network render and change the "Channels -> Render Type" option in the "Add Network Job Wizard", it appears to issue a parameter called "-layers" within the really long configuration string that's received by the nodes. I tested each option which corresponds to the below values:
  • All = -layers:0
  • Diffuse = -layers:1
  • Reflections = -layers:2
  • Refractions = -layers:3
  • Diffuse + Reflections = -layers:4
  • Reflections + Refractions = -layers:5
When I have -layers:0, it appears to render all of the channels into the main graphics buffer. When I have -layers:1, it appears to render only the Diffuse channel. When I set -layers from 2 to 5, it renders exactly like -layers:1.

I would imagine you guys have a conditional statement in your code that handles each of these options. Is it possible that when it was coded in the source, someone created condition 1 and then copy and pasted it to create the additional conditions from 2 to 5, but accidentally didn't change the resulting execution code so that it calls the MR engine the exact same way for -layers options 1 through 5? I've done similar things in PHP on accident, so that 's why I think this is the most likely possibility.

I hope this helps! Thanks Next Limit!
The "Render Layers" you referred to correspond to the Render Options > Illumination & Caustics parameters in Studio, which for some reason that I don't know, do not appear in the Render Options panel in the Maxwell Render UI. For that reason, they are not mentioned in the docs either, since the Render Options docs for Studio (here) just point to the ones for Maxwell Render (here). So, someone (who knows more about it than me) will need to go into the docs and rectify this oversight.

Regarding whether these things are physically working, I performed a test with, and the -layers:N command-line switch does appear to be working as intended; I checked the code, and it is read from the command line and converted directly from string to int using QString::toInt, so no possibility of a badly-coded switch. For the test itself, I used a simple scene to show the effect of the different channels; the output was as expected, and similar to the examples shown in the Render Channel docs (here):
  • Image
That's about all I can personally tell you about this; it's outside my scope to look into the render engine code dealing the Render Layers (i.e. Illumination & Caustics in Studio) options, and the Render Channels output, and tell you if every permutation of them is working as intended, but at least I can tell you that with the scene shown above, the -layers:N command-line switch does appear to be working correctly.
Thanks for the reply JD!

I upgraded the systems on our farm to and made a new test. I still get the same results when I queue up a cooperative network render through the wizard using the old network system (as opposed to the technology preview). When I render locally from 3ds Max to Maxwell, I get the results that would be expected. I haven't tried issuing the network render from the command line yet. The switch statement that I was presuming existed would actually have been somewhere in the logic of an active process of "mxnetwork.exe -node". But if you're saying that it interprets the configuration string from the manager simply by QString::toInt and then passes that directly to the engine, then you're right, a switch statement within the network tools (mxnetwork.exe) couldn't possibly be the culprit.

With that being said, and also that I haven't ever used Qt specifically but I do have some programming experience, the link to the toInt member function you sent me pointed something else out. That function appears to set 2 values. One is the return value and the other is the "ok" variable with a boolean value. According to a quick google search, the Qt framework uses C compilers, which can convert booleans to integers where false = 0 and true = 1. Is it possible that the wrong variable is being collected (ok vs the return)? I know it's a stretch because that would assume that layers:0 returns an ok = false, while layers:1 through layers:5 return an ok = true. It also doesn't explain how you can manually issue the render from the command line successfully. There are other formatting controls for QString::toInt that are toggled by the 1st value of the string and the specified (or implied) base value. Can you verify that the actual string value at a code level being passed to toInt is formatted correctly (doesn't have a space, colon, or other strange character)? The monitor and/or manager may be sending it slightly different than it reports in the log, which would explain why it works manually and locally but not from the wizard. Just some thoughts.

At any rate, here's the results I get:

Network renders via "Add Network Job Wizard":

Local renders from 3ds Max UI:

The Log output from one of the render nodes showing the setup configuration used on the 6 network renders shown above:
http://csimages.c-sgroup.com/external_f ... trings.pdf

Thanks again JD! I hope this helps (and that it's not just my overall setup :) )!

Try render region https://nextlimitsupport.atlass[…]

Let's talk about Maxwell 5.2

Is there any update regarding CPU engine ? Som[…]

Hello, I agree with Jasper ... I still have this […]

Squared looking surfaces while rendering

That's the typical "shadow terminator problem[…]