- Tue Feb 03, 2015 6:42 pm
#385199
The release version tp network manager, monitor and render node now works on my main workstation too, without me changing anything.
G
G
gianca wrote: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.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
My pleasure as always, especially in this case as the new network render is something I've been asking for a long time!
G

- By Andreas Hopf