Get into It! Using Large Model Viewer, Virtual Reality, and Visualization to Bridge IT and Design.

ROBERT ANGUS: Well, good afternoon. Thank you for coming. I hope you're having a good AU so far. My name is Robert Angus. I'm a Solution Architect. I've been with Autodesk for about 14 years now, and I work both in product from-- everything from inventor to the newest fusion product. And for the last three years I've been working in Autodesk consulting.

To begin with, I'd like to get a feel for what everyone's experience level is here with Forge Viewer. This class is mainly geared around how you can use Forge to visualize information within your enterprise. How many here have developed an application using Forge Viewer? Really, one. How many here have done any type of software development before?

AUDIENCE: [INAUDIBLE]

ROBERT ANGUS: What's that?

AUDIENCE: [INAUDIBLE] This is supposed to be Forge Viewer, virtual reality?

ROBERT ANGUS: Yeah, so it's using Forge Viewer to-- here, we'll go to the next slide. Page down. So it's using Forge Viewer to visualize data, and also how you can use virtual reality in that as well. So right now, you'll find as we get in this class that the VR capabilities of Forge Viewer are very much in their infancy but they're progressing very rapidly. And we'll talk about that at the end of the class.

How many are mostly here because they're interested in VR development? A lot of you. OK. Let's start a little bit about talking about the learning objectives. So in the class, we talked about-- our desire here is how do we combine data with engineering models to present a compelling story to our end user. And how the large model viewer, in particular, can be used and leveraged to facilitate that.

We'll look about our VR and AR options and see how-- what the large model viewer, which is really called the Forge Viewer now. They changed the name since I initially introduced the class. The Forge Viewer can support-- and talk about some of the impact it's going to have in the future, and how we can move forward on that.

So I want to start off a little bit talking about what the Forge Viewer is, and once you understand that, then we can better understand how VR can fit into that. Forge Viewer is a WebGL-based, JavaScript library. You embed it into your web application.

It's used in conjunction with the Forge Derivative services to produce your engineering documents into a streamable format that can be downloaded to your web application. All of the Forge Viewer runs locally on your browser. There's no web services, no processing on the web that happens at all, when you're viewing an application. It's all done locally.

One of the great things about the viewer, is because it's web based it runs everywhere, most everywhere. It runs on any browser that supports WebGL. It runs best on modern browsers that support the higher JavaScript syntaxes, with more modern JavaScript syntaxes.

So in saying that, what I'm saying is Internet Explorer is a much less desirable option than Microsoft Edge. Edge runs better. It's easier to program against and probably the best support is using Chrome. So because it's browser based we can run it on most platforms, most OS'. I've listed the major ones. It should also be able to run on Linux.

One of the-- the thing that I think is pretty remarkable about it is how performant the large model viewer is with large models or the Forge Viewer, I should say. The modules load and compile very fast inside your application. It scales to very large models. And one of the reasons it can do this is because it's called a progressive renderer.

And the fact that it uses a progressive rendering format is also one of the biggest problems it has in dealing with virtual reality. And we'll talk about that in a little bit. So its ability to scale also makes it not an ideal solution for virtual reality. Also, the quality of the rendering inside the Forge Viewer is improving rapidly. If you look at the rendering quality six months ago compared to where we are now, it's pretty amazing to see the progress we've made.

As I said before, it's an embeddable HTML component. And that means it's, for those who know the HTML development, it's embedded as a component using a Shadow DOM, meaning that you don't have to worry about stomping on any of its name spaces. It's very transparent to use as a developer, you can just consume its functionality.

Because it's built upon the web platform it becomes a very collaborative environment. It's easy to establish and share sessions. It's easy to form chat or communication. Its' extensible nature, it has a built-in plug-in framework makes it easy to do things like annotate the model, and provide ways of using it as a mechanism to talk about design choices, design optimizations, or procedural information.

