AUTOMATED ANALYSIS OF OBJECTS FOR CONSTRUCTION PLANNING

Abstract

Provided herein are systems and methods for automated analysis of objects for a construction planning. The methods may comprise a computer-implemented method which utilizes one or more machine learning algorithms. The systems may comprise one or more computer processors, which are configured individually or collectively to implement a method of the present disclosure. The methods may comprise performing a mesh analysis on a three-dimensional model of an object to be constructed. Based on the mesh analysis, support data between structure elements of the object may be determined which may facilitate an application of a pre-defined build formula(s) or formula relationship(s) for the structure elements. A construction plan may be generated and/or scheduled based at least partially on the pre-defined build formula(s) or formula relationship(s).

Description

BACKGROUND

Many modifications can be made during the course of a construction project. For example, the object of construction, such as a building, may undergo modifications. Further, a construction project may comprise the execution of numerous operations and use of numerous resources, which operations and resources can be interrelated with any degree of complexity.

SUMMARY

Provided herein are systems and methods for automated analysis of objects for construction which to facilitate efficient execution and completion of a construction project. A construction project can often be subject to limitations and constraints such as spatial constraints, temporal constraints, resource constraints, budget constraints, regulatory constraints, and other limitations that may or may not be interdependent on other limitations and constraints. If not managed properly, these limitations and constraints can lead to complications, hazards, inefficiency, waste of valuable resources and budget, or even complete or partial failure of the construction project. Thus recognized herein is a need for systems and methods that address the aforementioned drawbacks. In some aspects, the present disclosure provides methods for construction production management and scheduling. The methods may comprise computer processing a plurality of parameters of a given construction project to thereby generate multiple construction options for the project. The methods may generate multiple construction options (e.g., at least 50, 100, 200, 500, 1,000, 2,000, 5,000, 10,000, 20,000, 40,000, 60,000, 80,000, 100,000 construction options, or more) within a short time period (e.g., less than or equal to about 10 hours, 8 hours, 6 hours, 4 hours, 2 hours, 1 hours, 50 minutes, 40 minutes, 30 minutes, 20 minutes, 10 minutes, 5 minutes, or less). The computer processing may comprise using artificial intelligence, machine learning algorithms to process the parameters of a given construction project and generate construction options. Non-limiting examples of the parameters include precedence, available crews, available space, sequencing of crews, available materials, types of materials (e.g., consumable and/or reusable), available equipment (e.g., cranes), available resources, building capacity, location of equipment, movement of equipment (e.g., cranes and radii), construction methods (e.g., duration, prod rate, prefab vs. in situ etc.), design options, overtime, available time for construction (e.g., day time, night time, or 24-hour), multiple shifts calendars, delays require rescheduling, weather, or any combination thereof. At least a subset of the parameters can be updated or modified multiple times to generate a variety of different construction options before commencement of a construction project. In some cases, the parameters and/or the construction options are updated or modified in real-time.

An aspect of the present disclosure provides a system for object construction, comprising: one or more computer processors, individually or collectively configured to implement a method for constructing an object, comprising: (1) identifying a plurality of structure elements of an object by performing mesh analysis on a three-dimensional model of the object; (2) determining support data between the structure elements; (3) applying pre-defined build formulas or formula relationships for the structure elements based at least in part on the support data; and (4) generating an object construction plan comprising the pre-defined build formulas or formula relationships.

In some embodiments, the method further comprises generating a support data network using the support data determined in (2). In some embodiments, the mesh analysis of (1) further comprises arranging the support data in a hierarchical order which correlate to a workflow order as part of the object construction plan for construction of the object. In some embodiments, the mesh analysis is performed using one or more machine learning algorithms. In some embodiments, the method further comprises one or more of (i) categorizing the structure elements by shape or type; (ii) determining dimensions pertaining to the shape or type; and (iii) determining dimension values for at least a subset of the dimensions, which dimensions or dimension values are used for determining the support data. In some embodiments, the method further comprises tracking a progress of construction of the object. In some embodiments, the method further comprises modifying a remaining portion of the object construction plan based on the progress of construction of the object. In some embodiments, the modifying comprises modifying one or more parameters of the object construction plan. In some embodiments, the one or more parameters comprises parameters of available resources in a resource pool for construction of the object or properties thereof, parameters of the object construction plan comprising one or more of the pre-defined build formulas, the formula relationships, and the support data, or a combination thereof. In some embodiments, the tracking or modifying is performed in real-time.

Another aspect of the present disclosure provides a computer-implemented method for scheduling an object construction plan, comprising: (1) identifying a plurality of structure elements of an object by performing mesh analysis on a three-dimensional model of the object; (2) determining support data between the structure elements; (3) applying pre-defined build formulas or formula relationships for the structure elements based at least in part on the support data; and (4) generating the object construction plan comprising the pre-defined build formulas or formula relationships.

In some embodiments, the method further comprises comprising generating a support data network using the support data determined in (2). In some embodiments, the mesh analysis of (b) further comprises arranging the support data in a hierarchical order which correlate to a workflow order as part of the object construction plan for construction of the object. In some embodiments, the mesh analysis is performed using one or more machine learning algorithms. In some embodiments, the method further comprises one or more of (i) categorizing the structure elements by shape or type; (ii) determining dimensions pertaining to the shape or type; and (iii) determining dimension values for at least a subset of the dimensions, which dimensions or dimension values are used for determining the support data. In some embodiments, the method further comprises tracking a progress of construction of the object. In some embodiments, the method further comprises modifying a remaining portion of the object construction plan based on the progress of construction of the object. In some embodiments, the modifying comprises modifying one or more parameters of the object construction plan. In some embodiments, the one or more parameters comprises parameters of available resources in a resource pool for construction of the object or properties thereof, parameters of the construction plan comprising one or more of the pre-defined build formulas, the formula relationships, and the support data, or a combination thereof. In some embodiments, the tracking or modifying is performed in real-time.

Provided herein are systems and methods for construction planning. The systems and methods can receive and analyze a data file defining a three-dimensional (3D) model of structure elements and/or an assembly thereof. The 3D model can be a computer data file, such as a building information modeling (BIM) data file or a computer-aided design (CAD) data file. During analysis, the systems and methods can categorize structure elements, such as into shapes, determine one or more dimensions pertaining to the structure elements, and perform a mesh analysis to determine support data between the structure elements. The support data may comprise a support relationship between the structure elements (e.g., between a first structure element and a second structure element of a plurality of structure elements of an object to be constructed). The support data between the structure elements may form a network of relationships mapping out the 3D model. Support data can define, for example, which one or more elements support which one or more other elements. Support data can be a logical constraint.

The systems and methods for construction planning can involve (i) modification of support data between the structure elements, (ii) grouping and splitting of structure elements, and/or (iii) use of a pre-defined build formula library. The pre-defined build formula library can comprise a plurality of recipes, each recipe comprising a formula for building a specific type of structure element. The formula can define one or more operations (e.g., place formwork, place steel, pour concrete, dry concrete, remove formwork, etc.) and sequence thereof for building the structure element. An operation can define one or more resources (e.g., raw material, labor, etc.), production rate, spatial requirements, temporal requirements, and/or other instructions or factors for the operation. The formula may be dependent on one or more parameters (e.g., material, dimensions, etc.) of the specific type of structure element. The same recipe can be used to plan the building of the same type of structure element. In some instances, different recipes may exist for the same type of structure element and may be selected manually by a user or automatically (e.g., by a computer algorithm). A new recipe can be created and saved in the pre-defined build formula library for new types of structure elements. A recipe can be constrained by available resources, such as in a resource pool which is described further below.

The plurality of recipes in the pre-defined build formula library may or may not be interlinked via one or more formula relationships. The term “formula relationship,” as used herein, may be used interchangeably with the term “build formula relationship,” or “recipe relationship.” For example, a first recipe (or pre-defined build formula) can be linked to a second recipe via a formula relationship. A recipe can be linked to a plurality of recipes. A formula relationship can be a logical constraint. The formula relationship can define a sequential relationship, such as to identify which recipe is to be performed first, which recipe is to be performed after, which recipes are to be performed in parallel, which recipe is to be performed at a particular time (e.g., 45 minutes in, etc.), step, operation, phase, stage, point, duration, and/or other unit relative to another recipe, and other sequential relationships. A formula relationship can be a relationship between operations that are in different recipes. A formula relationship can link a recipe to external recipes, such as for building at another location.

The systems and methods may provide a resource pool for a construction project. The resource pool can define the available resources for the construction project, such as labor (e.g., skill set in labor pool, standard work week, available dates, cost, etc.), equipment (e.g., location, reach, available time, efficiency, cost, etc.), materials (e.g., amount, type, cost, etc.), space (e.g., area, volume, height, equipment allowed in space, available time, labor allowed in space (e.g., maximum number of adults), cost, etc.), production rates (e.g., rates at which operations are carried out, etc.), work weeks (e.g., hours a week per crew, hours a week per individual, etc.), and other resources. Some resources, such as space and production rates can be global variables that are accessible from any recipe in the pre-defined build formula library. A recipe may draw parameters and resources from the resource pool. For example, the resource pool can present a constraint on the recipe.

The systems and methods may provide comprehensive construction planning for a construction project using the abovementioned tools, such as pre-defined build formulas, formula relationship s, and/or the resource pool. In some instances, the construction planning can be completed prior to or during construction scheduling. In an example, the construction planning can create and/or define one or more plans that need to be scheduled. In some instances, scheduling can refer to plotting at least part of a construction plan (e.g., operation) to a timeline, such as assigning a start and end time (and/or date). The construction planning and/or scheduling can be modified or updated in real-time, such as by modifying or updating one or more parameters of the construction plan. Upon modification or update, the construction project can be re-planned and/or re-scheduled. The parameters that can be modified or updated can include parameters, such as parameters of available resources in the resource pool and/or properties (e.g., amount, type, cost, etc.) thereof and parameters of the construction method (e.g., recipe, formula relationship, support data, etc.) and/or properties thereof.

