#ZOLOTAREVA | Explore Tumblr Posts and Blogs

architectnews · 3 years

Text

Sphereing: Real-time Collaboration and Co-presence

Sphereing Real-time Collaboration and Co-presence, ZHVR Zaha Hadid Virtual Reality Research Group Website, Architecture Images

ZHVR Zaha Hadid Virtual Reality Research Group: Sphereing

2 Sep 2021

A Novel Framework for Real-time Collaboration and Co-presence in VR

A Novel Framework for Real-time Collaboration and Co-presence in VR ZHVR White Paper by Helmut Kinzler, Risa Tadauchi, Daria Zolotareva, and Aleksandra Mnich-Spraiter

In this paper, we present Sphereing as a novel conceptual framework for realistic co-presence and collaboration inside VR1. While our own research is aimed at the Architecture, Engineering, and Construction (AEC) industry, this framework is envisioned for broader, persistent use in cybernetic commercial and public domains. Through our research into the requirements for an immersive collective collaborative environment, we have come to see that a unified information space is essential for effective knowledge exchange, and for creating and hosting holistic, multi-author constructs. This raises questions of authorship, IP, and access privileges within the singular space, which we address through our Sphereing approach to unified data.

Introduction – Background Architectural project developments are historically collaborative efforts and have a cross-disciplinary culture and a wide and diverse ecosystem involving clients, designers, manufacturers, artisans, planners, managers, public relations, and academicians, to name a few. Despite this, all architectural project stakeholders are presently siloed within their respective discipline-specific design workflows and specialist softwares. Project information is discontinuous, divided along disciplinary boundaries and spread across disconnected company servers, with much of this data stored in proprietary specialist software file formats.

Frequent translation and merging of information is required throughout the design process, delaying access to information and jeopardising the accuracy of the information by un-managed metadata. Furthermore, a portion of the metadata is altogether severed from the digital sphere: key pieces of knowledge that reside in the human communication sphere of phone calls, zoom meetings, etc. need to be manually inputted and are at constant risk of being omitted from the record.

In the current disconnected digital environment, the persistence of legible and discernible digital data is illusory at best. Few people have firsthand knowledge of file names and locations of data within labyrinthine project folder structures. Without their input, various file versions need to be cross-referenced to forensically reconstruct what options were tested, how and when they were presented, and by what criteria the project evolved. As old versions of specialist software used to create project data quickly become obsolete and new operating systems no longer support previous versions of the software, this type of project forensics becomes a costly and near-impossible exercise.

This situation poses a serious problem for Quality Assurance (QA) protocols. Architects in the UK are currently required by law to keep project documents for any project for a period of 15 years after the completion of any given project, to defend against any legal claims for breach of contract, tort of negligence, or latent defect (Wevill and Institute, 2018). Moreover, the UK presently is going through a regulatory overhaul of the AEC industry based on findings of Dame Judith Hackett following the Grenfell tragedy (Hackit, 2018).

In the draft Safety Bill (Draft Safety Bill, 2020) currently under review in Parliament, UK Legislation is introducing the Golden Thread Principle that will require a complete record of every decision affecting the building’s evolution from early design decisions, through construction, to legacy handovers, including all maintenance and repairs. The project team will now be required by law to keep track of what changes were introduced to the design and the reasons behind them.

While Building Information Management (BIM) attempts to tackle this problem by storing project metadata, it requires a certain amount of project maturity and resolution to be deployed. Because of this, BIM often does not capture the early formative stages of architectural projects where the most critical and impactful decisions are made, especially on innovative non-standard projects, where the final result is not known from the start. Nor does it capture the evolution of the project over time and the reasons for certain decisions.

Our information management systems—and all current forms of data representation—have evolved from the two-dimensional constraints of the traditional drafting board, with systems such as layering systems and text-based systems coming from a classical understanding of architectural representation. Because the systems remain linked to textual records and two-dimensional drafting, the description of projects becomes limited by a linear understanding of space-making for the designer. As a result, current information systems are still not well equipped to capture three-dimensionality, nor the fourth dimension—that of time.

Architectural projects are never linear processes. They require iterative design and design evaluation to reach the final outcomes and build results (not just as an individual, but also as a collective level). The ability to simulate all aspects of the building, including the temporal, from the spatial and material qualities to the construction sequence at the highest resolution possible today’s immersive technology, is increasingly becoming integral to the contemporary designers’ toolkit and decision-making process.