Forge supports both 2D and 3D formats. Both vector and raster. Well that means you can use Forge to view your PDF documents, as well as your AutoCAD drawings, as well as your Revit models, as well as your 3DMax models. It supports an amazing number of formats and that's continuing to Progress and involve. So when I say cool, what I really mean is it's useful or powerful.

Now in order to get an asset into the Forge Viewer, you have to run it through a data pipeline inside the Forge services. And we'll talk a little bit more-- we'll talk in a little more depth of how you do that so that you're familiar with that process, because the ability to create an application that consumes Forge has some very specific limitations on what data you can access and how you can access that data.

So again, summary of what we talked to before, its strengths are the fact that it's platform agnostic. It's browser based. It's [? pluggable ?] into your application. Has, I think, a relatively easy to use API that can be extended through its plugin framework. And it supports most any file format, and it does so with great performance and reasonably good quality.

So in order to do-- there's a few steps you need to do in order to use Forge to do any type of application. The first of these, is you have to register your application with Autodesk. And through that process you go onto developer.autodesk.com. You request a new application. You name your app.

And then it will give you , what used to be called the consumer secret and a consumer key, they now call it a client key and a client secret, but it's in essence, it gives your app the ability to identify itself with the Forge Services that you will need in order to get the data into a viewable format. So this is the first step that you need to do.

Now one of the things that I think it's important that you realize, is that when you're going to view Forge data, that data becomes your applications data. In other words, when you get a consumer or a client secret and a client key, what Autodesk Forge Services Is doing, is they're giving you access to your own private sandbox for your data.

And so if you have data that's currently living in BIM 360 Docs or in A360, your application cannot access that data, because as a security measure Autodesk is sandboxing one application from another. So the process you need to use in order to consume that data, is you have to download that file, and put it into your storage, your application sandbox. And then from there then you can view it in your service.

So that's a pretty big limitation. Now they are working on some APIs that will allow your application to be able to act as a third party handler for the user's data. So in other words, your application will be able to work in proxy for your user to request that data. Those APIs are not developed yet. And so for now, you have to copy the data into your application in order to use it in your application.

So the process of doing that data copy is as follows. You're going to use the REST service API, and you're going to create a bucket. A bucket is analogise to a folder that lives inside of Autodesk's Forge's file storage system. That file storage system is called OSS.

From there, you're going to upload the file. So if the files already in Forge, in say Autodesk 360, you need to download it. Then you need to re-upload it in the Forge using your consumer key and secret, and put it into your bucket. After it's in your bucket, you can request the derivative service, which is the translation service that lives in the cloud, to translate that file into a viewable format

We'll talk a little bit more about what the viewable format is. And then the next step after you get the file so that it can be consumed, you need to create an instance of the Forge Viewer. It's super easy to do. If you look here, all you have to do is add a style sheet reference. You have to add a reference to the viewer 3D.min.

And then you need to create a place in your XML where that will live, and you do that by defining a div, which is a section in an HTML document. Once you define that div, you go through and you initialize your viewer, and then you tell it to load the model that you're interested in. So it's actually pretty remarkably easy to consume, as far as the component APIs concerned. But these are the foundational steps to being able to use LMV for a custom application to view your information.

So it just shows you-- Autodeskdeveloper.net that's or developer.Autodesk.net, this is where you register your application. This is where any documentation has, and this is where there are quite a few examples that you can reference. So one of the things that's been really interesting to me in consulting is we have gone and we've talked with all sorts of customers. And as we talked to them about their business problems, we have found that there is a remarkable resonance across a variety of different customer bases on how the ability to combine data with visualization can provide significant answers to their business problems.

It's been amazing how well that's been received by everyone we've shown it to, from the CXO level down to the manager level. It's been amazingly well received. It seems like the timing for this technology is really ripe.

So the data that we're talking about viewing can come from a variety of sources. In the case of a BIM model, or perhaps a large assembly and [? inventor. ?] That data comes from the model itself.

