Basically, and this is ripped from their documentation, instead of a side view, a top down view (technically it has to be a 3d view but for sake of argument and clarity of how the curtains move a top down view is better) and then adjust the curtains to the path that the sun takes throughout the day and projects into the room.
These nodes being used for blinds simplifies it incredibly since all it cares about is if the current azimuth of the sun is between the start and end of the window (90 degrees each side of the orientation for simplicity sake). Versus what I am describing which in effect is breaking the window into smaller (by width only) windows and checking those smaller segments (I assume with the same math) and then adjusting accordingly. Thinking of it in terms of smaller windows that make up a big window actually should make the calculation far easier.
Actually, upon further thought, I am not convinced if as written is “simplified”, it might just be different. It might be calculating smaller “windows” as well, but with a constant width, variable height segments, versus my idea which needs variable width, constant height segments.
Actually on further thought again, you combine those two and you basically have a targeting algorithm with a definable grid size, but back to the problem.
Maybe instead of checking for if it is within the width and then getting the depth into the room, we can check if it is within the height (backtrack from depth into the room and lower and upper heights to get the angle range and compare to current angle (anything shallower I am thinking would extend into the room further)) and then from there check what segment(s) of the width it is entering through:
blindHeight = (tan(altitude)*lengthOnFloor) - bottom
it could be
curtainWidth = windowWidth - (lengthOnFloor / tan(unsure how to express this angle in terms of its relation between window orientation and sun position (maybe their difference? not sure)))
(I think I am missing something to account for the opening from the left or right as well, but I cannot figure out what exactly right now)
NVM, I do not think this actually works, the triangle used does not have a reference point on the window so it can float anywhere in there, so calculating the base is not very helpful.
This works with the blind because it intercepts with the floor by definition, hence it has the reference of the bottom height of the window to calculate the blind position. I cannot find any point of reference in this curtain example however.
Also, I apologize for the arctan/tan mixup, it was like 3am in bed with my phone when I got this inspiration and when I took a second look and actually drew it out, I found the error, though my logic was still correct, I just called the wrong function.
but it must already be calculated since “in the window” is determined currently, though as I understand it that is just a comparison between sun azimuth and window azimuth range.
Yeah that actually seems like it might be doable, it might even be the exact same math used in the nodes I listed above, but just used in a different way. No clue how it would be done in a NR environment though (outside of functions, context variables, and tons of headaches), it seems like something that would have to be done in a traditional programming environment due to the math involved and the complex set of checks.
Also this is turning out to be a very interesting problem, you could reframe it as a grid and the coordinate you are trying to block (or hit) (grid steps defined by the accuracy of the motors) as (x,y), (curtainWidth, blindHeight) and then theoretically block out only certain parts if you had like a x,y motor array that could stretch and contract a cloth across your window. Hell, this sort of algorithm is probably used in stuff from weapon systems to 3d printing…what have I stumbled upon…