Cool - nice progress.
I have one question though: I see that if I don’t have a pickData member in the Geometry object, it seems not get rendered. this doesn’t seem intuitive - what is the pickData property for exactly?
In general, picking is used to select objects in the scene (like this Sandcastle example). Historical, Cesium would return the primitive under an (x, y) location on the screen. With batching, one primitive may be several different objects, so returning the primitive alone is not that useful. pickData is application-defined data - an ID, string, function, whatever - that identifies a mesh.so now Cesium will return the primitive and pickData so the application knows what exactly in a batch was picked. In the batching branch, just bring up the console window and mouse over different meshes in the viewer.
Anyway, a mesh should still render without a pickData, and that is the case on my machine, but I can believe that there are some bugs here, since I had, err, fun, getting it to work. Is your code on GitHub? Can I experiment with it?
my priorites are to have a PolygonGeometry object working, that would provide the top and bottom sides of an airspace. I also see this on your todo list. for this, polygon tesselation has to be solved somehow. what was your intention here - try to reuse the tesselation code from the ‘old’ Polygon class?
Yes, we would definitely reuse the code in the Polygon, most of which just calls into PolygonPipeline. As I mention on the roadmap, keep in mind that the PolygonGeometry will not need all the calls that the current Polygon has, because some of them, like encodeAttribute and fitToUnsignedShortIndices, are now in the Primitive.