From the manufacturing products, such as Inventor or Forge, you have part numbers, materials, mass properties. For plant data, for visualizing large plants, you have the asset tag numbers, you've got the pipe connection codes, you've got the line numbers. All that information exists within your model.

In a BIM model, then the idea is to have extra information that describes the functionality and behavior and systems in your building through the BIM data. And that's where a lot of people are coming and finding interest in this is because of the fact that they're already trying to add metadata to their model through BIM. And because the models there, they want to find ways to consume it.

All right. Now, as part of the translation process, when you take a file and use derivative services to convert it into a viewable format, the derivative services does a few different things. In fact, I skipped down and we'll get into that in a little greater detail. It creates-- it will create thumbnails of the different views in your model. And by different views, I mean you'll have 2D representations you have 3D representations.

It will create an SVG, which is your 3D model, in a streamable format file for your model. And for certain file types, you'll have different views in your model and it will create a separate SVG for each of those views. It will create an F2D which is a 2D viewable format, for each of your sheets within your model.

And then it will take all the properties in your model and it will put them into a SQLite database, and that database has an SDB extension. It then takes all of these files, these different formats, and it stores them inside the Forge OSS file service. And we call that the bubble. If you look at the LMV, the bubble is the collection of all these artifacts that are generated through the translation process. And when you want to view an asset in LMV, you need to ask the bubble to give you the information, so you know a specific asset and you tell it to load that's specific F2D instance, or you tell it to load that specific SVG instance.

I want to show [? you ?] a little bit about LMV, and how it can be used with the property data to view. By the property data I mean, the data is extracted and put into the local database. And how that can be used within a simple application.

So this is a Revit model. And in the Rivet model, you can see all the different views we've created. In this case, we have all the sheets. So we can look at the different-- any sheets that's been found is--

AUDIENCE: We can't see.

ROBERT ANGUS: Oh, OK. Thank you. Where is it? Hold on. I'm going to change my presentation so we share the screen. So in this file, in our bubble, then we have all these different sheets and we have our 3-D model. One of the things that we can do then, is we can query the system based on any of that data.

So if I want to say something like, I want to see roof. It queries the SQL database, and finds all of the object IDs that have anything related to roof. And so there are some interesting things here. For example, you look at this and you'll say, well, how come these items are selected when I said roof? You can look at the properties in the system, and you see that it's because the top level of that is associated with a roof.

So all we're doing in this case, is we're using the API to ask it to search all of the properties to find anything that references roof. And then we're telling it to highlight those in the model. So if we go to [INAUDIBLE] Oops. Sorry. So if we go to another example, we can see how this can be used in a little more-- in a richer way.

And what I want to show here are a couple of things. First of all, I've learned two instances of the viewer. One instance that's this pointing to a 3D model and one that's pointing to a 2D model.

This is from a Revit file. So in a Revit file, all of the entities in the model are given, when they're translated, they're given an object ID. And whether that object is visible in 2D or the 3-D, they're all referencing the same ID.

So I can tell it to select an object by its ID. For example, I can tell it to select this wall, and it knows that that's the same object in 2-D as it is in 3D. So I can then take that one step further and I can say well, let me extract all the properties in the database. And let me try to gain some-- try to establish some context around that.

So in this case, I've taken all of the different categories of items or this applications taken all the different categories that are in our application, and we can use that to filter and view the data. So we can say, well, show me the pipes, show me the fittings, show me the curtain walls.

This has been used by some of our customers to do things, such as estimating. They can view the different options during the proposal stage of a project and they can present these to the customers. I believe Jay Dunn presented this last year. How they use this to allow their client to make decisions by isolating the information that they're trying to get them to make decisions about.

The other thing that we can do is we can use it, the rendering capabilities Invent 360 Docs to highlight information and to make it accessible. So in this case, I'm looking for the attribute level, I'm aggregating those into groups, and then I'm applying different styles to each item, each level item.

Any questions about anything we've talked about so far?

