Bentley Systems, Inc.

Other

Raymond B Bentley

Keith A Bentley

Paul Connelly

John Gooding

Barry J Bentley

Rob Snyder

John Frampton

Sunand Sandurkar

Samuel W Wilson

Sam Wilson

In example embodiments, techniques are provided for refining tiles of an HLOD tree representing a model in order to display a view. A frontend module selects a tile represented by a node of the HLOD sub-tree and obtains information describing geometry of the selected tile. It determines that the selected tile requires refinement to support the view of the model based on the information describing geometry of the selected tile. A tile refinement strategy is determined from a plurality of tile refinement strategies. The frontend module applies the determined tile refinement strategy to the selected tile to generate one or more child tiles that have a higher resolution than the selected tile, the one or more child tiles represented by child nodes added to the HLOD sub-tree. The frontend module displays the view of the model at least in part by showing tiles represented by nodes of the HLOD sub-tree.

Efficient refinement of tiles of a HLOD tree

In example embodiments, techniques are provided for decoupling user access to infrastructure models from proprietary software that maintains and updates the infrastructure models. A backend application may include an infrastructure modeling backend module that, among other functions, handles communication with an infrastructure modeling frontend module of a frontend application that provides user access to the infrastructure model, infrastructure modeling hub services that maintain repositories for the infrastructure model, and an infrastructure modeling native module that creates, performs operations upon, and updates local instances of a database that stores the infrastructure model. While the infrastructure modeling backend module may pass information obtained from the infrastructure modeling frontend module and infrastructure modeling hub services to the infrastructure modeling native module, it may be functionally separated from the software of the infrastructure modeling native module that understands how to maintain and update infrastructure models, including interacting with local instances of the database.

In example embodiments, techniques are provided for converting geometry of an infrastructure model represented as high-level geometric primitives having a given symbology to low-level primitives, and encoding these low-level primitives into tile contents suited for transmission, and ultimately display upon, on a client device. An architectural split between frontend applications and backend applications may allow conversion of the high level primitives to be performed remote from the client devices by backend applications. Backend applications may be executed on robust hardware devices that execute software in a multi-threaded environment on powerful CPUs. By performing CPU-intensive operations on backend applications, frontend applications on client devices may be required to do little more than submit low-level primitives for rendering on their GPU.

Conversion of infrastructure model geometry to a tile format

In example embodiments, techniques are provided for frontend-driven, incremental HLOD sub-tree creation and dynamic generation of tiles. An infrastructure modeling frontend module (e.g., a iModel.js Frontend module) of a frontend application may incrementally create a local HLOD sub-tree, beginning with an initial HLOD sub-tree based on initial metadata provided without tile contents, and refined based on metadata provided with tile contents, from an infrastructure modeling backend module (e.g., a iModel.js Backend module) of a backend application. The local HLOD sub-tree of each infrastructure modeling frontend module may differ based on the individual tiles requested and the tile refinement strategies employed. The infrastructure modeling backend module may not maintain an HLOD tree, and simply generates tiles upon request, serving them and storing them in a tile cache incase they are needed again.

Dynamic frontend-driven generation of an HLOD tree

A system and method to compile different types of data from different locations into one reliable assemblage is provided. The assemblage includes an index of information provided to a user. The assemblage may be in the form of a three dimensional (3D) representation of an object, where the 3D representation includes an index and links to more detailed information regarding the object. The 3D representation of any object, for example, a body part in the context of medical imaging, or a building in the context of architectural and engineering design. The assemblage is comprised of 3D and 2D artifacts. The 2D artifact includes 2D vector and raster embellishment in a variety of forms. The 3D artifact includes vector graphics (2D and 3D) including all data obtained through data conversion methods, and 'Point clouds' (voxels).

Multi-dimensional artifact assemblage for infrastructure and other assets with interface node mediators

In one embodiment, a viewer executing on an electronic device having a touch sensitive display shows a three-dimensional (3D) model of a building created using computer aided design (CAD) software. A plurality of selectable interface nodes are provided at respective locations within the 3D model. Each interface node is linked to at least one corresponding two-dimensional (2D) construction drawing that shows a section view, a plan view, an elevation view or a detail view of the building related to the location of the interface node. In response to receiving input from a user indicating selection of a particular interface node, a menu is displayed with one or more selectable menu options. In response to receiving additional input from the user indicating selection of a particular menu option, a corresponding 2D construction drawing for the particular interface node is displayed in context of the 3D model of the building.