The construction planning and scheduling thereof can be visualized on a graphical user interface. For example, the planning and/or scheduling can be visualized as a plot, graph, table, or other charts showing information such as cost and duration (e.g., as axes in a graph, columns in a table, etc.). In another example, the planning and/or scheduling can be visualized as a three-dimensional (3D) visual output showing a time-dependent 2D cross-sectional output progress. In another example, the planning and/or scheduling can be visualized as a four-dimensional (4D) visual output showing a time-dependent 3D output progress, such as a 4D Gantt chart. The visualization may be filtered by different factors, resources, and/or other parameters. The construction planning and scheduling can be presented on a dynamic user interface, such as having one or more user interactive objects (e.g., slider bar). In some instances, the construction planning and scheduling can be visualized as information cards, such as by time, crew, operation, and/or structure element. Additional aspects and advantages of the present disclosure will become readily apparent to those skilled in this art from the following detailed description, wherein only illustrative embodiments of the present disclosure are shown and described. As will be realized, the present disclosure is capable of other and different embodiments, and its several details are capable of modifications in various obvious respects, all without departing from the disclosure. Accordingly, the drawings and description are to be regarded as illustrative in nature, and not as restrictive.

INCORPORATION BY REFERENCE

All publications, patents, and patent applications mentioned in this specification are herein incorporated by reference to the same extent as if each individual publication, patent, or patent application was specifically and individually indicated to be incorporated by reference. To the extent publications and patents or patent applications incorporated by reference contradict the disclosure contained in the specification, the specification is intended to supersede and/or take precedence over any such contradictory material.

BRIEF DESCRIPTION OF THE DRAWINGS

The novel features of the invention are set forth with particularity in the appended claims. A better understanding of the features and advantages of the present invention will be obtained by reference to the following detailed description that sets forth illustrative embodiments, in which the principles of the invention are utilized, and the accompanying drawings (also “Figure” and “FIG.” herein), of which:

FIG. 1 illustrates an outline for a method described herein.

FIG. 2A shows a three-dimensional model of an example construction object.

FIG. 2B illustrates a partial support data network for the construction object of FIG. 2A.

FIG. 3 illustrates a user interface for viewing and/or modifying support data.

FIG. 4 illustrates a user interface for assigning pre-defined build formulas to structure elements in a construction object.

FIG. 5 illustrates a user interface for creating an operation in a recipe.

FIG. 6 illustrates a user interface for creating a recipe.

FIG. 7 illustrates a network of formula relationships.

FIG. 8 illustrates a user interface for defining a resource pool for a construction project.

FIG. 9 illustrates a user interface for defining a space in a resource pool.

FIG. 10 illustrates a user interface for presenting a visualization of parametric scheduling.

FIG. 11 illustrates a user interface for presenting an enhanced Gantt chart for an exemplary construction schedule.

FIG. 12 illustrates an enlarged view of the information cards of FIG. 11.

FIG. 13 shows a computer control system that is programmed or otherwise configured to implement methods provided herein.

DETAILED DESCRIPTION

While various embodiments of the invention have been shown and described herein, it will be obvious to those skilled in the art that such embodiments are provided by way of example only. Numerous variations, changes, and substitutions may occur to those skilled in the art without departing from the invention. It should be understood that various alternatives to the embodiments of the invention described herein may be employed.

Provided herein are systems and methods for construction planning and scheduling for a construction project. A construction project can be for any type of construction, such as for residential, industrial, commercial, recreational, civil, public, private, and/or other purposes. A construction project can involve any part of a construction process. For example, the construction project can involve one or more distinct or overlapping processes, phases, or stages, such as designing, planning, scheduling, building, operation, and maintenance. A construction project may not necessarily be limited to building an object (e.g., a construction object). For example, the construction project can be for a demolition of a building or repairing of a building. In another example, the construction project can be for just laying the foundation, preparing a site for construction, and/or cleaning up a construction site.

The systems and methods for construction planning can involve different construction units, such as construction objects, structure elements, construction components, pre-defined build formulas, construction operations, and other construction tasks and construction methods. A construction object can be a physical structure, including physical infrastructure. A construction object can be an artificial structure. For example, a construction object can be a building, bridge, road, highway, gate, dam, wall, staircase, a part thereof, or any other physical structure. A construction object can be a plurality of buildings, bridges, roads, highways, gates, dams, walls, other structures, and/or a combination thereof. A construction object can be defined by one or more structure elements making up the construction object. The term “structure element,” as used herein, may be used interchangeably with the term “construction element.” A structure element can be any subset or unit of the construction object used for building or constructing the construction object. For example, a structure element can be a slab, a column, a wall, a beam, a block, a brick, a frame, an ingot, or any other subset or unit of a construction object. For instance, the construction object (e.g., building) can be a single structure element (e.g., column), a plurality of structure elements, and/or an assembly of a combination of structure elements (e.g., slabs, columns, etc.). A construction component can be one or more materials (e.g., raw, processed, etc.) that are used to form a structure element. For instance, a structure element (e.g., column) can comprise a plurality of construction components (e.g., concrete, formwork, and steel). In some instances, the construction object can be defined by a computer file, such as a building information modeling (BIM) data file or a computer-aided design (CAD) data file. The data file can be a three-dimensional (3D) data file. For example, the data file for a construction object can define a 3D model of the construction object. The data file for a construction object can define the structure elements of the construction object.

The term “pre-defined build formula,” as used herein, may be used interchangeably with the term “pre-defined recipe,” or “construction recipe.” A pre-defined build formula can be a formula for constructing a structure element (e.g., column, etc.). The pre-defined build formula can comprise one or more construction operations (e.g., pouring cement, curing, etc.). Pre-defined build formulas can be saved in a pre-defined build formula library, such as for future use.

The systems and methods for construction planning can involve one or more logical constraints, and/or logical relationships between the same or different construction units (e.g., construction object, structure element, pre-defined build formula, construction operation, construction task, etc.). For example, there may exist one or more logical support data between structure elements of a construction object. Such support data can be extracted or determined from a data file of the construction object. There may exist one or more logical relationships between construction operations within a pre-defined build formula or between different pre-defined build formulas. There may exist one or more logical formula relationship s between pre-defined build formulas of a structure element.

The systems and methods for construction planning can involve one or more adjustable parameters, such as for a construction unit. The systems and methods for construction planning can involve one or more fixed parameters. A parameter may be manually provided or adjusted by a user. A parameter may be pre-programmed or otherwise pre-determined by a computer system. A parameter may be automatically adjusted by a computer system, such as via one or more computer algorithms. A parameter can be for a construction resource, such as available labor, material, equipment, and/or space. A parameter can define a project constraint or requirement, such as spatial constraints, temporal constraints, quality constraints, and/or budget constraints. A parameter can be any adjustable factor. A parameter can be any fixed factor. In some instances, the available resources for a construction project can be saved in a resource pool common to one or more construction operations and/or pre-defined build formulas in the construction project. For example, a particular resource can be a global variable accessibly by all pre-defined build formulas in the construction project. Beneficially, the available resource can be coherently shared between the pre-defined build formulas without inadvertent double allocation of limited resources.

In some instances, the construction planning can be completed prior to or during construction scheduling. In an example, the construction planning can refer to creating and/or defining one or more plans that need to be scheduled. In some instances, scheduling can refer to plotting at least part of a construction plan (e.g., operation) to a timeline, such as assigning a start and end time (and/or date). The construction planning and/or scheduling can be modified or updated in real-time, such as by modifying or updating one or more parameters of the construction plan. Upon modification or update, the construction project can be re-planned and/or re-scheduled.

One or more aspects of the systems and methods for construction planning described above and further below can be implemented on a user interface, such as a construction planning platform. The user interface can be a graphical user interface. The user interface can be a dynamic user interface. The user interface can comprise one or more user interactive objects (e.g., buttons, sliders, hyperlinks, etc.). Advantageously, the systems and methods provided herein can provide a flexible user-controlled construction planning platform. By utilizing tools such as pre-defined build formulas, inter-formula relationship s, and the resource pool, among other tools described above and to be described further below, the systems and methods can facilitate accurate and efficient navigation and distribution of available resources.

Beneficially, the systems and methods for construction planning can allow users (e.g., involved in a construction project as workers, planners, managers, investors, owners, etc.) to flexibly plan a construction project, partially or entirely, before irreversibly committing expensive resources, such as materials, equipment, time, and labor. The systems and methods for construction planning described herein provide an improvement in computer-related technology, such as by defining specific rules and logical relationships (e.g., inter-formula relationship s, inter-elemental support data, intra-operation relationships, etc.) between construction units (e.g., structure elements, pre-defined build formulas, etc.) that have not previously been done before for construction planning. Furthermore, the construction planning and/or scheduling can be particularly visualized, filtered by part or as an overview, as a graphical representation (e.g., time-dependent 4D Gantt chart) to allow for more efficient presentation, translation, and data absorption or interpretation of construction planning data.

FIG. 1 illustrates an outline for a method for construction planning. A server, such as in a computer system for facilitating construction planning, can receive 102 a data file defining a 3D model of a construction object. For example, the data file can be a BIM data file or a CAD data file. The data file can be a file type supported by any existing construction or 3D model design software. The data file can be any other type of data file defining a 3D model. For example, the data file can be any data file defining a polygon mesh broken into elements. In some instances, the data file can be created by a user and uploaded to the server. In some instances, the data file can be pre-existing on the server and selected by the user. For example, the data file can be a template data file, such as a data file for a commonly used construction object that is offered for use to users by the server. While one server is mentioned, the computer system can comprise a plurality of servers that can individually or collectively perform the functions described above and further below. Any mention of “a server” performing one or more functions herein can refer to a plurality of servers acting individually or collectively to perform the one or more functions. Unless explicitly stated otherwise, all automated functions performed by the server described herein may be performed automatically by the server without user input, instructions, intervention, or other involvement.

