Feedback Resolve Lighting Data asset via relative path rather than / in addition to explicit asset GUIDs

Currently, after baking Realtime GI lighting, a LightingData.asset file is created in a sibling directory of the scene, and the Scene itself is updated to reference the LightingData asset:

m_LightingDataAsset: {fileID: 112000000, guid: da0e867bea83016479097a4254afece2, type: 2}

The problem with this approach is that if two separate computers bake lighting, they will each create their own unique LightingData.asset file, and each will try to update the Scene asset to reflect the GUID of the locally created LightingData.asset file. This is problematic when working on a team, where LightingData.asset files aren't including in version control due to their large size, where all team members bake lighting independently. Currently, if one team member bakes lighting for a scene, and commits their changes to the scene, Realtime GI will be broken for me if I pull down and update to the scene.

A solution I'm proposing for this is to (probably optionally) allow LightingData.asset files to be resolved based on relative paths rather than by explicit reference within the scene file. Currently, if I bake lighting for a scene named "MyScene", Unity will create a folder named "MyScene", and within it, the LightingData.asset file will be placed. My proposal is that if Unity detects that the LightingData exists at this path, that it use that LightingData.asset implicitly, rather than using the explicit reference in the Scene file. This would allow teams to each have their own local copy of LightingData.asset files.

I would also be fine with someone suggesting an approach I could take to having team members bake, but not commit, their own LightingData.asset files, without it stepping on everyone's toes.

 

I ended up with a relative simple workaround for this issue. It involves a bit of initial setup, and then some minor ongoing effort whenever a new scene is added. The basic idea is to use git's `skip-worktree' feature to stop tracking changes on the LightingData.asset files after a dummy version has been committed.

My overall plan was that for each LightingData.asset file, I would commit a dummy file, so that the scene would reference the file. I would then .gitignore the file, so that future changes to the file wouldn't be tracked. This doesn't quite work, though, since even if you .gitignore a file, that won't prevent git from tracking changes on it if it has already been added to the repo.

So, instead, I committed the dummy versions of each LightingData.asset, then use `git update-index --skip-worktree' on each of the files. The result is that the dummy file is all git knows about, but I can edit the file (by rebaking lighting) without those changes being tracked by git.

The downside is that update-index is just a local thing, it's not part of the repo, so everyone using the repo will need to execute those statements. I ended up making a simple shell script to find all LightingData.asset and call skip-worktree on it.

The "dummy" lighting file in this case is just the LightingData.asset of some trivially small scene, which was only 37 Kb in size, which I copy/pasted to overwrite all of the lighting data. That was then committed. Now both the Mac and Windows versions of the codebase have each scene pointing at the same LightingData.asset file, even though the files will end up with different contents on the two machines.

 

Half a year to late, I know, but it should be possible to ignore the lightning data (asset and textures) in git, and just share the file offline (via email), so the asset with the correct ID (saved in .meta file) exists on both computers but it will never be updated via git.
IDK how the asset behaves when you change the lightning-settings-asset..

 

Thanks. I believe you're probably correct, that manually copying files around like that would probably be another solution to this. That starts to become a bit of a burden when there are many scenes with many lighting data file.

I ended up writing some detailed steps for using the skip-worktree approach I described in the previous post: https://forum.unity.com/threads/bes...ightingdata-asset-in-git.716831/#post-6192324

It might seem a bit complex at first, but once you understand the approach, it's pretty simple, and just requires a one-time setup cost, and then it just works for everyone else from that point on. So, depending on the size of your project, and the number of team members, perhaps one approach is more convenient.