We can render fine from Max then we export the scene to be opened in Maxwell Studio for a pack & go so we can send to the rendering farm and the files opens OK but when we try to save or generate pack and go we receive a message that says: CANNOT WRITE FILE [Path].

When we launch the rendering from Maxwell Studio, Maxell render does not start and gives this error: ERROR MXS FILE DOES NOT EXIST, but the weired thing is that the rendering fires up in Maxwell Studio and start working, but as I said we cannot pack and go or save the file.

Please help, we are on a tight due date.
Is the path valid? Is it a local or network drive?
Try to change everything... The folder where you want to save, the name, the drive etc....
No need to tell you to restart MAX to see what happens... I am sure you did this already...
I remember having this silly behaviour but I can't remember what caused it and what I did to solve this...
User avatar
By Bubbaloo
I remember having this silly behaviour but I can't remember what caused it and what I did to solve this...
Me too!
It might have been a problem with multi-materials, but I thought it was solved in the latest release. Do you have the latest Max plugin? Maybe try to separate the objects with multi-material applied.
I haven't experienced this problem in a while.
By Mauro
Thanks for your replys. We are working from servers, not local machine. The files are on servers and all our libraries are on servers. We do have tons of multimaterials, can't go back and start separating everything. It works OK if I render internally, the problem is that to go with rendering farm we need the pack and go from Maxwell Studio.

We kind of find a work around: we do a resource collector from MAX that collect the majority of the maps and manually we go around looking for iors and other missing maps. Pain in the neck but for now is the only way we can move forward. Unfortunately we are under a major deadline and can't stop experimenting. Sometimes next week, when things calm down, we will go back and start looking at what is causing the issue. I'll keep you posted if I discovered what it is.
By Mauro
We are doing some testing this week and we discovered some interesting things. We built two scenes, one with a box with one multimaterial applied to different faces with different ID numbers and another one in which we created 6 different thin boxes that touch each other and look like the box in the first scene. WOW!!!!!!!!! No wonder why our scenes looked like crap and we were going crazy trying to tweak lighting and material in order to get good depth, reflection and shadows. The difference is amazing. One thing that I would suggest to all MAX users: stay away from using multimaterial and targeting different faces ID #s. Just build complete different geometry for each material and do not use multimaterial at all.
By Mauro
We are still trying a few things -- with some weired results. Actually, we did try a second time with a similar scene (not the exact same) and now we don't get a difference. We will keep testing for a while and see if we can get to the root of what is happening. I wonder if some of the machines have something corrupted....

As soon as we get more result I will post what we learn.
By Mauro
All right, I think we got to the root of all troubles...at least we hope.... :D

We have been working with several 3D models not built by us. We are just providing texturing/lighting. Everything just worked fine until we tried to open the MXS in Maxwell Studio and generate a pack and go to send to the rendering farm. We just could not save or pack and go the files. We spent some time this week and went through all components and try to eliminate components one at the time to see if anything in particular caused the issue. This is what we learned: We found in the models a few elements that had some vertices not connected, these elements were just single polys with different faces ID# and multimaterials applied to them. Basically:
Problematic vertices in a poly with different faces ID#s and use of multimaterials = Pack and go DID NOT work

We then tried the following:
1) Leave the not connected vertices as is and apply a single material to the poly = Pack&go OK
2) Leave the not connected vertices as is, detach the faces of all different materials (so it was not a single poly anymore) and use the original multimaterial = Pack&go OK
3) Remove the vertices that were problematic and leave all the rest as it was = Pack&go OK

To conclude: the issue that we had was due to a combination of inheriting a model with components set up as single poly that had extra vertices and try to use multimaterial targeting different faces ID#s.

The problem is that it would be a huge job to go around and double check all elements of these models and when you have team sharing models on big projects, I can see that possibly happening again. We have a sort of a script that check on extra vertices and removes them but I try not use it on big scenes because sometimes it messes up stuff and you don't really see it at the moment. Works OK for smaller scenes, where you can keep a close eye to results.

My question here is: Is there any way to have an error message that point to the element that is causing the issue? That would help to quickly look at those problematic components. Or, are we better off to just not use multimaterials, considering that with the single material the files just seemed to pack&go OK...

We also found the cause of the problems for the weird rendering artifacts: some of the components had a "double face", looks like the modeler created the poly then detached a face but then cap it again, leaving the extra face there. When we were rendering we were getting very weird results because the materials were sort of blending and show up every time in a slightly different way. Once we cleaned those faces everything went back to normal... :P
By Bogdan Coroi
If you can send me by email a simplified scene with the vertices issue, it would help us debug the Studio's Pack&Go. Thanks.
New podcast - CG Talks

Hi guys! We've just finished the first season of […]

Thanks, Luis, appreciated. It looks like industria[…]

That looks like a low bpc (bits per channel) norma[…]

Fully working plugin for C4D

When you will be working on it please try to keep […]