Hello, I was wondering if there is a way to import ESRI shapefiles into Twinmotion. I am an anthropologist working on Native American Earthworks I have created the earthworks in ESRI now trying to use those in Twinmotion, Thank you
No idea for twin motion but i can give you a blow by blow of using Qgis to make a 1:1 scale map in UE4 and exporting vertex data to use for splines.
My project is archeological in nature, and I’m actually struggling to understand if i should stick to WGS84 or export the shifted map to use.
Regardles of the choiche, in my case (covering 2 zones) I have bad results anyway.
With the 84 format stuff looks corect when in loco, but the distance between the 2 cities is about 20km due to the non elliptical nature of tiled worlds in Unreal.
with the deformed region stuff looks almost nothing like it should because of the distortion across the 2 zones.
Anyway the export process is the same and quite possible if you know your extent.
its basically just about mapping ratios.
Thank you anything would help
Anyone know if you can import kml are kmz that would also work for me.
I have to try and see if my process works with the properly adjusted file mapped to the proper spehere coordonates.
however it is a multi step process.
Start with a vertex extraction to get the points.
modify the points table to add in the reading of longitude and latitude.
Use the point sampling plugin to sample and obtained a mixed table that includes point id, lat, lon, and elevation as read off from the raster thanks to the plugin.
Make a formula to convert those values to unreal engine units.
geo of extent top left - value x of vertex = A
100 / extent size x = ratio
A * ratio = world units of dot.
Similar for y but they work opposite so you have to use the lowest corner and add to it to get the value.
The height is similar.
you need to know your min/max, come up with a ratio, and place it.
If it is any help we have successfully imported WGS84 data into 1:1 model of the Earth. And it’s an ellipsoid Earth - not some cheesy sphere.
More info on this UDN thread.
wgs84 is a cheesy ellipsoid approximation. The most correct data would always be that related to the lat/lon of the tile itself since the map is often “flat” when you acquire it.
Wgs84 is used for approximating with the convenience of not having to scale each tile by its lon/lat wgs projection.
Additionally. You exponentially loose accuracy on distance calculation, which you do not if the tile uses the proper localized projection.
I wonder if we are talking at cross purposes?
I know the WGS84 reference ellipsoid is an approximation of the geoid but would you agree that it is a better approximation than a sphere?
Also, the earth model we construct is not flat. We do not project from lat/lon to cartesian. We go from lat/lon to ECEF and then to local tangent plane coordinates (ENU).
For context, what we are doing is line of sight calculations for microwave point-to-point relays so a curved-earth was essential. Our distance calculations are accurate to 1 ppm (part per million) compared to a traditional ground survey, but maybe we are missing something - can you suggest a better method?
Naturally. it’s much more accurate when calculating distances at the same parallel.
IF the calculation is happening in unreal? I can screenshot the correction code for you. it’s a basic mathematical equation that adjusts from Linear to ellipsoid approximation.
If you are calculating on the file or in GIS, the distance usually already has an option for it to adjust, which is why error margins are so minimal. - however you should note that this distance is not equal to the Pixel distance of the flat file - unless the projection is correctly adjusted.
The whole issue is just that. A map/heightfiled is flat - and usually not in a 1:1 scale (but that’s another issue entirely since Scale can be calculated separately if need be).
This - within Unreal and with mind to a Gaming world where you do require collision - becomes very problematic because within unreal maps are also essentially “FLAT”. What we often re-create is not the reality of the solar system but a flat earth similar to what flat earthers model as gospel (the difference being we all know it is just an easier representation than having a spherical earth which rotates in relation to a sun/light source). Can it work? Yes. Is it accurate? Hell no, it’s an approximation.
Further more, unless correctly adjust it, far away tiles do not automatically “bend” as they should.
What does this mean? This means that on their own, the far tiles and objects in a game will be linearly visible no matter what at a distance. If you have a tower of 1km, at a distance of 10km you will see a tower of 1km in height instead of having over half (or whatever the actual math is) be not visible because of earth’s curvature.
If you were to create an ellipsoid of 6,371KM approx radius and selectively sculpt areas based on a correctly projected heightfield you would still get marginal errors in calculations, but were it possible memory load wise - the result would be FAR more accurate compared to a flat representation when calculating line of sight distances.
For me anyway, the issue comes with objects, not the map. You can force your impostor materials to conform to an ellipsoid with vertex calculations partially resolving the visual effect. However this won’t change the actual placement of objects on the map if they are placed with Collision.
I’m not sure what it is you are actually doing, so those are my considerations in relation to my project.
IF you are going for accuracy, modeling an ellipsoid is far more accurate from the start / Do not rely on the unreal maps/tiled world, or do the ground work to adjust their actual shape. You can totally make every tile bend somewhat correctly, it’s just an insane amount of work / It would be best to create a separate map system for it.
We are **not **using a heightfield.
Our earth model in Unreal is a 1:1 ellipsoid. IT IS NOT FLAT!
Are you reading *anything *I am writing?
Our tiles **do **bend. We **do **have an accurate horizon. Objects **are **hidden over the horizon.
Please look at this thread.
Unreal uses heightmaps which are height field derived 16bit files. So if you are using landscapes you are using heightmaps/heightfields.
If your model is an ellipsoid, as I stated above, you have less error to deal with.
A properly displaced world tile should “conform” to the ellipsoid if you place it on it.
Obviously unreal doesn’t do this for you.
Additionally, every level tile would need to be placed at a different world location in order to blend correctly for the ellipsoid effect to work.
Again, I’m talking about using the built in landscape system.
if you aren’t using the landscape system, then no one cares.
You can do whatever you want with custom meshes.
that said, to reduce calculation errors each lat/lon should still be projected to its specific wgs/esri version.
I have some shp files from agisoft that I would like to use to help shape the terrain. How would I go about this. Any help would be great.
best thing I can think of is that you download and install Qgis, import the shape file, make sure it is geo-tagged to the correct zone, enable the open map view as a layer. And work within Qgis to create the heightmap to use.
shp files are (usually) vector data, so I’m not sure it would help any on its own.
if the file isn’t geo tagged to a real location it would in fact be near useless.
Usually I do (or import) roads and rivers as shape files and export their x/y/z data to use within spline components…
We are not using landscapes.
We are not using heightfields.
Our world is curved. Like a real world is.
As I mentioned, likely best case scenario. If you throw in a proper quadtree optimization it is very likely to outperform the landscape system.
However you are most definitely using heightfields since thats the only way data is translated from lidar into a usable and shared format.
point clouds could also be used (and would definitely be more acfurate) - but unless you own or placed a satellite in orbit that’s not likely to happen.