AUDIENCE: So what's it look like when [INAUDIBLE] the web page side of HTML, the JavaScript and all that, is this HTML to capture all that data [INAUDIBLE].

ROBERT ANGUS: I'm sorry. What does the HTML-- so all of the data here is in-- for this application, all the data is local in the HTML page, because we're taking the information that was in the bubble, we're pulling it into the browser, and then we're querying it. So--

AUDIENCE: [INAUDIBLE]

ROBERT ANGUS: Yeah. So there's an established API for all these calls. For example, what we're doing here, there is an API called set color. And you pass in the entity, the ID, and the red, blue, green color definition, and pass, and the object ID, and we'll set the color.

So it's a very defined well bounded API. In the case of where we are hiding objects, there is an API where you pass a collection of objects and you say, isolate. And it will only show those objects, and it will hide all the others.

And you can do the same thing with selection. You can do the same thing for making things visible.

AUDIENCE: And [INAUDIBLE]

ROBERT ANGUS: So this code here, I can give you the URL. You can access this code. It's on GitHub, and you can download it and look at it.

AUDIENCE: OK.

ROBERT ANGUS: Yes.

AUDIENCE: I'm just curious about the data, you were talking about it's all local. Does anything go out? Because we have security requirements that we really can't [INAUDIBLE].

ROBERT ANGUS: Yeah. So as part of the translation process that I talked about, when you're using the derivative services, you take the file, it is then copied to our server and translated. And then it lives on our server. Now, there are certain cases where they're allowing customers to translate it internally, so that rather than being transferred in our server, it can be translated within your firewall.

AUDIENCE: So there is potential for that in the future?

ROBERT ANGUS: Yes. And the other questions? OK. So this is all data local to the model. So I want to do a little bit of reset here and talk about what I think is significant and what we're able to do that we weren't able to do before.

The ability to show-- that's a big model and loaded in a few seconds. It's actually pretty amazing. If you would load that in Revit, you're probably talking about downloading an 80 megabyte file that's going to take a long time to load. And that's a small Revit file.

And the things that have enabled this to happen are pretty remarkable. A few years ago-- 10 years ago when I joined Autodesk, we would have had to have a workstation to do this. We would have never been able to do this on the web, because of the bandwidth requirements of that 80 megabytes.

In addition, one of the things that is really enabling about the Forge Viewer is you're no longer bound to a software license, as far as being able to publish this and consume it. This has an amazing effect with our clients. For example, we have a client who does clash detection on the buildings.

And it used to be-- the clash workflow is very cumbersome. You would pull in your Revit model, you'd have to translate it to Navisworks. You go to Navisworks and you run a clash. Well, the Navisworks is very noisy in its clash results.

You have to define what is a clash and what isn't. And you have to define the fact that 30 or even 1,000 different clashes might actually represent the same clash. So they would take their Navisworks model, they'd pull it into AutoCAD and create spheres around their clashes. And that allowed them to visualize the spheres.

And then they would have to have a meeting where everyone could come and look at their AutoCAD model. And have a triage session where they're managing their clashes, and they're deciding who to blame, in essence, and who's responsible for the fix, or which group of people are responsible for the fix.

And all this was bound to license software that involved multiple people doing translations, and other steps. And now they're changing their business by saying, you know what, we can run this in a background process. We can pull it in the LMV and now we can remotely pull our collaborators together.

We can view the clashes that's now integrated with a system that manages who's responsible for it. So they manage the resolution of it, all on the same system. They're able to view, interact, and show that data, make decisions, and then track it through the clash resolution process.

It's pretty amazing how this has enabled them to combine a whole bunch of separate workflows into a single unified experience for their users. And they attribute this to significantly increasing their competitiveness in the marketplace.

So the fact that you're able to use software that's not bound to the OS. It's not-- another thing about AutoCAD, or Navisworks, or Revit, they're not to be trifled with. You can't give a copy of Navisworks to HVAC contractor and expect him to just know how to use it, and view it, things in it.

