ADR 276: light sources

[nearnshaw]

No description provided.

[cloudflare-workers-and-pages]

Deploying adr with    Cloudflare Pages

Latest commit:	5f4b636
Status:	✅  Deploy successful!
Preview URL:	https://7e27a6c1.adr-cvq.pages.dev
Branch Preview URL:	https://light-sources.adr-cvq.pages.dev

View logs

[leanmendoza]

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 :)

[leanmendoza]

I suggest removing the "Limitations and Considerations" section from this ADR. Here's why:

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

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

3. SDK's Role
   The SDK can provide:

• Platform-specific warnings
• Best practice guidelines
• Performance recommendations
• Scene validation tools

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

[aixaCode]

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.

[nearnshaw]

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.