Support layer opacity for vector points

[ahocevar]

See #144 (comment). This adds support for layer opacity on vector points. Layer and style opacity are combined on the billboard level.

[gberaudo]

@ahocevar, I will look at your code next week when I am back from FOSDEM.

[schmidtk]

I'm guessing you'll need to define your OL opacity attributes in the Cesium externs to avoid making the compiler angry. Otherwise the approach looks sound to me.

[gberaudo]

The olLayerOpacity will be undefined on first synchronization.
The correct way is to pass the layer to the synchronization function.

[ahocevar]

This is why opacity will be initialized to 1 above if it is undefined.

[gberaudo]

Why 1?

[ahocevar]

1 means fully opaque, which is the default.

[gberaudo]

The layer opacity may be different from the default; that is why it is necessary to read the actual value.

[ahocevar]

Sorry, I think we had a misunderstanding. billboards.olLayerOpacity will never be undefined here. Only opacity can, and this is when no opacity is set on the style.

[gberaudo]

There are several code paths where billboards.olLayerOpacity will not be set.
See BillboardCollection instantiations.

[ahocevar]

Sorry, you got me confused. As I said above, opacity is initialized to 1 if undefined, and stored as billboards.olLayerOpacity. billboard.olStyleOpacity will never be undefined, because it is always set (and initialized to 1 if undefined when a billboard is created.

To avoid such confusion in the future, we should make adding unit tests a priority.

[gberaudo]

@ahocevar, please see my comments.
Your PR only deals with Point geometries; do you plan to implement support for the other kinds of geometries to make it look consistent?

[ahocevar]

@gberaudo I'll see if I can make this work for other geometry types as well. Points were a lower hanging fruit than the rest though.

[ahocevar]

@schmidtk:

I'm guessing you'll need to define your OL opacity attributes in the Cesium externs to avoid making the compiler angry.

Did you run git submodule update before building? The ol3 version currently used as submodule already has the layer opacity in the generated externs file.

[gberaudo]

Why do you iterate in reverse order?

[ahocevar]

Starting the iterator with bbs.length saves me from having to store it in a separate variable. This is a small optimization I use frequently when the order of iteration does not matter.

[ahocevar]

@gberaudo The primitives are now updated by an ol.core function. I added FIXMEs for switching to Cesium.Color.fromAlpha once we update Cesium again. Making this work for geometry types other than point will be more effort, so I'd appreciate if we can get this in just for points for now.

[gberaudo]

Changing visibility should not trigger the expensive modification of all opacities.

[gberaudo]

@ahocevar, I feel it would be better to merge this PR in a dedicated branch of
the project until support for all other geometries are added.

Otherwise, it will look strange with only the points opacity changing.

Is it OK for you?

[ahocevar]

I do not see a way to change the opacity of other geometry types, other than recreating all primitives.

[schmidtk]

You have to use Primitive#getGeometryInstanceAttributes and modify the color with the new opacity, but keep in mind that function will fail until the primitive is ready to render. We're also not setting the id field on GeometryInstance objects we create in core.js here and here, which we should be doing. That will also cause errors in the uncompiled version.

[ahocevar]

This is what I tried, but after rendering the geometry instances of all primitives are undefined, so nothing can be changed.

[gberaudo]

@ahocevar, here is a working Sandcastle example

Cesium.Math.setRandomNumberSeed(1234);
var viewer = new Cesium.Viewer('cesiumContainer');
var scene = viewer.scene;
var primitives = scene.primitives;
var solidWhite = Cesium.ColorGeometryInstanceAttribute.fromColor(Cesium.Color.WHITE);

var id = 'anid';
var rectangle = Cesium.Rectangle.fromDegrees(-92.0, 20.0, -86.0, 27.0);
var rectangleOutlineInstance = new Cesium.GeometryInstance({
    geometry : new Cesium.RectangleOutlineGeometry({
        rectangle : rectangle
    }),
    attributes : {
        color : solidWhite
    },
    id: id
});


var ro = primitives.add(new Cesium.Primitive({
    geometryInstances : [rectangleOutlineInstance],
    appearance : new Cesium.PerInstanceColorAppearance({
        flat : true,
        translucent : true,
        renderState : {
            lineWidth : Math.min(4.0, scene.maximumAliasedLineWidth)
        }
    })
}));

ro.readyPromise.then(function() {
    var i = 0;
    setInterval(function() {
        var attrs = ro.getGeometryInstanceAttributes(id);
        //var color = attrs.color;
        attrs.color[3] = i;
        attrs.color = attrs.color;
        i = i + 20;
        if (i > 255) {
            i = 0;
        }
    }, 100);
});

[ahocevar]

I had found a similar example and implemented accordingly. As I said, the problem is that the primitive seems to forget about its geometry instances. I can push my non working code if you want to take a look.

[gberaudo]

@ahocevar, Cesium deletes the reference to the geometry instances for performance reasons. As suggested by @schmidtk, we need to set and keep a list of the geometry instance ids. Please push your code somewhere and I will have a look.

[ahocevar]

I just saw that we're not assigning an array to geometryInstances, but a single geometry instance. This is the cause of the problem.

[ahocevar]

I just saw that we're not assigning an array to geometryInstances, but a single geometry instance. This is the cause of the problem.

At least it is part of the problem. The correct approach is probably really to assign ids.

[ahocevar]

@gberaudo This is my code so far: 3206bf7

[schmidtk]

Do you know if Cesium uses the geometry instance id for anything other than lookup with getGeometryInstanceAttributes? If not, we can reuse a constant id instead of maintaining a list.

[gberaudo]

@ahocevar, have a look to gberaudo@84f566d for how to modify opacity after the primitive is rendered.

[ahocevar]

Thanks @gberaudo, that works well. I'll try to complete this pull request when I get to it. Might be a long time from now though.