ArcGIS Maps SDK brings geospatial data to Unity and Unreal Engine
spectrum.ieee.org
spectrum.ieee.org
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.
(Btw, I’m amazed that invisible details effect rendering, even our university toy renderer had a pass on visibility.)
Certainly not a silver bullet but it seems like it could be a huge time saver in certain scenarious
But they are moving into 3D, such as using drone photogrammetry to map cities at once: https://pro.arcgis.com/en/pro-app/2.8/help/mapping/layer-pro...
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.
You can already kinda do this with terrain with Cesium for Unreal (https://cesium.com/platform/cesium-for-unreal/) or for other games like Cities Skylines (https://en.number13.de/cities-skylines-how-to-import-heightm...), but I think those typically are limited to basic heightmaps.
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.
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 wait to see what people make.
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.
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.
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.
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.
Is it possible for the firm to produce the walk-around model from their actual design tools?
Without that, an Xbox based simulator is pretty expensive marketing material and it wouldn’t be a perfect match to the real plans.
Is it more than the cost of a technical person who knows how’s to make the models?
And if you internally automate it, are the results clean enough to show to prospective clients?
And even if the above two concerns are met, is the ROI on this higher than any other prospect the company has to increase customer satisfaction?
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.