The server can analyze 102 or otherwise process the data file defining the three-dimensional (3D) model or mesh data of the construction object, such as to identify and determine one or more structure elements of the construction object. The analysis, identification, and/or determination can be automated. The server can extract data about the one or more structure elements of the construction object. During analysis, the server can categorize structure elements, such as into shapes. For example, a structure element can have a shape of a cuboid, a sphere, a cylinder, or any other shape or form. The server can then determine one or more dimensions pertaining to the shape of the structure element. For example, a dimension can be a length, width, height, radius, diameter, altitude, depth, perimeter or any other dimension of a three-dimensional object. For example, a right cylinder can have the dimensions of a radius and a height. A sphere can have a single dimension of a radius. A cuboid can have the dimensions of length, height, and width. The server can then determine the respective values of the dimensions of the structure element. In some instances, the server may calculate or determine the respective values from other dimension values. In some instances, the server may determine a value for each dimension of the structure element. In some instances, the server may determine a value for only key dimensions of the structure element, such as the dimensions required for building.

Alternatively or in addition, the server can categorize structure elements into types, such as columns, walls, slabs, or other types of structure elements. In some instances, the type can be determined based at least on the shape. In some instances, the type can be user-defined in the data file. Alternatively or in addition, the type can be based on context of the structure element in the data file, such as based on an assembly or support data with another structure element, orientation, and/or arrangement. For example, two structure elements (e.g., slab, wall) having a similar shape of a substantially flat cuboid may be determined to be two different types based on their orientation and arrangement in the data file. Alternatively or in addition, the server can categorize structure elements by material or any other properties of the structure elements that can be extracted from the data file.

During analysis, the server can perform a mesh analysis to determine support data between the structure elements. Support data can define, for example, which one or more elements support which one or more other elements. For example an element can support another element. An element can support a plurality of other elements. An element can be supported by another element. An element can be supported by a plurality of other elements. A plurality of elements can be supported by a plurality of elements. Support data can be a logical constraint to the elemental configuration of the construction object. In some instances, the mesh analysis can be performed to determine support data both between the structural elements and within the structural elements. In some instances, the mesh analysis can be customized such that the mesh analysis is performed only on vertical adjacent planes, horizontal adjacent planes, select planes, or planes having certain angles. In some instances, the mesh analysis can be customized such that the mesh analysis is performed with different support tolerance. The mesh analysis can be customized with other parameters. The support data between the structure elements of a construction object may form a network of support data mapping out the 3D model of the construction object.

FIG. 2A shows a 3D model of an exemplary construction object. The exemplary construction object 200 can comprise a plurality of structure elements, such as slab type structure elements (e.g., slab 202), column type structure elements (e.g., columns 204A-D), and wall type structure elements (e.g., walls 206A-C). The exemplary construction object 200 can be a portion of a building. The server can receive a BIM data file defining the 3D model of the construction object 200. The server can analyze the BIM data file to extract data about the structure elements of the construction object. For example, for the construction object 200, the server may identify and determine from the data file that there are 1 slab type structure element (including slab 202), 12 column type structure elements (including columns 204A-D), and 6 wall type structure elements (including walls 206A-C). The server can then categorize each of the structure elements by shape and/or type (e.g., columns, walls, slabs, etc.) and determine one or more dimensions pertaining to the shape or type. The server can then determine the dimension value for each of the dimensions pertaining to the shape or type, or determine the dimension values for key dimensions pertaining to the shape or type. Thereafter, the server can determine one or more support data between the different structure elements.

FIG. 2B illustrates a partial support data network 250 for the construction object 200 of FIG. 2A. The server may perform a mesh analysis on the data file to determine the structure element. In some instances, the mesh analysis can be customized to analyze the structure elements and support data thereof adjoining vertical planes, such as the plane containing walls 206A-C. Upon analysis, the server may determine the partial support data network 250, where each block represents structure element arrow represents support data. For example, in the network 250, there exists support data between the slab 202 and Column A 204A, the slab 202 and Column B 204B, the slab 202 and Column C 204C, the slab 202 and Column D 204D, Column A 204A and Wall A 206A, Column B 204B and Wall A 206A, Column B 204B and Wall B 206B, Column C 204C and Wall B 206B, Column C 204C and Wall C 206C, and Column D 204D and Wall C 206C. That is, Column A 204A is supported by slab 202, and Column A 204A in turn supports Wall A 206A, wall A 206A is supported by both Column A 204A and Column B 204B, and so on. Support data may or may not have a hierarchical order. For example, the support data between the slab 202 and the Column A 204A may be defined at a higher hierarchy level than the support data between the Column A 204A and Wall A. The hierarchical order can correlate or correspond to a workflow order. For example, building (or adjoining or supporting) of the structure elements with support data at a higher hierarchical level may be completed, or required to be completed, before building (or adjoining or supporting) of the structure elements support data at a lower hierarchical level.

The analysis of the data file, such as involving identification of structure elements, categorization of structure elements into shapes, determination of dimensions pertaining to the different shapes, calculation of values of the dimensions, performing of a mesh analysis, determining one or more support data between the structure elements, and/or construction of a support data network, can be implemented via one or more machine learning algorithms. For example, the identification of the structure elements, categorization of structure elements into shapes, determination of dimensions pertaining to the different shapes, calculation of values of the dimensions, determining one or more support data between the structure elements, and/or construction of a support data network, can be presented to a user for approval, modification, and/or correction. The approval, modification, correction, or other updates from the user can be stored in a database (or a plurality of databases) accessible by the server for use in the machine learning algorithms. Alternatively or in addition, the analysis of the data file can be performed automatically by the server (e.g., via one or more processors) without requiring human input or instructions.

Referring back to FIG. 1, after receipt 102 and analysis of the 3D model data file, the support data can be modified 104. The support data can be presented to a user for modification 104. For example, the user may manually add new support data between different structure elements or remove existing support data. In some instances, the user may group one or more such relationships, such as by orientation, by location, by type of support data (e.g., horizontal support, vertical support, base support, side support, etc.), and/or by structure elements (e.g., all support data involving a structure element in one group). In some instances, the user may re-arrange a hierarchical order of the support data in the network. For example, a user wishing for the construction work to flow from a Northern part of the building to a Southern part of the building can arrange the support data in a Northern part of the building to be defined before support data in a Southern part.

FIG. 3 illustrates a user interface for viewing and/or modifying support data. The support data may be presented to a user as a graphical representation, such as on a graphical user interface 300 on an electronic display 350. For example, the electronic display 350 can be communicatively coupled to a user device (e.g., computer, mobile phone, tablet, etc.) of the user. The graphical user interface 300 can be a dynamic user interface. In some instances, a support data can be presented one at a time, and the user may navigate between the respective graphical representations of the different individual support data by manipulating a user interactive object 310, such as a slider on a slider bar, to provide user input. As the user slides the object 310 on the slider bar, at different locations on the slider bar, different support data can be presented one at a time. Alternatively or in addition, a support data can be presented one group at a time, and the user may navigate between the respective graphical representations of the different groups by manipulating the user interactive object 310 to provide user input. As the user slides the object 310 on the slider bar, at different locations on the slider bar, different groups of support data can be presented one at a time. User interactive objects can include buttons, drop-down menus, text fields, sliders, or any other object that a user can provide input with and/or to.

In FIG. 3, a graphical user interface 300 shows a graphical representation of a support group #9 of 22 total support groups. The user may interact with the graphical representation on the graphical user interface 300, such as by zooming in, zooming out, rotating (e.g., yaw, pitch, roll directions, etc.) relative to a point (e.g., an arbitrary reference point the user selects, such as by clicking), moving (e.g., x, y, z directions, etc.) relative to a point, changing lighting, changing color scheme, and other methods of interaction. In the support group #9, a first column 302 of interest is supported by a second column 304 beneath the first column 302 and supported by a first beam 306 also beneath the first column 302. In some instances, each of the structure elements involved in the support data in the support group being presented on the graphical user interface 300 may be highlighted, such as by color, shade, bolding an outline of the shape, arrows, markers, symbols, blinking of the graphic of the structure element, dynamic effect, or other methods of emphasis. In some instances, a first structure element supported by a second structure element and the second structure element supporting the first structure element can be visually differentiated, such as by color, shade, bolding an outline of the shape, arrows, markers, symbols, blinking of the graphic of the structure element, dynamic effect, or other visual formats.

In some instances, each of the structure elements in the construction object may be a user interactive object, and the user may perform an action on or with a structure element, such as by selecting the structure element. The user may select (e.g., click, tap, touch, double-click, double-tap, tap and hold, etc.) the first column 302 of interest. Alternatively or in addition, the first column 302 of interest may be pre-selected by the server for the support group #9. The user may then select another user interactive object 308, such as a button, to modify support data of the first column 302. The user may, for example, add new support data of the first column 302 with other structure elements (e.g., with a second beam) and/or remove existing support data (e.g., with the second column 304 or the first beam 306) from structure elements supporting or supported by the first column 302. In some instances, the user may also re-arrange the support group #9 to be higher or lower in the hierarchy of 22 support groups in the 3D model of the construction object. In some instances, the user may re-arrange a support data within the support group #9 to be higher or lower in the hierarchy of the support data in the support group.