With the advent of VR, it is possible to move beyond the limitations of flat-screen CAD and modeling softwares and re-establish the sensible relationship between the human subject and the site. Being ‘inside’ the space removes the disconnect (to the virtual extent) that current technology provides. The simulated environment at scale taps into embodied knowledge that is not accessible in other ways as the building is realised, and provides a way of strengthening or re-establishing the links between two-dimensional projections, three-dimensional models, and the physical scale of the human subject.

As an enhanced form of human-machine interaction, VR is also a valid practical means to access information and the data-sphere. Philosopher Philip Zhai writes that, logically, VR experience is identical to physical-reality experience because both rely on the same ‘wetware’ physiological equipment. This is not only determined by the physiological means, but is tied to the human biological reference system that forms human cognition (Zhai, 1998). On the basis of this equation, VR is the optimal way for humans to interact within the digital information sphere, connecting human cognitive facilities with evolving information systems.

Even though VR has potential to revolutionize the way we design and interact with information, current developments in VR Design and Design Coordination Solutions are primarily single-discipline; without acknowledging the legal and multi-disciplinary aspects of the ecosystem. Thus, despite the evolution of digital tools for the AEC industry, the narrative thread of a project’s development is most often missing in current projects as no system is yet able to store all project-related data. This calls attention to a need for a unified review and record-keeping VR platform that can be used to consolidate digital data and keep track of the review and decision-making process during the entire lifecycle of a project.

We, therefore, aim to innovate a platform with the interface between all the architectural disciplines and the unified database sustaining the project information and content developed across the lifespan of an architectural project.

The Sphereing Solution We base our subsequent investigations on the central premise that all project information must be contained in one singular and flexible information structure that is capable of sustaining the entire project ecosystem. We can imagine this system working similarly to the SDKs of the i-Phone, NVIDIA’s Omniverse [Omniverse], and Nucleus Server [NVIDIA], for instance, and including information semiotics, experiential aspects (photo-realistic and abstract representation), information registration, management, and visualisation for architectural assets, as well as the application of parametric and algorithmic tools and AI for production and data management.

This unified information sphere, or World Environment (WE), is a metaverse that functions as a review space, communication, visualisation, and project management tool; able to handle high resolution immersive space as well as documentation and recordkeeping, it allows all parties involved in the creation and maintenance of a building to converge in a single experiential space. Crucially, all parties maintain their specialist roles and legal requirements in the World Environment, because the sphereing framework is an acknowledgement of collective use that upholds all existing agreements and demarcations.

Due to the diversity of data characteristics collected in the WE database, a uniform data classification system is needed to distinguish between the four distinct core asset types: the immersed human, the experiential project data, project metadata, and the virtual user interface. All four data classes and combinations thereof can be visualised and interacted with inside the immersed environment by participating disciplines with their unique requirements and visualization styles.

Immersed Humans (IH) An Immersed Human (IH) is a customisable digital representation 2 of an immersed individual who is on-boarded to work inside the World Environment (WE). The IH is assigned a discipline-specific colour code, and the person’s height, navigation sensitivities, and field of view can all be adjusted based on the needs of the user. Each IH is contained within a dedicated Personal Work Sphere (PWS). Experiential Project Data (EPD) Experiential project data refers to all object assets produced inside the World Environment or uploaded by on-boarded IHs that are immersively accessible.

Metadata Metadata is defined as a set of project information and data that is referenceable to other sets of project information and data that exist within the unified database. Project information in the World Environment is defined as information and references related to the EPD that is produced and accumulated from the early stage of a design development onwards.

Virtual User Interface (VUI) User Interface (UI) is a connection between IH and all other core classes inside the WE. The four classes described above form the totality of the information sphere, and always exist in the context of one or more amalgamations. For instance, various immersed humans participate as authors, as consultants, and as visitors throughout the design process. There are also various stages and iterations of experiential project design assets and metadata. To interact with the totality of this information, a clearly-distinguishable UI is necessary, which must also be distinct from an experiential point of view from all the other data.

Sphereing is a functionality used to record, access, organise and demarcate combinations of assets in the World Environment, recognising the various authors, their credentials, and the scale and time and the location of the information. Likewise, when sphereing applies to immersed humans and their actions, both to individuals and collectively, it creates the necessary conditions and agreements for co-presence. As topological data divisions, spheres are not geometrically visible; they exist as envelopes for collections of data in three dimensional World Environment coordinates and with the WE time aspect.

