This idea of importing CAD-type content into game engines has been around for ages. People used Duke Nukem 3D to model building interiors, and not just for workplace deathmatch amongst the IT crew.
The core problem of CAD importing in my experience is that CAD content is not at all designed for or suitable for direct game engine importing. It requires a ton of cleaning to be optimized.
It's one thing to bring in some terrain and an appropriate overlay of imagery, but another thing to try and import actual CAD content.
As an example, I had the CAD files for a large industrial printing press at work, and thought about importing them into Valve's latest engine for VR. But the CAD files were TOO detailed. I mean literally the threads on each screw were modeled, and even the interior of the lock on a cabinet that was part of the machine. Every single component on circuit boards was modeled. It brought Hammer and the game engine to its knees with all the detail.
Another issue with CAD is that not only can things be incredibly overly complex, but the model can include details that the end user simply has no need to visualize, and hence no need for the engine to try and render. Like the interior of that generic key hole latch on the cabinet. You don't need to model the interior of a pipe let alone some complex interior valve unless there is a reason to actually see that detail. 99% of the time a cylinder will do just fine.
Then there is kinematics and animation. Want doors to open and close? Objects that are moveable by humans to be physics objects? You have to do all that yourself. Why would you do that? Well because that's part of an immersive environment that creates a truly engaging and informative experience for the design you are working with.
In the end it was easier to draw on my past experience as a level designer. I selectively imported some details that would be difficult to reproduce, then hand built other components out of simple shapes and apply textures that showed the necessary detail without actually modeling it in detail. And if I did need detail, I could remodel a specific part at a higher level of detail and take advantage of built in level of detail management for models to keep the engine happy.
Summary: nice idea, been talked about for ages, not really that easy if you actually want to build good interactive content in a game engine.
I was going to say the same thing. Seems like a lot of art focused vector programs aren't as rigorous with their polygons as a CAD program. But, I suppose it is just a matter of the level of detail the end use demands.
Tons of VFX and game content "shortcut" strategies like this require lots of cleanup however - even very good 3D photogrammetry scans are probably going to need to be manipulated (even if they look visually great) from an artistic point of view. The whole point is shortcutting and cutting time off the artists table. Lidar does not really give you anything that you can directly use out of the box but it does give you a huge leg up with perspective, sizing, etc etc.
Certainly not a silver bullet but it seems like it could be a huge time saver in certain scenarious
I think GIS content is typically more straightforward than CAD. Most of it is 2D, stuff like vector rivers and streets, or a heightmap (terrain) as a raster bitmap. You can import that kinda stuff into many games and use it as a real-world location.
Sometimes those 3D layers are built from simple extruded polygons, other times they are more detailed meshes. But AFAIK even the most complex don't typically approach CAD complexity. More like the 3D buildings you see in Google Street View or the old Microsoft Flight Simulator.
Any GPU capable of running an Unreal Engine game should be able to handle that sort of stuff.
But it's really cool to see them going this way. It's always been a dream to play a AAA game in a real-world city (kinda like Watch Dogs or GTA) but where you can import any city you want.
Being able to translate not just buildings, but hydrology, vegetation, population density, etc. all from public GIS data, and simulate a whole game from them...? That'd be really awesome.
Indeed, the ArcGIS Maps SDK is about GIS content first and foremost, not CAD content that almost always lacks geolocation. It's a bit disappointing from HN that the top comment, while containing valid information, is only remotely applicable to the tool at hand.
I hear ya, but I also think it's so cool that these tools are finally intersecting! GIS has come a long way in the last decade or so, along with drone photogrammetry, while UE and Unity continued to mature alongside GPUs. We're finally at a point where this sort of thing is not just conceivable, but even doable on a typical mid to high end gaming computer at home, using largely open tools (like QGIS, public GIS data from the city/county/state/federal agencies, the open drone photogrammetry toolkit whose name escapes me at the moment) alongside home/indie pricing for the big commercial tools (UE, Unity, Arc, ESRI APIs).
We're finally at a place where that convergence is happening. As someone who grew up a gamer, went into the natural sciences, then web dev, it used to be hard to find overlaps in these fields. Then gradually the professionals in each started realizing their shared need for geospatial data, QGIS really took off, Leaflet and Openlayers got really good, WebGL matured... Anyway blah blah blah it's a perfect storm of many technologies finally getting cheap and easy enough to use.
I can't help but to wonder why more engines, like Unity don't implement this, since it seems like a game changer in some specific scenarios. Unreal's Nanite, for example, generated a lot of attention for this exact reason (being more advanced than Godot's offering, but covering at least a few similar use cases).
Of course, ideally you'd take the models that you need and feed them through some retopo solution to generate slightly lower poly meshes (if you don't actually want to show all of the details for the screws etc.), even a Blender modifier might be useful here, even though it might give worse results than doing things by hand: https://docs.blender.org/manual/en/latest/modeling/modifiers...
But in lieu of that, LODs might just make the runtime performance passable, though the settings you'd need would be pretty niche - only showing the highest level of detail inches away from the model, or something like that. It doesn't really solve editor performance per se, though.
There are many tools that do this, but more often than not they still require significant hand tuning to look good. Best metaphor I can think of is publishing a translation of a novel. You can google translate it to get started, but you probably still need to reread the whole thing. In many cases, it's probably faster to start from scratch.
It can be automated but a deep import pipeline would really hurt iteration times. There's also a lot of tuning that goes into what is and is not the important part of a model and whether the simplification removes detail you expect to see.
This sounds like a type of problem where on import a pad can be done to remove invisible detail. Then if any changes like making a door interactive can be remembered and re-applied, or perhaps even written declaratively. “All objects with label X can be opened”. Then it seems like at least the import prices can be more repeatable.
(Btw, I’m amazed that invisible details effect rendering, even our university toy renderer had a pass on visibility.)
Do you think a good neural network could take CAD as an inspiration and produce a usable, simplified model with only the parts which actually are visible?
I feel like many people in this comment section don’t understand the difference between CAD data and GIS data. It’s true that 3d models can be built and put into game engines and has been for some time, but GIS data is specifically geospatial data. It’s not a model of a building and never was. The models of buildings in this article are NOT gis data. The ground is the GIS data.
When we build models of buildings for engineering planning purposes we get a surveying crew to physically measure the relative positions and elevations of many points on a map so that the ground in the ‘model’ is representative of the ground in reality, from which you can plan cut and fill, figure out challenges, etc.
The shitty models of buildings so that execs can ‘see’ the space are not GIS data, and were never meant to be. They’re just visualization. The execs won’t know if something is shifted over by a bit, but the engineer needs to know, and it has to be more or less perfect.
I looked at building information model (BIM) standards a while ago. There are apparently some EU rules that new buildings should have a BIM. This sounds great until you realize what that means is that some cad file needs to get converted into that format and that that file is typically created and never updated before anyone moves into the building. A fun little exercise is trying to get your hands on such a file for any given company building. It exists, somewhere (because it has to). But finding out where is going to be interesting. Typically nobody in companies knows anything about any of this. And when you finally find a BIM file, chances are it isn't very useful. I've seen some samples. It's just a lot of vector data without context, semantics, etc. They are basically technical drawings and not intended to look pretty or nice.
Extracting usable, attractive 3D (or 2D) models from that is a non trivial exercise and I know of a few companies that do this. It's a lot of work, typically and only half automated.
GIS data can be 3D by the way. E.g. geojson uses an array for coordinates and the third position is reserved for altitude. It's just that a lot of GIS data sets don't include altitude information.
One interesting aspect of GIS data is that coordinates are not exact. They can be off by meters and misaligned with other data sets. I've had lots of fun trying to align floor plans with maps and image satellite imagery from different sources. They don't agree with each other where things like building coordinates are. Switching between Apple, Google, and Openstreetmap you may get a slightly different map. It's very common for roads to not be exactly aligned with the satellite imagery. If you think about it, there are all sorts of things that can introduce errors. GPS is not perfect, you get perspective problems with aerial photography. And tectonic plates actually move around. Not very fast, usually. But it adds up over the years. In many places it's centimeters per year. Everything combined, your average map is accurate to about a few meters at best.
>GIS data can be 3D by the way. E.g. geojson uses an array for coordinates and the third position is reserved for altitude. It's just that a lot of GIS data sets don't include altitude information.
yes, its why I said relative positions and elevations.
>One interesting aspect of GIS data is that coordinates are not exact. They can be off by meters and misaligned with other data sets.
It often depends on relative projection etc. The coordinates are exact, but if you're getting them from a source with a relatively high inaccuracy they may just be wrong, or disagree with another data source. As I said, when it really matters a survey crew goes out and does things to a much higher degree of accuracy than 'a few meters', or a lidar scan takes very accurate measurements that are accurate to mm not meters.
The case in the article where they're looking at a construction site and making decisions based on the information would get a digital file from the survey crew based on a nearby survey benchmark, not from GPS. When using actual surveying tech based on GPS the accuracy is much higher than 'GPS', and errors in properly done surveys are something like 3 cm in 30km.
The issue is that people are using data not intended to make detailed plans, to make detailed plans, because they don't want to pay for surveying. When surveying is paid for, the map is accurate to millimeters not centimeters or meters as you say.
Tectonic plates shifting are unlikely to be a measurable issue in the overwhelming majority of projects unless you have very very long term projects that are very large, in which case the thermal expansion of materials is likely to make a much larger variability than any plate movement.
When the article is about something you're familiar with, you do start to wonder if all HN comment threads are similarly topped by blowhards missing the point.
It is included in my org's license and we haven't been paying anything extra. I guess it will be a completely free add-on to most ArcGIS Pro licensing. Unity/Unreal are already free to use too below a certain profit threshold. Overall I'm quite optimistic about it.
I visited an architectural firm many years ago, where they had started to show prospective customers prototypes of designs via an xbox. The customers could walk around, go inside the building and the experience helped them win deals. Always wondered why more firms didn't try something like that. Its great to see more sdks making things like that easier
I remember visiting AutoCAD in SF once, and they had a driving simulator for the newly constructed Presidio Parkway Tunnels, which were designed in AutoCAD. Simulation of real spaces is an interesting niche that I suspect will get leveraged way, way more as the data becomes pervasive.
I bumped into similar issues - most kitbash modes i use are detailed down to screws. I remesh them or blender simplify them or drop the details. It is somewhat time consuming but nowhere near the complexity described in there. And for a building you dont need that level of detail.
We experimented with a similar process in agriculture for customer VR tours of facilities that are too remote or would result in excessive biosecurity risk for the plants/animals inside.
However, we now just use 360 degree video to provide a better, more realistic experience. it's not helpful for exploring designs, but its a better choice (IMHO) for tours of facilities that already exist.
Texturing is trivial if you don’t care if it looks good. Texturing and lighting are an enormous amount of work if you’re using the model to sell or impress people.
Substance painter and procedural materials work wonders. Plaster, bricks, marble, glass look great. And render nicely in ue or unity +hdrp. It can bake normal maps, ao, and so on for high fidelity. Worth giving it a go. Tho you need to uv your models in blender with marked seams or use triplanar textures.
all of these tools exist and you're totally right they work, but they aren't trivial and require time and skill to do properly. I was responding to the idea that this kind of texturing and lighting is trivial - its not if you care about the product and actually want to sell based on it.
The core problem of CAD importing in my experience is that CAD content is not at all designed for or suitable for direct game engine importing. It requires a ton of cleaning to be optimized.
It's one thing to bring in some terrain and an appropriate overlay of imagery, but another thing to try and import actual CAD content.
As an example, I had the CAD files for a large industrial printing press at work, and thought about importing them into Valve's latest engine for VR. But the CAD files were TOO detailed. I mean literally the threads on each screw were modeled, and even the interior of the lock on a cabinet that was part of the machine. Every single component on circuit boards was modeled. It brought Hammer and the game engine to its knees with all the detail.
Another issue with CAD is that not only can things be incredibly overly complex, but the model can include details that the end user simply has no need to visualize, and hence no need for the engine to try and render. Like the interior of that generic key hole latch on the cabinet. You don't need to model the interior of a pipe let alone some complex interior valve unless there is a reason to actually see that detail. 99% of the time a cylinder will do just fine.
Then there is kinematics and animation. Want doors to open and close? Objects that are moveable by humans to be physics objects? You have to do all that yourself. Why would you do that? Well because that's part of an immersive environment that creates a truly engaging and informative experience for the design you are working with.
In the end it was easier to draw on my past experience as a level designer. I selectively imported some details that would be difficult to reproduce, then hand built other components out of simple shapes and apply textures that showed the necessary detail without actually modeling it in detail. And if I did need detail, I could remodel a specific part at a higher level of detail and take advantage of built in level of detail management for models to keep the engine happy.
Summary: nice idea, been talked about for ages, not really that easy if you actually want to build good interactive content in a game engine.