Breaking Down the Silos: Enhancing Interoperability Between Rhino and Revit

DAVID A. FINK: So welcome to our session today on breaking down the silos, enhancing interoperability between Rhino and Revit. Thanks for the Autodesk University Board for inviting us to present this topic. We think it's really relevant and a valid exploration of using the data connectors in working processes. So just a quick state harbor statement. Antonio's from Autodesk, so we have to show this to you. Don't make any purchasing decisions on the information that we're showing you today.

So my name is David Fink. I'm the Digital Manager at Henning Larsen in Copenhagen. My main role is promoting digitalization across Henning Larsen and Ramboll. Henning Larsen was purchased by Ramboll about five years ago, and we were working on this integration between the two offices. I've been at Henning Larsen since 2019, working as a Digital Manager, and I'm also a member of Ramboll's Transforming Delivery Steering Committee, where we look into how we can improve the daily working processes across the entire organization.

I started my BIM implementation and digitalization journey at Schmidt Hammer Lassen in 2007 with the Danish BIM Mandate. This was a mandate that required all public buildings to be done in BIM. I'm also the chairman of the BIM Copenhagen Network Group, so if you're interested in seeing what's going on in digitalization within Scandinavia, come and join one of our meetups. You can find us on LinkedIn. So in my free time, I'm an avid biker, brewer, and barbecuer.

ANTONIO CANERO: Hi, everyone. My name is Antonio Canero. I'm a Principle Implementation Consultant at Autodesk. Normally, I'm trying to drive innovation and efficiency in BIM implementation projects. And in Autodesk, my role is Implementation Consultant, as I mentioned, but with Ramboll, I'm acting as a product owner of a number of solutions. And my goal is to empower teams to deliver faster incremental value in complex projects.

I started to work in BIM many years ago as a BIM coordinator in large-scale projects, such as the Riyadh Metro. And later on, I moved on to BIM manager roles in large-scale projects as well, such as Sydney Metro and Brisbane underground line. In my free time, I like to travel. I still technology enthusiast and architectural lover.

The learning objectives that we are going to be tackling during these sessions are around Data Exchange, how to exchange data, in this case between Rhino and Revit. We are going to be looking at the workflows involved. We are going to do that through in a creative way. We are going to involve Dynamo, and we are going to have all the time in the core of the session collaboration between different teams within or outside of the organization.

DAVID A. FINK: So I'd just like to say a few words about Henning Larsen. We're an office based in Copenhagen. And this is actually Henning Larsen in Denmark. He's known as the master of daylight. But in our office, he's known as also the head of curiosity, and that's also what drives the exploration of new technologies and new workflows in the office.

We're a global practice. We have offices around the world. It was founded in 1959. We have done projects in over 30 countries and have design studios in Copenhagen, New York, Munich, Berlin, Oslo, Hong Kong, Singapore, and Sydney. We're about 600 people globally, and our most recent office is in Sydney. So we're pretty happy about expanding into Australia now.

We do primarily architecture, but within our architecture, we try to integrate landscape and also urbanism. So we don't look at just buildings by themselves, but we look at them in the built environment as well. We're very interested in materials, so we look at sustainability and circularity in the materials that we use. We have a high focus on design, and we do a lot of internal research in the office. We have a lot of industrial PhDs doing research on new technologies in the construction industry.

We do a lot of evidence-based design and data-driven design. We feel that this is the future for engaging sustainability in our projects. And also we have a way of dialogue and collaboration, not only with our clients but within the office as well, that we're really into talking about and hashing out our designs within the design teams.

So some of today's learning objectives are we want to learn more or teach you more about the Data Exchange between Revit and Rhino and the possibilities that it offers. We also want to explore some of the effective workflows that we've tailored to get the results that we want out of this design Data Exchange and also how we've leveraged the Dynamo connectors to get this to work. And in the end, we want to also show you how you can cultivate creativity and innovative thinking through Data Exchange and also freeing up the time to do more interesting work in your offices.

So today's agenda, we'll look at some of the challenges that we have, both in today's working environment and with the out-of-the-box Data Exchanges. We'll take a look at the big picture of how we want to use Data Exchange in the future, the vision that we have of how we want to get the most effective results out of the Data Exchange. And then we'll wrap up with some use cases and some demos.

