Everything related to Maxwell Render and general stuff that doesn't fit in other categories.
#385199
The release version tp network manager, monitor and render node now works on my main workstation too, without me changing anything.
G
gianca wrote:
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.
pablo 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.
Will try asap
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.
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.
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
Help with swimming pool water

Nothing beats observing the real world or, if that[…]

Sketchup 2026 Released

Considering how long a version for Sketchup 2025 t[…]

Greetings, One of my users with Sketchup 2025 (25[…]

Maxwell Rhino 5.2.6.8 plugin with macOS Tahoe 26

Good morning everyone, I’d like to know if t[…]