Dmitry Bondarenko

What I am saying is basically having a `channel` field in `THREE.Light` and `lightChannel` field in `THREE.Mesh` or something like that. If the latter is null then it is affected...

Well, I could achieve something like that with shadows (and I've already tried), but it gives different side effects and I feel that it is a hack, because I don't...

Maybe the most simple solution could be the most effective here: 1. Add a `channel` (or `group`) to `THREE.Light` 2. Add a `affectedByLightChannel` (or `affectedByLightGroup`) to `THREE.Mesh` (Or maybe even...

Maybe the 'affectedByLightChannel' is too long and something like 'lightChannel' would do, but I think it would be convenient: just channel numbers on light source and receivers. Like that: ```...

If `lightChannel` is equal to 0, then it is affected by all channels. If `channel` is equal to 0, then it affects all meshes. So it would be fully backward...

Seems absolutely fine to me. Maybe it is a bit more difficult to use in some cases, but it is easier to understand, obviously.

I could give an example from the task with two rooms above. The main point of using the channel approach over the array approach is that simple operations like 'move...

> Well, that's a problem. Channels would not be object-based. But why? Is it a technical limitation? Because it kind of invalidates the whole idea of all that. Because there...

Shadows is also a related topic. I think there should also be something like selective shadow casting. Like 'receiveShadowFrom = ...' (and list of sources) instead of just 'receiveShadow =...

> Shadows attributes should really be on the materials and not the objects for the same reasons as above in this thread. Yes, it makes sense!