Patrick,
I made some initial results with migrating the airspace display to the
batching branch. See some results here, with the 'vertical sides' of the
airspaces rendered: http://akos.maroy.hu/~akos/cc/
(the code is terribly structured at the moment)
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?
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?
Akos
Akos,
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.
Thanks,
Patrick
thanks
it’s on Google Code, under svn:
or, the svn checkout URL is:
(I know, svn is oldschool, etc)
I see
since then, I did an initial version of a WallGeometry, see in the
above codebase, and also deployed here:
you have to zoom out, and you’ll see a yellow path, which is a
flight track, this one:
the track is parsed from a KML file with a LineString:
as during taxiing it’s at ground level, it seems the terrain map
wins over it.
I’ll have to clean this up before I sand you a proper patch though.
Akos
Hi Akos,
Looks good so far. Does Google Code have an option to download the code as zip? I’m having network issues here at work; I can also try at home.
Patrick
unfortunately I don't see such an option 
Hi Akos,
No worries. Just keep the pickData for now. I thought this might be a video-card issue that I could reproduce even without your code, but my initial testing does not show that to be the case. I’ll try your code on my home machine soon-ish.
Patrick
Akos,
If you pull down the batching branch, things should work now when you do not provide pickData for a geometry instance.
I still have a few more vertex format matching changes, but the pickData should already be taken care of.
Patrick