On the other hand, everyone knows how to use a web browser. And you can create the interface that makes it very easy for them to interact with that data. In fact, they're the ones that I first they've actually demonstrated this in AU, but they're using VR to view those clashes. So they can create a collaborative session, where everyone's looking at the clash, but yet while they bring you to the clash, you're free in VR to look all around and examine that clash.

So now you have 10 collaborators who are each able to independently assess the impact of that clash, and come to a decision on how to resolve it. Yes.

AUDIENCE: Is there [INAUDIBLE] cost to [INAUDIBLE]?

ROBERT ANGUS: There is no software licensing cost, there are services costs, so you pay for usage. But the Forge Viewer is not licensed. The translation, which is the CPU time in the storage for that file, is what is licensed, but it's relatively trivial. I mean, the talk is for a small model, it'll cost about $0.20. For a large very complex model around $1. So but once it's translated, then everyone has access to that without cost.

AUDIENCE: So one time?

ROBERT ANGUS: Yeah and you're just paying for the processing time. Yes.

AUDIENCE: The processing time [INAUDIBLE] consumes a certain database technically [INAUDIBLE] for me if I use this for an [INAUDIBLE] multiple users, or are we talking--

ROBERT ANGUS: Well, the translation only happens once. Once is translated and you have the SVG, and the SDB, and the F2D files, there's just in the cloud. You never have to translate again. You're just downloading them. So you're not paying to bring the bits across the wire, you're paying for the compute time to do the translation. Yes. In an update cycle, you would pay for each processing that you did?

ROBERT ANGUS: Yes.

AUDIENCE: And what I was wondering is, you talked about a push up [INAUDIBLE] get a key [INAUDIBLE] initially?

ROBERT ANGUS: So yes. So right now, say your using BIM 360 Docs, and you're using that for the process of managing the change on that document. You would go through a change management process and you eventually approve that change. Once that's approved, then you would release in essence, that documentation as part of that process, then you'd retranslate that file to your application.

Now, that's only if-- so the scenario that I was talking about, is if you have a third party application, and that third party application is doing a whole bunch of work for a whole bunch of different users. If you want to have each user authenticate as the Autodesk user, then they can directly access the file that's in BIM 360 Docs.

So you're just building functionality around the Autodesk service, but you have to have a BIM 360 doc subscription, in that case, or an Autodesk A360 team subscription. So you're still paying for those services, but you can have them log in directly, rather than your service acting in their behalf. If you're trying to write your own internal application that's independent of BIM 360 Docs, then you have to do the move the data back and forth. I hope that's clear. If they are logged in as the user, then they can access any of the server the user is subscribe-- services that the user has subscribed to.

AUDIENCE: I was more just thing about the generic public HTML that needs to be updated. Once you generate your key, if you're updating the [? bubble. ?]

ROBERT ANGUS: Yes.

AUDIENCE: You wouldn't need to regenerate your key, it would--

ROBERT ANGUS: No. The key is a one time thing. So you get the key, you're registering the application which, as I mentioned before, that does is it authorizes your application to have storage on the OSS service.

So and typically, I think for most companies, if you want to have something like this, it's more it's facing external to the engineering organization and you're trying to add value somewhere else in the supply chain or in the downstream processes. And so it makes sense to have it more of a third party application that's acting on behalf of the user.

Now that being said, I anticipate that sometime in the near future, we'll have the API's that will allow your application to act for and behalf of the other user, so you could use their storage and access that for them. The first product that will probably support that will be BIM 360 Docs.

And they will provide the API's that will allow you to do things, such as, ask the system, give me the list of files this person has. Because you're not that person. It's a tricky thing because you're giving super powers to your application to access other people's data. And so that's why they haven't got it yet. They haven't decided the rules that have come into play to allow a third party application access to other people's data. So there will be some definite rules and security measures put in place and it's going to take some time to work all those out.

