by 0xb2223f4038def8a62a86e3c4b108cdfe00a74c4f (Chillin)
Should the following $5,999 grant in the Platform category be approved?
Abstract
This project aims to develop a platform to test and explore the possibilities of increasing scene limitations in Decentraland. By identifying key performance bottlenecks related to entities, materials, textures, height, and more, we plan to showcase the possibilities to increase the performance. This initiative will allow users to dynamically test the limits in-game and hopefully increase the limits in the docs.
Decentraland’s SDK6 imposed specific limitations to ensure optimal performance and stability. Recently, file size limits have been increased, but limitations on entities, bodies, triangles, height, materials, and textures remain. Exceeding these limits can lead to lag, crashes, or degraded user experiences but recent testing indicates that the new client can handle more objects; for instance, we have successfully tested over 50,000 textured planes using “dynamic swapping” without issues.
Current Limits:
Triangles: n x 10,000
Entities: n x 200
Bodies: n x 300
Materials: logâ‚‚(n+1) x 20
Textures: logâ‚‚(n+1) x 10
Height: logâ‚‚(n+1) x 20 meters
Project Plan:
Test each of these limitations in various combinations, sometimes exceeding them using “dynamic swapping” (adding/removing objects via a server).
Measure the impact on performance as we approach the limits.
Identify thresholds where performance degradation becomes significant.
Develop solutions to improve the limitations algorithm.
Release the platform and findings to the Decentraland community.
Suggest potential enhancements to the SDK.
Encourage collaboration and testing.
By undertaking this project, we aim to enhance user experiences and contribute to the growth and vibrancy of the Decentraland platform.
Roadmap
Phase 1 (Month 1):
Platform Development:
Build the core testing platform to evaluate all specified scene limitations.
Measure performance metrics such as frame rate, load times, lag, and resource usage.
Document the effects of approaching and exceeding each limit.
Phase 2 (Month 2):
Advanced Testing and Optimization:
Explore combinations of limitations to understand their cumulative effects.
Identify optimal configurations for complex scenes.
Reporting and Community Engagement:
Compile a comprehensive report detailing findings and optimization strategies.
Highlight practical tips for creators, such as efficient use of textures and materials.
Release the testing platform as an open-source tool.
Engage with the community through workshops or webinars to share insights.
sorry for the misunderstanding…
The limits were created in SDK6…
But they haven’t been rereviewed since we moved to SDK7…
So this is a proposal to increase the limits for SDK7…
Both the Foundation and Protocol squad working on the Godot/Bevy client have testing scenes.
As I said in my vote comment, the limitation are not here due to the lack of testing but due to an unwillingness to change the limit, it’s simply a decision to not change it for now.
If I understand this correct, you will develop an SDK7 scene where you can add/remove Entities and materials on the go. You will upload the code to Github or alike. People will be able to download this scene and upload on their land to see the limitations of their devices. You will use the scene to gather information about what (triangles, bodies, materials) is causing the problem and give feedback to foundation so they can work on it.
It’s a good idea, yet it is too expensive in my opinion. Above mentioned stuff could be coded/achieved in a weekend. I don’t see a $5,999 value if you don’t contribute code to SDK which would solve a couple drawbacks.
As far as I know, the limits are documented but not enforced by any client. In practice, if your scene exceeds these limits in production, nothing really happens. It might be helpful if someone from the Foundation could provide more clarity on this.
I believe each explorer must determine which limits to enforce and make that information public. These limits will also vary depending on the performance-to-device target curve.
To illustrate that these limits aren’t being applied, take a look at Genesis Plaza, which consists of:
Parcels: 379
According to the documentation, the limits should be:
Triangles: 3,790,000
Entities: 75,800
Bodies: 133,000
Materials: 172
Textures: 87
Height: 172m
Here are some of the current stats for this scene (which works across all clients):
Height: Within limits
Triangles: ~50% of the allowed limit, so that’s fine
Textures: This limit is definitely being exceeded. Although we don’t have an exact number, the external textures cause the scene to break the limit.
Materials: 8,310 vs 172 allowed (a significant overage)
Bodies: Data not available, but it’s less relevant since physics mainly run for locomotion.
Entities: Stats aren’t available, but for all SDK7 scenes, the limit is 2^16 - 512 = 65,024 (with 0 to 511 reserved for entities).
One of the most resource-intensive aspects—handling various materials and textures—is clearly broken.
Yooo Lean
I know they’re not enforced.
I also agree that each explorer should determine its own limits.
I’m just trying to figure out where the problems start? I have also noticed that it doesn’t like too many textures and materials, similar to the current limits…
Nowadays I generally build scenes not really caring about limits and sometimes it crashes when I post it live…
And nobody should ever see this screen …
Soooo yhhhh, I have 6 devices ready to test and I can do this in bevy as well…
Depends how deep down the rabbit hole we want to go really.
I did the dynamically swapped shark in a weekend.
But it would take a lot longer to do something more comprehensive.
I think it’s a necessary proposal but let me know if I’m wrong…
If you ask me, what we need are solid explorers that don’t crash (and I include alternative explorers) and that must handle the scene overload properly. We also need proper tools that raise not one but several warnings before deploying an overloaded scene (and where you can select what target, low-end or high-end) and a profiler to debug them (no-code friendly).
Maybe you wonder, what about scenes that dynamically overload? Well, a solid explorer has to handle them and warn the player if they’re a risk, or directly kill the scene if not taking action could trigger a crash or out-of-memory.
The research you propose is okay, but it should be included in an explorer roadmap and/or SDK one.
Agreed.
You could probably have warnings in the explorers saying things like “Loading textures 200/10,000 (Do you wish to continue?)”…
I think eventually we will go back to enforcing limitations. (Maybe in SDK8 )
If we have the solid explorer that we talk about. Then we still need a scene like this to test it’s limits. I can deploy this to genesis city so any explorer can test.
I did a recent experiment but you need to get 10 points before dynamically adding numbers:
The issue with this proposal is that it is being put forth in front of the DAO without any of the preliminary motions befalling a request of this kind.
While dynamic testing is something which will be beneficial to any software project, the priority, cost, and other factors have absolutely not been considered by the DAO, so informed decision is rather difficult at this point.
My suggestion is to start with a Pitch to ascertain the DAO’s considerations about the need for such functionality.
Then this can be moved on to a Tender, in order to provide the appropriate opportunity for the job market to help the DAO determine what should be the proper compensation.
There were votes to increase the limits but there was limited discussions about how much…
I already have a few different builds that are using dynamic swaps…
I have a ui card game, a golf game, ai that can recreate objects and more…
Since the grants are getting deprecated i thought I’d just compile all my unpaid work for the last 2 years and release it…
I constantly see people asking for things that ive already built… like importing glbs from external websites… So why not just release everything like this…
I dont think paying the cheapest bidder is a better solution in this situation… but sure can do…
$5999 is also pretty cheap to avoid all the time wasting of bidding etc
I actually agree that this testing should be done ! The DAO should fully support a Pitch and Tender motion for setting it up.
And simply on the merits of your being the inspiration for this project, I would prioritize a Bid from you if it reaches that stage.
Nevertheless the DAO must be given the opportunity, in the Tender phase, to properly ascertain the breadth and scope this project currently needs to have.
Ive spoke with a few people about this…
Its not really something being explored at the moment but imo its 100% the future…
The 2 things i disagree about the bid and tender:
If I’m outbid then it would be someone else building my idea.
Bidding and tenders take ages and the process is slow. We need to do a pitch that takes 2 weeks… we need to redefine… more weeks… then a bunch of teams need to waste time convincing people that they can do the best job… more weeks… Then if we get to that point where someone is approved… then we build… Its a waste of time for voters and a waste of time for teams… Only to maybe not be approved… which would be a complete waste of time… Even me writing this post is a waste of time… and if you’re still reading… sorry for wasting your time
It is never a waste of time to listen to the concern of others.
Here are my two satoshis:
If the idea is successful, it will benefit the whole of the DAO, including yourself, by improving the functionality of Decentraland. This is the principle to keep in mind.
Furthermore, the gratification from the community should still be there during the bidding phase. I would personally vote for such a bid from you, even if another bid seems to somewhat more attractive.
Nevertheless, if you are outbid by a significant amount, by a team that shows it will be able to do the work that is desired, the DAO should still be considered entitled to choose the more equitable route.
Bidding and Tendering is not a quick process (for now), but it will remain important for the members of a decentralized community, that have the required expertise, to have a chance at voicing their opinion.
The process could stand to be streamlined a bit… Nevertheless, it is even the case that all the decentralized tools are there for anyone to attempt to start the motions for this streamlining !
I want to build for decentraland and get paid though. I have a proven history. So why should my idea be built by someone else…
This has never been the way historically. Are you saying that golfcraft or wilderness should of gone to bid and tender?
There were 3 proposals about increasing the limits which all had more yes than no votes. We had many discussions here and on discord about increasing the limits but nothing manifested from those discussions. This could of been proposed at launch 5 years ago but nobody is interested in doing it.
Why dont you go through the whole bidding process for this proposal? You can even submit my entry for me as well. Then let me know when i need to start.
…
