Is depthTestAgainstTerrain on a per-Entity-component basis possible?

I am currently trying to figure out how to use appearances with Entities.

The reason for this, is that I have Entities that have both ellipsoids and billboards, and I need the billboards to have depthTestAgainstTerrain disabled, and ellipsoids to have it enabled. I want billboards visible through terrain so that I can easily see things in mountainous regions from bizarre camera angles, but I only want to be able to see geometry when it's directly visible.

I noticed that on this page:

There is an example that shows being able to set depthTest and cull for a specific appearance. Now I just need to learn how to use this with my entities.

var anotherAppearance = new Cesium.PerInstanceColorAppearance({
  renderState : {
    depthTest : {
      enabled : true
    },
    cull : {
      enabled : true,
      face : Cesium.CullFace.BACK
    }
  }
});

In short, I have a few questions:
1. What is the best way to enable depthTestAgainstTerrain for only some entities?
2. Can you add an appearance to an entity?
3. Can you add a primitive to an entity?
4. How do you add an EntityGroup to the viewer (in addition to the viewer.entities group that's there by default)?
5. Do I appear to have absolutely no idea what's going on based on these questions?

  1. This isn’t possible and it’s not an easy problem to solve in general. We are actively working on addressing primitives on terrain and you’ll be able to specify individual entities as “on terrain”. Billboards and Labels are actually already done at the Primitive API level, Entity API support is coming soon. Polygon and Polyline support should follow in the next few releases. My recommendation would be to just wait until the official support is available. If you are anxious to try it out, you can play with the entity-clamp-to-ground Github branch which adds a heightReference property to BillboardGraphics and LabelGraphics that might actually do what you want already.

  2. Entities use Appearances under the hood where applicable, but that’s an implementation detail. You do not use the Appearance system when working with Entities. Billboards don’t use appearances at all as they are specific to geometry.

  3. The Entity API is built on top of the Primitive API, so it creates primitives under the hood. There’s no one line way to associate a primitive with a specific entity other than to just glob a property onto Entity (but that doesn’t actually cause the primitive to interact with the entity in any way or obey the “entity.show” property for instance. There is a plug-in system to associate custom primitives/visualization with a given Entity, but that goes pretty far down the rabbit whole and I don’t think it’s what you want.

  4. CustomDataSource is what you want. You can also implement the DataSource interface directly if you want to make it a plugin.

  5. No, I think this is our failure to provide better documentation. Balancing features/bug-fixing/doc is one of the hardest parts of an open source project. Cesium has also grown and changed over time and there’s currently blurring between the “old way” and the “new way”. I would recommend you read the Visualizing Spatial Data tutorial which explains this some (as well as provides a good overview of Entity API basics. The Entity API is what we officially recommend most users to use these days.

When we eventually start on “Cesium 2.0” I think we’ll be able to clean up some of the cruft that has cropped up in the last 5 years worth of development and that will hopefully streamline the learning process quite a bit.

Hope that helps,

Matt

Thank you very much for your quick and detailed reply. I'm definitely looking forward to the Entity clamp-to-ground support. I should be able to work around not being able to disable or enable depth testing on a per-entity basis.

One more quick question: ScreenSpaceEventType.LEFT_DOUBLE_CLICK doesn't seem to register when running Cesium on my Android phone and double-tapping, but it works fine on my laptop. Is this expected behaviour?

I think it’s expected, but not necessarily what we want. The state of input handling on the web is a bit fragmented so different devices can have different behavior.

You may have some luck using https://github.com/jquery/PEP in your app, which will switch Cesium over to use PointEvent, which should make behavior more consistent.