AUDIENCE: [INAUDIBLE]

ROBERT ANGUS: No. The Forge Viewer is not the viewer used in A360 Glue, and it is the viewer used in A360. Now they're in the process-- my understanding is they're in the process of moving the Glue viewer to the Forge Viewer. It just takes time. So--

AUDIENCE: So did you just say that the Forge Viewer is used-- like if I go to A360 viewer right now, is it using the Forge Viewer.

ROBERT ANGUS: Yes. So again, the Forge Viewer [? is skinnable. ?] The UI, the little toolbar buttons, those are all customizable. And so every product then creates the look and feel that they want to have. And in addition, other products are then creating wrappers around this viewer.

The BIM 360 Docs, if you want to use that for example, or is going to create what they call matrix component, which takes all the services that their viewer has and makes them as this as a higher level component. Because they've added things to the viewer, such as, redlining capabilities offline capabilities and other things. So you can choose to use that component or you can choose to use the Forge component. The caveat there is that if you use the BIM 360 component, you have to have a BIM 360 subscription or a BIM 360 doc's subscription. Yes.

AUDIENCE: [INAUDIBLE]

ROBERT ANGUS: Yeah, well, we'll talk a little bit about that. Let's move on and we'll kind of get-- so we're talking about viewing data internal to the model here. The power comes when you start expanding that beyond the model. You have all this enterprise data from all these different systems.

So let's start talking about that. And that's where I think the power of having something like an LMV really comes into play, because you already have access to the model properties within Revit. It's nothing revolutionary there.

Where you start to see the value, is when you have a work [INAUDIBLE] say an inspection process, say an estimating process, and previously they weren't able to see what they're inspecting. They weren't able to assess. In a plant scenario, you may say inspect this pump, but you don't know, do you have direct access to that pump? Is it going to require scaffolding? Do I have to move other pieces of equipment to get to it? There was no way to triage and assess your work plan because you had no way of knowing it.

In a large refinery, there's thousands of valves, and no one knows them offhand. And that's actually one of the big expenses a lot of our oil and gas customers have. There is a pump station in Alaska. It takes a helicopter to get there. And they have to send someone up there to assess the situation so that they can plan how they're going to do the maintenance of it. That's an extremely expensive operation. If they could visualize that, that would have a huge benefit downstream and upstream for their processes.

OK. One thing I wanted to point is for those who have been with Autodesk for a while, you'll remember the churn of viewers. I mean, we have never had a good viewing story and this is the first time I think we've come up with something that is a great service. All right.

One of the things that we're seeing is people's expectations are different than they were before. Especially the millennials that are coming up. They're used to having data, , all the time accessible. They're used to having apps that perform specific functions. They're very niche oriented, rather than these monolithic applications. And so we're seeing more of a desire to have to find solutions to various workflows.

So again, I mentioned before about how combining visual graphics with data has absolutely resonated with people. Everyone who sees-- whenever we show this to someone, they start coming up with ideas on how they could use this in their own organization.

So to me, it's is a very compelling thing. There are certain things that have really enabled this that didn't exist in the past. One of them is the open standards that didn't exist before. The HTTP protocol, WebGL, WebVR. All these standards-- WebVR isn't an official standard yet, but it is coming along. It's in its final stages.

But these standards allow us now to program against a standard set of rules that can be then run against anywhere. And because of this, standards based things, data vendors and information providers have been forced to comply to those standards, and they've done things like provided REST API's to access their data. And so now you have a ubiquitous way of accessing their data, that you didn't have previously. Used to be you had to have an Oracle Driver or you have to have a SQL Server driver. Now they all have REST endpoints that allow you to access that data.

The thing that's even more amazing to me is the amazing amount of community and synergy that is in the web world around tool sets, and frameworks, and helping people come up with solutions. And that's exactly what we're trying to do with our solutions. We're trying to create a standard set of APIs and tools that are accessible to anyone that you can use as components to build solutions to real problems.

