[T0M0]

Maxwell Render 3.1.0 RC1 is available with Technology Preview of new Network Manager !

DOWNLOAD:

http://www.maxwellrender.com/betas/

(can't wait to test it )

[eric nixon]

3.1 not working for me, studio opens but C4D doesn't load the plugin, complains about; get processor active group count....

[ababak]

Among the new features, you will now be able to try the new prototype of the Network System, now as a Technology Preview (so far named TP Network, and now only available for Windows and Linux), that in the future will completely replace the existing one.

Does this mean that the OS X version of the TP Network is not ready but will be available when the beta is over?

[zparrish]

I just installed the RC to test it out, specifically it's networking tools. I had a few questions. I suppose I'm asking these a bit prematurely since the temp docs aren't released yet, but does the technology preview automatically replace the network tools in the release candidate or do I need to execute the files within the "tp_network" directory? There appeared to be no UI changes in the default tools.

I tried launching the "tp_network.exe" executable, and even looked for CLI help messages, but was unsuccessful in sustaining a running process for it. It appears to attempt to launch but then no process actually spawns for it. When launching "tp_network.exe -monitor" from the command line, I get the following messages:

Code: Select all

C:\Users\USERNAME>"C:\Program Files\Next Limit\Maxwell 3\tp_network\tp_network.exe" -monitor
Traceback (most recent call last):
  File "<string>", line 33, in <module>
  File "<string>", line 21, in open_browser
  File "C:\cygwin64\home\vm6\mxcloud\build\mxcrun\out00-PYZ.pyz\ConfigParser", line 607, in get
ConfigParser.NoSectionError: No section: 'Manager configuration'

Then I thought I would try and throw some parameters at it and the terminal messages changed. For example, If I tried to pass the IP address of the manager (192.168.2.32 in my case) in using the old syntax, it would return:

Code: Select all

C:\Users\USERNAME>"C:\Program Files\Next Limit\Maxwell 3\tp_network\tp_network.exe" -monitor:192.168.2.32
usage: mxcnetwork [-h] [-M MANAGER] [-v VERBOSITY] [-l LISTEN] [-j JOBMAN]
                  [-g LOGHUB] [-a JOBFILE] [-r] [-n] [-s SHARED] [-t TREE]
                  [-T TEMPDIR] [-p PARAMS] [-P] [-H] [-w] [-np]
                  [--address-webserver ADDRESS_WEBSERVER]
                  [--port-jobman-listen PORT_JOBMAN_LISTEN]
                  [--port-jobman-publish PORT_JOBMAN_PUBLISH]
                  [--port-params-listen PORT_PARAMS_LISTEN]
                  [--port-webserver PORT_WEBSERVER] [--port-tree PORT_TREE]
                  [--port-log-push PORT_LOG_PUSH]
                  [--port-log-web PORT_LOG_WEB]
                  mode
mxcnetwork: error: too few arguments

I see that "tp_network.exe" lists some parameters for the HTTP access, so I think I'm on the right track. I tried several variants of the parameters shown but always got the "usage:" response. What would be the proper syntax for launching this application through command line?

Thanks Next Limit! I'm looking forward to giving this new system some thorough testing!

[gianca]

The old network tools are still there and working, that's good just in case...
Without docs, I feel like a cg monkey hitting keys, but I just can't wait....


I started first the "tp_network.exe", prompted to choose either manager or render node.
Everything starts without drama...
The "TP Network Render Node" and "TP Network Manager" are the same as above but with the choice of mode already supplied in the shortcut.

TP Network Monitor: that launches a web page pointing to my internal ip address with port 8888.
No joy there, but I had port issues before so I may need to change port number.

Will try later.

G

[gianca]

Tried few different port numbers, the monitor does not connect.
Killed karpersky just in case: still no joy.
Need to go trough the docs first I guess, seems I'm missing something,

One thing I noticed is that when I launch the monitor from the manager menu it opens at 127.0.0.1:8888 even if in the shell it reports the correct ip address, which is obviously different, but when I open the monitor with the supplied shortcut it opens with the correct ip address but the default port, regardless if what I set in the manager preferences.

G

The old network tools are still there and working, that's good just in case...
Without docs, I feel like a cg monkey hitting keys, but I just can't wait....


I started first the "tp_network.exe", prompted to choose either manager or render node.
Everything starts without drama...
The "TP Network Render Node" and "TP Network Manager" are the same as above but with the choice of mode already supplied in the shortcut.

TP Network Monitor: that launches a web page pointing to my internal ip address with port 8888.
No joy there, but I had port issues before so I may need to change port number.

Will try later.

G

[AlexP]

under ubuntu linux:

Code: Select all

olo@rn00:/opt/maxwell3/tp_network$ ./tp_network
Traceback (most recent call last):
  File "<string>", line 2, in <module>
ImportError: No module named mxcjobman

[pablo]

under ubuntu linux:

Code: Select all

olo@rn00:/opt/maxwell3/tp_network$ ./tp_network
Traceback (most recent call last):
  File "<string>", line 2, in <module>
ImportError: No module named mxcjobman

I found that the automated (w Jenkins) packaging for tp_network lack some packages needed for tp_network to work on linux. Next beta will load correctly. Thank you for reporting!

[pablo]

Hi zparris. Yes, the command line has changed a bit. You can start with -manager, -monitor and -node as always and then the values stored on the ini files (editable through the File/Preferences dialog). If you want to overwrite with command line parameters the syntax is a bit different. It will be documented.

As per the error that you get, could it be that you have run a previews version of tp_network (when it was called mxcrun) and left out the old configuration files? They are at C:\<userdir>\AppData\Local\NextLimit\mxcrun in that early beta. Try to delete that folder and re-run.

Thank you for testing!

[pablo]

One thing I noticed is that when I launch the monitor from the manager menu it opens at 127.0.0.1:8888 even if in the shell it reports the correct ip address, which is obviously different, but when I open the monitor with the supplied shortcut it opens with the correct ip address but the default port, regardless if what I set in the manager preferences.

On the manager the web is always served on localhost as well as on the WAN address, so the manager pointing to localhost is correct. The monitor link, tough, uses the node configuration do not have the web port on it, so it just links to <manager ip address>:8888 regardless of the port being configured. Thank you for reporting this.

[dariolanza]

Hi all,

Some Documentation about the new Technology Preview Network System is already available here:

http://support.nextlimit.com/display/mx ... gy+Preview

so you can already start it up and submit your first renders.
We'll keep completing the information in the page in the following days.

Enjoy!

Dario Lanza

[gianca]

I was able to make the manager and monitor work by running the manager from my render computer: could not make it run on my main workstation.
The render node runs fine on my workstation. I can open the monitor on workstation, but I cannot start new jobs with it.
I may have some port issues: changing port # in the manager did not help, neither disabling my antivirus which is karpersky and runs on both machines.

On the other hand everything on my render node works without a glitch: the manager, the render and the monitor all worked as described in the docs.

Note:
The tp_network requires the mxs to be on the shared folder: cannot navigate anywhere else than inside the shared folder.
I assume this is just a temporary limitation, right?
Not a a biggie as long as we are not forced into this for the final release: just tested a simple scene with textures in different locations and that works just fine, so this is just a requirement for the mxs file to be rendered.

FYI when I start the tp_network.exe application I only get the manager and the render node button, not the monitor.

G

[pablo]

Hi gianca, answering inline

I was able to make the manager and monitor work by running the manager from my render computer: could not make it run on my main workstation.
The render node runs fine on my workstation. I can open the monitor on workstation, but I cannot start new jobs with it.
I may have some port issues: changing port # in the manager did not help, neither disabling my antivirus which is karpersky and runs on both machines.

I guess that overzealous antivirus software will block sometimes the ports. Perhaps it will be easier better to configure or open them ports if all where in a known interval (i.e 8100-8120) or something like that instead of having 8888 for the web and 15051 etc for the communications between nodes and the job manager ... this is a change that i'll add to the queue.

Note:
The tp_network requires the mxs to be on the shared folder: cannot navigate anywhere else than inside the shared folder.
I assume this is just a temporary limitation, right?
Not a a biggie as long as we are not forced into this for the final release: just tested a simple scene with textures in different locations and that works just fine, so this is just a requirement for the mxs file to be rendered.

In the future the requirement of a shared folder between rendernodes and manager will be removed, or kept as an option. IMHO it is always more efficient and reliable to use NFS/SMB to move files around in a network than doing it by oneself, but as the old network system did move files around by itself i guess that it is a feature worth replicating

'Fishing' somehow the dependencies around and sending them to the manager (or perhaps copying them to the shared folder in a place where the rendernode will find them) is also something that needs to be done also on this tp_network, as having to copy all the dependencies to the share is cumbersome.

FYI when I start the tp_network.exe application I only get the manager and the render node button, not the monitor.

The documentation is a bit ahead of time Future betas will have it in place, along with some changes on messages, menus, etc.

Again, thank you gianca for reporting back. It is very useful

[gianca]

Hi gianca, answering inline

I was able to make the manager and monitor work by running the manager from my render computer: could not make it run on my main workstation.
The render node runs fine on my workstation. I can open the monitor on workstation, but I cannot start new jobs with it.
I may have some port issues: changing port # in the manager did not help, neither disabling my antivirus which is karpersky and runs on both machines.

I guess that overzealous antivirus software will block sometimes the ports. Perhaps it will be easier better to configure or open them ports if all where in a known interval (i.e 8100-8120) or something like that instead of having 8888 for the web and 15051 etc for the communications between nodes and the job manager ... this is a change that i'll add to the queue.

Will try asap

Note:
The tp_network requires the mxs to be on the shared folder: cannot navigate anywhere else than inside the shared folder.
I assume this is just a temporary limitation, right?
Not a a biggie as long as we are not forced into this for the final release: just tested a simple scene with textures in different locations and that works just fine, so this is just a requirement for the mxs file to be rendered.

In the future the requirement of a shared folder between rendernodes and manager will be removed, or kept as an option. IMHO it is always more efficient and reliable to use NFS/SMB to move files around in a network than doing it by oneself, but as the old network system did move files around by itself i guess that it is a feature worth replicating

'Fishing' somehow the dependencies around and sending them to the manager (or perhaps copying them to the shared folder in a place where the rendernode will find them) is also something that needs to be done also on this tp_network, as having to copy all the dependencies to the share is cumbersome.

Pleeze do not drag ourself in that can of worms that is moving files around! IMO that's the achille's heel of the old network system...
The rendernode and mximerge IMO do all the work is needed: they are solid. When I use deadline as a render manager for either sequences or coop renders it gives for granted that all the files are reachable on a common location for all render modes, which is really a basic requirement for all renders. So all deadline does is start the renders, decides what SL is needed for each node, and starts the mximerge once all renders are done which often fails but I never lost a coop render that way so I always been able to run the mximerge manually afterwords.
What I would like the new network manager to be is to stay as simple as it is, and perhaps facilitate the coop renders from within the host application.

FYI when I start the tp_network.exe application I only get the manager and the render node button, not the monitor.

The documentation is a bit ahead of time Future betas will have it in place, along with some changes on messages, menus, etc.
Again, thank you gianca for reporting back. It is very useful

You are welcome!
My pleasure as always, especially in this case as the new network render is something I've been asking for a long time!

G

[zparrish]

Here's the freshly released docs to the Technology Preview:

http://support.nextlimit.com/display/mx ... gy+Preview

Looking forward to giving this a thorough evaluation! Thanks Next Limit!