So we use a NAS drive shared across all our machines, all mapped to the same letter - N. When we try to use Corona DR it constantly says it cant find materials using the following N path even though all those machines can access the drive with the same directory.
The only way it does work is if we go to the asset tracker thing in max and resolve path to UNC location. Is this a must every time we want to use the DR?
Then the other question is…some of the machines are different specs, so sometimes a scene will run out of RAM on a couple of machines and it warns about having different results in the final image, how do we stop this from happening while still using all the machines?
How do you define a “machine”? It´s always a user account/credentials who can access something (localy or on a network). So which account runs DrServer.exe? And has THAT user also your “N”-drive mapped?
I do not know any reason to use (legacy) network letters but running DOS emulators UNC makes less trouble in all respects.
by machine i just mean another PC with its own account for that PC, all of them mapped to use N as the shared drive.
If using UNC is the way to go then I will just keep using that but is there a way to get it to map like that by default? or do you always have to go into the asset tracker?
Where does who have which account? Usually a PC cannot “map a drive” at all. Only a user account can. So most important again: which account/user runs DrServer.exe on your slaves? If you want to solve this you may want to describe your setup more detailed. Maybe you run some nasty NAS client software of which I don´t have any knowledge
Usually it´s no problem to use drive letters but UNC is more fail safe as you can see (not only relating to Corona). And the paths used are simply those you have defined in your materials (Xrefs/IES_Lights/Output Paths and so on go the same). So if you want to make a paradigm change to UNC you will have to adjust all your materials (including libraries) and props one by one. When creating new ones you simply do not load “N:\Textures\Wood\shinywood.tga” but navigate to “\NAS\sharename\Textures\Wood\shinywood.tga” and load that instead.
For conversion you can use various tools, one of them is the asset tracker but also “Bitmap / Photometric Paths” (in utilities) can be handy or some external tool like “Relink Bitmaps”
I understand now! I didn’t realise navigating to the texture different like that would give it a different path name. I just tested going through the network instead of straight through “N:” I’ll just make sure to navigate the network like this when linking files.
In terms of more detail how the PCs are setup, there is say workstation 1, work station 2 and node 1 node 2. Node 1 has account Node 1, node 2 has account Node 2. Both are always running DR.exe and have NAS mapped to N:. Its the same for workstation 1 - account is workstation 1 etc. They submit render and the nodes pick it up and help to render.
However just navigating for textures how you explained is probably just easier and then running asset tracker or relink bitmaps if accidently miss any.
Do you know how to fix the RAM problem though? when it says a node has run out of RAM and results may differ, what do I do in that situation? just not use the nodes?
-upgrade RAM
-optimize scene as much as possible
-avoid any other activity on the computers which are rendering - close all unused applications, do not perform any other tasks like playing videos, running other 2d/3d editing software
-there may be some error in the scene/file, or a bug, which causes this
Thanks, I have looked around at these, sometimes optimisation of the scene can’t be fully achieved. In these cases, Im not really sure how progressive rendering works with a network but would lowering the ‘max pixels to transfer at once’ mean the lower spec PC could still help out? and is it better to synch at more frequent times or less frequent times?
I dont want lines to appear in the image if i transfer less pixels. Not sure if im missing somewhere i can read about the details of DR.
I still hold out hope that you guys will remove the need for UNC paths for DR to work. It’s really killing a lot of time having to set that up and remember to keep doing it for every project, and many times within each project too.
After the explination above and the use of relink bitmaps, it is rather simple. Asset tracker was an inconvenience. I dont feel so bad about the UNC now.
I’m still not finding much info on how the DR works though, the tool tips only say so much. I want to know if synching frequently is better and if using smaller packages of pixels to save on RAM for lower spec machines will result in an inconsistant image or not.
Is this since 1.3? Because we went through this many, many times here doing exactly that in 1.2.1, setting up the usual mapped network drives etc. and it never worked unless we use UNC paths e.g. \machine1\project\project1\map.jpg. Nothing else worked.
If that’s changed since 1.3 then freakin’ halleluja!
edit: nope, still not working here. I have 2 machines with mapped network drives, both able to see the main machine just fine. But if I map to local paths DR won’t work - I get missing maps errors. As soon as I change to UNC it works.
Local paths are something completely different. This thread was about using mapped drives. So if you use at your local machine a path like N:\textures\wood\shinywood.tga in a material, where N is mapped to \server\stuff\ (with “textures” as subdirectory of your share root) and the user(!) which runs drserver.exe on your slave also has this share mapped to N:\ everything is peachy.
But of course if you use at your local machine e.g. C:\data\textures\wood\shinywood.tga and your slave even does not have this c:\data[..,] directory with the same maps it fails. BUT if your local machine shares this “C:\data” and you point to your local directory by using UNC, your local machine acts like a server and it works. Is this what you did?
Nutshell:
There are three different ways to point at assets:
Local Pahts (nono for DR/BB)
Mapped drives (quite ok but not very fail safe)
UNC (fail save)
Just imagine opening your scene at the remote slave: paths have to be configured simply in such way that the scene would render fine when opened interactively there by the user who runs drserver.exe
That’s exactly what we tried here. By local I meant a mapped path to F:\Projects, which is the same on all machines. Just as you described. So all 3 machines point to the exact same absolute mapped path e.g. F:\Projects\Project1\maps\map1.jpg. But it doesn’t work at all. All the machines can see the same folders and files and have write privilleges to them. But as soon as you try to read them over DR it fails. As soon as we switch to UNC paths it works 100%. We have tried quite literally everything we can think of to get it to work through mapped network drives but no joy.
There is no reason why it should not work. What´s the name of the user behind “drserver.exe” in the process tab of the taskmanager on your slaves? And are you logged in at the slave as that user when checking if the “machine can see the folder”. Again, I can´t emphasize it more (while I´m always getting ignored it´s not about a machine seeing something / having a drive mapped but about the user running drserver.
I will try this again on a fresh scene and see what happens. I’m almost positive that all machines are using the same name for their User account but perhaps this is what’s causing the issue. Cheers
That means: You are logged in interactively on both with - say user “user1”. You have as “user1” your F:\ drive mapped and you can access it. Then you simply start drserver.exe interactively as this “user1” and then you get those errors?
I’m not sure but I have created a user account on all 3 of my machines which is named the same and with the same password. The DRServer.exe is launched on each of these machines which is logged in with that user account. So all 3 machines have the exact same setup, same mapped drives etc.
From Max/Corona side this should just work fine - I can´t reproduce that at all. DrServer spawns Max as the same user and thus should also have the mapped drive(s).
Sole “win 8.1. pro” makes my head itching a bit. DarcTheo, OP, are you still reading your thread? You are not running win 8 or 10 like Alex by any chance? Though I could not imagine why such basic networking stuff should have changed.