Referring back to FIG. 1, after modifying 104 support data between structure elements, the user may group 106 and split different structure elements. In some instances, the user may group and/or split different structure elements before or during either or both the aforementioned operations 102, 104. In some instances, the user may use a design tool (e.g., design software, application, platform, etc.), user-provided and/or server-provided, to achieve the splitting and/or grouping. For example, a large slab type structure element may be split into three smaller slab type structure elements. The splitting may be saved in the 3D model data file defining the construction object. In some instances, the splitting of one or more structure elements may modify the support data of the construction object. The server may re-evaluate the support data, such as by performing the operations 102, 104 previously described. Structure elements may be grouped together in any manner. For example, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 20, 30, 40, 50, 100, 150, 200, 300, 400, 500, or more structure elements can be grouped together as one group. The structure elements grouped together may or may not share common features. A group may have a name or other identifier. In an example, a construction object may comprise a first sub-slab A and a second sub-slab B, each sub-slab supporting a plurality of columns thereon. A user may arbitrarily or categorically group together all columns on the first sub-slab A into a group named “columns on sub-slab A” and group together all column on the second sub-slab B into a group named “column on sub-slab B.” In some instances, the user may group together structure elements that the user intends to build as one group.

Next 108, the server may assign a pre-defined build formula for each structure element. The server may access a pre-defined build formula library stored in one or more databases and/or memory that may be local or external to the server. The pre-defined build formula library can comprise one or more recipes, each recipe in the library comprising a formula for building a specific type of structure element. The server may assign an existing recipe saved in the pre-defined build formula library for a structure element. Alternatively or in addition, a new recipe can be created and saved in the pre-defined build formula library to assign to a new type of structure element. A recipe can be constrained by available resources, such as in a resource pool which is described further below.

The same recipe can be replicated and used for the same type of structure element. For example, the same recipe can be used for all beams. In some instances, different recipes may exist for the same type of structure element. For example, different recipes may exist for the same type of structure element having different parameters (e.g., dimension, material, placement, location, orientation, etc.) or having different sub-types. As an example, different recipes can exist for I-beams (e.g., H-Beam, W-beam, etc.) and curved beams. As another example, different recipes can exist for I-beams having a length dimension less than x₁, I-beams having a length dimension in the x₁-x₂ range, I-beams having a length dimension in the x₂-x₃ range, and I-beams having a length dimension greater than x₂. As another example, different recipes can exist for I-Beams having different width:length dimension ratios.

A recipe may be assigned to a structure element with user input, such as with user instructions to assign the recipe to the structure element. Alternatively or in addition, a recipe may be assigned to a structure element automatically (e.g., by a computer algorithm) without user input. For example, the server may assign a recipe based on the shape and/or type of the structure element. Where there are multiple different recipes for the same type of structure element in the pre-defined build formula library, the server may select a recipe based on context of the structure element extracted from the data file, such as a location, orientation, or support data. Alternatively or in addition, the server may select a recipe using a machine learning algorithm, such as based on past user preference. Alternatively or in addition, a predetermined default recipe (e.g., pre-programmed) may be selected by default. In some instances, a user may override automatic selection or assignment of a recipe to a structure element by the server.

For example, there may be one recipe each for a slab type structure element, a column type structure element, a wall type structure element, and a beam type structure element. A same slab recipe may be applied to all slab type structure elements, a same column recipe may be applied to all column type structure elements, a same wall recipe may be applied to all wall type structure elements, and a same beam recipe may be applied to all beam type structure elements. Beneficially, where there is a plurality of the same type of structure element, the same pre-defined build formula can be applied to each of the same type of structure element without having to manually (and redundantly) create and manually logically relate different operations for each structure element. This can significantly save both user-required labor (e.g., defining operations) as well as memory and processing capacity of the computer server (e.g., server) facilitating the construction planning. Furthermore, the probability of introducing error (e.g., user error, system error) is also reduced. For example, referring back to the construction object 200 in FIG. 2A which has 19 structure elements including 1 slab, 12 columns, and 6 walls, only three total pre-defined build formulas can be required, a slab recipe for the 1 slab, a column recipe for the 12 columns, and a wall recipe for the 6 walls. If 5 operations were required to build each structure element, this would reduce 95 operations (5 for each of 19 structure elements) to be defined to 15 operations (5 for each of 3 pre-defined build formulas) total operations.

FIG. 4 illustrates a user interface for assigning pre-defined build formulas to structure elements in a construction object. A graphical user interface 400 can be presented to a user on an electronic display (not shown). The graphical user interface 400 can be a dynamic user interface. In some instances, the graphical user interface 400 can show a navigation panel 404, such as a tree view navigation panel, of the different structure elements in the construction object. The navigation panel 404 can show groups of structure elements and/or individual structure elements, such as in a nodal structure. The individual structure elements and/or groups thereof can be identified a name or other unique identifier (e.g., text, graphic, symbol, etc.). Each structure element in the navigation panel 404 can be selectable (e.g., via clicking, tapping, etc.). In some instances, the graphical user interface 400 can show a graphical representation 402 of the 3D model of the construction object and/or the structure elements. In some instances, the graphical representation 402 can be the graphical representation of the support data in FIG. 3. Each structure element in the graphical representation 402 can be selectable. In some instances, selection of a structure element in either the navigation panel 404 or the graphical representation 402 can automate selection in the other. A selected structure element can be emphasized, such as via bolding, color, shading, blinking or other dynamic effect, and/or other methods of emphasis described elsewhere herein.

For example, in FIG. 4, a user may select a plurality of columns from the navigation panel 404. The user may then select a recipe menu 410 (e.g., button, link, etc.) from a user menu, and select an assign recipe option 406 (e.g., button, link, etc.) to select a pre-defined build formula from the pre-defined build formula library to assign to the selected plurality of columns. Alternatively or in addition, the user may create a new recipe to assign to the selected plurality of columns. The selection can be presented in a selection display 408.

A recipe can be created and/or defined by a user. For example, the user may provide one or more operations, sequence thereof, one or more resources, production rate, spatial requirements, temporal requirements, and/or other instructions or factors in the formula of the recipe. A recipe can be pre-defined in the server, such as for reference as a template. A recipe can be defined by both server and user input. For example, a user may modify a pre-defined template recipe for a structure element. In another example, the server may automatically complete, or recommend suggestions (e.g., auto-complete suggestions) to, a user-defined recipe.

A recipe in the library can comprise a formula for building a specific type of structure element. The formula in a recipe can define one or more operations (e.g., place formwork, place steel, pour concrete, dry concrete, remove formwork, etc.) and sequence or interconnections thereof for building the structure element. The formula can define logical relationships between the operations. An operation can define one or more resources (e.g., raw material, labor, etc.), production rate, spatial requirements, temporal requirements, and/or other instructions or factors for the operation. The formula may be dependent on one or more parameters (e.g., material, dimensions, etc.) of the specific type of structure element.

To create a recipe for a structure element, one or more operations, or processes, required to build the structure element is created. The operation can be identified by a name or other identifier. The name or other identifier can be provided by the user and/or the server. FIG. 5 illustrates a user interface for creating an operation in a recipe. A graphical user interface 500 is shown on an electronic display (not shown). The graphical user interface 500 can be a dynamic user interface. Each operation defines required resources (e.g., labor 502, equipment 504, material 506, space 508, etc.), duration 512, and production rates 510. An operation can define other factors or instructions for building a structure element. The definitions can be in numerical format, text string format, visual instructions (e.g., modeling a safety area for space 508), and/or other instruction formats.

In some instances, duration 512 can be calculating using the production rate 510 and dimension values previously calculated for the structure element. For example, duration can be equal to a structure element volume divided by the production rate (where production rate is defined in volume unit per time unit). In another example, duration can be equal to a different structure element dimension (e.g., length, width, etc.) divided by the production rate (where production is defined by the corresponding dimension per time unit). Alternatively or in addition, duration can be manually fixed to a user defined value (e.g., 4 days).

For an operation, the required resources can be defined. In some instances, available resources can be separately defined in the resource pool which is described further below. For labor 502, a minimum and/or maximum number of assignable crews can be provided. Alternatively or in addition, a minimum and/or maximum number of assignable workers can be provided. For example, a minimum of 1 steel crew and a maximum of 3 steel crews can be provided for an operation. Beneficially, during actual construction, when free steel crews are available at some point, the free steel crews can be assigned to operations having extra capacity in the minimum-maximum range. Thus, flexibility is built into the operation definition.

For equipment 504, constraints for the equipment can be provided. For example, for a crane, a location of the crane, radius, and time required to move between locations can be provided. In some instances, a specific model of an equipment can be selected, and radius can be automatically provided by the program. The server may determine, based on the information provided, all the elements that the equipment is capable (or incapable) of reaching. Beneficially, especially because construction equipment can be costly, limited, and difficult to maneuver, the constraints can ensure, ahead of time, that the equipment is distributed where necessary and where it is capable of operating.

For material 506, a type and amount of materials can be provided. For example, a material can be selected to be reusable (e.g., formwork) or consumable (e.g., bricks). In some instances, some resources may have a limited number of reusable lives (which can be defined in the operation or in the resource pool), such as to define formwork to be reusable a maximum of 5 times after which it may be too damaged for re-use.

For space 508, an area and location for the space can be provided. For example, a user and/or the server can set areas to be blocked off around the operation being performed. Beneficially, work paths and safety areas can be built into the operation.

For production rates 510, rates for the operation can be provided. For example, a rate of pouring concrete, a rate of removing formwork, and other rates can be provided. Beneficially, production rates provided for one operation can also be used for another operation. For example, production rates can be saved as a global variable accessible from all operations and/or all recipes in the system. For instance, the rate of pouring concrete can be used for both an operation in a column recipe and an operation in a slab recipe.