So why Data Exchange? It's like, I think we all know that we lose a lot of time and. In interoperability between the different tools. In our office, we use Revit and Rhino, and we spend a lot of time remodeling Rhino models in the Revit environment. So through these Data Exchanges, we can see that we can save time, we can reduce the amount of rework we have on projects, we can develop better products and projects, and we can also minimize the data loss. And what does this do? This allows more time for design and more time for human-centric processes.

So if you're not familiar with Data Exchange, Data Exchange was first presented at AU in New Orleans in 2021, and we kind of saw this as really a groundbreaking tool within the Autodesk Construction Cloud, because now not only are we starting to look at the tools for Revit, but it was also using tools for Rhino. And now you can see that there's a whole group of connectors for Tekla, Power BI, Dynamo, Grasshopper, and more connectors are coming.

But what is the challenge of using these Data Connectors in a working environment? So before I go into the challenges, I'd also like to just ask a few rhetorical questions about data centricity, because I think these Data Connectors and Data Exchanges is really the future. And the idea is, can we work in environments without files? Because I think if we look at how we work today in the AEC industry, we have a tendency to share a lot of files with each other. And the idea is, how can we work more fluidly without these files?

And next question is, how can we overcome our interoperability challenges? And this is where the Data Exchanges are really helpful because now we can see that we're starting to break down the walls between the tools that we use. Then will it be possible to exchange only the data that's needed? And I think that's a definite yes, because we can see with Data Exchange that we don't need to exchange an entire project. We only need to exchange what's needed at that point in time to the consultants who need it.

And will it also be possible to visualize data without the need for software? And this is also yes. By moving to the cloud, we can see that we no longer need installations on our PCs, but we can use this through a web browser, which also kind of liberates the data for everyone. So it's not only the modelers that have access to it, but also the project architects and project managers.

So let's take a look at how we worked before. Before, we used to work in Rhino. Then we would get to a point where the geometry was more or less fixed. And then we would move over to Revit, and then we would model the rest of the project from there.

But times are changing. We can see that we're using Rhino further into the design process after our Revit models have been completed. So this causes a problem that we have these divergent models that are still being used for production and design. But the longer the project goes on, the more divergent they are and the less they work with each other.

Then we also have a situation where we use Rhino further into the process, but we also take out pieces of the model for design explorations. This requires somebody to remodel those design explorations back into the main model, where they can get a new piece of the Revit model for another design exploration where it's fed back in. So we feel that we can optimize the processes that we have by using these Data Exchanges.

And then we have a new situation where we have an interior design department, and their primary tool is Rhino. So they're developing all the fit out for our projects in Rhino, but we would like to get this in as native objects in Revit. So not only do we have these sketch models, but we also have these objects that are being modeled in Rhino that we need to push into our projects.

So the question we have now is, can we work across multiple platforms without remodeling geometry? And that is what we were trying to show today, that it is possible to do this. So if we look at some of the exchanges we have available, we have Rhino inside and we have BEAM, and we consider these as these point-to-point exchanges, where you're just pushing objects back and forth between the two. And this is not taking advantage of the cloud. It's just going directly from one tool to another.

Then we have these what we also consider single-directional exchanges, where we're also only getting direct shapes and generic models out of the exchanges. So we don't feel that these are efficient or as effective as we possibly can be, because every time there's a design change that we need to push a new piece of geometry across. So we have this idea of being more data-centric and then using tools like Speckle or the Data Exchanges to push geometry back and forth.

This is great because we're starting to leverage the cloud where we can store this and take advantage of this kind of visualization of the data that's being exchanged. But the problem is that we're still ended up ending up with direct shapes and generic models, which means that we can't edit the files downstream. So we're kind of locked into the geometry, and then they're also ending up in the wrong categories.

We've also decided between Speckle and Data Exchange, but then if we look at Speckle, that means we have to manage a second cloud. And our idea is to have everything for a project hosted in a single cloud solution. So then that's why we've decided on Data Exchange, but we also want to get native geometry and have the objects assigned to the correct categories in the end. So this is not as easy as it looks, and I'll show you why.

Because if we take a look at the out-of-the-box Data Exchange connectors and we start with our Revit model, this is just a simple house. Not that many objects in it, but I think this is the best way to show the problem. So we can model a house in Rhino. Then we can move it into the Data Exchanges and into Revit.

