#So yeah, that's a bit besides the point

1 messages · Page 1 of 1 (latest)

short hull
#

To that point: I really don't really know
I'm like 66% sure it generates a new meta file when you bake, because when generating a lightmap asset it gets import settings like compression from the lightmapper

#

But other points are relevant I think

I've been using lfs from the very beginning, and from my experience, lfs actually stores each change as a whole new file.
Afaik there's technically no way to store deltas for binary files, that'd have to work uniquely per-format and wouldn't be particularly useful because even with slight changes the data can get replaced or reordered in many formats
It'll happen regardless of version control method
One point of it I believe is that not every version of binary files needs to be packed in the cloned repo even if the whole code history would be

#

Mainly it's meant to separate non-code files so they don't have to use the code format packing algorithms for delivery, and can be controlled separately

ashen bay
short hull
#

Well, should be really quick to try

ashen bay
#

Also, I am not concerned about the size of the cloned repo, since you mentioned it, I am trying to optimize source control due to insanely unfair github lfs pricing.

ashen bay
short hull
#

Obviously you don't rebake the 2 hour lightmap for this test

ashen bay
#

Good point, let me make a test scene 💀

short hull
#

Simplest scene with low lightmap settings should take much less than 30 seconds
Then commit and push just the meta file
Then delete the lightmap locally and bake again
See if commit reports meta file as changed

short hull
#

Because if no and no, there is a bit of a hack you can utilize
Git's LFS service has storage limits, but repositories themselves don't
So if you exclude the lightmaps from LFS, you can push them as code/text and it won't count towards the cloud storage limit

#

With the drawback that now they'll be included in your repo's history rather than LFS history, so if you want to clone the repo with history, you'll always be lugging along every version of the lightmaps there has been

ashen bay
#

Good point for excluding them from LFS, however, it makes git a ton slower from my experience.
Also, I am concerned about the total file size, as I don't use just github, I also use gitlab which has a 10GB storage limit.
My setup is a bit complicated.
I host my own forgejo server that clones to both github and gitlab 💀
Even if I was to include them as non lfs object, I feel the repo would quickly grow in size, unless I decided to not commit them constantly, which leads to another issue where I'd never have a clean working branch, which complicates things a lot. That's why I feel that excluding them fully would be a better option.
I am honestly just trying to solve problems as I go because I've never worked on a bigger project before this :/

short hull
#

I work with a smaller team, we have 0 income, and paying for insane l+s prices is not an otion.
GitHub, for example, expects you to pay for bandwidth, which anyone can just decidn to waste in seconds without any permission.
They have to be collaborators to push changes aka waste space, so not without permission exactly
Ideally your team should understand what's happening when they push their changes

ashen bay
short hull
#

But ultimately you're just facing the same issue from different angles repeatedly

#

You have a lot of data to push, but git can't handle binary files well, and LFS space isn't free

ashen bay
short hull
#

At least storage isn't, I don't believe "bandwidth" has any cost

short hull
ashen bay
short hull
ashen bay
#

Possibly good news.
I just baked again, and only the asset changed, not the meta files.
I'll try manually deleting all the files except the meta ones and seeing if that changes stuff.

image.png
short hull
#

Anyway, github's cloud services aren't your only option or the recommended one really

ashen bay
#

If it wasn't as popular as it is, I'd just be self hosting as it's the best, and cloning to gitlab, but gh sadly gives at least a bit of recognition.

short hull
#

But if you have the option to host locally or rent external space it'd be much better

#

Not better as more convenient but

ashen bay
#

Ok, that's insane.
I'll actually look into this because if we can find a reasonably priced provider, or even self host, we could share all the project save files etc., without worrying about unfair limits posed by github.
Thanks a lot for sharing this with me, I was fully unaware it was even an option o_0

#

Ok, I am not sure whether this is good news or not.
When I deleted everything but meta files and refreshed unity, they appeared with D(probably stands for deleted) in lazygit.
However, when I rebaked, meta files no longer appear as changed, and neither does the scene asset.

image.png
short hull
#

commit and push just the meta file
Then delete the lightmap locally and bake again
See if commit reports meta file as changed

#

But that looks like the lightmap asset, and shows that it did change from its previous version, or so git assumes
Neither picture shows meta file changes though which is what we want

#

Ideally the lightmap asset should not be in the repo, just the meta file alone

#

Hopefully unchanged when baking a new lightmap to be associated with it

ashen bay
#

Ah, so I should exclude LightingData.asset and * Baking Set.asset too?
I thought those had some data I should keep in the repo, but I can easily exclude them too.

short hull
#

Hmm I guess if they are large enough to warrant it, and if it seems they don't have crucial information to keep around
size 18145 means 18 MB?

#

Anyway, what LFS also lets you do with custom configuration is to define how the assets are delivered independetly from commit/branch
So if the cloner is not testing visuals, they could choose to get only super low resolution textures and models
Or so I've been told, this part I have not had to do

ashen bay
#

seems to be 18Kb actually

image.png
short hull
#

Ah, nevermind then

#

I guess that's good then?

ashen bay
short hull
#

It sounds like your repo is going to be public since you mentioned recognition?

ashen bay
ashen bay
short hull
#

There was a fair warning that LFS doesn't tend to get used for public repositories because of the bandwidth limit
Which you'd have to deal with even if you skip using github's hosting for it

ashen bay
#

I see.
Well ig I'll have to find a good host, or even self host to workaround that.

short hull
#

There are several forum discussions with many people asking the same questions with no answers
I suspect this is because once have a project that's exceeding the cloud storage limits, assuming space is not being wasted carelessly with huge files, projects of that bigger size tend to be from studios who either just pay for cloud storage or roll their totally custom systems that they don't bother explaining on forums

#

But this information really could be more available
My knowledge is mostly heard from programmers directly + some very scattered forum posts

#

yet another example of unity's poor version control handling
Git isn't Unity's version control handling at all so it's kind of "extra" that it works at all, and git itself at its core isn't designed to control anything except code and text

#

No idea how Unity's Collaborate handles large files
They likely don't make it the user's problem at all regardless of how it happens
But might not give precise control either

ashen bay
ashen bay
short hull
#

If forking a public repo consumes LFS bandwith, I wonder if that means changes to that fork are allowed to be uploaded to your LFS
That'd be wild

#

But, they're not collaborators allowed to commit to the project itself, sounds like it might not be that big of a deal if the scene can change along with generating lighting for it

#

If the lone meta files can take care of it that'd be ideal

#

The most practical option almost seems to be to keep the baked lightmap assets in like google drive as a .unitypackage for those who don't want to bake them again

ashen bay
ashen bay
short hull
#

True point

short hull
#

Assuming your PR'ers use it

ashen bay
ashen bay
short hull