Just again, the proliferation of data, I think is very significant. And there's two types of data that I think we're trying to solve. One is big data and that is we're collecting so much information. The internet of things is going to start bombarding us with sensor data. Positional data,s we're going to start being bombarded with where our assets are.

So we have massive amounts of data, and it becomes very hard to make sense out of it. And the ability to do things to visually represent that data has significant effects on what value there is to that data. Also, right now we have tremendous amount of siloing of data. I see this all the time. They might have-- internally, your company might have a custom database for managing inspection data. It might have an SAP as an ERP system. You might have a proactive maintenance system like Meridien or Maximo for your facilities management.

All this data is really separated from one another. And then you have your model data, your BIM data. And even though we have all that data, there needs to be a way of aggregating that data so that you can define the meaningful relationships that exist between them.

Again, this is more of what I just talked about. And I mentioned before about things like clash management or in manufacturing you have a design BOM versus a manufacturing BOM. In maintenance operations you generally have tons of word documents that are procedures that don't have any context to the actual equipment in the plant. So we have all this heterogeneous data and where people are seeing the need, at least from my perspective, is how do I started aggregating that and consuming it in a way that defines a solution to a specific set of problems.

And so as we talk about all these things, what's the business benefit? Is it going to save you time? Is it going to reduce rework? Is it going to facilitate decision making? Because-- I work with clients who, because of their perceived technological leadership, anticipate that as a result of AU, they will close several large contracts.

I have another client that I've worked with, their competitive advantage is the fact that they have better control over their safety procedures and how people are adhering to them. And because of that, they have a competitive advantage because it reduces legal [? waste, ?] it reduces schedule delay, and allows them to stay on task as far as the pricing goes. There's little things that people use to increase their competitiveness in the marketplace. And many of these are geared around their use of technology to solve a specific business objective.

And so there's either people who are collectively working to solve a problem, or there's people who are saying, what's the cost of doing nothing? And you have to ask yourself what's the cost of doing nothing in today's world, where there's so much data, so much information, and some people are choosing to take advantage of that and some aren't. Is your response time going to be as fast as your competitors? Are you going to be in control of your processes? Are you going to be able to maintain the tight schedules that people are having?

So I wanted to show a little bit of how we can start accessing external data through some-- and I like to show these because these are all examples-- oops. Page up. Where am I. These are all examples you can download on the web and look at. So I'm going to go ahead and pull up a manufactured product very similar to what you had before, but now we're going externally to the external system and we're saying, OK. Show me the price data for these things.

I'm going to go to my SAP procurement system, and I want to be able to look at all of the rubber components and see the price break down on those. Or I want to be able to look at the aluminum components.

AUDIENCE: Did you say SAP?

ROBERT ANGUS: Yes.

AUDIENCE: [INAUDIBLE]

ROBERT ANGUS: Yes. So this is not SAP, but we do have-- and I'll talk more about that in just a minute-- we do have customers who are actually queering against SAP data and pulling it back into their processes for estimating. In fact, last year, Jay Dunn presented on the main stage their system, and that's what their system does. Is they go through and they look at historical data, and they say this is how much of this type of thing costs. And then when you click on that in the model, they say based on a historical data, this is what we estimate it's going to cost to do this system. And if you change it to something else, this is how much we think it's going to cost you. So it's all mining data from their ERP system.

So very simple, but we're now starting to get information from external sources. Now, you're talking about [? SAP ?] data, there are some problems with getting information from actual service sources that I don't know if you're aware or not, but there are major roadblocks as if you're not aware of them. So I want to talk to those real briefly, then we'll look at some more examples of external data, and then we'll get to the VR stuff that a lot of you seem to be wanting to talk about.

One of the big caveats is the same-origin policy. And what that means is the biggest, the most prevalent security vulnerability is cross-site scripting. And what that basically means is anytime you have a HTML page, you can hit F12, and you can go and you can make changes to it. You can go in, and you can click on a button, and you can override that but it's handled. You inject your code into that web page. And what cross-site scripting is people do that automatically through vulnerabilities in your code. They go in, and they inject their code, and then they try to get your information, and send it to their server.

