Hi,
Is it possible to visualise buildings from Cesium ion on a Unity mesh.
I have no Cesium Terrain but a unity mesh with lat/lon and height. We use our own tiles from wmts-services.
Hi @Ruediger_Brand,
If you’re trying to visualize something like Cesium OSM Buildings – which only contains buildings, no terrain – then you can stream that from Cesium ion while using your own terrain underneath. But if you’re trying to stream Google Photorealistic 3D Tiles – which is baked into an underlying terrain layer – then I’m afraid there’s no straightforward way to separate the buildings from the terrain.
Let me know if I’ve misunderstood your question.
Hi @janine,
You are Right - I would Like to draw the buildings as Quaders or Polygons on a mesh.
Rüdiger
Hi @janine could you go in more detail - in which way do get the buiding from Cesium ion ?
Rüdiger
Hi @Ruediger_Brand,
It’s not completely clear to me what you’re trying to do. Adding Cesium OSM Buildings to your scene is easy, though. Just sign into Cesium ion using the Cesium panel, and then click the + next to “Cesium OSM Buildings”. That will display just the (untextured) buildings with no underlying terrain.
If that’s not what you’re after, can you please describe it in more detail?
Hi Kevin,
thanks for the tip - I will try.
One question to this - I think to use the whole package for one functionality - is this not an overhead ?
Also if I have a mesh with lat/lon - what coordinates do the buildings have, do I have control to this ?
to clear:
- i have a mesh (I know the transformation from world coordinates (EPSG:4326) to this mesh)
- i would like to visualize the buildings on my mesh at the right position and with the right scale
only LOD2 - if my mesh is moved, the buildings should move also and stay at the right positions
Regards
Rüdiger
Hi Kevin,
I have seen the following:
The **Place Origin Here button** affects more than the orientation. You may have noticed that the **Latitude, Longitude,** and **Height** fields of the georeference have also changed. That is because the button tells the georeference to recenter the Unity origin at those coordinates. In other words, the point **(0, 0, 0)** in Unity will correspond to the real-world position defined by the georeference. It also aligns the Unity axes so that **+X** points from that position to the East, **+Y** points up, and **+Z** points to the North.
The ability to position the Unity world origin at some real-world location globe is very useful. Many things in Unity, from cameras to transforms to physics, prefer a coordinate system with relatively small values. By “georeferencing” the Unity scene in this way, we allow normal Unity objects to be placed in and around Melbourne and act just as they would in any other game.
Do you mean this ?
In my case: I have a dynamic scene and would like to load at runtime, so I cannot put the data in the scene at the beginning. Because I cannot change all concepts of my app: I would like to move the dataset to a unity-position, but not at all (0,0,0), is this possible ?
Hi Kevin,
I have seen the following:
The **Place Origin Here button** affects more than the orientation. You may have noticed that the **Latitude, Longitude,** and **Height** fields of the georeference have also changed. That is because the button tells the georeference to recenter the Unity origin at those coordinates. In other words, the point **(0, 0, 0)** in Unity will correspond to the real-world position defined by the georeference. It also aligns the Unity axes so that **+X** points from that position to the East, **+Y** points up, and **+Z** points to the North.
The ability to position the Unity world origin at some real-world location globe is very useful. Many things in Unity, from cameras to transforms to physics, prefer a coordinate system with relatively small values. By “georeferencing” the Unity scene in this way, we allow normal Unity objects to be placed in and around Melbourne and act just as they would in any other game.
Do you mean this ?
In my case: I have a dynamic scene and would like to load at runtime, so I cannot put the data in the scene at the beginning. Because I cannot change all concepts of my app: I would like to move the dataset to a unity-position, but not at all (0,0,0), is this possible ?
I thought I can use something similar to that code:
using UnityEngine;
using CesiumForUnity;
public class CesiumTilesetManager : MonoBehaviour
{
[Header("Cesium Ion Asset Settings")]
public Cesium3DTileset tileset; // Assign in Inspector or create at runtime
public long ionAssetID = xxx; // Replace with your Cesium ion asset ID
public string ionAccessToken = xxx; // Replace with your token
[Header("Placement Settings")]
public double longitude = 50.0; // Example
public double latitude = 8.0;
public double height = 0.0; // meters above ellipsoid
public Vector3 localOffset = new Vector3(0, 0, 0); // Unity local offset in meters
public Vector3 localRotation = new Vector3(0, 0, 0); // Unity rotation in degrees
private CesiumGeoreference georeference;
void Start()
{
var cesiumIon = GameObject.FindGameObjectWithTag("CesiumIon");
// Ensure we have a CesiumGeoreference in the scene
georeference = FindObjectOfType<CesiumGeoreference>();
if (georeference == null)
{
GameObject geoObj = new GameObject("CesiumGeoreference");
georeference = geoObj.AddComponent<CesiumGeoreference>();
georeference.transform.SetParent(cesiumIon.transform, false);
}
// If no tileset assigned, create one
if (tileset == null)
{
GameObject tilesetObj = new GameObject("My3DTileset");
tileset = tilesetObj.AddComponent<Cesium3DTileset>();
tileset.transform.SetParent(cesiumIon.transform, false);
}
// Configure Cesium ion connection
tileset.ionAssetID = ionAssetID;
tileset.ionAccessToken = ionAccessToken;
// Set the tileset's georeference origin
georeference.SetOriginLongitudeLatitudeHeight(longitude, latitude, height);
// Apply local offset and rotation
tileset.transform.localPosition = localOffset;
tileset.transform.localRotation = Quaternion.Euler(localRotation);
// Optionally adjust scale
tileset.transform.localScale = Vector3.one;
Debug.Log("Cesium 3D Tileset placed at: " + longitude + ", " + latitude + ", " + height);
}
// Example: Move tileset at runtime
public void MoveTileset(double newLon, double newLat, double newHeight)
{
georeference.SetOriginLongitudeLatitudeHeight(newLon, newLat, newHeight);
}
}
But nothing is displayed ! Is one step missing ?
Hi Kevin,
coul dsoleve the problem.
I have to put the 3dTiles Gameobject as child to the GeoReference.
Now my problem is to handle the position/Rotation of the 3d-tiles in relation to my own objects/mesh.
Regards
Rüdiger
Hi @Ruediger_Brand, I’m having trouble following you. But it sounds like you’re trying to place an object at particular longitude/latitude/height coordinates. To do that, you want to add a CesiumGlobeAnchor component to your GameObject and then set properties on that component. The GameObject must also be a child of the game object with the CesiumGeoreference component. Calling georeference.SetOriginLongitudeLatitudeHeight does something different: it sets where on the globe Unity’s (0,0,0) is located.
This should be well covered by the Placing Objects on the Globe tutorial, so definitely take a close look at that if you haven’t already.
Hi Kevin,
to explan:
- i have a terrain, based on a tms-tile scheme, I know the coordinates of ll-corner in lat/lon/height
(as coordinate system in unity I use a local system)
according to some reasons, I can’t change this. now I would like to place the 3d-Tiles (buildings) on this terrain.
I set the origin of the georeference (parent of the 3d-tile) to the coordinate of the LL-corner and set the scale of the georefenece, so that the position of the 3d-tile fits.
I know the transformations from unity (ENU) to ECEF and to lat/lon/height.
from my perspective now the 3d-tiles are rotated or shifted a little bit. I see this especially at the elevation/height/altitude, but I don’t know the reason.
Is it the ENU-system at the origin or is my plan to display the data together not possible in this way ?
I’m not sure @Ruediger_Brand, there’s a lot that can go wrong there. What exactly is the coordinate system of your terrain? How are you rendering it? If it’s represented in some kind of projected coordinate system, then there’s going to be a mismatch between the projected coordinate system and ECEF, and it will increase as you move away from the origin. It will probably be most noticeably in height. In a projected coordinate system, a constant height forms a plane. But in reality, a constant height (above the WGS84 ellipsoid) forms a globe, and that is how Cesium OSM Buildings is mapped. This difference cannot be resolved with a transformation matrix; the coordinates need to be unprojected.
Hello Kevin,
thank you for the explanation. We use a slippy-map for the terrain in the unity coordinate system (x,z) and the height (unity y).
I could understand your explanation with the constant height, but I thought you use a ENU-System in unity, so a constant height should be a plane, or ?
From your documentation:
Internally, Cesium uses a global Earth-centered, Earth-fixed (ECEF) ellipsoid-centered coordinate system, where the ellipsoid is usually the World Geodetic System 1984 (WGS84) ellipsoid. This is a right-handed system centered at the Earth's center of mass, where +X is in the direction of the intersection of the Equator and the Prime Meridian (zero degrees longitude), +Y is in the direction of the intersection of the Equator and +90 degrees longitude, and +Z is through the North Pole. This Actor is used by other Cesium Actors and components to control how this coordinate system is mapped into an Unreal Engine world and level.
So I thought the main difference in my system, is that maybe I have a transformation between the tangent plane of your ENU-System and my cartesian system using the height perpendicular to my slippy map.
Regards
Rüdiger
Unity’s coordinate system is left-handed, so it is actually EUN, not ENU.
So yes, the CesiumGeoreference makes the Unity coordinate system into EUN at a particular location on the globe. Which means that a constant Y value forms a local-horizontal plane. However, a constant WGS84 height will not have a constant Y value. Its Y values will decrease as we move away from the origin. Because we’re rendering a globe, right?
So, to be really clear… when we’re rendering buildings from Cesium OSM Buildings, if all the buildings in an area happened to be at the same elevation, the Unity Y coordinate of those buildings would decrease the farther we are from the origin, and they will be increasingly rotated to be aligned upright on the globe. On the opposite side of the globe, they’ll be completely upside-down.
Hi,
ok this clears a lot. I thought with the transition to EUN-System you will render a plane with position and a height and not a globe.
In unity we don’t render a globe - this means that this doesn’t work for us. In our case a constant y in unity is a constant height.
Regards
Rüdiger
Even if you’re not rendering a globe, a constant-height surface really is curved in reality. So your visualization will be more accurate if you allow for this. You can usually achieve this by unprojecting your other projected dataset.
We sometimes get requests for using a projected coordinate system within Cesium for Unity. We may implement something like that in the future, but it is not available today.