[quote="BET, post:20, topic:23195"] I want to build for decentraland and get paid though. I have a proven history. [/quote] Great ! But it is not up to you alone to decide what Decentraland should be building. And testing various hardware limitations isn't really a new concept. [quote="BET, post:20, topic:23195"] This has never been the way historically. [/quote] It would appear that historically, the Grants Program, and the Pitch / Tender / Bid process, have been tragically mashed together. From what I understand, the **Grants Program** is intended to **onboard work** that has been **completed**. It should be **including** clauses such as "the **code** must be made **open-source**". And there should **not** be any kind of time-table for **future work**...

1. 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? 2. 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. 3. 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. 😉

[quote="BET, post:18, topic:23195"] Even me writing this post is a waste of time… and if you’re still reading… sorry for wasting your time [/quote] It is never a waste of time to listen to the concern of others. Here are my two satoshis: 1. 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. 2. 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 !

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: 1. If I'm outbid then it would be someone else building my idea. 😓 2. 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

[quote="dao, post:1, topic:23195"] Exceeding these limits can lead to lag, crashes, or degraded user experiences but recent testing indicates that the new client can handle more objects [/quote] 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.

Enhancing Scene Capabilities Through "Dynamic Testing" This proposal is now in status: REJECTED. Voting Results: * Yes 33% 1,010,738 VP (32 votes) * No 18% 564,709 VP (10 votes) * Abstain 49% 1,484,695 VP (10 votes)

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

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.

Still need a bunch of votes if anyone has any......

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 :sweat_smile:) 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: https://decentraland.org/play/?position=95%2C122&realm=dg&island=I14iy1

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.

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 :sweat_smile:..  Soooo yhhhh, I have 6 devices ready to test and I can do this in bevy as well.. [quote="OnSr, post:8, topic:23195"] It’s a good idea, yet it is too expensive in my opinion [/quote] 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..

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.  Edit: file size and total size is already checked in the catalyst side :slight_smile:

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.

But still no opensource scene tester in-game? [There is a poll to increase the willingness..](https://decentraland.org/governance/proposal/?id=77275432-f9ac-4161-88b7-d7a753b95b8a) We need more dynamic testing with different devices to see what works. If you have the code, let's see it.

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.

@HPrivakos if the limits are updated, how will they be tested? Something like this still needs to be built... dynamically swapped shark:  https://decentraland.org/governance/proposal/?id=77275432-f9ac-4161-88b7-d7a753b95b8a

OK thanks for clarifying

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..

I thought this was the point of migrating to SDK7, which is almost complete. Why study SDK6 ?