Can FFP/RC introduce an install option to have ALL maps installed to network?

[DM5847]

Hi,

I'm not a network/IT specialist, so very likely I'm missing a setting with administrative rights in windows, but at the same time should I need to be an IT specialist to get FP to find maps consistently in a network environment? These are the only plugins where we are running into these issues. I've searched the forum and seen different options from reg edits to custom max user paths but that wasn't always needed. It started with the move to install all the textures to local user accounts and has now progressed to network node renders and administrator access rights issues (for us).

Question: Can Itoo add an option during installation to have ALL maps installed on a network location and have the plugins always reference that location?

Reason: Network rights and user location saves are not the same between user pc's and rendernodes. Meaning that more often than comfortable renders get messed up because a link to a map isn't accessible because the plugin always reverts to the standard user account location and program files directory.

Our workaround now is to just copy all the textures (both models maps and program files distribution maps) to a network location and when saving the file go through the asset browser to make sure everything is linked to the network location. However, as often the case in spite of our best attempts to be vigilant about this a small FP update we forgot to check is linked to a program files directory and that is screwing up certain frames in the animation.

Is the install option possible? Everything else in our max workflow regarding textures is linked to a central network location, can't Itoo's also do that for users that prefer that? Thanks, and now off to reload multiple animations and have another hour or 2 spent behind the pc by this issue....

If there is a clear workthrough that I've missed with the forum search I'm happy to try it, but I also don't want to have to go through 6 pc's everytime there is a RC or FP update.

[iToo]

Hi,

I think we must differentiate two issues here:

a) Distribution Maps.

We don't recommend to move them from their original path (C:\Program Files\Itoo Software\Forest Pack Pro\distmaps).
These files are part of the plugin, require little space (< 1Mbyte), and always are installed at the same place, both in workstations and render nodes.
Sincerely, i don't see any reason you want to move them to a network path. If i'm missing something because you need that, please tell me.

b) Library Assets.

They are installed in a local folder (C:\Users\<user name>\AppData\Local\Itoo Software\Forest Pack Pro),
We're hesistant to include an option to install them in a network folder, because several potential issues. For example:

- Windows user must have permissions to write in the network path.
- Assets may be overwritten, if Update Manager (the tool which downloads our assets) is executed by several users.
- Problems with missing paths, or different mapped drives between nodes (UNC format is a must).
- Slow asset loading, if network is not properly configured.

Although we know that most of our customers may lead with these issues, we prefer to not include options which may cause problems to less experienced users.

Instead to download the Library assets directly to a network path, we suggest you create a copy from the local folder to your network path, and then include that path to the Library Browser.
Basically, handle it in the same way that you use third-party libraries.

Following this procedure, you should have not problems with Forest updates: distribution maps are not modified, and library doesn't change either, because the network copy is separated from the local files.

Please, tell us if this procedure may suit well with your workflow. If not, i will pleased to discuss it, and to considere other changes.

Thanks,

[DM5847]

Hi,

Thanks for responding. The issue we are running into at the moment is due to windows user rights on the rendernodes means they can't access the distribution maps in the program files. That is what is so frustrating. I'm going to review the rights when I have time again, to hopefully clean this up, but as I said in my earlier post, only the FP/RC stuff has this issue. Looking at your list we seem to have opposite workflows, 

a) Distribution Maps. = Because of the above issue and the minimal size, it's currently our "hack" to make sure the nodes find the maps. We also set up the nodes with limited rights to have a safer network environment (just incase).

b) Library Assets.

They are installed in a local folder (C:\Users\<user name>\AppData\Local\Itoo Software\Forest Pack Pro), = For us this mean we have to download it multiple times or just aim the install from the network location where the downloaded files are stored. Either way, it means, in our case, unused data having to be saved on the nodes. To be honest, we mostly use the original FP/RC stuff for the geometry and a lot of the textures get updated. Most of the actual elements are from 3rd party libraries on the network.
We're hesistant to include an option to install them in a network folder, because several potential issues. For example:

- Windows user must have permissions to write in the network path. = Users have this, nodes don't. Would nodes need this when they are only reading library data?
- Assets may be overwritten, if Update Manager (the tool which downloads our assets) is executed by several users. = We don't edit FP assets / libery, we make our own in a separate folder to keep it clean and unified.
- Problems with missing paths, or different mapped drives between nodes (UNC format is a must). = This is all uniform, ironically our issue is that the non networked / baked in FP/RC stuff causes issues. Everything else is clean and organised on the network with fixed protocols to add files / maps.
- Slow asset loading, if network is not properly configured. = Agree with this, however a decent sized landscape file has this issue anyway so a couple more seconds for the, in our case, limited original FP stuff when called upon isn't a noticable issue.

I guess the easiest solution seems to be to give the nodes more rights for now. Hopefully you guys will consider an option based on the above, I can't image that the majority of studios don't run in to this issue when wanting to minimise the data on local harddrives / keep a central library system.

[iToo]

Hi,

The issue we are running into at the moment is due to windows user rights on the rendernodes means they can't access the distribution maps in the program files. That is what is so frustrating.

I see. But this is a very specific configuration, which is not normal in standard installations.
By default, Program Files is available to all Windows Users in read-only mode. That should be enough for a safer environment.

If you absolutely need to remove all permissions to Program Files (including read access), i would suggest to copy distribution maps to any texture folder, which is accessible to the render nodes.
I assume your render nodes have other texture folders configured, which may be used for this purpose. Remember that texture folders can be configured for render nodes in 3dsmax.ini, as described here.

We have not modified these files since a long time ago, and i doubt we need to modify them in the future.

- Windows user must have permissions to write in the network path. = Users have this, nodes don't. Would nodes need this when they are only reading library data?
- Assets may be overwritten, if Update Manager (the tool which downloads our assets) is executed by several users. = We don't edit FP assets / libery, we make our own in a separate folder to keep it clean and unified.
- Problems with missing paths, or different mapped drives between nodes (UNC format is a must). = This is all uniform, ironically our issue is that the non networked / baked in FP/RC stuff causes issues. Everything else is clean and organised on the network with fixed protocols to add files / maps.
- Slow asset loading, if network is not properly configured. = Agree with this, however a decent sized landscape file has this issue anyway so a couple more seconds for the, in our case, limited original FP stuff when called upon isn't a noticable issue.

Well, with these points i just was describing potential issues which may happen to non-experienced users, if we allow to install the library assets in any folder.
For this reason, we try to keep the installation process as simple as possible.

For customers with more experience in network installations (as your case), i guess the best workflow would be this:

a) Run a default installation in a local workstation, including the download of library assets by Update Manager.
b) Once installed, make a copy of the assets to the network path of your election, and add this path to the Library Browser (in the same way you handle your custom or third-party libraries).
c) In render nodes, just install the plugin... but don't run Update Manager. It's not necessary to install the library asssets locally, because you are already using them from your own network path.

Please note that all above only affects to the library assets included with Forest.
But we assume that most of customers already have many other libraries, which requires a similar procedure (copy to a network path, configure texture folders, etc.).