The plurality of operations in a recipe may or may not be interlinked via one or more logical inter-operation relationships. FIG. 6 illustrates a user interface for creating a recipe. A graphical representation of a recipe 610 is shown on a graphical user interface 600 on an electronic display (not shown). The graphical user interface 600 can be a dynamic user interface. The recipe can comprise one or more operations (e.g., operation 602) and one or more logical relationships (e.g., relationship 604) interconnecting the one or more operations. In some instances, a recipe having one operation may not have any logical relationships.

A logical relationship can be a task dependency. For example, a logical relationship can be a Finish-to-Start (FS) type relationship. A FS relationship from operation A to operation B can mean that operation A must finish before operation B can start. Operation B can start any time on or after operation A is finished, for example, immediately after operation A finishes (e.g., 0 time lag) or after a time lag. The time lag can be defined, such as in units of seconds, minutes, hours, days, weeks, months, years, or other time units. The relationship can be closed or open. In an open relationship, for example, Operation B can start any time after an x time lag (x≥0). In a closed relationship, for example, Operation B can start exactly, or substantially precisely within a certain tolerance (e.g., about 1%, 2%, 3%, 4%, etc.), after x time lag. For example, a closed FS relationship from a cement curing operation to a painting operation with a 1 hour time lag can mean that the painting operation starts precisely 1 hour after the cement curing operation is completed or within a certain tolerance of the 1 hour time lag. In another example, an open FS relationship from a cement curing operation to a painting operation with a 1 hour time lag can mean that the painting operation can start any time at or after 1 hour after the cement curing operation is completed.

A logical relationship can be a Start-to-Start (SS) type relationship. A SS relationship from operation A to operation B can mean that operation A must start before operation B can start. Operation B can start any time on or after operation A starts, for example, immediately after operation A starts (e.g., 0 time lag, start substantially in parallel) or after a time lag. The relationship can be closed or open. For example, a closed SS relationship from a cement pouring operation to a heating operation with a 1 hour time lag can mean that the heating operation starts precisely 1 hour after the cement pouring operation starts. In another example, an open FS relationship from a cement pouring operation to a heating operation with a 1 hour time lag can mean that the heating operation can start any time at or after 1 hour after the cement pouring operation has started.

A logical relationship can be a Finish-to-Finish (FF) type relationship. A FF relationship from operation A to operation B can mean that operation A must finish before operation B can finish. Operation B can finish any time on or after operation A finishes, for example, immediately after operation A finishes (e.g., 0 time lag, finish substantially in parallel) or after a time lag. The relationship can be closed or open. For example, a closed FF relationship from a molding operation to a curing operation with a 1 hour time lag can mean that the curing operation finishes precisely 1 hour after the molding operation finishes. In another example, an open FF relationship from a molding operation to a curing operation with a 1 hour time lag can mean that the curing operation can finish any time at or after 1 hour after the molding operation has finished.

A logical relationship can be a Start-to-Finish (SF) type relationship. A SF relationship from operation A to operation B can mean that operation A must start before operation B can finish. Operation B can finish any time on or after operation A starts, for example, immediately after A starts (e.g., 0 time lag) or after a time lag. The relationship can be closed or open. For example, a closed SF relationship from a molding operation to a curing operation with a 1 hour time lag can mean that the curing operation finishes precisely 1 hour after the molding operation starts. In another example, an open SF relationship from a molding operation to a curing operation with a 1 hour time lag can mean that the curing operation can finish any time at or after 1 hour after the molding operation has started.

A logical relationship can also be a Finish-at-Start (FaS) type relationship. A FaS relationship from operation A to operation B can mean that operation B must start immediately upon operation A finishing. For example, a FaS relationship from a pouring concrete operation to a curing concrete operation can mean that the curing concrete operation is started immediately after the pouring concrete operation is complete. In another example, while a FS relationship from operation A to operation B with 0 time lag permits operation B to start any time after operation A is finished, a FaS relationship from operation A to operation B requires operation B to start immediately upon operation A finishing.

Any two operations in a pre-defined build formula can be related via a logical relationship, such as by joining the two operations with a type of logical relationship (e.g., FS, SS, FF, SF, FaS, etc.) on the graphical interface 600. An operation can be related to a plurality of other operations via separate logical relationships. For example, an operation can be related to three other operations via three separate logical relationships. In some instances, an operation in a first recipe can be related via a logical relationship to another operation in a second recipe. For example, an operation can be linked from a previous recipe via a previous task link 606 and linked to a subsequent recipe via a next task link (not shown in FIG. 6). A previous task link in a first recipe can be linked to a next task link in a second recipe via a formula relationship. In another example, an operation can be linked to a different recipe via an external recipe link 608.

Referring back to FIG. 1, after creating and/or assigning 108 a recipe to the structure elements, formula relationship s between the recipes can be created 112. The plurality of recipes in the pre-defined build formula library for the construction object may or may not be interlinked via one or more formula relationship s. For example, a first recipe can be linked to a second recipe via a formula relationship (e.g., previous task-next task link, external recipe link, etc.). A recipe can be linked to a plurality of recipes. In some instances, a single formula relationship can define a one-to-one relationship between two recipes. In other instances, a single formula relationship can define a relationship between more than two recipes, such as a one-to-many relationship, many-to-one relationship, many-to-many relationship, and/or a plurality of one-to-one relationships. A formula relationship can be a logical constraint. The formula relationship can define a sequential relationship, such as to identify which recipe is to be performed first, which recipe is to be performed after, which recipes are to be performed in parallel, which recipe is to be performed at a particular time (e.g., 45 minutes time lag, etc.), step, operation, phase, stage, point, duration, and/or other unit relative to another recipe, and other sequential relationships. A formula relationship can be a task dependency relationship (e.g., FS, SF, SS, FF, FaS, etc.) as described elsewhere herein. A formula relationship can link a recipe to external recipes (e.g., such as via an external recipe link 608), such as for building at another location. In some instances, a formula relationship between recipes of different structure elements can be based on the support data of the different structure elements identified earlier. For example, a formula relationship can be constrained by support data.

FIG. 7 illustrates a network of formula relationship s. A network 700 can show both intra-recipe (e.g., inter-operation) relationships and inter-recipes relationships. The network 700 can have a first slab recipe 702, a column A recipe 704, a column B recipe 706, and a wall A recipe 708. Each recipe can be defined by one or more operations. For example, the first slab recipe 702 is defined by a first operation to “place formwork,” a second operation to “place steel,” a third operation to “pour concrete,” a fourth operation to “dry concrete,” and a fifth operation to “remove formwork.” The operations in each recipe may be logically related by one or more logical relationships (e.g., intra-recipe, inter-operation, etc.), such as described with reference to FIG. 6.

A plurality of recipes can be logically related by one or more formula relationship s (e.g., inter-recipes relationship). For example, the four recipes 702, 704, 706, 708 can be interlinked via a first formula relationship 712, second formula relationship 714, third formula relationship 716, and a fourth formula relationship 718. Any operation in a recipe, regardless of sequence or order of such operation in the recipe, for example, can be linked to any other operation in a different recipe. In some instances, the inter-recipes relationship can be support data between structure elements (e.g., discussed with respect to FIGS. 2A and 2B). An operation can be linked to a plurality of operations, such as in a plurality of different recipes. For example, as shown in FIG. 7, a ‘remove formwork’ operation in the first slab recipe 702 can be linked to a ‘place formwork’ operation in the second slab recipe 704 and a ‘place formwork’ operation in the third slab recipe 706. While FIG. 7 shows the last operation of a recipe linked to the first operation of another recipe, any operation can be linked to different recipes. For example, an intermediary ‘pour concrete’ operation in the first slab recipe 702 may be linked to an intermediary ‘place steel’ operation in the second slab recipe 704. That is, each operation in a recipe can be an entry point from another recipe to the recipe. Each operation in a recipe can be an exit point from the recipe to another recipe. An operation can be both an entry point and an exit point. There may be multiple entry and/or exit points in a recipe.

An operation in a recipe may be linked to another operation external to the recipe via previous task and next task links. For example, a ‘remove formwork’ operation in the first slab recipe 702 can be linked to a next task link in the first slab recipe 702. The next task link in the first slab recipe 702 can link to the respective previous task links of two separate recipes, the column A recipe 704 and the column B recipe 706, via the first formula relationship 712 and the second formula relationship 714, respectively. The previous task link for the column A recipe 704 can be linked to a ‘place formwork’ operation in the column A recipe 704. The previous task link for the column B recipe 706 can be linked to a ‘place formwork’ operation in the column B recipe 706. For example, after completing the ‘remove formwork’ operation in the first slab recipe 702, the ‘place formwork’ operations in each of the column A recipe 704 and the column B recipe 706 can start. The task dependency of the ‘place formwork’ operation in the column A recipe 704 to the ‘remove formwork’ operation in the first slab recipe 702 can be defined by the first formula relationship 712 (e.g., FS, SS, SF, FF, FaS, etc.). Alternatively or in addition, the task dependency between operations in different recipes can be defined by a logical relationship from an operation to a next task link and/or a logical relationship from a previous task link to an operation. The column A recipe 704 and the column B recipe 706 can each be linked to the wall A recipe 708 via the third formula relationship 716 and the fourth formula relationship 718, respectively. The formula relationship between a previous recipe and a subsequent recipe can be linked via a previous task link in the subsequent recipe and a next task link in the previous recipe. The formula relationship between a previous recipe and a subsequent recipe can be linked via an external recipe link.

Thus, logical relationships (or constraints) can be created and managed both intra-recipe (e.g., inter-operation) and inter-recipes. Beneficially, different construction operations for a construction object can be managed within a structure element and between structure elements.

