[javigon]

I do the job in cinema on Mac. to do a render with the manager in another computer (windows) or to send to an external renderfarm.
The purpose of the Pack and go is to collect all dependencies?
When a want to create a new render in the monitor (windows) he ask me for this dependency, because the path is not the same or because the computer is in another location.

[javigon]

In Maxwell 2.5 and earlier versions, the linked mxm was put inside the mxs because Maxwell Studio can´t manage linked mxm, but in Maxwell 2.6 Studio can manage this.
When I pack and go any scene now from cinema and open it in Studio, the mxm is linked as is in Cinema. The problem is that the pack and go puts in the "textures" folder all dependencies used in the scene but no the mxm.

I don´t know if I´m explaining well. Sorry if you don´t understand me.

[JDHill]

I do the job in cinema on Mac. to do a render with the manager in another computer (windows) or to send to an external renderfarm. The purpose of the Pack and go is to collect all dependencies?

Well, yes and no. For textures and such, I understand it, because they cannot be embedded; the the concept of referenced MXMs, though, is inherently contrary to the idea. I will just walk through my thinking on this. Say that you have an MXM file on a network drive:

• \\office\materials\external.mxm

And some Cinema files on your machine:

• c:\jobs\job1\doc.c4d
• c:\jobs\job2\doc.c4d
• c:\jobs\job3\doc.c4d

Say that each Cinema doc contains a material which links to \\office\materials\external.mxm. The only reason for doing that is so that by editing external.mxm, you are able to change how all three Cinema documents render. Now let's say that you export MXS files, with pack & go enabled, from each Cinema document, to these locations:

• c:\jobs\job1\doc.mxs
• c:\jobs\job2\doc.mxs
• c:\jobs\job3\doc.mxs

The materials in each MXS will also reference \\office\materials\external.mxm, and purpose of the referenced MXM workflow is maintained. However, if pack and go considered linked MXM files, those materials would refer to these new MXM files:

• c:\jobs\job1\textures\external.mxm
• c:\jobs\job2\textures\external.mxm
• c:\jobs\job3\textures\external.mxm

For each of these copies, there is only one MXS which references it. In other words, the MXM files are unnecessary, and external.mxm should have been embedded, rather than linked, in the first place. The same logic cannot be applied to textures, because they cannot be embedded.

I can see a compromise, though: copy MXM files to the /textures folder, but do not change the materials in the MXS to point to the copies. The point of doing that would be:

• If referenced MXMs can be found at their correct locations, they will be used.
• If not, Maxwell/Studio/Network will search the /textures folder and use the copies.

I am not sure whether Maxwell/Studio/Network work this way or not, though.

Let me know your thoughts.

[javigon]

Ok. I agree with this workflow if in this workflow all machines are Mac or PC, but not in the case to mix, for example mac to work and windows to render, because the network part are not the same in mac or windows.
For example:
in the work machine were I do the scene in cinema, the linked material path are:
/volumes/materials/material.mxm
If I render always in mac, the path are the same. So there´s no problem.
If I render in windows, the pats must be:
//server/materials/material.mxm
So the maxwell monitor don´t find the mxm with the mac path and the render can't continue.
In the case I send to an external render farm, this will be the same problem.

That I would want to get is what Maxwell in Cinema was doing until 2.6: all linked materials will be embedded. The problem is that now these linked materials are not embedded and I have to look manually each one.

[JDHill]

I think that what you would want to do is to un-link your materials in Cinema, before exporting the MXS for rendering on another machine. Just open an Attribute Manager, select all of your linked Maxwell materials, and un-check the "Link to:" box.

Basically, if you want embedded materials in your MXS, you should be using embedded materials in Cinema, and vice-versa.

[javigon]

Ok, I understand. This is a logical way.
My problem was when always use linked materials and Maxwell until now always embebed all. Now this changes, so I have to change my workflow.
Thanks for your patience

[JDHill]

No worries -- you may also want to be aware of Preferences > Maxwell > Enable MXM Linking when MXM files are imported, which controls how materials are initially created in the plugin. Meanwhile, I am testing the method I mentioned before (copying MXMs, but not changing the paths of references).

[jwiede]

I can see a compromise, though: copy MXM files to the /textures folder, but do not change the materials in the MXS to point to the copies. The point of doing that would be:

• If referenced MXMs can be found at their correct locations, they will be used.
• If not, Maxwell/Studio/Network will search the /textures folder and use the copies.

I am not sure whether Maxwell/Studio/Network work this way or not, though.

Let me know your thoughts.

Under the circumstances, I agree you shouldn't arbitrarily break external linkages just because Pack&Go is selected, esp. since the change induced (switching from a single, global reference to locally-embedded ones) would effectively be "invisible", and could thus create difficult-to-detect/debug scene problems down the road. Putting a copy locally that'd be available is a reasonable fallback solution, though ideally there'd be some indication the fallback had occurred. Will Maxwell log a warning in such cases? If not, perhaps it should.

BTW, really impressed with 2.6 all around, thanks for all the hard work!

[JDHill]

What I find so far is that the network system will not find the MXM copies, unless the Pack & Go textures folder is explicitly set as the dependencies path in the network job. So that should be sufficient indication of what is going on. I'd guess that path could also be set automatically in the future -- in either case, though, path fix-ups are recorded in the render log, as usual.

[RK_art]

I also would kindly beg (like Aniki already did) for a native RealFlow-Particles / Grid-Meshes etc support within the C4D-Maxwell Plugin as it is integrated in Maxwell studio right now. Working over the RealFlow-plugin is real pain as the Thinking-particles-system is a waste of time and ressources. It doesn't work even with Vray right now flawless. Maxwell 2.6 has itself a by far much, much better integration of handling RealFlow data than the Realflow-Plugin will ever provide via this useless thinking-particles step.
So it would be logical to use maxwell's procedures out of C4D via the Maxwell-plugin.

[JDHill]

To begin with, the Maxwell for Cinema plugin will read objects (i.e. RF Mesh Importer, RF Particle Importer, RF SD Animation) created by the RF Cinema plugin. During export, these will be written as extension objects (i.e. Studio > Objects > right-click > Create Extension Object); meshes created for Cinema by the RF Cinema plugin will be ignored.

I happen to be working on this as we speak.

[RK_art]

Thanks JD.

As I saw now, there is this RFK-feature already available for Maya-users:

http://support.nextlimit.com/display/ma ... +RenderKit

[Aniki]

meshes created for Cinema by the RF Cinema plugin will be ignored.

I happen to be working on this as we speak.

Please make this an optional choice;)

Great to see there is progress on the matter though;)

[JDHill]

Can you provide a compelling use case for such an option?

[Aniki]

Just the case when I want to render the meshes I built and exported out of realflow;)