And when we do that, we can see that everything comes in as direct shapes. All the objects come in as generic models, and they're also assigned with a GUID code. So this means that we can't edit it, and every object is unique in the entire project, not the greatest workflow for us.

So we have a dream that we can take the Data Exchanges and move them from Rhino to Revit and get native objects assigned to the correct categories that we can edit. This means that we can take the objects that we developed in Rhino, move them to Revit, and continue the life cycle of the project on. We don't need to remodel the objects, moving from direct shapes into actual native geometry.

So the big picture of this is that right now, we have a siloed environment of tools and disciplines where we use multiple tools, and disciplines are modeling in their own environment. And then we're throwing files and to each other and hoping that they have the right information that they need. So with these tools, we believe we can break down these silos and just give the information to the consultants and the designers that they need at that particular point in time.

Then we also can see that this is really a fragmented workflow, that we don't have that fluidity across the different platforms and across the different phases that we want to have, that every time we have to stop and make an exchange, we either lose a little data or we have to take a break, or we need to wait for some data to be received. So we believe that these data exchanges can remove some of the fragmentation we have in our daily work.

And then we're also very interested in this versioning. So we can also go into the cloud and see what we've done in the past, to see which designs worked, which designs didn't work. And we have all of this documented in one location, so we can move backwards and forwards through the versioning of the different exchanges that were done over time. So we also see this as a huge benefit.

So what is our vision? Our vision is having the ability to have these streamless handoffs from software to software, from discipline to discipline, and from project team member to project team member, so we don't need to have a break in between. So we have this vision where we can start to sketch in Rhino, begin to add more Rhino objects into our projects, and then continue on through Revit production without the need for multiple files or multiple work streams that are running parallel and becoming divergent from each other.

So we see that this is our ideal flow between the tools that we use. So I'd like to hand over to Antonio now, and he'll run through some of the use cases we have.

ANTONIO CANERO: So thank you, David. I will start with the overview and how we started to look into the different use cases. And this is a "as is" and "to be" process. Initially, the "as is," is about modeling Revit objects based on Rhino models. And the "to be" or the desire is to automate this generation of native elements in Revit.

The "as is" or the way it's working at the moment or in the past was to manual remodel design changes, and the desire is to better flow between Revit and Rhino. "As is," is divergent models, and the "to be" is more consistent models where we can really rely on the data. Before, there was a lot of waste of time, and the goal is to save time to be used on human-centric processes so that designers really use their time in what's more important and what they can use the skills in a more relevant way. And the "as is," is double work, and the goal is better results and better projects.

And where we started? So we started looking into and system families. Initially, we looked into the walls, floors, and ceilings categories. And the reason for that is because we thought that those elements are the more commonly used elements, and we wanted to trigger those that they are going to provide the highest time savings. And after we start to look into more complex families, that they will also provide a greater value, such as curtain panels. Curtain panels, they are well known for their flexibility, and we thought that was a great use case for this process and project.

I'm going to start looking into the first use case, which are walls. Revit families are typically designed and optimized for repetition. Like any other basic element in a building model, walls are instances or predefined system family types, as we know them in Revit. Walls are commonly used in any Revit project because they are crucial construction elements, both for architecture and structural disciplines. And this is the reason why we wanted to focus in walls coming from Rhino geometry, because the time savings will be significant.

In the ideal world, a wall in Rhino should be modeled following a number of steps. We or the designer will normally look and start from a floor. The perimeter of the floor, if we are looking at a perimeter wall, it will define an offset. We will create surface out of them, and then we will create poly surfaces by extruding the surface.

However, with the fast pace of design, we often encounter various modeling techniques and some scenarios that may present some challenges. And the challenges that we are normally facing are about dealing with location lines, considering the geometry types as solids or poly surfaces. Not every geometry is likely to look the same when modeling a wall. Ensuring that elements within a block are treated as wall elements and we don't have any other category within the block. Managing walls with multiple thickness in the project environment that can face a challenge for this use case, and then dealing with walls that don't have parallel faces.

And the approach that we took in this use case was to first gather solids from Rhino, filter the surfaces, and then determine the base level out of the surfaces that we have filtered. Then we will select the largest surface. Normally, in the wall definition, we may have a larger surface than the other because of the existence of a door, for example.

Then we will extract the edges of the largest surface. We will create center lines, and then we will clean them up. And from the center line, we will create and generate the walls. This is using normally a method that is defined by the curve of the wall.

