Shading Design Applet: This is an interactive applet showing real-time window shading analysis. Click and drag the shading diagram itself, window edges or any of the shading fins to see the shading pattern change as you move things around. Use the middle and right buttons to pan and rotate the view respectively.
Pointer Controls
Basically, you can drag the shading mask anywhere behind or in front of the window and shading devices and see the effect of the window and it’s shading in real time. It’s particularly useful if you select the Obstruction Colour option in the Shading menu to distinguish the effects of each shade. This is really useful as you can image what it will be like once the room behind has been defined.
NOTE: You can also move the shading mask up and down using the Z and Shift + Z keys.
I specifically made the front and back faces of the rear wall un-selectable to make it easier to click-select the window surrounds so that you can more easily adjust the window size. With them selectable, you had to move the view to select different sides of the window. I also added an extra feature where you can press the Space bar to cycle through all the other objects that the last pick might have selected.
Shading Design Rules
For me, the main interest in this experiment was implementing a set of simple design rules where the various model components interact as you drag any one of them. Rather than create a series of artificial draggable nodes that define the main characteristics of the shading system, is it possible to give the user freedom to manipulate any component as they normally would, but make the model smart enough to update itself appropriately?
I was hoping I could do it using a simple inter-object relationship class which defined some basic boundary and offset dependencies, created and applied at design-time. However, this wasn’t as trivial as it first looked as the best order of rule application seems to depend very much on which object is actually being dragged. Also, because you don’t know how big or complex a model is going to be, I only wanted to update the selected object each drag iteration rather than have to check all objects. However, this approach initially turned out to create all sorts of circular dependancies and to often apply them out of order, especially for louvres where they are co-dependant on some parent parameters.
After a bit more work I’ve sorted out most of the rules pretty successfully now, but the self-imposed restriction of only updating the currently selected object has thrown up a couple of glitches that I need to look into further. If you are interested, you can see this if you drag the horizontal shade up and down quite quickly. Doing this also adjusts the top surface of the left and right fins when it covers them. For me, updating means the more intensive re-calculation of plane equations, vertex normals, surface areas and bounding boxes. Thus, by only updating the selected horizontal shade as it is dragged, the bounding box of the vertical fins stays the same until you release the drag. Because the bounding box is used for hit-testing, you may see a small gap appear above where the vertical fins should shade as you drag, which disappears as soon as you release. Looks like I may have to allow partial updates of other objects during interaction but I’m not giving in just yet.
UPDATE 2nd June, 2011
Hah! Found a way around it by simply adding rules for linking bounding boxes as well as object vertexes in the inter-object relationship class. You shouldn't see any glitches at all now.
Click here to comment on this page.