Integrated assemblage of 3D building models and 2D construction drawings

In one embodiment, a particular number of best entities are found in a database with a spatial index that satisfy both spatial criteria and entity filtering criteria. For each of a set of targets in the spatial index whose bounding box meets the spatial criteria, a spatial score is calculated. If the spatial score is less than a minimum spatial score in a current map of best entities and the current map is full, the target is excluded from further consideration. If the spatial score is not less than the minimum spatial score, when the target is an entity that meets the entity filtering criteria, the current map is updated to store the entity and the spatial score for the entity. When each of the targets in the spatial index has been subject to test or excluded from consideration, the current map is returned as a final result.

Efficiently finding spatially scored best entities

In one embodiment, a union of the bounding boxes is computed of entities in a relational database indexed by a spatial index, filtered according to some criteria. For each of a set of targets to be considered, a bounding box of the target is tested against a current range union result. If the bounding box is completely contained in the current range union result, the target is excluded from further consideration. Otherwise, the target is processed. When the target is an entity, it is determined whether the entity meets the entity filtering criteria. If so a union is computed and the current range union result updated. When each of the targets to be considered in the spatial index has been subject to test or excluded, the current range union result is returned as a final range union result.

Efficient range unions in SQL

Conventional file-based engineering design data for an engineering model are represented by a plurality of components. The plurality of components are kept in stores, which reside on servers. Each store contains the components that correspond to the elements of one design file. The stores also maintain a history of changes made to the components. A plurality of client computers are bidirectionally connected to the servers. Each client computer may obtain the current version of the components and may send locally edited versions of the components back to the servers to replace the current versions in the stores. At the client computer, the user interacts with the components using conventional file-based software. Before the locally edited versions of the components are committed to the servers to replace the current versions, a synchronization and merging process occurs whereby the latest version of the components are downloaded to the client computer and are compared to the locally edited version of the components to detect resolvable (compatible) and unresolvable (incompatible) conflicts. The commit process is performed only if no unresolvable conflicts exist between the two versions of the components. To facilitate translation between file-based data and components, a schema is written to 'wrap' each of the engineering file formats. Each schema is a set of classes that capture all of the information in the file-based data.

System, method and computer program product for collaborative engineering using component and file oriented tools

Conventional file-based engineering design data for an engineering model are represented by a plurality of components. Each component has a unique identifier, a set of fields, each field having a data type and a data value, and a program which interprets and modifies the fields. The plurality of components are stored in a repository of a server. The repository also stores a history of any changes made to the components. A plurality of client computers are bidirectionally connected to the server. Each client computer may obtain the current version of the components and may send locally edited versions of the components back to the server to replace the current versions in the repository. At the client computer, the user interacts with the components using conventional file-based software. Before locally edited versions of the components are committed to the server to replace the current versions, a synchronization and merging process occurs whereby the latest version of the components are downloaded to the client computer and are compared to the locally edited version of the components to detect resolvable (compatible) and unresolvable (incompatible) conflicts therebetween. The commit process is performed only if no unresolvable conflicts exist between the two versions of the components. To facilitate translation between file-based data and components, a schema is written to &ldquo;wrap&rdquo; each of the engineering file formats. Each schema is a set of classes that capture all of the information in the file-based data.

System for collaborative engineering using component and file-oriented tools

A fluorescent-type lamp fixture is disclosed which can be rapidly assembled and has channel and cover members each with means to enable the members to be snapped together. The cover member carries spaced-apart holders for receiving the lamp and other electrical components. A pair of caps are provided which are plugged into the open ends of the assembled channel and cover members, the caps are shaped to insure proper alignment and effect their retention. A lens is also provided having projections that are snapped into recesses in the end caps to hold it securely. In another embodiment, a light shield is rotatably mounted on adaptors positioned adjacent to the caps to direct light to a number of positions.

Growing community of inventors

Elverson, PA, United States of America

Raymond B Bentley