And this is the high-level overview of this process that we have just defined. So we can see how we move from solid to surfaces and then to the curve that will define the wall in Revit. But we didn't end up in this approach by casualty. We have really tried to identify which are the typical scenarios that we will encounter when model Rhino geometry, and there are three critical scenarios here.

The first one is Rhino poly surfaces that in plan view represent a surface with a hole. The second one is solids. So in plan view, they will look like a surface without a hole inside. And then the third one will be linear walls.

So looking into the first scenario, as we said, this is really commonly used when modeling external facade walls or perimeter walls. And this in construction is really often used because at the end of the day, walls are treated to enclose areas. This use case was addressed by selecting the longest curve representing the external face of the wall and then using it to create the rectangular profile that after we will use to create the wall. This use case was easy to manage and it was the base of our design script.

The second use case is how often or not that often goals are defined as a solid. This we consider that shouldn't be a common way of representing walls because it does not accurately reflect the geometry of how the wall is going to be built. And because of that, we decided to exclude that from the use case.

And finally, we have the scenario number 3 that make us think a little bit further. So we really often have linear walls, and those are normally part of partitions. And we also have T-shaped walls, which are intersecting walls. We wanted to focus that regardless of the scenario we encounter, the wall creation method will work consistently. So basically, from this scenario is where we actually define the approach that we described before, where we will, no matter which is the wall shape, we will gather the center lines, and from there we will define the curve for the wall creation.

I'm going to transition into curtain panels. This is the second category that we have chosen. Curtain panels are widely used for building facade and interior assemblies. A curtain wall, just for the sake of the definition, is a wall that is attached to the building structure that does not support any structural loads from floor or roofs. Typically are thin, aluminum frame metal panels, or with thin stone infills. However, this definition has expanded because, as we all know, curtain walls have a lot of flexibility, and they allowed users to actually be imaginative and go beyond what they were created for.

And of course, there are some challenges around curtain wall panels creation. In the ideal world, we will start from a floor, and then we will define the curtain wall line that then will set the curtain system. And then we will define the grids that after will define the structure where the panels needs to be placed. However, again, there are many ways of modeling, and there are many challenges to consider when transitioning geometry from Rhino to Revit.

And some of those are that panels needs to be blocks in Rhino for this use case. They are meant to be mapped as family types, so each block in Rhino will transition into a family type in Revit. Extracting layer data from within blocks suppose a problem at the beginning.

Identifying the curve that is going to define the curtain system, it was also a challenge for us at the beginning. Defining the grids was quite challenging as well. Also, creating nonlinear elements for curtain panel creation was also a big challenge.

But we end up defining an approach to create both curtain panels and curtain system. In this case, we are going to focus in the panels themselves. And basically, what we did was to [? fledge ?] the solids from Rhino using the Data Exchange nodes within Dynamo. We find the layers from within the blocks, and we associated the solids to the layers. We join all the solids that correspond to the same layer, and then we calculate the center of the geometry in the dictionary, where we were gathering solids and layers, and define the origin. And based on that, we often needed to rotate or translate the geometry to be correctly placed in the family.

We load the template curtain panel, we create the family object, we create freeform elements in the family, and then we save it in the current document or in the document where the system wall instance will be placed. And this is a high-level overview of the steps that we just defined, how we move from solids to loading a family template, family instance, and then regenerating the geometry. And just as a note, we will assign the correct materials to each of the solids within the family.

And again, we want to just to map some of the scenarios that we have commonly seen. And we have four key scenarios. The first one is linear panels, where the panel will likely be a straight line between the start and endpoint. Then we have the scenario number 2, which are corner panels. Basically, as the diagram shows, it's a 90-degree angle that defines the lines of the panel.

We can find also angle panels where the panel has an angle that is greater or lower than 90 degrees. And finally, we have curved panels. Of course, we can find many more instances and use cases, but we focus on those.

Now we are going to transition into the process, and we are going to be looking on how we move or exchange the data from the source app into the target app. This use case is basically about exchanging Rhino data to Revit data and is designed to allow users to start a design in Rhino because it has great capabilities and end up in Revit because it has really good capabilities in terms of collaboration, coordination, and for delivery. In this use case, the source app is Rhino, and we move into Revit by creating an exchange from the Rhino user interface. And that will be the producer connector.

