Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support layer opacity for vector points #166

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

ahocevar
Copy link
Member

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

@ahocevar ahocevar mentioned this pull request Jan 29, 2015
@gberaudo
Copy link
Member

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

@schmidtk
Copy link
Contributor

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.

}
color = new Cesium.Color(1.0, 1.0, 1.0,
opacity * billboards.olLayerOpacity);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why 1?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1 means fully opaque, which is the default.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

gberaudo commented Feb 2, 2015

@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
Copy link
Member Author

ahocevar commented Feb 2, 2015

@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
Copy link
Member Author

ahocevar commented Feb 3, 2015

@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.

}
bbs.olLayerOpacity = opacity;
var i, bb;
for (i = bbs.length - 1; i >= 0; --i) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you iterate in reverse order?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member Author

ahocevar commented Feb 3, 2015

@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.

olLayer.on('change:visible', function(e) {
csPrimitives.show = olLayer.getVisible();
olLayer.on(['change:visible', 'change:opacity'], function(e) {
olcs.core.updateCesiumPrimitives(olLayer, csPrimitives);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@gberaudo
Copy link
Member

gberaudo commented Feb 3, 2015

@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
Copy link
Member Author

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

@schmidtk
Copy link
Contributor

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
Copy link
Member Author

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

@gberaudo
Copy link
Member

@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
Copy link
Member Author

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
Copy link
Member

gberaudo commented Feb 12, 2015 via email

@ahocevar
Copy link
Member Author

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
Copy link
Member Author

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
Copy link
Member Author

@gberaudo This is my code so far: 3206bf7

@schmidtk
Copy link
Contributor

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
Copy link
Member

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

@ahocevar
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants