by 0x54e93609eb454a1f152edefdf022480794ce2130 (Roustan)
For years many community members have been wanting an increase in parcel limitations. With the incoming client 2.0, thisis a great opportunity to get things rolling on an increase.
Currently the limitations to deploy a parcel via SDK are at 15mb per parcel and capped at 300mb MAX (regardless of estate size).
I propose an increase upgrade to 30mb per parcel and no max cap based on estate size.
With these performance improvements promised by the new client, especially since it is no longer a browser based end goal, Decentraland needs to be able compete with the creative potential as other client based such as Sandbox and Nifty Island.
Hey @Roustan , I’m not totally sure if I agree with this because it’d focus only on the new reference client (there might be more clients, e.g., web and mobile) and only on one part of the issue (the storage).
After an analysis, we should propose limitations to limit the root cause and not the storage. These constraints should focus on how many materials, textures, vertices, and/or primitives a scene has running.
You can have a huge parcel size and the capability of more storage to have more diversity, but memory limitations are always there, so you have the responsibility of managing those resources smartly.
If there are proper tools to manage this, inspect it, and debug it before deploying, we could start considering removing the maximum size. For now, it’s manual work that only some are doing.
Main reason why I disagree, only related to 3d models and textures, I believe it’s possible to create very beauty and very well optimized scene with baked textures and many models with current limitations. I don’t think we need size increase for models and textures.
Main reason why I agree is that with 15 mb limit it’s impossible to include good quality images and videos for 16x16 gallery scene, for example.
I’m not sure that it’s required to increase size limitations for all parcels. But I would increase size limitaitons for 1x1 and 2x1, 2x2 parcels, maybe. Not sure if size should be doubled, I think it needs to be individually calculated for different sizes.
Same with wearables, It was absolutely fine to have 2mb limitation for wearables, the are no needs to have more, if models made right from technical side. But for Skin wearables that was a mess, and nowadays, if i’m not wrong, 3mb size was implemented, and this is more than enough for them.
I have some questions regards triangles, materials, textures limit for huge scenes, but for now, with current web issues, this limitations feels fine. They’re good calculated and more than enough for stylized scenes, can’t tell same for coming PBR where only one very good normal map can eat huge amount of space.
Yes, I am directly speaking of STORAGE not asset optimization. I would like to be able to upload MORE optimized assets. Currently, we are VERY limited with what we can upload. I definitely appreciate what I have been taught via the current limitations as far as optimizing assets. And I have pushed all my builds to their limits. But I want to be able to upload WAY more optimized assets than we currently can. It is obscene compared to any other platform what were are able to create. Double that chit, and continue to educate on asset optimization. I would also personally like to double the parcel size to 32 x32 but that’s a different discussion entirely.
Yeah, not talking about assets, just storage. 3mb of the 15 mb are taking by index.js file. we are actually given more like 12mb for a single parcel. And I’ve certainly been able to create some really nice builds on single parcels despite the limitations with fully optimized assets, but we still should not be so heavily limited there, especially since we are now switching from browser to an app. Pop into a sandbox parcel (which is a client app) and you can see an insane disparity in parcel size. Regarding no max cap, an example of a 100 parcel estate once owned by Xeta had the same building limitation (300mb max) as a 20 parcel estate. So really, there is less incentive to buy an estate that is more than 20 parcels. I don’t see why there should be a stop limit to an estate size.
edit: Oh, but also. Perhaps specifics like materials, triangles, etc should ALSO be increased. because if current SDK triangle count was suddenly enforced, I think all my scenes would break right now. And if that happened, with all the optimization efforts I’ve already put into my builds. I might just be done with DCL because those Builder limits are just absurd IMO.
Although this should be a Canny request, but its good to highlight the need to increase the limit for a single parcel. This change would allow creators to use better materials and textures, which I often struggle to minimize them in size.
Additionally, it’s worth mentioning the estate limitations. Which I believe you can deploy as large as your estate allows, from my experience iam developing a 300-parcel recently, where I’ve divided them into smaller estates to work on individually. Currently, I’m deploying on 100 parcels, and so far, I’ve been able to deploy files up to around 600 MB on them ( photo attached).
The key to do it, is that each model’s folder needs to be under 300 MB. So, if you have 900 MB for a 60-parcel estate, you should divide the files into three folders, each with a maximum of 300 MB.
I will verify this with Nico or someone from the foundation and push a modification in the documentation after ensuring it’s accurate and correct .
I’m all about optimization, many years of XP in game design and art installations for virtual worlds, and I think we shouldn’t allow anyone to publish in DCL without the proper knowledge. But I agree with Roustan in here: It’s too little if what we want is to atract the WOW of public, investors, creators… If we are talking at pro-level, ofc.
I agree - we should remove the hard limit of 300mb no matter what number of parcels you have.
Currently a 20 parcel scene (20 * 15mb per parcel = 300mb) has the same storage capacity of a 30 parcel scene and greater. 20 parcels is only a 4x5; not very big. Tominoya Casino is greater than 20 parcels for reference.
With the new client and improved performance, optimizations, LOD, sight lines etc, we should allow for greater scene density and detail through higher file size limitations.
@rizk appreciate you finding a work around and posting! Please let us know what Nico says about its viability. However; this should not be the standard for content creation.
The impact on performance of increased storage availability should really be minimal; it is possible to create scenes with horrible performance even with the given limitations. I believe this is a side-issue.
The main issue as I see it is increased requirements on the catalyst runners themselves, which are separate entities from the Foundation.
@theankou’s suggestion is on the right path, I believe, but rather than increasing the limitations of [1-2]x[1-2] parcels, simply adding a base storage for all scenes instead.
So all scenes could get the current 15MB per parcel (or also have it increased), plus a base 10-20MB, for the javascript code and everything.
But catalysts runners are probably ok with increasing the size per parcel anyway.
Do we have an idea of what would be the impact of such an increase in storage requirement if the catalysts had been moved to the cloud already ?
I bought a large parcel expecting to upload movies… but then it got capped to 300mb… I thought it was unfair to cap it suddenly…
I also think that it shouldn’t matter about “estate size” but instead how many LANDs owned…
Don’t know if this affects the design of the new contract or not…
Also, if this goes to draft can we increase the maximum file size of 15mb to unlimited?
It is another pointless limitation that can be bypassed by splitting a large file into smaller parts and then merged back together…
The catalysts are not a files hosting service, you are just supposed to host your scenes there, large assets like movies or long audio should be hosted elsewhere.
I can understand the convenience of hosting it somewhere else…
But deploying stuff that can last forever is more decentraland IMO…
I don’t see why we would give our competitors our content and support their latest APIs rules?
For the time being, it’s not “stuff that can last forever”, as the cost of storing in web3 is still rather prohibitive.
As far as I understand, the DCL Catalysts are community-run servers, which will hopefully be moved to the cloud at one point. Files stored there are not stored on the blockchain !