So in other words, this is how your application expects itself to work. You're going to have your application that's going to talk to your web services. And that's the only thing the browser allows you to do. It's called the same-origin policy, meaning if you're Autodesk.com, you can't make a call to it.

Well, the problem is now you want to call your SAP server, which has some other address and origin. And you want to call that your salesforce.com service and get some information on what's coming down the pipeline. And you have your own custom homegrown database for scheduling. All these are not the same origin and as a result, if you try to call those from a web browser, you're going to get an error saying that you can't, cross-site calls are not allowed.

So the idea is to prevent the evil cross-site scripter. They're injecting code but the browser is preventing them from calling their server. So again, here's the scenario. You have many, many different sources you want to access. There's three ways to solve this problem. One is to create your own web service that does the routing independent. The other is to use JSONP, which I don't want to talk about. And the other is CORS.

Wrap it up in a web server basically you create a server that makes all those calls and your browser just calls your web server that's in your domain. That's a very common way to do those things. So it's probably the most secure way to do it, but it requires the most amount of effort.

CORS, or Cross Origin Resource Sharing is really a protocol that allows a server and a browser to negotiate, if you will, the ability to share data from a different origin. It's a little less secure but it's way nice. And so that's typically most of your data sources, especially most of your web based data sources that allow you to access that data across site.

Another caveat is when you're building an application, this is especially true with LMV, your browser is single threaded. Everything runs through one thread of execution in your processor. And browsers also happen to make calls to resources that take a long time to get there. You're going to download that SVG file. That SVG file, that model definition streamable model file could easily be 80 megs.

That takes a long time. So what we do with a browser is we make everything nonblocking. So you call-- you make a call and you say, when you're done, I'll handle you. So you do all these non-blocking calls, but that limit your ability to handle performance.

And in a VR situation, your VR platform wants to run at at least 30 frames per second and you have one thread to do all that in. In addition to all your business logic. So we'll talk about that in a little bit.

AUDIENCE: Is the presentation going to be available later?

ROBERT ANGUS: Yeah, it will be up on the site. The other thing that's a problem when you're dealing with data from multiple sources is universal identity. Every system has its own way of identifying its entities. And how do you establish commonality? How do you--

Ron here, who works with me, he [? made a ?] terminology, he called the friendly object ID that I like and I copied. And what it's really saying is some way you've got to be able to define an ID that spans all of your systems. So that when you click on a door you know how to identify the SAP data. You know how to identify the material data sheet. You know how to identify the high definition rendering in 3D Studio Max. So you have to have a commonality of ID.

There's three different ways to do that. That I kind of use, there might be a whole lot more. I don't know. The first one is to create the friendly ID, and then the owner becomes one of your systems. Maybe SAP becomes the owner of that ID. All the maintenance to that ID happens in SAP. And every other system then has as a property, that same ID.

So in Revit then you would create a property and you would call it, if its a tag ID, say this is my tag ID. And if you change the ID in SAP, then you've got to propagate that change to all your other systems.

The other way is to create an independent hierarchy that's in essence its own database and it establishes the mapping for you. So that if I want to change it, I change it in this independent database and I can make all the adaptations in the independent table that contains all those mappings.

And the third way is very similar is you have a separate hierarchy, but you still maintain the property and each of the individual data sources. This might be a little techy, but it's a real problem when you start to deal with data from different systems, and visualizing that data from different systems.

The other thing you have to consider is how much do you really want to maintain in your Revit model or in whatever you're trying to visualize? By very nature, model files aren't great databases. Databases tend to be transactional, accessible, lightweight access to data. And it's just the opposite with a two gigabyte Revit file. In order to read the data, you've got to load two gigabytes of data, and then you've got to access it.