The official Maxwell Render public forum. A place to share your latest projects and be inspired by others, or get help and feedback from the Maxwell community
https://forum.maxwellrender.com/
)
Does this mean that the OS X version of the TP Network is not ready but will be available when the beta is over?dariolanza wrote: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.
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'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 argumentsgianca wrote: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
olo@rn00:/opt/maxwell3/tp_network$ ./tp_network
Traceback (most recent call last):
File "<string>", line 2, in <module>
ImportError: No module named mxcjobmanI 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!AlexP wrote:under ubuntu linux:
Code: Select allolo@rn00:/opt/maxwell3/tp_network$ ./tp_network Traceback (most recent call last): File "<string>", line 2, in <module> ImportError: No module named mxcjobman
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.gianca wrote:
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.
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.gianca wrote: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.
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 replicatinggianca wrote: 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.
The documentation is a bit ahead of timeFYI when I start the tp_network.exe application I only get the manager and the render node button, not the monitor.
Future betas will have it in place, along with some changes on messages, menus, etc.You are welcome!pablo wrote:Hi gianca, answering inline
gianca wrote: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.Will try asappablo wrote: 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.
gianca wrote: 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.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...pablo wrote: 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.
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.
The documentation is a bit ahead of timeFYI when I start the tp_network.exe application I only get the manager and the render node button, not the monitor.
Again, thank you gianca for reporting back. It is very useful