No, you still don't get it, and please read the whole sentence, not just the first part.
I did, in fact, read and understand the complete sentence, and would very much appreciate a change of tone. It's not particularly encouraging for me to get into a project like this.
First off, a dimmer channel can be on different positions depending on the fixture you use. On Scenes this is fixed. On palettes, it doesn't matter. It is elapsed at runtime depending on the fixtures a Scene has in THAT moment (and can be changed in time)
Second, I also mentioned Pan @ 36°" or "Yellow color". 36° can be one value on a fixture with 540° pan but another value on a fixture with 630° pan. On Scenes this is fixed because it doesn't work on degrees but on DMX values. Same for "yellow color". It can be applied to a RGB fixture but also to a CMY fixture.
That still sounds like an abstraction. You take an abstract value, "Pan @ 36°" and map it to a concrete DMX value for some fixture. As you say that may be in different positions, possibly even across multiple channels or even just parts of a channel.
Now, that does in no way imply that it's implemented as abstract classes or such in the code of course, just that the concept is an abstraction.
See screenshot. I imagine defining a 3D volume where a selected group of fixtures should point toward, always inside and never outside of it.
This means calculating the min/max pan/tilt degrees each fixture should be limited to to point the defined volume. A 2D area would lack proper tilt calculations and could point to the ceiling by mistake.
Since generic items (like the cube I used for the screenshot) are saved in the monitor properties (which is indeed preview stuff), I'd say a "volume area" can be placed there for consistency and not among palettes, which are used exclusively by Scenes.
Yeah, that about sounds like the second part I talked about; automatically calculating pan/tilt limits for the area based on fixture position/orientation.
I see that that would be useful to some people, however, I don't think using the 3D view should be a requirement. Both from a personal view (I would sadly rarely have the time to setup a full 3D scene) and generally for this application (QLC+ is really great because it's easy for newcomers, you can start off really easy, from just controlling the DMX channels, to adding fixtures, to creating simple scenes to more complex functions etc.), requiring the use of the 3D view would gatekeep people from using this feature).
What I could imagine as a decent compromise would be going with my feature roughly as described in the OP (with a 2D, pan/tilt, XY, control) but then making it possible to "link" a 2D area to a 3D volume. If linked, the user would be restricted from manually adjusting the pan/tilt limits and they would instead be calculated from the 3D volume as you describe. That way you can, just as with the rest of QLC+, use either feature (areas/3D view) or both together.
Another thing to think about for a 3D volume would be a case such as the following (green being a volume/area for "Dancefloor", the red dot a moving head and the blue lines the extent of the light beam):
- namnlös.png (7.58 KiB) Viewed 1992 times
That's accepted according to the calculation (beam passes through volume) however it points at the back wall. This is likely fine if you have lots of haze/fog, however without haze/fog or even just a slight haze it might not be the result expected. Just a thought that might need to be adressed.