After creating the exchange, the exchange will be basically a store in a cloud hosting provider. And in this case, it's Autodesk Construction Cloud that will serve as the core cloud environment. Moving to the next step, we will have a consumer connector. In this case, it's Dynamo.

In Dynamo user interface, by using some nodes, we can [? fledge ?] the data from the Data Exchange that is hosted in ACC. And that's allowed us to create the native geometry in Dynamo and then transition into Revit. We will create the native elements in Rhino, as we mentioned, and the target app will be Revit, where the native geometry will be created.

We are going to be looking at the processes for the two use cases. So first, we are going to be looking into the walls. And we all know that Rhino has great capabilities in terms of versatile modeling, precision, but also great speed and flexibility. And this is why normally Rhino users will be start the design process-- normally, users will start the design process in Rhino.

However, it is important to note that this flexibility and speed come to a cost, often in lack of potential standards and standardized workflows, and that's why we wanted to ensure that there is going to be a consistency by defining a set of templates for layer names where every project will use the same layer naming convention and structure. But also we wanted to make sure that the modeling practices in terms of Rhino elements are consistent. For example, the goal was that all the walls will be created as poly surfaces in every single project, and that will be the consideration when we are fetching data from Dynamo.

In this case, we see how rather than just exchanging the whole geometry, the user can actually select which elements do we want to exchange. And in this use case, we are exchanging the core walls of these projects. The next step will be so once the geometry has been identified in Rhino, we will use the Producer Connector to create the Data Exchange, and this Data Exchange will be stored in the cloud.

There are many benefits using Data Exchange beyond the exchange itself. Some of them are presented because we are using Autodesk Construction Cloud in the core. So Rhino users, Revit users, but also design managers or users or part of the project team members that they are not actively working on the authoring softwares can actually go into Autodesk Construction Cloud and easily interrogate the model. In this case, for example, we are showcasing how the user can create sections out of the Rhino geometry or assign measurements to understand if the geometry is as accurate as it needs. Also, that allows Revit users to review the data that is going to be exchanged and imported into Revit beforehand to decrease the waste of time.

Once the Revit user has reviewed the geometry, then the goal will be to use Dynamo Player. Dynamo is great because of the parametric design, data-driven workflows, and enhanced collaboration. In this case, the user doesn't really need to go into the code to create the native geometry. It will just need to run Dynamo Player and define which is the maximum wall thickness, the maximum wall height, the maximum wall length, the family type that we want to use. In a few seconds, all the native geometries will be created.

But we wanted also to just show you what's happening behind the scenes. This is the code where basically the user will gather the data, will get the Data Exchange, will process the geometry, and will generate the walls. Those are the key steps in Dynamo.

And finally, the native geometry is created. This allowed users to directly modify the walls elements in Revit and progress with the design with native elements, which often can be game changers for the speed and accuracy of the project. The next category is curtain walls, and then we are going to be running through the steps of curtain walls. We are going to be focusing in panels, but I'm going to provide an overview of the curtain wall system as well. In the source app, we will have the curtain walls with the panels in Rhino.

There are some considerations that needs to be taken into account. In order to define the line that is going to define the curve for the curtain wall creation, we created a line from within the block instance, and then in Dynamo we concatenate those lines. And from there, we will have the curve that will define the wall.

Once the geometry is selected, that can be selected by either by everything in view, by layer, or by section, we will create the exchange. In ACC, the user will be able to interrogate the model. So we can actually see with a greater level of detail the geometry in the cloud and also the data associated to the geometry. We can take measures, understand the section elements.

And by leveraging Dynamo, we will also define the parameters needed. Finally, we will create the geometry. Before that, I just wanted to show you, which is the data in the script behind the scenes. Basically, we are, again, copying across the URL, populating the data.

As we define in the approach for curtain wall creation, we are gathering the solids, gathered in creating a dictionary with the solids and the layer names, adding the family type, family template, and loading the family into the project. And we will see more details during the demo. And finally, we can see how the native curtain panels are created in the project environment, providing, I think, a really great value to the speed, accuracy, and performance of a project.

Now we are going to transition into the demo where we are going to be showcasing the demo for the wall creation and the curtain panel creation. So we are going to be displaying a video where we showcase how we are selecting Rhino geometry. In this case, we are going to be selecting walls by the block name. So we are selecting the blocks that we are going to be exchanging.

