When importing a 3D Object to a new Asset, I can set the GeoPosition on the world inside the Cesium Ion user interface.
When importing multiple objects in the same asset (in my case multiple zip files with gltf files inside) all the object are placed at the same world position.
Is there a way to define and communicate during upload a Lat,Lon geoposition per object ?
If I understand correctly, you would like to be able to upload multiple OBJ files and create a single 3D tileset from them. Currently all of the OBJs are located at the same position. And you would like to be able to adjust the position in Cesium so that they are at different positions when tiled.
This is not currently supported in Cesium ion. Can you provide some more information to help us better understand your workflow? This will help us better provide alternative solutions as well as consider adding in additional functionality to support this use case
What software did you create theses OBJ files in?
How many OBJ would you need to reposition?
How are you using the 3D tileset generated from these OBJ files?
The objects will most certainly be created in Blender but they can also be bought from existing 3D object databases.
In order to improve the quality or recognition of certain places we would like to create our own buildings, props, … other objects like bridges or anything that could be landmark-recognizable.
Our current project is in Unity so realtime loading of objects can only be done through tile sets.
We select the tileset depending on the user-selected area he’s visiting.
If we would need to place 500 custom objects in the area, we could place them all in the same object and import it and place it at the right position but how would these individual objects snap to the ground ? and how can we accurately place these objects ? (your object import UI has a nice positioning tool)
You can compare it to the “OSM buildings tile set”, but we would create our own objects and “add/delete/replace” them in the tile set.
So you would like to to something similar to this sandcastle example where each building’s elevation is set based on the elevation of the terrain at the building’s location.
Cesium ion currently only supports setting the location and elevation for the entire tileset, not individual features.
One option would be to use Blender to position the objects relative to one another and then save a single OBJ file to import into Cesium ion. This would require you to correctly set the relative elevation of each object as well. This is also how the OSM Buildings data set is working. It has the elevations set directly in the data and is not dynamically clamped to the terrain.
The other option is to tile each building individually. The down side is that you would have to load many tilesets but then you could use the position editing functionality in Unity to adjust each individually.
I’ve reached out to the Cesium for Unity team to see if they can provide any additional information.
I just want to confirm my understanding of your circumstances. So, you’re looking to place buildings in Unity at specific points on the globe, and clamp them to the ground. I’m not sure if you have put these buildings into one Cesium3DTileset, or if they’re separate – could you clarify?
In the meantime, I will mention that Cesium for Unity includes the ability to “anchor” a Unity object to a specific location on the globe. This is possible through the CesiumGlobeAnchor component. With a globe anchor, you can specify the lon / lat, as well as the height above the WGS84 ellipsoid, that an object should be. So if your buildings are all separate models, you can attach a globe anchor to each one.
Getting an object to automatically clamp to terrain is a bit trickier. We have typically instructed our users to raycast to the terrain, then move the objects to that point of intersection, like in this thread.
I hope that helps. Let me know if I’ve misunderstood your post, or if you have any follow-up questions or concerns.
The initial idea is to create custom 3D objects to make areas (that do not yet or have really bad Google 3D photorealistic tiles) look closer to reality instead of seeing only the smashed trees and cubic single colored (or mono textured as we do it) buildings.
I was thinking of creating our own tile set to group these objects inside so the loading would happen through Cesium. In order to achieve this placing the objects in Blender in 3D coordinates and trying to match the heights, and positioning on the satellite images, I presume, is going to be a rather intensive job.
What would be nice would be to be able to add different objects to the same tile set and be able to position them on the selected terrain.
My second option would be the Unity-only option, which I actually implemented already but which I think is not so cool as if it would be Cesium “create manually your own tile set of 3D objects”
As input I have 3D objects and positions in Geopos (lat-lon) and I would like them to be assembled in one tile-set and in preference each object being a different tile. And I would like to see them snap to the ground. That would be awesome.
My current tools do this but all happens through Unity, which works fine. The data is stored on our server and we can add/delete data as needed.
Concerning the “snap to the ground”. The use of the RayCast or RayCastAll is a little bit tricky. If I raycast on the Bing terrain this is working nicely, however, if I chose to use Google photorealistic 3D tiles, I come across a few issues. As both terrain data do not share the exact same heights (display the building the set and google 3D to observe) one must raycast with the right terrain. In Google 3D there are many artefacts and the 3D mesh depends the LOD as well. Resulting in raycasts intersecting sometimes not with the ground.
The other big downside of this raycast solution is that you can only raycast on created meshes, so if I would like to plant a forest of trees I will need to have all tiles in my display cone before planting them.
If the “create manually your own tile set of 3D objects” is not possible, too bad. I would have preferred that but what I have now works, so I am not going to complain