Referring back to FIG. 1, while creating and/or assigning 108 a recipe for the structure elements, a resource pool for the construction project can be defined 110. The systems and methods may provide a resource pool for a construction project. The resource pool can define the available resources for the construction project, such as labor (e.g., skill set in labor pool, standard work week, available dates, cost, etc.), equipment (e.g., location, reach, available time, efficiency, cost, etc.), materials (e.g., amount, type, cost, etc.), space (e.g., area, volume, height, equipment allowed in space, available time, labor allowed in space (e.g., maximum number of adults), cost, etc.), production rates (e.g., rates at which operations are carried out, etc.), work weeks (e.g., hours a week per crew, hours a week per individual, etc.), and other resources. Some resources, such as space and production rates can be global variables that are accessible from any recipe in the pre-defined build formula library. A recipe may draw resources from the resource pool. For example, the resource pool can present a constraint on the recipe or assignment of a recipe. In another example, the resource pool can present a constraint on one or more logical relationships between operations and/or between recipes (e.g., a SS relationship between two operations with 0 time lag may not be possible if resources available in the resource pool are insufficient, but a FS relationship may be possible).

FIG. 8 illustrates a user interface for defining a resource pool for a construction project. A graphical representation of a resource pool 810 is shown on a graphical user interface 800 on an electronic display 850. The graphical user interface 800 can be a dynamic user interface. The resource pool can comprise definition of one or more resources. The graphical representation of the resource pool 810 can have a resource navigation panel 802, such as to navigate between the different types of resources (e.g., labor, equipment, materials, production rates, spaces, workweeks, etc.). FIG. 8 illustrates a labor view of the resource pool.

For the labor resource, factors such as types of crews (e.g., carpenters, curing crew, etc.), number of workers per crew, wage (e.g., hourly pay, weekly pay, monthly pay, annual pay, per operation pay, per structure element pay, per construction project pay, etc.), idle days, and workweeks for the crew can be defined. For the equipment resource, types of equipment (e.g., cranes), flexibility of equipment (e.g., fixed in location, movable between different locations), available locations, reach, time required to move between locations, travel speed, and other equipment properties can be defined. For the material resource, factors, such as the amount and type (e.g., consumable, reusable, etc.) of material can be defined. In some instances, dimensions of material units can be defined. In some instances, the number of reusable cycles for a material unit can be defined. In some instances, the type of material can be specific (e.g., brick Brand A, brick Brand B, etc.) For the production rates resource, rates at which different operations are performed can be defined. For the space resource, a set of one or more spaces can be created by the structure elements involved in an operation. For the workweeks resource, definitions of times that a crew or a worker works can be defined. For example, a workweek can define how many hours a week a crew works. Such workweeks can be combined together, such as to create partial or complete calendars of workweeks. One or more resources in the resource pool, such as the production rates and the space, can be global variables that when created once can be used (or shared) by multiple recipes.

FIG. 9 illustrates a user interface for defining a space in a resource pool. A graphical representation of a space 910 is shown on a graphical user interface 900 on an electronic display 950. The graphical user interface 900 can be a dynamic user interface. The space can accommodate one or more structure elements. A user may select one or more structure elements and then drag (or otherwise interact with the structure elements or computer objects representing the structure elements) the one or more structure elements onto a space editing platform to create a space and/or a set of spaces. The set of spaces created by the user can be saved as global variables in the resource pool. Beneficially, the set of spaces can be accessed and/or shared by multiple recipes without requiring users to build the same space multiple times with small variations that can overlap and present problems during consolidation of the construction plan.

The systems and methods may provide comprehensive construction planning for a construction project using the abovementioned tools, such as pre-defined build formulas, formula relationship s, and/or the resource pool. Beneficially, logical relationships can be created and managed both intra-recipe (e.g., inter-operation) and inter-recipes to achieve both detailed and high level planning for a construction project. The intra-formula relationship s and inter-formula relationship s can be constrained by inter-connected logical relationships and the available resources in the resource pool such that changes can be made at any level of detail, including within an element, within a recipe, within the whole project, or any other level, without cyclic definitions. In some instances, one or more logical relationships may be created between groups of recipes. A logical relationship between groups of recipes may be created at different levels of detail, allowing for flexible control of hierarchies of recipes.

The construction planning and/or scheduling can be modified or updated in real-time, such as by modifying or updating one or more parameters (e.g., operation, element, grouping, recipe, etc.) of the construction plan. Upon modification or update, the construction project can be re-planned and/or re-scheduled. The parameters that can be modified or updated can include parameters, such as parameters of available resources in the resource pool and/or properties (e.g., amount, type, cost, etc.) thereof, sequence parameters, and parameters of the construction method (e.g., recipe, formula relationship, support data, etc.) and/or properties thereof.

As an example, a modification in the number of available resources can modify the number of available resources in the resource pool and reduce or extend a duration of completion for an operation, a recipe, and/or the whole project. In another example, requiring the finish of an operation, recipe, and/or the project within a fixed duration with reduced resources can require overtime work for available labor and increase costs. A sequence parameter can be modified, such as a hierarchical order in support data, a sequence of operations in a recipe, and/or a sequence of recipes in the construction project. In some instances, logical relationships can be modified, which can in turn affect sequence. In some instances, support data between structure elements can be modified, which can in turn affect sequence. A construction method parameter can be modified, such as a recipe definition, an operation definition within a recipe, logical relationships between operations in an recipe, logical relationships between operations in different recipes, logical relationships between different recipes, and/or other construction method parameter. As an example, a pre-defined build formula can modified such that a paint operation is added, or a drying time of concrete is reduced from 72 hours to 24 hours. A duration parameter, such as in a recipe, can be modified. A production rate parameter, such as in the resource pool and/or a recipe can be modified. An equipment parameter, such as crane type (e.g., no movement, movement) or a duration to move the crane between different locations can be modified. Any other parameter can be modified. Modifying, creating, deleting, or updating a parameter (e.g., modifying a recipe) can automatically update other parameters and/or variables throughout the construction plan for the whole construction project, such as to ensure there are no conflicts within the plan and the changes are feasible. The parameters and/or variables throughout the construction plan may be integrated in the construction plan such as to prevent cyclic definitions. In some instances, when the changes in a parameter conflicts with another parameter or are not feasible, the server may provide an error or warning message to the user. In some instances, a user may override the error or warning message and force the change.

Referring back to FIG. 1, the construction plan can be scheduled 114. For example, at least one part of the construction plan, such as an operation, can be plotted on a timeline. During scheduling, a start time and/or end time can be assigned to at least one part of the construction plan (e.g., operation). In some instances, a start time and/or end time can be assigned for the whole construction plan. In some instances, a start time and/or end time can be assigned for a part of the construction plan. The remaining part may or may not be automatically scheduled based on the first scheduling input. In some instances, the construction plan and schedule thereof can be visualized 116 on a graphical user interface. For example, the construction plan can be visualized as a list of operations that need to be completed, their respective durations, their respective required resources, and other definitions. The plan and/or schedule can be visualized as a plot, graph, table, or other charts showing information such as cost and duration (e.g., as axes in a graph, columns in a table, etc.). In another example, the plan and/or schedule can be visualized as a three-dimensional (3D) visual output showing a time-dependent 2D cross-sectional output progress. In another example, the plan and/or schedule can be visualized as a four-dimensional (4D) visual output showing a time-dependent 3D output progress, such as a 4D Gantt chart. The visualization may be filtered by different factors, resources, and/or other parameters. The construction plan and schedule can be presented on a dynamic user interface, such as having one or more user interactive objects (e.g., slider bar). In some instances, the construction plan and schedule can be visualized as information cards, such as by time, crew, operation, and/or structure element.

FIG. 10 illustrates a user interface for presenting a visualization of parametric scheduling. A graphical representation of parametric scheduling is shown on a graphical user interface 1000 on an electronic display (not shown). The graphical user interface 1000 can be a dynamic user interface. The outcome of a schedule for each modification or variation in parameter can be plotted in a chart 1002. For example, the chart 1002 can have two axes, including a duration (or time) axis 1006 and a cost axis 1008. Alternatively or in addition, the output can be represented in other forms of visualization methods, such as tables, graphs, charts, plots, or other forms of graphical representation. Alternatively or in addition, the output can be plotted as a function of a different combination of variables, such as duration, cost, total labor, efficiency, rate, and/or other variable. Each point (e.g., point 1004) can represent a construction plan and corresponding construction schedule with different parameters. In some instances, the location of a point on the chart 1002 for a construction plan and/or schedule can be indicative of a duration and total cost of the project. Beneficially, such visual plotting can easily allow assessment of whether a construction plan is within an operable or objective time frame and/or operable or objective cost. Different construction plans and/or schedules may be easily compared. This can help with downstream planning, downstream scheduling, and/or even downstream financing. In some instances, each point can be a user interactive object that can be selected. Upon selection of a point, more detailed information can be provided on the construction plan and/or schedule represented by the point. Such detailed information may be visualized, such as in the form of a 4D model and/or an enhanced Gantt chart.

FIG. 11 illustrates a user interface for presenting an enhanced Gantt chart for an exemplary construction schedule. One or more graphical representations of a construction schedule are shown on a graphical user interface 1100 on an electronic display (not shown). The graphical user interface 1100 can be a dynamic user interface.

A construction schedule having a particular set of parameters (e.g., such as represented by data point 1004 in FIG. 10) can be visualized as a 4D model 1102. The 4D model 1102 can be a 3D model of the construction object varying along a time axis 1106. A progress of the construction schedule may be visualized by presenting an expected (or actual) status of the construction object as a 3D model at a time of interest 1108 on the time axis 1006. The time of interest 1108 can be changed, such as by manipulating a user interactive slider along the time axis 1006. For example, depending on the location of the slider, the 3D model can be updated for view. In some instances, the 4D model can be viewed in playback, along a segment (e.g., start to finish segment, intermediate segment, etc.) of the time axis 1006, such as by selecting a ‘play’ button.