This is the geometry that we want to exchange in this case. There are many ways of selecting geometry in these things, but one of them is by selection, other is layer, and the other is everything in view. We are going to define the name of the exchange, and this will allow us to identify the exchange in Autodesk Construction Cloud. We select [? by ?] selection and we create the exchange.

This exchange will be loaded into Autodesk Construction Cloud in a few seconds and will allow the user to actually interrogate the model there. And as we have mentioned before, anyone can do it. Now we will copy the URL. This will serve us later on to paste the URL in Dynamo.

And in the middle, of course, we have Autodesk Construction Cloud and that's going to look like. We can access to the exchange. And we can manipulate the view and interrogate the elements within. And in the Revit environment, we will select Dynamo Player, really easy for every user to use it. Then we will copy the URL, define all the parameters that are needed around the wall properties, but also about the wall type, and then we will run it.

And again, really quickly, we will have all the geometry populated in Revit to [? share ?] the Revit IDs. And if we open a 3D view, we will be able to access to the native walls, which is a great success for a lot of projects.

And then we are going to showcase the curtain panel creation. And this is the video. So basically, in the video, this is already the exchange created in Autodesk Construction Cloud out of the Rhino geometry.

And basically, we are going to copy in the URL, and in Dynamo we will paste the URL. We will define the family type, the family name, and we will run the script. And again, in a few seconds, something that is normally really time consuming, which is the creation of curtain panels, it will be loaded with all the materials assigned to the relevant geometry as it was defined in Rhino.

And we can see that the level of detail is as great as it was in Rhino, and all the materiality is properly defined. And if we select the element, we can see that it's a curtain panel with the correct name. And with that, I hand over back to David.

DAVID A. FINK: Thanks, Antonio. It was really great to see the workflows in process. So I think we can really save a lot of time from this. So I think this can also really give a lot of value to us as designers, that it just increases our efficiency, reduces this manual rework that we spend so much time on, and also reduces the amount of errors that we see in our projects.

I think through that, we can also see that it increases accuracy and it ensures that a little bit more precise transfer of the design intent across the platforms from our designers to our production teams. And then it also increases the collaboration because we can have the designers and the project managers and everybody involved in the project being able to access and visualize the data in the projects. So it was really a lot of benefits that we can see.

So it also requires a little bit of some best practices. One thing you need to be is you need to be a little bit more organized than you have been in the past. Most likely, your Rhino models need to be a little bit more clean, using the right layer strategy, and just being a little bit more accurate about how you model in these tools.

It also requires a little bit more strategy. How do we exchange? When do we exchange? How much do we exchange? And just also that the planning of how the project develops and where you see the project going in the future.

So it's not just something you can click and do it whenever you want. You still need to have some kind of strategy, and also finding the optimal points in time of when you can make these exchanges. Because I think that when you take all of this into consideration, it just is common sense to be more organized, more accurate, having the strategy and planning in place, and working on your timing, because we're all trying to optimize our workflows, and these are all the pieces that we need to be a little bit more optimal in the way that we work.

So there's just a few summaries and takeaways I'd like to go through is one thing you need to be aware of is these Data Exchanges are still under development. I mean, you can see that we've had to develop some extra workflows to get the results that we want, but we're hopeful in the future that this will be built into the Data Exchanges so you can go straight from Rhino to Revit without having to do a little bit of Dynamo on the side. But I think there's still a little ways to go.

And there's also more Data Exchange nodes that are coming out all the time. So we still need these extra processes in order to convert this data between the platforms. It's just not a one-stop shop, but I think it's definitely headed in that direction.

So we can see that rather than remodeling, you can move geometry back and forth, and we can take more advantage of the limited resources we have on our projects. We can see that our budgets are tighter and tighter and it's more competitive in the industry, and this is something that is really a great tool in our toolbox. So I think we've moved away from that single platform idea that everything will be done in Revit or in a single platform. But we can see that we need multiple platforms that work together to get the results that we want.

So in that way, the Data Exchange is really important to get this workflow to work, to be achievable. And we really see a future in these cloud-centric workflows between platforms. We see at Henning Larsen and Ramboll that cloud is the future and we're headed in that direction. I don't think we'll be turning back any time soon.

So with that, I'd like to conclude today's presentation. And if you have any questions or comments, feel free to reach out to us. We'll definitely contact you. And look for us around the event in San Diego. So with that, say thanks for attending, and we'll see you soon.