Unity please read this

Hello, im working on a game and the scene is pretty heavy like 4gb for the texture, i saw the problem many and many times thats mean texture broken on 4gb above size build, the problem have been for like 6 years now and your only answer is assetbundle, with HDRP, raytracing... (bigger texture bigger build size), isnt time to i dont know may be adding a built in way to make more than 4gb build without having to"hack" ?

Its like i dont know, a car constructor who telling, yes guys, we did it, we made bigger and faster car but you can run only 1mile with it, other than take a petrol truck with you to do more miles, yeah !

Hoping having a good answer on this.


https://forum.unity.com/threads/bug-4gb-limit-to-textures-in-standalone-build.441116/
https://forum.unity.com/threads/tex...35.168133216.1571139252-1711344860.1559558885

I saw

Isnt this possible now in 2019 ? Sill not possible ?

Thanks
Regards

 

Just break your textures down into different resources so they're not hitting the 32 bit file size limit. This is what asset bundles and addressables are for, basically.

 

Yeah but having to make them is simply waste of time, why unity dont make a built in way right now ?
and i dont make a thread on asset bundle but on build...
i know what they are but having to make them is just wtf even more in 2019 when you see the problem from many years...

 

Backwards compatibility is a major aspect of Unity. Karl pointed this out right at the beginning of the first thread you linked.

 

-_- in 2019 most of devices are 64bit and backward caompatibility and hdrp, raytracing are not compatible i think ?

Like my grandpa telling it was better before , but no, we have to live with our time ... change are here and tomorow as it was yesterday.

 

Correction. The CPUs are 64-bit. That doesn't mean the rest of the hardware supports 64-bit. I'd be very surprised if the actual hardware that handles the textures could handle 4GB natively outside of standalone, PlayStation, and Xbox. If anything I would expect the limit to be 32-bit because memory capacities on anything else isn't that high.

 

Or add a pure 64bit build setting, i dont know but please, someone that want 32 bit will build in 32 bit

 

What a ridiculous sentiment. The benefits of things like addressables and asset bundles are more than just this. They also help severely reduce things like load times and the deployment of additional/altered content when you need to issue patches.

It's hardly a waste of time.

 

For me it doesnt make any sense. Claiming 64 and having 32 bit limitations are just anyonning -_-.

 

Dont change my problem with a pseudo solution ...
Asset bundle isnt my problem once more ...

 

Why would i build in 32 bit as im building for pc ? as my game would never run on a 32bit ever

 

and for ps4 and other 32 bit device no plan at all so ...

 

backward compatibility in 2019, for pc just dont make any sense ...

 

Is just as important as it has always been.

 

Nahhh i had a 32 bit pc back in 2010, 64 from somes years later and in 2019 even raspberry can run 64 bit

 

Once again just because the processor is 64-bit doesn't mean the rest of the hardware is capable of it.

 

It literally is because you're ignoring the fact that asset bundles and addressables fix this problem.

 

I will wait/hope an answer from unity and not waiting pseudo answer, in clear pc build 64 bit more than 4gb build...
No backward compatibility bullshit ... and asset bundle are just hack i dont want to wast times on this ai i still have much to do, If you make a big game this is not your target. do you imagin remaking assetbundle for large scene as asset bundle also have somes problems ...

 

If you have a problem with asset bundles, it's probably solved by addressables. Don't blame Unity just because you refuse to use the tools given to you that can solve this problem.

 

You already quoted the answer from Unity. You didn't bring up any new questions or problems. What kind of answer do you expect, honestly?
I understand the frustration and the need to vent, but what do you expect form this thread?

 

Anyone making a big game should do their homework before they try to build it. Know what the limitations are. It's not like any of this information is buried. That you couldn't be bothered to understand the limits before you started working is not the fault of Unity.

 

The problem is there is a 32 bit limit to the addressable file size for resource files used by scenes in Unity builds. One super easy solution would be for Unity to simply make a file that is not backward compatible with platforms that the user is not targeting.

For example, when I build for 64 bit PC, I don't care about whether or not that build will generate files that are compatible with outdated 32 bit platforms that I am not building for. Unity's build tool should be smart enough to allow for 64 bit files on 64 bit platforms in 2019, while still allowing for other builds to properly target other platforms.

And asset bundles are not a perfect answer for this. Asset bundles seem to work fine for small projects with small assets. I had real problems using asset bundles with larger projects on PC. I used Multi-Scene with great results, though.

Anybody who has not wasted days chasing this bug, count yourself lucky. Don't blame people for not automatically knowing to use asset bundles or Multi-Scene as a file size workaround. Unity does not even tell users that there is a 4GB addressing limit in the build files, so most users stumble around trying to figure out what suddenly broke in their project when they smash into this silly 32 bit limit in Unity.

 

I dont blame anybody here, just this problem have been many time (many threads on it) as windows pc are 64 bits , Pc target peopple can build there 64 bit normal without restriction and wast of time of other platform limitation 32bit isnt a pc limitation so why do we still get this.
If no one ask for it, we will never get it , so i exept make many peopple that are targeting pc may be to not waste time on that sort of useless stuff wich is not related to 64bit , im not building for 32 bit, im not building for ps4 and no plan for them so why the hell those 32 bit limitation make so many peopple wasting time on asset bundle, it would need my game success high to plan on them and im not even sure ...

