Search Unity

  1. How has 2019.2 and the beta been for you so far? Give us feedback in this thread.
    Dismiss Notice

Is LightmapSnapshot.asset in Unity 5 the same as Unity 4's LightProbes.asset?

Discussion in 'Unity 5 Pre-order Beta' started by seattlebluesky, Nov 13, 2014.

  1. seattlebluesky

    seattlebluesky

    Joined:
    Sep 2, 2014
    Posts:
    170
    I suspect it is. My issue with the Unity 5 project I have is that the on demand baked light probes are 450MB+ and this exceeds GitHub's 100MB file size limit.

    So now of course I need to reduce this asset size. I'm suspecting that if this asset is the result of baking light probes that less light probes will reduce the size of the asset.

    1) Any other ways to reduce the size of the LightmapSnapshot.asset in Unity 5?

    2) Is 450MB+ normal for this file? There are just over 950 light probes in the single light probe group that is baked. So that's nearly 0.5MB of data per light probe. If this isn't expected behavior I'll try to reduce down to a project that I can report via Bug Reporter / FogBugz.

    Cheers.
     
  2. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    5,671
    I think it also includes the actual lighting/lightmaps as well now, that's why the size went up that much.
     
  3. KEngelstoft

    KEngelstoft

    Unity Technologies

    Joined:
    Aug 13, 2013
    Posts:
    1,033
    Hi! The lightmap snapshot is not just the light probes... as the name implies it is a snapshot of all the data needed to lightmap the scene.
     
  4. seattlebluesky

    seattlebluesky

    Joined:
    Sep 2, 2014
    Posts:
    170
    No concerns about the potential size of the file w.r.t. source code control systems receiving it?
     
  5. DanSuperGP

    DanSuperGP

    Joined:
    Apr 7, 2013
    Posts:
    383
    Seems like adding it to your .gitignore might be a good idea, even if it were uploadable to github, it's undesirable to have a file like that bloating up your git repo.
     
  6. seattlebluesky

    seattlebluesky

    Joined:
    Sep 2, 2014
    Posts:
    170
    Agreed! Which is why the folders '/Library' and '/Temp' for example are useful to have in .gitignore.

    GitHub's provided .gitignore for Unity projects is currently,

    [Ll]ibrary/
    [Tt]emp/
    [Oo]bj/
    [Bb]uild/

    # Autogenerated VS/MD solution and project files
    /*.csproj
    /*.unityproj
    /*.sln
    /*.suo
    /*.user
    /*.userprefs
    /*.pidb
    /*.booproj

    # Unity3D Generated File On Crash Reports
    sysinfo.txt

    So my questions is if this file is to remain as a large conglomeration of light-map data,

    Can it be quickly regenerated if not found inside of the project sub-directory? I suspect not as whilst there are still individual lightmap files of atlas size, there is no individual probes asset like in Unity 4. This LightmapSnapshot.asset file would be in the Scene assets sub-directory and not found there if a team member cloned down the Git project form the remote repository and the .asset had been Git ignored.

    If it can somehow be quickly regenerated from asset data then arguably it should be in /Library and not /Assets.
     
  7. DanSuperGP

    DanSuperGP

    Joined:
    Apr 7, 2013
    Posts:
    383
    Yes whether it's safe to actually put in a .gitignore and whether it will rebuild itself is an important consideration.

    If it's something that's going to change often, is binary, and is that large it will bloat up a git repo to huge in a very short span of time.




    My .gitignore is a bit bigger and I find it works very well. I found it online somewhere described as "the best .gitignore for Unity" and it's much more comprehensive than the one github provides.

     
  8. Jesper-Mortensen

    Jesper-Mortensen

    Unity Technologies

    Joined:
    Mar 15, 2013
    Posts:
    196
    The lightmapsnapshot contains all the data needed to update lightmaps and lightprobes at runtime. This includes all the Enlighten data needed to update the global illumination at runtime. Currently, this file is a bit bloated as it contains data for multiple platforms - we will fix this. Also I'm considering adding some compression for this data.

    Concerning the rebuild time this will vary. If your GI cache is populated i.e. you have done a bake on the machine before (on the scene in its current state) it will be fast. If you are pulling the scene to a machine with a blank cache or the cache data needed has been removed due to the cache size limit, the cache will have to be populated first which requires the precompute and bake processes to run. These can take some time.

    You can see your cache settings in Edit->Preferences->GI Cache. It is of course also possible to share the cache folder via some other means, this would make the snapshot rebuild faster.
     
    IgorAherne and StormyShelter like this.
  9. seattlebluesky

    seattlebluesky

    Joined:
    Sep 2, 2014
    Posts:
    170
  10. seattlebluesky

    seattlebluesky

    Joined:
    Sep 2, 2014
    Posts:
    170
    Is the GI runtime data in LightmapSnapshot.asset less 'bloated' for RC1? I noticed that in Beta 22 it's still a healthily large size.

    Given that it's the data for updating GI at runtime I'm assuming it's important to version control. Unfortunately the size is such currently that this isn't possible using a source control remote like GitHub.
     
  11. superpig

    superpig

    Quis aedificabit ipsos aedificatores? Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,156
    Well, it is generated data. It ought to be the case that you can recreate the file with the exactly the same contents just from having the scene and mesh/material assignments all be stored. And if you're using continuous baking while you edit your level, it's going to be changing very frequently, and there's not a lot of point committing it over and over. So, I would say that perhaps you should not be putting it into source control.

    Yes. Unfortunately I think Github - and Git in general, really - is simply unsuitable when you have large binary files like many game projects do (e.g. it's no good for storing high-resolution source PSDs either). I ran into this on my own project (at Bitbucket, not Github, but same problem) and eventually moved over to Unfuddle who have no such restrictions.
     
    seattlebluesky likes this.
  12. seattlebluesky

    seattlebluesky

    Joined:
    Sep 2, 2014
    Posts:
    170
    @superpig unfortunate but workable. Sure these kind of generated files don't need to be versioned, but there's a convenience and time savings not to have to re-bake if they are clone-able from a remote copy. If in future versions of Unity 5 something could be done to reduce the size of the GI realtime data that would be swell.

    Currently for one of my scenes the baked GI data at 15 texel resolution generates 200Mb of baked data split over 14 2048x2048 EXR files (light and direction). The corresponding realtime GI data at 2 texel resolution (this could be lowered for the scene I'm sure) generates 900Mb of data in 1 monolithic asset. Perhaps as @Jesper Mortensen says this may in future builds be reduced by a platform dependent data split and/or compression. Lossless compression (ZIP) on the realtime GI data gave a 14% reduction on the 900Mb file. Different layout or data format of the realtime GI may get more reduction.
     
    Last edited: Feb 8, 2015