Alternatively or in addition, the construction schedule can be visualized as an enhanced Gantt chart 1104. The enhanced Gantt chart 1104 can have a time axis 1112. The time axis 1006 of the 4D model 1102 and the time axis 1112 of the enhanced Gantt chart 1104 can be correlated to each other. For example, the time location of the time of interest 1108 on the time axis 1106 can correspond to the time location of the vertical slider 1112 on the time axis 1110.

The enhanced Gantt chart 1104 can comprise a plurality of bars (e.g., bar 1114). A bar can represent an operation a crew must perform. The bars can be organized in rows, such as by operations in a recipe, operations in a location (e.g., level of a building), and/or operation by type of labor. For example, all operations in a single recipe can be visualized along the same row, and each row can represent a different recipe. In another example, all operations in a single location (e.g., C-deck, W-deck, E-deck, etc.) can be visualized along the same row, and each row can represent a different location. A bar can be labeled with an identifier of the operation, such as an operation name (e.g., “pour,” “cure,” “paint,” etc.).

In some instances, the bars can be color coded, such as by crew type (e.g., carpenters, painters, etc.). The bars can be color coded by other characteristics of an operation (e.g., duration, equipment, material, etc.). Alternatively or in addition, the bars can be visually grouped or categorized via another method (e.g., stripes, patterns, dynamic effect, shape, thickness of bar, etc.). The color coding or other visual marker of the bars in the enhanced Gantt chart 1104 can be correlated to the 4D model 1102, such that the respective colors of the structure elements in the 3D model corresponds to the color or other visual marker of the operation involving the structure elements. If more than one operation involves the structure element at the time of interest 1108 (e.g., corresponding to vertical slider 1112), the colors or other visual marker of the operations can be combined, such as in a stripe pattern or other forms of combination (e.g., blend of colors, other patterns, border and filling, etc.).

A bar may curve up at the end, such that operations taking a longer duration are more distinguished and easier to follow visually. For example, two bars overlapping, partially or completely, on the time axis 1110 can be distinguished in the overlapping portions by their respective curvatures or lack thereof. Advantageously, more bars, and thus more information, can be fit into a single chart without clustering the chart or adversely affecting legibility of the chart. The end of an operation can be represented by a black vertical bar at the end (e.g., right end). Alternatively or in addition, the end of an operation can be represented or otherwise emphasized by other visual markers (e.g., symbols, markers, different colors, different patterns, etc.). In some instances, the start of an operation can be represented or otherwise emphasized by visual markers. In some instances, a key reference time point (e.g., midpoint, 25%, 75%, 24 hours, 36 hours, 72 hours, etc.) in an operation can be represented or otherwise emphasized by visual markers.

When similar operations are performed by multiple crews of the same type, the similar operations may be collapsed as one bar, but the bar being identified with identifiers, such as operation names, of each of the operations collapsed into the one bar. Beneficially, this can avoid clustering the enhanced Gantt chart 1104 and make the chart easier to read.

The enhanced Gantt chart 1104 may be filtered, such as by crew type, recipe, element type, locations, and other groups described elsewhere herein. Beneficially, such filtered Gantt charts can be customized for users participating or interested in a particular type of group. For example, a particular crew may be provided with a Gantt chart of only the operations the crew is involved in. Such Gantt charts can be distributed daily, weekly, monthly, or for any time duration within or beyond the construction project duration.

A slider to navigate through the time axis 1106 for the 4D model 1102, such as to select the time of interest 1108, may move forward or backward through the time axis 1106 in variable increments. The time axis 1106 can be a discrete or continuous axis. For example, the slider can move in discrete increments of time, such as in increments of seconds, minutes, hours, days, weeks, months, quarters, years, or other time increments. Alternatively or in addition, the slider can move in discrete physical increments, such as in increments of operations, elements, recipes, crews, locations, or other groups. Alternatively or in addition, the slider can move continuously along the continuous axis as allowed by the resolution of the graphics on the graphical user interface 1100. The vertical slider 1112 to navigate through the time axis 1110 for the enhanced Gantt chart 1104 may move forward or backward through the time axis 1110 in variable increments, such as in discrete time increments and/or discrete physical increments, as described above. The vertical slider 1112 can move continuously along the continuous axis as allowed by the resolution of the graphics on the graphical user interface 1100.

In some instances, the construction planning and/or scheduling can be visualized as information cards 1120. FIG. 12 illustrates an enlarged view of the information cards of FIG. 11. A plurality of information cards (e.g., information card 1202) are shown on a graphical user interface 1200 on an electronic display 1250. The graphical user interface 1200 can be a dynamic user interface. The information cards can display information about the progress of a construction project at a segment of time, such as at a particular hour at a particular date (e.g., Tuesday Jul. 11, 2017 at 22:00). The information cards can display information at any time. Referring back to FIG. 11, the segment of time pertaining to the information cards 1120 can correspond to the time of interest 1108 in FIG. 11. Thus, the 4D model 1102, enhanced Gantt chart 1104 and the information cards 1120 can each be synchronized to the other in time. Sliding along a time axis in one of the three may display the synchronized view in the other two.

Referring back to FIG. 12, an overview information card 1210 can display a day number (e.g., since the construction project started), current time segment, total percentage complete, number of crews in operation, and number of operations at the current time segment. The overview information card 1210 can comprise other information about the status of the construction project (e.g., number of elements completed and/or in progress, number of recipes completed and/or in progress, etc.). Individual information cards (e.g., information card 1202) can display information about a specific crew, such as crew name, % work completed by the crew, operation that the crew is working on at the current time segment, and the recipe that the crew is working on at the current time segment. An individual information card can display other information about the status or involvement of the specific crew (e.g., location, equipment used, etc.). Alternatively or in addition, individual information cards can display information about a specific operation, a specific recipe, a specific element, or another specific group.

In some instances, the server may track a real progress of the construction project. For example, a real progress can indicate a completion rate of a structure element, recipe, operation, construction object, and/or construction project. In some instances, such real progress can be manually entered by a user. In some instances, an estimated progress can be confirmed as real progress by a user. In some instances, one or more machines or other devices may be able to detect, probe, and/or sense a progression rate of a structure element, object, and/or project. In some instances, the server may track a real condition or parameter of the construction project, such as a weather, atmosphere, humidity, temperature, pressure, or other condition or parameter that is capable of affecting, and/or defined as a parameter in, the construction schedule. In some instances, the server may track a real resource pool, such as real availability of different resources. Upon receipt of the real progress, real parameter or condition, and/or real resource pool of the construction project, the estimated construction schedule for the future time frame can be updated. For example, the server may re-run or re-calculate the remaining construction schedule based on remaining (e.g., future) portions of the construction plan. In some instances, the estimated construction schedule for the future time frame can be updated in real-time. Real-time can include a response time of less than 1 second, tenths of a second, hundredths of a second, or a millisecond. All of functions, such as those described above or further below, performed by the server is capable of happening in real-time. That is, the server may receive, identify, process, and output data in real-time. In some instances, a comparison between the estimated progress and real progress can be factored into a machine learning algorithm used by the server. An updated construction schedule can be presented to a user automatically or upon user instructions for an update. The updated construction schedule may be visualized, for example, by methods (e.g., graph, Gantt chart, 4D model, information cards, etc.) described elsewhere herein.

Computer Control Systems

The present disclosure provides computer control systems that are programmed to implement methods of the disclosure. FIG. 13 shows a computer system 1301 that is programmed or otherwise configured to, among other actions, receive data files defining a 3D model of a construction object, analyze and process such data files, identify one or more structure elements in the construction object, determine a shape and/or dimensions of the structure elements, identify one or more support data between the structure elements, create, delete, and modify support data between the structure elements, group and split structure elements, build and access a pre-defined build formula library, create, modify, and save pre-defined build formulas, create, modify, and save operations within a pre-defined build formula, create, delete, and modify logical relationships between operations and/or recipes, define a resource pool, and visualize aspects of construction plans and/or schedules. The computer system 1301 can be programmed to receive and effect user input via a user interface 1340, such as a graphical user interface. The computer system 1301 can be an electronic device of a user or a computer system that is remotely located with respect to the electronic device. The electronic device can be a mobile electronic device.

The computer system 1301 includes a central processing unit (CPU, also “processor” and “computer processor” herein) 1305, which can be a single core or multi core processor, or a plurality of processors for parallel processing. The computer system 1301 also includes memory or memory location 1310 (e.g., random-access memory, read-only memory, flash memory), electronic storage unit 1315 (e.g., hard disk), communication interface 1320 (e.g., network adapter) for communicating with one or more other systems, and peripheral devices 1325, such as cache, other memory, data storage and/or electronic display adapters. The memory 1310, storage unit 1315, interface 1320 and peripheral devices 1325 are in communication with the CPU 1305 through a communication bus (solid lines), such as a motherboard. The storage unit 1315 can be a data storage unit (or data repository) for storing data. The computer system 1301 can be operatively coupled to a computer network (“network”) 1330 with the aid of the communication interface 1320. The network 1330 can be the Internet, an internet and/or extranet, or an intranet and/or extranet that is in communication with the Internet. The network 1330 in some cases is a telecommunication and/or data network. The network 1330 can include one or more computer servers, which can enable distributed computing, such as cloud computing. The network 1330, in some cases with the aid of the computer system 1301, can implement a peer-to-peer network, which may enable devices coupled to the computer system 1301 to behave as a client or a server.

The CPU 1305 can execute a sequence of machine-readable instructions, which can be embodied in a program or software. The instructions may be stored in a memory location, such as the memory 1310. The instructions can be directed to the CPU 1305, which can subsequently program or otherwise configure the CPU 1305 to implement methods of the present disclosure. Examples of operations performed by the CPU 1305 can include fetch, decode, execute, and writeback.

The CPU 1305 can be part of a circuit, such as an integrated circuit. One or more other components of the system 1301 can be included in the circuit. In some cases, the circuit is an application specific integrated circuit (ASIC).

