re-using vertices in the batch branch>

Patrick,

After having done a little of the WallGeometry, I figured it might make
sense to draw the LineStrip points with, well, a LINE_STRIP :slight_smile: which
would of course be of a different color than the triangles drawing the
wall. now, for I already have the vertices for the whole thing, it would
make sense just to add another GeometryIndices object to the same
WallGeometry object, with a LINE_STRIP primitive.

but, as I understand, when combining the WallGeometry object with an
Appearance, thus creating a Primitive, there is no way to separate the
Appearance of the triangles from the appearance of the lines. thus, in
this case one cannot reuse the points (attribute positions) so that the
same points are used to draw the lines?

Akos

Right - these would be two separate primitives since changing the primitive (triangle to line) and appearance (shader and render state) is a “batch breaker.” Later, we may write custom primitives for some of these cases, but the initial vision here is to be general even if it costs a bit of memory and performance. Compared to similar engines, I still expect we will be significantly faster.

Patrick

ok, thanks for the clarification

BTW, as for the WallGeometry, as I'm at it, I might just make it
'complete'. thus: what were your specific requirements for it?

Akos,

I should have also mentioned that parts of the new Primitive probably only work with triangles, not lines or points, so you might have to comment out some code for the time being to get the line primitives to work. The batching branch is the wild west, I know.

Thanks for the kind offer on the WallGeometry. Initially, we want to meet the needs of the KML LineString with extrusion.

  • Bottom/top offset each relative to WGS84 or terrain (see Sample Everest Terrain in the terrain example). This is a bit more general than KML, but it will help us later. :slight_smile:

  • In addition to positions, compute normals, texture coordinates, binormals, and tangents. (We can also do this for you). This will allow us to use the wall with the material system for some pretty cool effects.

  • Please add tests and update CHANGES.md. They aren’t the best tests, but the ellipsoid tests are a reasonable example to start with. Later, we’ll add tests that also render each geometry.

Later, we might also do relative to MSL, but Cesium doesn’t have MSL yet, and I’m not sure how important it is.

Finally, it would be nice to get your CLA in to help speedup merging.

Thanks,

Patrick

thanks for the info - so I won’t try to make contour lines work for
the WallGeometry for the time being.
I see. but then, if only triangles work now (and lines do not), how
would you implement LineStrings if they are not extruded?
what I’ve done until now is an extruded LineString, with an absolute
altitude mode, this basically draws two triangles for every two
point in the LineString, between elevation 0 and the LineString
point elevation. for non-extruded linestrings need be implemented,
but I’d need GL line support for that I guess.
KML LineString does have a relativeToGround altitude mode, so I
guess this would be it…
I see. I feel under-educated in these parts, but I’m open to learn
:slight_smile:
ok, will look at the ellipsoid tests then!
hm, interesting, but how for as ‘relative to WGS84’ from ‘relative
to MSL’?
ok, I just sent you a CLA.
Akos

Hi Akos,

I see. but then, if only triangles work now (and lines do not), how would you implement LineStrings if they are not extruded?

Use separate code that uses the existing PolylineCollection. Although it sounds strange, for lots of reasons, this actually doesn’t use WebGL line primitives. In time, we’ll expose this for generic batching as well.

KML LineString does have a relativeToGround altitude mode, so I guess this would be it…

Exactly, but ours is a bit more general.

hm, interesting, but how for as ‘relative to WGS84’ from ‘relative to MSL’?

I’m not sure what you mean, but relative to WGS84 is relative to the analytic representation of the ellipsoid (Ellipsoid.cartographicToCartesian), and relative to MSL would be relative to the MSL dataset, which is a basically low-res terrain describing mean sea level.

ok, I just sent you a CLA.

Great, but I don’t see it. Did you send it to cla@agi.com?

Thanks,

Patrick

Regards,

Patrick

I see - I’ll take a look at PolylineCollection then
I see. is there such a terrain source available for Cesium? (in
aviation, it is crucial to have things denoted properly in relation
to MSL
yes, from (my corporate address)
Akos

Hi Akos,

I believe the MSL dataset is EGM96 Worldwide 15 Minute Binary Geoid Height Data. If you need it soon, you could process it into our terrain format and host it (it is very small). However, expect the terrain format to change in the coming months. If you’re not in a rush, we are likely to do the conversion at some point.

Also, we got your CLA, thanks. It was stuck in spam.

Patrick

I see. thus, a KML object than would contain a number of primitives,
say a primitive based on a WallGeometry and then a
PolylineCollection primitive.
I think this is beyond my currents scope now. but I did send a pull
request for the WallGeometry I created.
Akos

ok, thanks for the input, as soon as I get there I might do the
conversion.
after doing WallGeometry (or, well, parts of it that I need), I’ll
go on for PolygonGeometry. after that I’ll need to create ‘a polygon
that follows the terrain with a specified offset’ to represent an
airspace vertical boundary which is specified relative to the ground
level.
glad to hear that.
Akos

Akos - thanks for the pull request for the WallGeometry. I’m looking at it now.

As for KML - yes, we’ll have a whole infrastructure to make it easy to write readers for KML, GeoJSON, TopoJSON, etc. Under-the-hood this will create geometries and batch them together. I expect we will have significant progress on this by late summer, in the meantime do whatever KML subset you need. We are likely to reference your KML code as an example, but we probably won’t put anything KML-related into master under we have the full infrastructure in place.

Looking forward to the pull request for the PolygonGeometry. That is a very welcomed contribution.

Also, I’ll be at FOSS4G NA the rest of this week (I’m at the airport now) so my responses may slow down. However, Dan is doing a lot - probably most at this point - of the batching work, so he can also help you.

Regards,

Patrick