[Q] VCS Branches, Unity Versions, breaking lightmaps

[realmar]

Hey all, we use the unity cache server in our local network for the whole team. Recently we were forced to split development into two branches which are diverging. We noticed that lightmaps started to break between the teams working on the two branches. (we have different lightmaps on the two branches) We suspect that the cache server is at fault, as both teams use the same server and unity might not be able to differentiate which lightmap correspond to which branch. (they maybe generate the same hash?)

Until now we didn't run the cache server in High-Reliability Mode. We enabled this mode this morning and now hope that this resolves our problem. (we used default.yml as a template for our configuration, we assume this is correct?)

However, this issue caused us to ask ourselves following questions:

1. Does the unity cache server support multiple branches which are diverging? (same project, same unity version, different lightmaps, materials, assets, etc.)
2. Is the cache server specific to a unity version? Do we need to use one cache server per unity version? If yes, how do we configure that? If no, is it possible to use the same cache server with multiple unity versions on the same project? (eg. PS4 requires to use a different unity version than XBox One)
3. Can the same cache server be used to cache multiple projects at the same time? (two teams working on different projects using the same cache server)

We also have some other questions unrelated to the issue stated above:

4. Does the cache server support authentication and encryption? (eg. teams working in different countries/people doing home office sharing one cache server) If no how would you recommend using a cache server in such a scenario? One solution might be using stunnel however, this is slightly complicated for non-programmers.

[partounian]

Have you found the answers to these?

[realmar]

Unfortunately, I didn't find answers to these questions yet.

[stephen-palmer]

Apologies for the delayed response to this. Answers to your questions:

1. This scenario should be fully supported, as any differences in asset imports would be reflected in the asset hash calculation, unless one branch has implemented some asset post processors that introduce dependencies that are not tracked.
2. We recommend running separate cache servers for each major unity release (i.e 2018.1 vs. 2018.2). Use the -CacheServerIPAddress <host:port> CLI option in Unity to override the system wide cache server config and connect to a specific cache server
3. This should work fine, but depending on project size and complexity it's not impossible to encounter hash collisions, so at the very least I would operate in high reliability mode when caching multiple projects.
4. not at this time. Adding a higher level encryption/auth solution is your best bet, like VPN or SSH tunneling. You could probably simplify this for end-users by using transaction mirroring between servers that are already securely accessible by your clients. Also note that v6.1 introduces IP whitelisting for PUT (write) transactions. This doesn't provide data security but at least can prevent unauthorized changes to a cache server accessible over an insecure network.

There is a proposal to introduce client namespacing to the cache server to address scenarios 1-3, but currently isn't prioritized for development. Feedback from devs like yourself that would find value in that feature is helpful to inform priorities.

I'm curious what your experience with High Reliability mode has been so far? I haven't received much feedback on that feature since its release.

[realmar]

Thank you for your answers! And no worries, we were busy too!

We figured out why our lightmaps, were breaking, it had nothing to do with the cache server: we are building the lightmap UVs using unity, it turns out that if the project is opened using a unity version which is newer than the one with which the UVs were generated then the lighting breaks. As a workaround, we initially import the project using the Unity version with which the UVs were generated and then switch to the newer version. Because the cache server is sensitive to the unity version, this workaround obviously does not work.

Because we were in the middle of releasing a game we had no time to rebuild lightmap UVs or do anything about that so the team stopped using the cache server. I was the only one continuing using the server. Because of that, I cannot give you any valid feedback for the High-Reliability mode yet. However, we are planning to use the cache server in the near future again, then I'll provide you with feedback!

We recommend running separate cache servers for each major unity release (i.e 2018.1 vs. 2018.2).

Is it possible to configure unity to use different cache servers for different unity versions? As it is now all unity versions installed on my PC use the same cache server, even though I configured it only in one version. I assume the issue is that all installed unity versions use the same configuration files and not their own version specific configuration.

[stephen-palmer]

No it is not possible right now - the cache server configuration is a system wide editor setting. The best workaround is to create shortcuts for launching Unity that use the CLI option I described above to override the system setting at startup.

[BenWoodford]

I feel like the command-line argument approach butts heads with Unity's own recommendation that we should use the Unity Hub - as far as I know we can't setup Hub to pass command line arguments to a launching Editor?

[stephen-palmer]

The Hub will have the ability to pass CLI args to Unity on a per-project basis in an upcoming release (currently planned for Q1 this year)

[BenWoodford]

The Hub will have the ability to pass CLI args to Unity on a per-project basis in an upcoming release (currently planned for Q1 this year)

Maybe per install to?

[bobobaribu]

Hi,
To give you more details on the CLI features that are planned in the Hub, here is a list of what to expect (I'm not listing everything but at least enough to give you the big picture). The goal is to provide every visual feature as CLI features.

This is the high level CLI arguments :

• Editor installations management (download/install/uninstall/add components etc.)
• Projects management (create/launch/build/update/clone etc.) This will include forwarding editor arguments and editor version selection
• Account management (license management, sign-in, org selection, etc)