Sphereing forms guided personal, discipline-specific (internal), and cross disciplinary constraints on project data and information, and applies to all data existing inside the WE database. By default, the WE platform and the operating system produces a single type of sphere, the World Environment Sphere (WES). The WES is a unique immersed sphere that contains all the project information visualised via the game engine. This is equivalent to the immersed, experiential, and four dimensional version of the WE Unified Database that exists in the server.

Further intrinsic sphereing at the root level occurs as soon as the immersed human enters or joins the information space with an agreement as to the scale, location, and WE time of that particular immersive experience. The presence of IH creates a persistent individual sphere, and leads to the possibility of creation of other spheres automatically or manually by the IH.

In order for individual human beings to access the World Environment platform and to become recognisable and identifiable within the system as an Immersed Human (IH), every individual is first asked to pass the WE Onboarding System. Essentially, each IH is a type of WE asset with a WE Passport (WE_PASS). The WE_PASS contains all the personal registered information of individual users, such as the person’s name, discipline, company name, company role, email, contact, and any other information that may be required.

Once the on-boarding and platform registration is completed, the system automatically produces a fundamental type of sphere for personal use, the Personal Work Sphere (PWS). PWS is a customisable personal work environment that contains a digital representation of the immersed human and their Personalisable User Interface (PUI). PWS is an individual unit for each IH, enabling the individual to be recognisable and interactable inside the WES. With the registered personal information about discipline and role types, the system allocates each IH to one of the collective units, called Collective Work Spheres (CWS), typically displayed as (Company Name) Collective Work Sphere (eg. ZHA-CWS).

Automatic spheres spring into action whenever the WE automated system needs to create anything with an IH name tag that then has to be distinguishable from all the other information; this happens in the background and without the user’s active involvement. It’s a part of the production pipeline, where all assets generated or uploaded by the users must be made distinguishable by their unique identifiers containing information about who uploaded or created the information and when.

High level manual sphereing is necessary for curating information specific to the needs of an IH. Whether it is to describe a certain aspect, to make a distinction, or to inform others, selected information needs to be placed in a specific context, and certain aspects brought to the foreground. Whenever the IH wishes to explain their reasoning, either as part of a dialogue with another IH or for a presentation to another discipline, they manually bring together and cast a net around a subject or several subjects and several core classes. This has the function of describing certain aspects or certain parts of the selected information, by giving them a name and a distinction, as well as recording the date, time, and location of this particular selection. This is part of the multidisciplinary aspect of looking at the same information, but forming independent inputs from unique points of view and areas of experience.

Another type of manually-created sphere that advances the project discourse is a meeting sphere. In every meeting sphere, there is an agreement between multiple parties that has its own time and location inside the World Environment. The host / owner of the meeting sphere has persistent privileges, such as the ability to lock certain aspects and functions of the sphered information, and assign a presenter. The presenter, in turn, is able to relocate the meeting to new coordinates (unless locked by the host) and make changes to the UI to interact with the experiential data in a way that is fitting to their needs.

Here sphering is used to create a group of individuals, name the meeting group, assign a tag to the meeting group with relevant information, such as the world coordinate of the meeting location, meeting time, meeting organiser and host, meeting sphere capacity and number of attendees. Experiential design assets can be added to the meeting sphere, with instances of the project shown at different scales.

Another very important functionality of sphering is to handle the access rights, either on a temporal/ad hoc, or a more permanent/systemic manner. For instance, to enable asset sharing and version control inside the meeting sphere, a temporary increase in an asset access level is required for invited IHs to review and evaluate internal discipline-specific project content.

Project specific data with properties inside the Project Sphere is tied to authorship, IP ownership protection, and disciplinary demarcations. Broadly referred to as WE assets, they are able to contain WE experiential data and metadata. All project data and information that exist inside the WE unified database is demarcated with special administration and permission levels called Sphereing Levels (SL) (Figure 1). This demarcation system controls visibility, transparency and access privileges of all WE assets inside the World Environment and also manages version controls. The SL is only editable by the registered discipline specific project admins, who are able to upgrade or downgrade design objects of their discipline; until they are upgraded, all design items remain as personal production.

When any WE asset is created, it is not given full circulation inside the WE. Instead, it is created at the Personal Sphereing Level (inside the Personal Work Sphere), or SL1, and is then pushed to the company-wide SL2 (Collective Work Sphere) or the interdisciplinary SL3 (Project Sphere), prior to being reviewed and submitted to the client (SL4).

