These are utilities that generally provide the user with a more pleasant experience with Buildes. They are not all applicable to making buildings and it is generally possible to enter these commands more than once in a single session file. They are provided in alphabetical order. As the documentation grows it may be necessary to organize them differently.
It is desirable for designers to retain ownership of their design solutions. Full responsibility is often retained due to many reasons one of which is because the decisions made originate from professional/personal experiences and styles. To support this, Buildes provides a means for the designer to sign the design. For any design session, at least a designer’s name and phone number must be provided before any information can be saved. It is possible to add as many designers’ information as possible for everyone that is involved with the design. This command can be entered at any point in the session file.
Use the following syntax to use this command:
designer(name, phone, email=None, role=None, office=None)
# name: (String) Name of the designer. This is required.
# phone: (string) Telephone number for contacting the designer. This
# + is required.
# email: (String) Electronic mail address. This is not required.
# role: (string) This is the role of the person whose information is
# + being provided. This is not required.
# office: String) The office name where the designer works.
There are two types of coordinate systems, one can be referred to as left-handed and the other right-handed. These two systems can be described in terms of the z-axis. Imagine you are facing a computer screen. In the left-handed system the positive z-axis increases INTO the screen while in the right-handed system it increases OUT of the screen towards you. In both cases the x-axis increases horizontally to your right while the y-axis increases vertically to the ceiling. Another difference is in the left-handed system the user is immersed in the building which means that the plane (or the ground) is on the xz axis while in the right-handed system the user is looking down on the building which means that the plane is on the xy axis.
Most (if not all) CAD software use the right-hand system while a few other modeling packages use the left-hand system such as POV-Ray. Buildes was built initially to export objects to the POV-Ray scene description language format and so works internally with the left-handed coordinate system (see Coordinates).
In recognition that most CAD users feel more comfortable with the right-hand system, it is possible to tell Buildes to accept right-hand coordinate entries from the user.
Use the following syntax to change entry coordinate system:
entryCoords() # The default. Informs Buildes that all coordinates
#+ entered from this point is in the left-handed system
#+ format.
entryCoords(CAD) # Informs Buildes that all coordinates entered from this
#+ point is in the right-handed system format.
This commands allows the designer to provide information about the building site. The most important information provided here is the North Direction. This is the direction, while standing on the site, towards where the north pin on a compass will point. It is important for orienting the house and putting it in context with the surrounding structures. It is important when designing for ventilation, lighting, insulation, etc. If this information is not provided, Buildes assumes that the north direction is at 0.0 degrees (i.e. towards the top of the computer screen).
In addition to the north direction this command is used to provide the full address of the site. Buildes uses this information to assist the user in the application of codes, by-laws, etc. (not implemented yet). Use the following syntax to use this command:
location(north=0.0, addy1=None, addy2=None, city=None, region=None, country=None)
# north: (float) north direction
# addy1, addy2: (String) First and second lines of site address
# city: City site is located
# region: region in which site is located. It is the same as 'state'
# + in the US or 'province' in Canada.
# country: Country site is located in.
Buildes provides an avenue for communicating about the actions it is taking (or not taking) to the user. It does this using the python logging module. This module provides different levels at which messages are emitted by a program. By default, Buildes automatically logs messages at the level of warn to both a file called ‘buildes.log’ and the console.
Other available levels are:
- debug
- info
- warn
- error
- critical
To change the default log level use the following syntax:
logLevel(debug) # debug is the lowest logging level so with this setting
#+ message for all higher levels will be logged as well
logLevel(error) # At this setting, only logs of type error and critical
#+ will be logged.
When executed, Buildes processes the session file and creates all building parts in memory. In order to be able to browse, visualize, analyze or export the information created it is necessary to save the session to a preferred format. Use the following syntax:
saveSession() # This saves to buildes (.bdkl) format. This is the
# default and allows the user to use the buildes GUI
# program. This is also the recommended format for
# creating buildings as it allows the user to quickly
# check the design effort.
saveSession(POV) # This saves to POVRay (.pov) format. This allows the
# the use of the popular ray-tracing and rendering
# program. POVRay is an excellent and free program for
# realistic visualization and animation. This output
# tries to provide a pov (script) file that can be
# rendered without additional manipulation. More on
# this.
SaveSession(SCAD) # This saves to OpenSCAD (.scad) format. OpenSCAD is a
# CAD modeler that compiles scripts to produce the 3D
# objects. The interesting part of OpenSCAD is that it
# can cut 3D objects to produce sections. This is the
# reason why it is supported in buildes and the file
# created can be used in this way without additional
# manipulation. However with a little manipulation it
# is possible to remove the settings for cutting
# sections in order to use OpenSCAD normally.
Note: This command must be the last line to capture all objects described. The default option creates a binary file while all others create a text only file. The file produced has the same name and location as the session file but with the extension that is based on the file format requested.
The sides of spaces are typically solid and visible which demarcate clearly the spatial boundary. Sometimes however the sides of spaces are not solid for example in cases where traffic is expected to flow unimpeded from and to the space. At such times the sides are present but should be shown as invisible in the design and are called OpenSides in Buildes. It may be difficult to work with an invisible object during the design process so this command is provided to allow the designer to temporarily show OpenSide objects in the design stage. Use the following syntax:
showOpenSide() # Does nothing
showOpenSide("level_name") # Shows all OpenSide objects in named level
showOpenSide("space_name") # Shows all OpenSide objects in named space
showOpenSide("openSide_name") # Shows the named OpenSide object
showOpenSide("openSide_name1", "openSide_name2", ...)
# Shows named openSide objects
Sometimes it may be desirable to visualize the model without some shapes. This feature makes it possible to provide a single object name or a comma-separated list of names to exclude from the final view of the model. NOTE: This does not remove the object from the design as it will still participate in the creation of the building information however it’s shape will not be visible in the resulting model. Use the following syntax:
skipShape() # Does nothing
skipShape("level_name") # Skips both the shape and the
# contained objects of the
# named level object.
skipShape("space_name", "space_name", ...) # Skips construction of both the
# shape and the contained objects
# of the named space objects.
skipShape("side_name", "side_name", ...) # Skips named sides of space(s).
skipShape("marks") # Skips all mark objects in the
# design.
This is an important way to interact with objects in Buildes. All objects created in buildes have points (snappoints) that provide additional information about their profiles. These points can be referenced by the user while in the design process to accurately manipulate both the object and any others that have a relationship with it.
To reference an objects snappoint, combine the objects name with the designation for the snappoint. This combination must be made with an underscore. The following sections describe the types of snappoints and how they can be referenced.
Global Snappoints
All objects have begin, middle and end points which are designated by “b”, “m” and “e” consecutively. The begin point is the first point in the creation of the objects profile. Assuming an object is called “thisObject”, to access any of the three points combine the name and the appropriate snappoints like thisObject_b, thisObject_m and thisObject_e. Circular or curved objects have a center point that can be accessed with “c” designation.
Mark Snappoints
Mark objects have points that define their edges based on an interval that can be redefined by the user and is designated by “p”. The current interval setting is used to generate a certain number of points along the mark objects edge that can be referenced as an edge or as a snappoint by the user. To access the edge, the name must be combined like thisObject_p. To access a specific point on the edge the user must designate the actual desired point. For example to access the first point use thisObject_p1 which is the same as thisObject_b using global snappoint designation.
Using Mark Snappoints
Show illustration of marks and how snaps describe them and how other marks can be placed around them using snaps.
Component Snappoints
Component objects have a thickness. When created all components are defined in a specific orientation. There is left and a right side with an axis in the center of the object all of which can be accessed with the designations “l”, “r” and “a” consecutively. To access any of the edges, combine the name with the appropriate designation for example access the left edge with thisObject_l. All edges have a begin, middle and end point so to access the middle point on the left edge use thisObject_l2. If you are not interested in the edges, the components begin, middle and end points can be accessed with “b”, “m” or “e” as described in Global Snappoints above which is the same as the three points on the left edge. For example these two references thisObject_e and thisObject_l3 are the same.
Using Component Snap-points
Show illustration of spaces and how snaps can be used to describe and manipulate their boundaries.