Closed bwelle closed 6 years ago
@theo-armour @chiensiTB @antonszilasi
There are 4 primary areas of development for the demo (2 quite very related)....
Build Well Geometry Specification/Visualization: This is basically what has been "Build Well" releases, and includes input fields and resulting 3d and 2D geometry views. Current release is Issue #47 .
gbXML Export of Build Well Geometry: This is now summarized in Issue #50 .
3D Scatter Plot Visualization: 3D Scatter Well is current addressed in Issue #38 .
2D Scatter Plot Visualization: We haven't discussed this much, but we'd like to have this for the demo. Hopefully it will be a fairly simple derivative of the 3D Scatter Plot.
@theo-armour @chiensiTB @antonszilasi
Build Well Geometry Specification/Visualization:
Implementation of logic for new geometry parameterization, detailed in Issue #48 .(Theo to do for L-Shape, then Anton can probably take it from there).
Put x,y,z axis on the ground plan, make it black and thicker so it's very clear to the user visually, and put letters x,y,z on them. 3D text. (Anton)
Add new window inputs and logic to place window arrays. (Anton)
Add N,S,E,W letters to view. Calculate based on angles so updates as rotate building. Make letters 3D. (Anton with Theo's help).
Create 2D ortho view that updates with 3D. (Anton, theo has given an example how how to do this with some simple shapes)
On 3D ortho view, show Length, Width, and Thickness (as labels, or 2D text) next to the appropriate side by shape. (Anton)
Take ortho view zoomed into building extents and place labels (2D text) for zone #'s for Space Layout Page. (Anton)
@theo-armour @antonszilasi
3D Scatter Plot Visualization (Scatter Well)
Details are in Issue #38 , but I will summarize some tasks here:
1. Modify Theo's current code that is hardcoded in a few places to flexibly import a variety of inputs and outputs (i.e. our new dataset on Google Docs). (Anton to give this a go).
3. Scale appropriately the geometries of each data point with the axes units/ranges so visually navigable (i.e. not too many shape clumps). How do we deal with inputs and outputs that are very close? (Theo)
4. Update HUD so only a fixed number of inputs/outputs to be shown. Let's assume we simply display the following inputs and outputs in the HUD...Inputs: Footprint Shape, Building Area, Num of Floors, Floor Height, Orientation, WWR, Window Type, Overhang Depth, Wall R-Value/Type, and Roof R-Value/Type if applicable. For Outputs, we will display Annual Cooling Load, Annual Heating Load, PV Generation, and EUI. That's 14 lines items, which should keep the HUD to a minimum. (Anton)
6. Fix Annual Cooling Load on the Z-axis, EUI on the X-axis, and # of Floors on the Y-axis. (Anton)
8. Create a preference shading slider for Annual Cooling Load and EUI, the two fixed outputs for the plot. Somewhere the user clicks whether they want to maximize or minimize that output objective, then they can use the slider to define which one is more important to them, which will then change the color transition on the X and Z plane only. (Theo) Just need to add naming on sliders
@theo-armour @antonszilasi
How do these breakdowns sound to you guys? Just a first pass....
@bwelle
In reply to:
Implementation of logic for new geometry parameterization, detailed in Issue #48 .(Theo to do for L-Shape, then Anton can probably take it from there).
The geometry for all nine shapes is on bw qLine. Fingers crossed that once we have parameters working for one or two shapes then it will work for all. Or It's a silly demo on GitHub with only a couple of shapes. But, yes, if things get difficult, then we have priorities.
Add N,S,E,W letters to view. Calculate based on angles so updates as rotate building. Make letters 3D. (Anton with Theo's help).
Will work on this after parameters are working
Add opacity slider. (Anton)
@bwelle
Thinking out loud:
The trend on GitHub seems to be one issue per issue. This can make for a lot of open issues. But it also makes it easier to close issues and move on,
@theo-armour
The geometry for all nine shapes is on bw qLine. Fingers crossed that once we have parameters working for one or two shapes then it will work for all. Or It's a silly demo on GitHub with only a couple of shapes. But, yes, if things get difficult, then we have priorities.
Unfortunately it won't go so smoothly. Each shape has it's own equations to define upper and lower bounds based off Length and Width, so any new shape will need it's own set of equations, with Length and Width each having it's own unique min and max values for a given value of area, # of floors, and Length and Width itself. That's what I think without knowing more about your code. We will see after the first shape integration.
The trend on GitHub seems to be one issue per issue. This can make for a lot of open issues. But it also makes it easier to close issues and move on,
Understood. But I need a primary thread to summarize everything for everyone's benefit. Feel free to take an individual item, make it it's own issue so you can close when complete. But I will still keep it on this "master" issue, then delete it once the more specific issue is closed.
Closing to more efficiently document.
@theo-armour @chiensiTB @antonszilasi
I have closed the previous Build Well PM issue and am creating a new update to date one. I will try to have this serve as a central location for all the various initiatives here on Git between Theo, Ben, Anton, Chien Si, etc. It will reference when appropriate other issues. Specific comments pertaining to a given issue should be made within the specific issue itself. If nothing more, this is a place for me to keep things organized in my head.:)