SL0 is the personal immersive space prior to entry into the company-owned IP domain. SL1 contains private and personal assets, whose IP belongs to the associated registered company. These assets are visible and accessible only from the Personal Work Sphere. SL2 contains Internal Discipline Specific (IDS) approved assets. These assets are visible and accessible from the Collective Work Sphere. SL3 contains Cross Disciplinary (CD) approved assets. These assets are visible and accessible from the WE Project Sphere and shared and visitable by selected disciplines with special agreement. SL4 contains client approved assets. These assets are visible and accessible from the We Project Sphere and shared and visitable by all disciplines with special agreement. These are typically polished assets that are prepared or being prepared for official or/and legal submissions. SL5 contains public assets. Assets at this level show the potential to marketise We assets (e.g. for exhibitions, company promotions etc). After the completion of a project with an agreement with project contributors, the WE Project Sphere owner can arrange to invite public domain users/visitors with SL5 special permissions to their site to share the cultural development of the project.

Inside the WE, there is a need for a commercial/corporate relationship between the employee and the company they are working for. This bonds SL1 and SL2 to the employer for persistence, in case the employee changes jobs, and for information affiliation purposes (the IP of the generated output belongs to the employer). A person can thus have a Personal Work Sphere SL1, and also have during regulated hours and contractual affiliations their work bonded to the employer.

Conclusion We have demonstrated the need for a collective virtual environment, due to the state of computerisation in the industry and the collaborative and multidisciplinary nature of the work. This is needed to minimise translation of information and maintain a unified record of project information that is readily accessible according to the suitable access privileges, and to allow all industry partners to author directly into the singular unified data space right from the inception of any project. Because a collaborative virtual environment for the entire AEC ecosystem would need to ensure that parties can be liable for their individual scope, it necessitates differentiation of the parties and their input.

We propose sphereing as a dynamic methodology to allow all disciplines to review, co-author and manage the entire architectural project ecosystem collaboratively. Sphereing inside the unified dataspace applies to the full extent of a project timeline, from the pre-inception stage to post completion, in the form of digital twins and archiving.

Acknowledgement This paper stems out of ZHVR’s contribution to the collaborative research project called PrismArch. PrismArch is a cross-disciplinary immersive technology research project funded by the European Union under the Horizon 2020 research and innovation programme. The main objective of PrismArch is to achieve a “prismatic blend” between aesthetics, simulation models and meta-information that can be presented in a contextualized and comprehensive manner in Virtual Reality (VR) in order to allow collaborative manipulation of the design and accurate assessment of new design decisions

References Goriunova, O., 2018. Digital Subjects: an introduction, Springer Nature Limited. Available at: [Accessed 5 July 2021]. GOV.UK. 2021. Draft Building Safety Bill. [online] Available at: [Accessed 12 August 2021]. Hackitt, J., 2018. Building a Safer Future Independent Review of Building Regulations and Fire Safety: Final Report [online] Available at: https://ift.tt/3gVtNs4 ort [Accessed 12 August, 2021]. Wark, S., 2018. The Subject of Circulation: On the Digital Subject’s Technical Individuations, Springer Nature Limited. Available at: [Accessed 5 July 2021]. Wevill, J. and Institute, R. (2018). Law in practice. London: Riba Publishing, p. 48. Zhai, P., 1998. Get Real. Maryland, US: Rowman & Littlefield, p. 38.

ZHVR Group website

Sphereing: Real-time Collaboration and Co-presence image / information received 020921

Previously on e-architect:

26 Feb 2019 Project Correl Collaborative Virtual Reality Experiment Design: Zaha Hadid Virtual Reality Group (ZHVR)

Location: University Contemporary Art Museum (MUAC), Mexico City

Model photographs below by Julien Loalo:

Project Correl Interactive Virtual Reality Experience

Zaha Hadid Architects

Location: London, UK

Cocoon Hotel, Tulum, Quintana Roo, Mexico Architects: DNA Barcelona image from architects Cocoon Hotel Building

ZHVR LOOP Immersive Sound Lounge

Niop Hacienda Hotel, Champotón, Campeche, Mexico Design: as Arquitectura & R79 photograph : David Cervera Castro Niop Hacienda Hotel, Champotón

Zaha Hadid Architects

Comments / photos for the Sphereing: Real-time Collaboration and Co-presence page welcome

The post Sphereing: Real-time Collaboration and Co-presence appeared first on e-architect.

#e-architect

0 notes