The storage unit 1315 can store files, such as drivers, libraries and saved programs. The storage unit 1315 can store user data, e.g., user preferences and user programs. The computer system 1301 in some cases can include one or more additional data storage units that are external to the computer system 1301, such as located on a remote server that is in communication with the computer system 1301 through an intranet or the Internet.

The computer system 1301 can communicate with one or more remote computer systems through the network 1330. For instance, the computer system 1301 can communicate with a remote computer system of a user (e.g., operator, manager, administrator, worker, crew leader, etc.). Examples of remote computer systems include personal computers (e.g., portable PC), slate or tablet PC's (e.g., Apple® iPad, Samsung® Galaxy Tab), telephones, Smart phones (e.g., Apple® iPhone, Android-enabled device, Blackberry®), or personal digital assistants. The user can access the computer system 1301 via the network 1330.

Methods as described herein can be implemented by way of machine (e.g., computer processor) executable code stored on an electronic storage location of the computer system 1301, such as, for example, on the memory 1310 or electronic storage unit 1315. The machine executable or machine readable code can be provided in the form of software. During use, the code can be executed by the processor 1305. In some cases, the code can be retrieved from the storage unit 1315 and stored on the memory 1310 for ready access by the processor 1305. In some situations, the electronic storage unit 1315 can be precluded, and machine-executable instructions are stored on memory 1310.

The code can be pre-compiled and configured for use with a machine having a processer adapted to execute the code, or can be compiled during runtime. The code can be supplied in a programming language that can be selected to enable the code to execute in a pre-compiled or as-compiled fashion.

Aspects of the systems and methods provided herein, such as the computer system 1301, can be embodied in programming. Various aspects of the technology may be thought of as “products” or “articles of manufacture” typically in the form of machine (or processor) executable code and/or associated data that is carried on or embodied in a type of machine readable medium. Machine-executable code can be stored on an electronic storage unit, such as memory (e.g., read-only memory, random-access memory, flash memory) or a hard disk. “Storage” type media can include any or all of the tangible memory of the computers, processors or the like, or associated modules thereof, such as various semiconductor memories, tape drives, disk drives and the like, which may provide non-transitory storage at any time for the software programming. All or portions of the software may at times be communicated through the Internet or various other telecommunication networks. Such communications, for example, may enable loading of the software from one computer or processor into another, for example, from a management server or host computer into the computer platform of an application server. Thus, another type of media that may bear the software elements includes optical, electrical and electromagnetic waves, such as used across physical interfaces between local devices, through wired and optical landline networks and over various air-links. The physical elements that carry such waves, such as wired or wireless links, optical links or the like, also may be considered as media bearing the software. As used herein, unless restricted to non-transitory, tangible “storage” media, terms such as computer or machine “readable medium” refer to any medium that participates in providing instructions to a processor for execution.

Hence, a machine readable medium, such as computer-executable code, may take many forms, including but not limited to, a tangible storage medium, a carrier wave medium or physical transmission medium. Non-volatile storage media include, for example, optical or magnetic disks, such as any of the storage devices in any computer(s) or the like, such as may be used to implement the databases, etc. shown in the drawings. Volatile storage media include dynamic memory, such as main memory of such a computer platform. Tangible transmission media include coaxial cables; copper wire and fiber optics, including the wires that comprise a bus within a computer system. Carrier-wave transmission media may take the form of electric or electromagnetic signals, or acoustic or light waves such as those generated during radio frequency (RF) and infrared (IR) data communications. Common forms of computer-readable media therefore include for example: a floppy disk, a flexible disk, hard disk, magnetic tape, any other magnetic medium, a CD-ROM, DVD or DVD-ROM, any other optical medium, punch cards paper tape, any other physical storage medium with patterns of holes, a RAM, a ROM, a PROM and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave transporting data or instructions, cables or links transporting such a carrier wave, or any other medium from which a computer may read programming code and/or data. Many of these forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to a processor for execution.

The computer system 1301 can include or be in communication with an electronic display 1335 that comprises a user interface (UI) 1340 for providing, for example, visualization or other graphical representations of the systems and methods disclosed herein. Examples of UI's include, without limitation, a graphical user interface (GUI) and web-based user interface. For example, the user interface 1340 can be the graphical user interface 300, the graphical user interface 400, the graphical user interface 500, the graphical user interface 600, the graphical user interface 700, the graphical user interface 800, the graphical user interface 900, the graphical user interface 1000, the graphical user interface 1100, and/or the graphical user interface 1200 described elsewhere herein. The UI 1340 can be a dynamic UI. The UI 1340 can be a user interactive interface. For example, a user may provide input to the computer system 1301 through a user input interface. In some embodiments, user input interfaces may comprise user input buttons, switches, knobs, levers, keys, trackballs, touchpads, cameras, microphones, motion sensors, heat sensors, inertial sensors, touch sensors, or any combination of the above. Alternatively or in addition, the user may provide input through a touch-enabled display (e.g., touchscreen) comprising GUI.

Methods and systems of the present disclosure can be implemented by way of one or more algorithms. An algorithm can be implemented by way of software upon execution by the central processing unit 1305. The algorithm can, for example, among other functions, receive data files defining a 3D model of a construction object, analyze and process such data files, identify one or more structure elements in the construction object, determine a shape and/or dimensions of the structure elements, identify one or more support data between the structure elements, create, delete, and modify support data between the structure elements, group and split structure elements, build and access a pre-defined build formula library, create, modify, and save pre-defined build formulas, create, modify, and save operations within a pre-defined build formula, create, delete, and modify logical relationships between operations and/or recipes, define a resource pool, and visualize aspects of construction plans and/or schedules. The algorithm may be a machine learning algorithm that can improve accuracy or converge to a user preference with repeated iterations.

While preferred embodiments of the present invention have been shown and described herein, it will be obvious to those skilled in the art that such embodiments are provided by way of example only. It is not intended that the invention be limited by the specific examples provided within the specification. While the invention has been described with reference to the aforementioned specification, the descriptions and illustrations of the embodiments herein are not meant to be construed in a limiting sense. Numerous variations, changes, and substitutions will now occur to those skilled in the art without departing from the invention. Furthermore, it shall be understood that all aspects of the invention are not limited to the specific depictions, configurations or relative proportions set forth herein which depend upon a variety of conditions and variables. It should be understood that various alternatives to the embodiments of the invention described herein may be employed in practicing the invention. It is therefore contemplated that the invention shall also cover any such alternatives, modifications, variations or equivalents. It is intended that the following claims define the scope of the invention and that methods and structures within the scope of these claims and their equivalents be covered thereby.

Claims

1. A system for object construction, comprising: one or more computer processors, individually or collectively configured to implement a method for constructing an object, comprising: (1) identifying a plurality of structure elements of an object by performing mesh analysis on a three-dimensional model of said object;(2) determining support data between said structure elements;(3) applying pre-defined build formulas or formula relationships for said structure elements based at least in part on said support data; and(4) generating an object construction plan comprising said pre-defined build formulas or formula relationships.

2. The system of claim 1, wherein said method further comprises generating a support data network using said support data determined in (2).

3. The system of claim 1, wherein said mesh analysis of (1) further comprises arranging said support data in a hierarchical order which correlate to a workflow order as part of said object construction plan for construction of said object.

4. The system of claim 1, wherein said mesh analysis is performed using one or more machine learning algorithms.

5. The system of claim 1, wherein said method further comprises one or more of (i) categorizing said structure elements by shape or type; (ii) determining dimensions pertaining to said shape or type; and (iii) determining dimension values for at least a subset of said dimensions, which dimensions or dimension values are used for determining said support data.

6. The system of claim 1, wherein said method further comprises tracking a progress of construction of said object.

7. The system of claim 6, wherein said method further comprises modifying a remaining portion of said object construction plan based on said progress of construction of said object.

8. The system of claim 7, wherein said modifying comprises modifying one or more parameters of said object construction plan.

9. The system of claim 8, wherein said one or more parameters comprises parameters of available resources in a resource pool for construction of said object or properties thereof, parameters of said object construction plan comprising one or more of said pre-defined build formulas, said formula relationships, and said support data, or a combination thereof.

10. The system of claim 7, wherein said tracking or modifying is performed in real-time.

11. A computer-implemented method for scheduling an object construction plan, comprising: (1) identifying a plurality of structure elements of an object by performing mesh analysis on a three-dimensional model of said object;(2) determining support data between said structure elements;(3) applying pre-defined build formulas or formula relationships for said structure elements based at least in part on said support data; and(4) generating said object construction plan comprising said pre-defined build formulas or formula relationships.

12. The method of claim 11, further comprising generating a support data network using said support data determined in (2).

13. The method of claim 11, wherein said mesh analysis of (b) further comprises arranging said support data in a hierarchical order which correlate to a workflow order as part of said object construction plan for construction of said object.

14. The method of claim 11, wherein said mesh analysis is performed using one or more machine learning algorithms.

15. The method of claim 11, further comprising one or more of (i) categorizing said structure elements by shape or type; (ii) determining dimensions pertaining to said shape or type; and (iii) determining dimension values for at least a subset of said dimensions, which dimensions or dimension values are used for determining said support data.

16. The method of claim 11, further comprising tracking a progress of construction of said object.

17. The method of claim 16, further comprising modifying a remaining portion of said object construction plan based on said progress of construction of said object.

18. The method of claim 17, wherein said modifying comprises modifying one or more parameters of said object construction plan.

19. The method of claim 18, wherein said one or more parameters comprises parameters of available resources in a resource pool for construction of said object or properties thereof, parameters of said construction plan comprising one or more of said pre-defined build formulas, said formula relationships, and said support data, or a combination thereof.

20. The method of claim 17, wherein said tracking or modifying is performed in real-time.