[zoppo]

Continuing my monologue:

I installed 3.0.0.3 on all machines.

This time I started the Manager on one of the Nodes.

All Nodes connected with it, including the one one my Work Station.

I started the Monitor on my Work Station and created an "Animation Job".
This job was exported from Cinema4D to the NAS with Pack&Go enabled.

I did NOT enable "Send Dependencies".
Setting a dependencies directory does not change anything.

Result:

The Node on my Work Station is rendering, all the others do not.



This is a screenshot from the machine with the Manager:

[zoppo]

Now with "Send dependencies" enabled:

The nodes started working (blue) except two of them (green and red) who could not find some textures the others could find.



That is the red Node:




Juan, should I post the Nodes log file here?

[zoppo]

I had a peek in the Node's log file.

This part is from the "Send Dependencies" DISABLED:

The Node was assigned frame 7 and did wait for the MXS file. After a Minute I stopped it:



In this screenshot from the Node the file clearly is accessible:

[Mihai]

But that doesn't seem like a UNC path? It should look like this: \\computername\folder\myfile.mxs

When you browse to the mxs file, in the explorer that appears you need to browse through the "Network" and browse to the shared folder.

[zoppo]

To test whether the NAS is the problem I set one of the drives of my work station as network drive.

It is drive G:

I connected this drive G: as G: in all render slaves.

Then I exported the animation from Cinema4D with Pack&Go

I saved it to G:\Conntronic_Animation

Maxwell saved all MXS' in G:\Conntronic_Animation and created a subfolder "textures" with all textures in it.

I started all the Nodes.

I started the Manager and the Monitor on the work station and created a job as "Animation".

Result (and it doesn't matter whether I set a path or not):



So I opened frame 0 MXS in Studio ... oh - look - Pack&Go did work:



But Missing File Dependencies check disagrees:

[zoppo]

But that doesn't seem like a UNC path? It should look like this: \\computername\folder\myfile.mxs

When you browse to the mxs file, in the explorer that appears you need to browse through the "Network" and browse to the shared folder.

I NEVER did that?!
Not in MW1 or MW2 and certainly not with C4D or Vray.

This is a completely unusual way of working for Windows.

I don't know if you work with Windows, but there you have letters assigned to drives.
So all network clients connect to folder "test" on the NAS under U:\test\


EDIT: Could someone using Windows and MW in a network please weigh in?! How do you save and open MW's files?

[zoppo]

On page 2 you wrote:

Forgot to mention, it's not always needed to enter a dependency path when you have 'send dep.' unchecked. For example, if you set up your scenes materials, IBL, IES, by browsing to textures,hdrs, ies etc. files through UNC paths (so your entire scene only uses UNC paths) a dependency path is not necessary. It IS necessary though if you worked on a scene locally, the paths to dependencies are local. Then you need to move/copy all these dependencies to a networked folder, and specify the path to it in the Dependencies path.

That is what I did, right?


Edit: I will try saving with Pack&Go to "\\MAINBRAINII\G_Flash\Conntronic_Animation"
We will see ...

[zoppo]

Well, I exported to an UNC path:



The texture check is ok:



I checked and all textures are saved under "\\MAINBRAINII\G_Flash\Conntronic_Animation\textures"

But Studio says:




The funniest thing is: "steel dark" doesn't even contain a texture ...

Now on to the Monitor ...

[JDHill]

I've been working on figuring out that bogus missing "textures" thing for awhile; hadn't noticed it exporting from Cinema yet, but from SketchUp. Aside from making you want to click "No to all" when you maybe shouldn't, I believe it is harmless, and indicative of nothing. At this point, it seems somehow related to the active texture in the material, combined with the plugin's writing of relative paths to the MXS when Pack & Go is enabled.

[zoppo]

Monitor settings:





RESULT: Only 4 Nodes are rendering




One of the Non-Rendering-Nodes shows this (and, again, stays that way):



The Node has full access to the network:



Its log file:



The same as before only with an UNC path ...

And again - there it is:

[zoppo]

I've been working on figuring out that bogus missing "textures" thing for awhile; hadn't noticed it exporting from Cinema yet, but from SketchUp. Aside from making you want to click "No to all" when you maybe shouldn't, I believe it is harmless, and indicative of nothing. At this point, it seems somehow related to the active texture in the material, combined with the plugin's writing of relative paths to the MXS when Pack & Go is enabled.

I believe it to be harmless too, as all textures were found both in C4D's check and the Monitor's dependencies check. It is not even a real texture name. In a material that does not use textures.

[zoppo]

Now the updates in the Monitor have stopped again. Nothing has crashed, there is no error, just no updates in the job window.

The Manager is still updating, reporting SL updates from the 4 Nodes that actually started rendering.

They even started new frames and are still rendering!


---------

Now I stopped the Monitor and this is reported in the Manager's window immediately.

----------

Restarted the Monitor, works and updates again.

Still only 4 Nodes working, the other five still are reported as "State: running".
Still no error in the Monitor's console.


--------------

I terminated one of the "waiting" Nodes..
The Monitor did not see this but after a restart.

Now the terminated Node has vanished from the "Render Nodes" list but the frame in the job list it was (not) working on looks like this now:



That's right - still running, although there is no Node assigned.


-----------

Now I restarted the Node I earlier terminated.

It is rendering now frame 53.

The Monitor shows it in its "Render Nodes" list by its name.

The Monitor shows it in its "Job" list by its IP address rendering frame 53 but doesn't update its status.

The Manager recognizes a new Node, also under its IP.

The Manager does NOT take the Nodes status updates.

The Node reports rendering frame 53 and SL progress (ignored by the Manager) and suddenly reports an error when the Manager sent a job order to it while it was still rendering frame 53.

The Node reports having finished frame 53.

The Monitor says frame 53 is still running.

The Node has gotten a new frame to render, frame 55.

The Monitor shows the Node under its name in the job list rendering frame 55.

Frame 55 is marked "finished" and written on the disk.

Frame 53 is still marked "running" and NOT written to the disk.

--------

To be continued ...

[numerobis]

The funniest thing is: "steel dark" doesn't even contain a texture ...

It only happens with materials without textures for me (exported from Sketchup as JD says). You can simply hit "No to All" and it opens correctly - as "workaround".

[zoppo]

It only happens with materials without textures for me (exported from Sketchup as JD says). You can simply hit "No to All" and it opens correctly - as "workaround".

Thanks, but I used Studio only to verify that Pack&Go set the textures' paths to UNC. It did


-----------------

Next try:


Now I restarted (NOT 'reset' from the "Render Nodes" list but a restart via VNC) all Nodes that did not render.

They show the same behavior as the one before:

In the job list they are listed under their IP address.

They are stated to be "running".

They are indeed running but although they are even recognized by the Manager under their IP their SL updates are ignored.

When they have finished their first frame after the restart they get assigned the next one and appear in the job list under their name.

The frames with the IPs assigned stay in the list with "State: running

After restarting the Monitor the frames are still "running" but without any Node assigned to it.

[zoppo]

Unfortunately I have to go home now.

I hoped to get to page 4 today.

Well, tomorrow is another day.