Hi to all. Great work with Cesium!
Recently we tried many GoogleEarth alternatives (including ArcGis, SharpMap, etc...), but none of them was good enough to replace it.
We are still using googleEarth, but the clock is ticking and we decided to try Cesium.
For now, it looks very promising!
One of the problems we try to solve is to correctly show objects represented with this KML:
For your issue, would you be able to post a screenshot of what you expect it to look like and what it looks like in Cesium? That will help me give recommendations to achieve what you’re looking for.
Is there some workaround that will allow me to achieve the same result as in GoogleEarth?
Maybe by using CZML, or some custom geometry, or writing some custom shader/renderer, or something else?
Unfortunately, I don’t think there is any easy workaround for this. You would need to implement a custom geometry type that generates the correct texture coordinates, then you would need to connect that type through the entity API and finally modify KmlDataSource to use the new type.
If you would like more information about how to implement this, I can point you to some resources.
We made some complicated workaround.
We warped input image in the way it fits to the groundOverlay in the same way as in googleEarth.
After transformation our image looks like: http://s32.postimg.org/5h6jitcat/test_frame_warped.png
That works, but it isn't elegant solution because we had to add another layer of abstraction that changes our input image.
There are few of us here that are willing to try to implement at least a custom geometry type with correct texture coordinates (we don't explicitly need to do this through the kml), so any additional information and resources are welcome
Great! Glad you were able to make that work for now.
So to get a general idea of how the geometry and appearances layer works as a whole, start by reading this tutorial: http://cesiumjs.org/tutorials/Geometry-and-Appearances/
If you need the latlonqad to curve to the surface of the globe, you’ll probably want to tesselate it in a similar way, just instead of iterating on lat/lon degrees you’ll probably want to interpolate between points using an EllipsoidGeodesic.
You might be able to compute the ‘st’ texture coordinates the same way. The code for finding the normals/tangents/binormals should be similar as well.
If you haven’t already, take a look at our Contributors Documentation. This includes a Build Guide with instructions for pulling down and running the code
reviving this as I want to know if there are any new developments in this area. I'm trying to visualizes some ground overlays which we used to overlay using google earth. Cesium doesn't seem to apply any rotation. Bellow is an example where you can see that the image inside the box isn't rotated as it should: https://dl.dropboxusercontent.com/u/10965353/Screen%20Shot%202017-02-13%20at%2018.00.03.jpg
Τη Δευτέρα, 13 Φεβρουαρίου 2017 - 6:15:17 μ.μ. UTC+2, ο χρήστης Hannah Pinkos έγραψε:
Sorry, dropbox is blocked from my network so I can't see the image. Can you attach it or insert it into the forum post instead?
-Hannah
On Monday, February 13, 2017 at 11:05:06 AM UTC-5, nikos....@gmail.com wrote:Hello,
reviving this as I want to know if there are any new developments in this area. I'm trying to visualizes some ground overlays which we used to overlay using google earth. Cesium doesn't seem to apply any rotation. Bellow is an example where you can see that the image inside the box isn't rotated as it should: https://dl.dropboxusercontent.com/u/10965353/Screen%20Shot%202017-02-13%20at%2018.00.03.jpg
I tried to find an attach button but I still do not see it. Here's a link that should work though. Notice that the image/layer isn't rotated inside the box. http://citisens.eu/rotation.jpg
thanks for your input. I still cannot figure out how could I fit the pictured overlay inside the background box by defining just two points/corners. Rotation messes up with the overlay’s corners and they do not align with the box corners.
I decided that one path forward is to stop using rotations altogether until gx:LatLonQuad is supported fully by Cesium.
My problem now is that although the screen overlay displays OK when terrain view is disabled, when I enable a terrainProvider the overlay isn't clamped to the ground despite setting the clampedToGround option to true in the KmlDataSource.load options. I tried this with other types of KMLs that we use (vector types, polygons, etc.) and the problem remains.
Please tell me that I'm doing something wrong and that the "clamped to ground" functionality is supported is some way.
camera : viewer\.scene\.camera,
canvas : viewer\.scene\.canvas,
clampToGround: true
}));
If you are doing that and your entities are still not clamped to ground, could you put together a sample KML file that reproduces the problem?
Thanks,
Hannah
On Tuesday, February 14, 2017 at 11:36:29 PM UTC-5, nikos....@gmail.com wrote:I decided that one path forward is to stop using rotations altogether until gx:LatLonQuad is supported fully by Cesium.
My problem now is that although the screen overlay displays OK when terrain view is disabled, when I enable a terrainProvider the overlay isn't clamped to the ground despite setting the clampedToGround option to true in the KmlDataSource.load options. I tried this with other types of KMLs that we use (vector types, polygons, etc.) and the problem remains.
Please tell me that I'm doing something wrong and that the "clamped to ground" functionality is supported is some way.
Hi Hannah,
did you notice the problem using the files I gave you? I have the same problem when using KMLs containing polygon coordinates (no overlays). The polygons are still not clamped to the ground even when I use the clampedToGround option.
Sorry, I forgot to take a look at this before. Thanks for reminding me.
The problem is because we currently do not have ground clamping support for geometry with an image material. Geometry can only clamp to ground if it has a color material.
Thanks for the issue report. As I said in my previous email the problem exists not only for image materials but for polygons as well. Try to visualise the attached KML with terrain ON and watch the polygon positions drift when tilting the camera view despite setting clampToGround: true.
