ADR 276: light sources #276
Conversation
Deploying adr with
|
| Latest commit: |
9443ca5
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://796f0b8f.adr-cvq.pages.dev |
| Branch Preview URL: | https://light-sources.adr-cvq.pages.dev |
There was a problem hiding this comment.
Thank you for putting this ADR for light sources! This is a crucial feature for Decentraland.
I want to take this place to debate this, given the previous work we've done in the protocol. Please take a look before reading the next part:
- https://github.com/decentraland/protocol/blob/protocol-squad/proto/decentraland/sdk/components/light.proto
- https://github.com/decentraland/protocol/blob/protocol-squad/proto/decentraland/sdk/components/spotlight.proto
- https://github.com/decentraland/protocol/blob/protocol-squad/proto/decentraland/sdk/components/global_light.proto
I had written a whole text to comment as a review, but then I split into different topics and comment each part of the ADR to keep the conversation cleaner :)
| - The creator can chose the shadow resolution as a setting on each light source | ||
| - The shadow resolution is picked by the player in the user’s settings, as a global option. If they have low settings they’ll always use low res | ||
|
|
||
| ## Limitations |
There was a problem hiding this comment.
I suggest removing the "Limitations and Considerations" section from this ADR. Here's why:
- Separation of Concerns
- This ADR should focus on defining the light component interfaces and their behavior
- Implementation details like performance limits should be handled separately:
- Engine-specific optimizations
- Platform-specific limitations
- Scene-level restrictions
- Flexibility for Implementations
Let each explorer/renderer decide how to handle:
- Maximum number of lights
- Shadow map allocation
- Performance optimizations
- Mobile vs desktop capabilities
- Low-end vs high-end configurations
- SDK's Role
The SDK can provide:
- Platform-specific warnings
- Best practice guidelines
- Performance recommendations
- Scene validation tools
- Better Documentation Structure
These topics deserve their own documentation:
- Performance best practices ADR
- Scene optimization guide
- Platform compatibility matrix
- Implementation guidelines
This approach:
- Keeps the component specification clean and focused
- Allows for platform-specific optimizations
- Enables future improvements without spec changes
- Lets implementations evolve independently
There was a problem hiding this comment.
I’m okay with removing the Limitations and Considerations section, but I’d like to challenge this approach slightly. These limitations guide how each client should behave, ensuring consistency across implementations. Without them, we risk significant divergence in how the feature works across clients, which might shift responsibility to creators to adapt to different behaviors.
Creating a separate ADR or RFC for these constraints could work, but we’d need to align on how the protocol should remain generic while still providing a baseline for consistent behavior. I also see the value in keeping this ADR abstract to allow for experimentation and flexibility, but it’s crucial we ensure creators aren’t left with unpredictable experiences due to discrepancies between clients.
Are we ok with having that differences between clients?
If we move this to another ADR, then we need to provide a clear guidelines, tools and documentation for creators to navigate that different clients.
There was a problem hiding this comment.
I agree with both, the ADR should focus on the protocol, but sometimes the protocol is more than just the data sent via the transport, it's also about the expected behavior.
I simplified these lines to something more generic:
Each engine is free to determine considerations like shadow resolutions, or putting a limit on the number of shadows being computed and how to prioritize these. It's recommendable to make these variables dependent on user quality settings.
No description provided.