Dont feel me rude, just if no one ask we will simply never get it, been blocked for a problem that doesnt concern my case is just OMG

 

"Knowing what the limits are" is hilarious in this case. That is literally the problem. Unity does not tell developers about this limit. Even when the limit is exceed, Unity does not tell developers. One by one, people just find out about the silly limit the hard way. If you have never run into this problem, don't victim blame those who have. Thanks.

 

I have never run into this problem but that's partially because I have known about it for years now thanks to it constantly coming up on these forums. If you spend absolutely no time with other developers you won't hear about the bugs they've encountered and ways to solve them. Who would have known?

 

Asset bundles is one potential workaround, but asset bundles does not work great for all use cases. I tried using asset bundles to work around the 32 bit limit in Unity build resource files, and asset bundles offered terrible performance. What I ended up using as a work around was multi-scene. Basically, I split all of my project's major resources into different scenes and then used multi-scene to load all of the scenes at startup. That won't work for every use case, either, though.

 

Someone who know and experienced.Also some duplicate case problem on asset bundle.

 

Good for you. Consider yourself lucky. When I ran into this silly undocumented limit/bug several years ago, I literally wasted days of development time searching for answers. I posted in the forum about it to try to help others hopefully find a solution faster than I did, but even then those people waste a lot of their time hunting for a solution to a problem that should not even exist in Unity in 2019.

People should not need to rely on common knowledge of strange bugs or limits in Unity this many years after the problem was initially reported. Unity has had plenty of time to fix this bug, but they chose to let this become a permanent bug in Unity.

 

BTW, the current comment from Unity on this issue is that they hope to bring a fix in 2020 if everything goes well. Here is a link about that:
https://forum.unity.com/threads/bug...n-standalone-build.441116/page-5#post-5043509

 

Those performance issues are largely solved by addressables, the other thing I mentioned.

 

Ill just take your asset as example unity : https://assetstore.unity.com/packages/templates/packs/snaps-art-hd-european-market-150638 Size: 5.1 GB

Isnt time now with hdrp and higher texture quality. Or may be rethinking those system ?

That would avoid so many peopple wasting times on those limitation

 

Good to see, this is really important even more in future.

 

Your posts say otherwise.

Because rewriting Unity is not a small task. And we're talking about core functions here. That's why. If you read the thread where @karl_jones described the situation, you know it. Although I'm not sure you understand it or care.

That's simply not true as you can see among the answers. And constantly ranting about it won't make the development faster, believe me.

It is not wasting time to handle the assets properly. Look, I understand, everyone wants to get away with the minimum work possible. But following the proper ways to mitigate problems and avoid future ones is always better than ranting about semi-serious issues on the internet.
(semi-serious because although having no limit or higher limit would be comfy, but we have many other techniques in place which work well and have additional benefits)

 

https://forum.unity.com/threads/bug-4gb-limit-to-textures-in-standalone-build.441116/
its not a semi serious issue when you are facing it and you have a deadline, imagine 5000 poepples having to bundle or ressource folder, wasnt easyer to a unity team did that before and arround 5000x 30h to convert to bundle for big scenes thats some waste of times , and even anounced on copenhagen so its ok, i really hope see it

 

That's why you plan architectural decisions ahead of time instead of flying by the seat of your pants and doing everything in the least efficient way possible.

 

you know juging peopple wont make you better ... and wont help on those problem...

 

It's hard not to judge someone when they're ranting about how the problem is the fault of everyone but themselves.

 

From someone who never facing those problem ... keep talking you were usefull here . trying to find me a problem for an old unity problem, im certainly a unity worker and i own all source coude ...

 

this is why a 5 years old thread is still not solved .

 

On the contrary there are tons of solutions in that thread. That you don't want to use any of them is your problem.

 

@SunixDev

You don't want to read anything at all that shows you as being wrong with how you planned out making your game. You also don't want to read any of the solutions to your problems people have given you.

All you want to do is moan and complain and start a flame war. Get a grip and realize that you're in the wrong with how you are replying to others in this thread. Grow up and chill your bones.

 

If we never faced these problems, why do we know at least two solutions?

 

Oh, and just to be precise here. The 4GB limit is not a bug. It is a limitation. Per definition.

 

Who said bug ?
When you have stuff to do, you dont have to find a workout due to limitation, im not a dev of unity i own my deadline and remaking asset bundle isnt in my deadline for a so big project, you can call me whatever you want in this time im not trashtalking, and other solution are just bad for open world, do you imagin loading assetbundle on a loaded big world and how far it can slow down ?

 

Did you even work with asset bundle with larg area ?

 

An enormous multi-gigabyte file is going to be slow to load regardless of whether you store it in an asset bundle or store it in the main build. I would have subdivided that texture long before it reached that point.

 

as its loading once its ok, its more simultaneous work that woulld slow it like playing and loading same times even more when you use some high setting

 

I literally removed all but the initial load-in in my current project using addressables. Once the game has loaded, there isn't a single loading screen unless you load a previous save, and even that one is mild thanks to the fact that I planned the architecture to allow for this. This is even after converting from the previous asset bundle setup I was using.

Incidentally, the asset bundle system just meant that I was dealing with periodic load times when jumping into zones that weren't loaded due to them being culled because they were too far away.

 

Addressables have a fully configurable async loading process. Everything is handled on a separate thread.

https://blogs.unity3d.com/2018/10/0...ance-understanding-the-async-upload-pipeline/