cesiumgs / cesium Goto Github PK

The window coordinate origin is the bottom left in WebGL and it is the top left in the browser. Most users will expect any window coordinates to be in respect to the top left. Any functions that accept or return window coordinates should treat the top left of the window as the origin.

when calling the clock constructor and only currentTime is undefined it calls startTime.secondsDifference.
it should be startTime.getSecondsDifference.

For consistency throughout the code (most exceptions I suspect). Also update the coding standards.

Low-hanging fruit if anyone wants it...

In the sandbox example, when I hold the left mouse button down and do not move the mouse, the globe slightly pans to the north west every second or so. This is a lot more noticeable on higher zoom levels because the map can jump very far. I believe this has something to do with the mouseConstrainedZAxis set to true because it does not happen on the other examples.

scene.getCamera().getControllers().get(0).mouseConstrainedZAxis = true;

Also because of this, I was able to turn the globe completely upside down and it became stuck there.

On another machine the globe did not continuously pan north west on mouse down. It only does it once which is still undesirable and I was still able to get it stuck upside down.

The current version of master does not respond to the middle mouse button being clicked.

Edit: This only happens in Sandbox, and since we are moving away from sandbox soon this bug might not matter.

I did a test today. I found that if I open the browser and type the cesium page, the memory will increase sharply during several hours. It increased from 300M to almost 1 GB. I want to know how js clear the memory problem?
Thanks.

In many places we use || instead of checking for undefined. For example

this.myValue = value || 12.0;

This is bad because a value of 0 will result in myValue equalling 12. The correct code is

this.myValue = typeof value !== 'undefined' ? value : 12.0;

@shunter wrote a simple function to make this easy, so it would be simplified to

this.myValue = defaultValue(value, 12.0)

Someone needs to go through the entire code base and look into all || usage, replacing non-boolean specific usage with these checks.

I am unable to test this on a machine without ANGLE turned on, so not sure if this is a side effect of using ANGLE or not.

When I set the horizontalOrigin property on a label to RIGHT or CENTER, it does not work, and the text gets mangled.

Try this in the Sandbox "Set label properties after creation"

l.setHorizontalOrigin(Cesium.HorizontalOrigin.CENTER);

See screen capture here:

https://docs.google.com/open?id=0BxRv_pudufMfbXJPZGxTWEZxMVE

I can get this to happen reliably, so I can demonstrate in person, but to describe, while holding right mouse, a sharp downwards motion can often leave the entire view black, including the bing logo viewport quad. Once in this mode, I haven't found any way yet to get the camera back to a normal viewing position.

Less is more.

Discussion: 1f7e2f0#commitcomment-1405144

Right now, each coordinate type has it's own methods for how conversion to other types works. This can also create circular dependencies when both types want to offer conversion routines; for example adding a toCartesian3 method to Spherical and a toSpherical method to Cartesian3 is not possible without hacking around the require system.

As part of the viewer branch pull request, I added a new object, CoordinateConversions, which makes a good place to store all such routines without the circular dependencies. It also makes it easier for users to find the correct method. For example, creating a Spherical out of a Cartesian3 maps to the sphericalToCartesian3 method (and vice-versa). I think all similar methods should be moved into this object and follow the same pattern.

Run the Sandbox and step through the draw calls with WebGL Inspector. A lot of draw calls are made for tiles that are not visible.

Is there a bug with view frustum or occlusion culling? Are the bounding volumes too large? What percentage of draw calls are for tiles that are visible? We expect some false positives but not many.

Firefox renders red pixels incorrectly. This is most noticeable when we read pixels from the texture atlas' texture to confirm the atlas drew correctly (in TextureAtlasSpec.js). The current workaround is to check if the R component is 0 or 1, like:

expect((pixels[0] === 0) || (pixels[0] === 1)).toEqual(true); // Workaround: Firefox on Windows expect(pixels[1]).toEqual(255); expect(pixels[2]).toEqual(0); expect(pixels[3]).toEqual(255);

I'm working on a Cesium prototype for my customer that will be completed early August. All of our visualization needs are achievable in Cesium right now except we have a need to visualize translucent solid spheres around our satellite billboards that grow and shrink in radius over time. We calculate an uncertainty error surrounding each satellite as part of our calculations and I want to visualize that in the prototype as a sphere. The sphere will intersect and pass through a CustomSensorVolume, if it matters.

• Run the 3D skeleton.
• Zoom in until about a few states are visible.
• Hold down shift and look to the horizon.
• Start panning for a bit, then zoom in close.

It will take a long time for the imagery in the area of interest to appear as all the outstanding requests, which are no longer needed, are serviced. Once a tile request comes back, should we keep it if it is far enough out of view? What other priority strategies should we use?

It's pretty simple, if a line is normal to the earth, it disappears in 2D. Ideally, we would use the width and outline of the line to turn it into a point in 2D mode. We have some code in DynamicScene that creates points on the fly using billboards, we might be able to adapt/refactor that out for this use case as well. I have an example CZML that shows the issue if anyone wants to look at this.

Careful with precision. Compare to our CPU implementation.

I am seeing a couple strange behaviors when drawing polygons in 2D mode. In both cases the polygons are rendered accurately in 3D mode. The issues can be replicated in the sandbox example "Draw a polygon" by pasting the included code.

First, when I draw a circle like polygon close to a pole it renders 4 strange triangles that are drawn within the polygon. However, in 3D mode the circle renders properly, without them. Here is the code that I pasted into the sandbox for this issue:

transitioner = new Cesium.SceneTransitioner(scene);
transitioner.to2D();
cb.affectedByLighting = false;
var polygon = new Cesium.Polygon();
polygon.affectedByLighting = false;
polygon.setPositions(ellipsoid.cartographicDegreesToCartesians([new Cesium.Cartographic2(-42.75,65.6249),
new Cesium.Cartographic2(-58.7498,64.3139),
new Cesium.Cartographic2(-71.5318,60.7427),
new Cesium.Cartographic2(-80.3024,55.6384),
new Cesium.Cartographic2(-85.8009,49.6215),
new Cesium.Cartographic2(-88.9521,43.0974),
new Cesium.Cartographic2(-90.4365,36.317),
new Cesium.Cartographic2(-90.6873,29.4448),
new Cesium.Cartographic2(-89.9653,22.6),
new Cesium.Cartographic2(-88.4185,15.8811),
new Cesium.Cartographic2(-86.1224,9.3805),
new Cesium.Cartographic2(-83.1049,3.193),
new Cesium.Cartographic2(-79.365,-2.5773),
new Cesium.Cartographic2(-74.8895,-7.8139),
new Cesium.Cartographic2(-69.6722,-12.386),
new Cesium.Cartographic2(-63.7362,-16.1532),
new Cesium.Cartographic2(-57.1585,-18.9746),
new Cesium.Cartographic2(-50.0889,-20.7259),
new Cesium.Cartographic2(-42.75,-21.3201),
new Cesium.Cartographic2(-35.4111,-20.7259),
new Cesium.Cartographic2(-28.3415,-18.9746),
new Cesium.Cartographic2(-21.7638,-16.1532),
new Cesium.Cartographic2(-15.8278,-12.386),
new Cesium.Cartographic2(-10.6105,-7.8139),
new Cesium.Cartographic2(-6.135,-2.5773),
new Cesium.Cartographic2(-2.3951,3.193),
new Cesium.Cartographic2(0.6224,9.3805),
new Cesium.Cartographic2(2.9185,15.8811),
new Cesium.Cartographic2(4.4653,22.6),
new Cesium.Cartographic2(5.1873,29.4448),
new Cesium.Cartographic2(4.9365,36.317),
new Cesium.Cartographic2(3.4521,43.0974),
new Cesium.Cartographic2(0.3009,49.6215),
new Cesium.Cartographic2(-5.1976,55.6384),
new Cesium.Cartographic2(-13.9682,60.7427),
new Cesium.Cartographic2(-26.7502,64.3139)]));
primitives.add(polygon);

The second issue is when I draw a polygon across the date line. Occasionally, one or more lines are rendered across the entire earth in 2D mode, but the polygon looks fine in 3D mode. Here is the code that I pasted into the sandbox for this issue:

transitioner = new Cesium.SceneTransitioner(scene);
transitioner.to2D();
cb.affectedByLighting = false;
var polygon = new Cesium.Polygon();
polygon.affectedByLighting = false;
polygon.setPositions(ellipsoid.cartographicDegreesToCartesians([new Cesium.Cartographic2(-176.3437,11.6397),
new Cesium.Cartographic2(-179.881,11.3338),
new Cesium.Cartographic2(-183.3023,10.4275),
new Cesium.Cartographic2(-186.5001,8.9531),
new Cesium.Cartographic2(-189.3814,6.9614),
new Cesium.Cartographic2(-191.8712,4.5174),
new Cesium.Cartographic2(-193.9114,1.696),
new Cesium.Cartographic2(-195.4586,-1.421),
new Cesium.Cartographic2(-196.4804,-4.7479),
new Cesium.Cartographic2(-196.9514,-8.1962),
new Cesium.Cartographic2(-196.851,-11.6746),
new Cesium.Cartographic2(-196.1629,-15.0895),
new Cesium.Cartographic2(-194.8767,-18.344),
new Cesium.Cartographic2(-192.9929,-21.3391),
new Cesium.Cartographic2(-190.5298,-23.9743),
new Cesium.Cartographic2(-187.533,-26.1519),
new Cesium.Cartographic2(-184.0836,-27.7825),
new Cesium.Cartographic2(-180.3019,-28.7933),
new Cesium.Cartographic2(-176.3437,-29.1358),
new Cesium.Cartographic2(-172.3856,-28.7933),
new Cesium.Cartographic2(-168.6039,-27.7825),
new Cesium.Cartographic2(-165.1545,-26.1519),
new Cesium.Cartographic2(-162.1577,-23.9743),
new Cesium.Cartographic2(-159.6946,-21.3391),
new Cesium.Cartographic2(-157.8108,-18.344),
new Cesium.Cartographic2(-156.5246,-15.0895),
new Cesium.Cartographic2(-155.8365,-11.6746),
new Cesium.Cartographic2(-155.7361,-8.1962),
new Cesium.Cartographic2(-156.2071,-4.7479),
new Cesium.Cartographic2(-157.2289,-1.421),
new Cesium.Cartographic2(-158.7761,1.696),
new Cesium.Cartographic2(-160.8163,4.5174),
new Cesium.Cartographic2(-163.3061,6.9614),
new Cesium.Cartographic2(-166.1874,8.9531),
new Cesium.Cartographic2(-169.3852,10.4275),
new Cesium.Cartographic2(-172.8065,11.3338),
new Cesium.Cartographic2(-176.3437,11.6397)]));
primitives.add(polygon);

Unless the developer is extremely careful, it's very easy to create JulianDate instances represented as UTC. This leads to major performance issues whenever time arithmetic is needed, which in the case of Cesium is quite often. It also leads to bad edge cases the moment leap seconds get involved. Me and @kring agree on taking the following actions:

1. JulianDate should still take data as either TAI or UTC, but always convert UTC and store it internally as TAI.
2. The only way to get a UTC date out of JulianDate is to convert to a JavaScript date, which is the most common reason for needing UTC anyway. All instances of JulianDate themselves will be in TAI.
3. Some JulianDate operations end up creating "throw-away" JulianDate instances for no good reason, change the code so this no longer happens.

Add tests and also remove the need for the collection.

Even if the highest resolution image is reached (or in the case of the single image tile provide, the only image), we should still refine the tile geometrically if its geometric pixel error is above our threshold. We should, of course, stop tessellating when the local area around the tile is basically flat. To implement this, several tiles, each with different texture coordinates, will need to be rendered to draw one image.

Im sorry if this question has been asked before. Has anyone tried running Cesium on Android and is it possible to do so? I would like to find out whether it is possible to run Cesium on Android.

No matter what altitude I put my label at, it always gets rendered beneath a polygon or polyline when the primitive is added after the labelcollection. To see what I mean, try In the Sandbox to paste the label code example into the polygon example and move the label's position so it intersects with the polygon.

I can use sendtoback in compositeprimitive to keep the ordering correct, but I was just thinking that maybe this should be done always in the compositeprimitive class without my intervention.

Everywhere we create or store an object literal to represent a color should be changed to use an actual Color object instead. Note that everywhere we TAKE a color should still handle a user created object literal, we just shouldn't use it internally.

Custom sensor examples in sandbox stop working after commit c1e68f1. Conic sensor volumes seem to work fine.

The Polygon primitive should have a clean way to support extents, circles, ellipses, etc. In general, we need to better decouple geometry and rendering, and still present high-level interfaces.

Almost all of our types have methods that create new instances, which leads to a ton of unnecessary throw away objects and increases memory pressure. For example, computing the sun position ends up creating several Cartesians every frame, when in reality it shouldn't need to create any (or at most 1). All of our functions that create new instances should allow for a result parameter to be specified as the last parameter which is the instance to store the result in. It should also allow for the result parameter to be the same as "this" so that you can do in-place modification.

For example:

Cartesian3.prototype.normalize()

becomes

Cartesian3.prototype.normalize(result)

If result is undefined, then we create a new instance. In either case, we return the result for easy chaining.

We should then revisit all of our existing code and make sure we are using private scratch objects and passing result parameters to eliminate all throw away objects.

I know we originally thought we might want static versions of all of our methods as well, but if we follow the above strategy, that won't be necessary. I've done some of this work on the viewer branch (the minimum necessary to make it performant) but I (or someone else) should do a full refactor everywhere after that branch comes in.

For KML and to help declutter scenes like the all airports.

Integrate code from @jktaylor -

https://groups.google.com/forum/#!topic/cesium-dev/cCqN91gjdW8

I tried adding some code to the keydown example handler in the 3D skeleton, but it never gets called.

Also, I think the "keydown" event provides raw key codes, which are different from ASCII codes and can vary depending on your locale's keyboard layout. The "keypress" event, which we do not support, provides ASCII codes, but does not fire for non-ASCII buttons like the function keys.

The following reference "seems" correct to me, but is un-official:
http://www.javascripter.net/faq/keycodes.htm
http://www.javascripter.net/faq/onkeypress.htm

The bigger question here is, what value does Cesium bring to keyboard processing? Is there any situation where our EventHandler could make things easier for the user, as opposed to telling them to register their own event callbacks on the canvas with the normal JavaScript methods?

• Browse to http://cesium.agi.com/CesiumViewer/
• When switching between 3D/2D/columbus view, we see tiles disappear. I assume this is due to incorrect occlusion culling.

When I set the polyline.width and polyline.outlineWidth, no matter what size I set, there is no noticeable difference. The sandbox examples don't even seem to be working. On the example for set interior and outline color, there should be a red outline, but all I see is the yellow line.

This seems to be the case both in chrome and firefox.

The DynamicConeVisualizerUsingCustomSensor requires CZML to define maximumClockAngle and outerHalfAngle. I would think if these are not specified, then they should default to CesiumMath.TWO_PI and Math.PI respectively.

While the performance improvement will probably be negligible, it's just good practice. Static instances should also handle the case where both parameters are undefined and prototype instances should check if the passed in object is undefined.

For example, createGuid and binarySearch both have documentation, but it does not show up in the JSDoc tree.

If you select an imagery source that uses the proxy, such as ArcGIS or OpenStreetMap, and for some reason the proxy server isn't configured where Cesium thinks it should be, Cesium enters an infinite loop of making repeated requests that issue 404 errors.

Ideally, it should fail gracefully, and attempt to use CORS locally, or at least stop issuing requests.

Hey guys, I am trying to get some things working in 2D mode that work fine in 3D.

If you paste this into the top of the sandbox example for "show cartographic position on mouse over", you'll see my problem.

transitioner = new Cesium.SceneTransitioner(scene);
transitioner.to2D();

First you'll notice that the sun shines only in the center. I can fix this by using the "affectedByLighting" flag in CentralBody which was added a couple of weeks ago, but the 2D map will be darker than it was in 3D.

My main problem is that scene.getCamera().pickEllipsoid no longer works. How do I get the cartographic position when in 2D?

Some ideas

1. Do it in screen space like how we fill cracks. Scissor out the projected bounding rectangle of the bounding sphere for the hole. Ray cast or stencil the ellipsoid, or use the alpha channel. When shading, still use the geodetic ellipsoid surface normal.
2. Render a low-resolution globe under the actual globe. Render it second for early-z.
3. Render low-resolution geometry for just the poles under-lapped a bit to avoid cracking.
4. Create tiles with a 1x1 white texture

I suggest 1. It's fragment load is higher than the others, but I expect the visual quality to be the best.

• Run the Sandbox.
• Select Apply a checkerboard material.
• Zoom in and look north towards the horizon. You can zoom forward and back.
• Rotate so you are looking south. You can only move left or right; not forward or back.

If you don't select Apply a checkerboard material, everything works. Perhaps the Sandbox zoom code is incomplete or exposing a camera bug?

If the Cesium canvas is hidden (for example with display:none), a DeveloperError is thrown.

In CentralBody.js, CentralBody.prototype.update, there's a line that says:

width = context.getCanvas().clientWidth;

This gets value 0 for width and height (on the following line). It then attempts to call context.createTexture2D with zero size, and the DeveloperError is thrown.

Cesium should be able to hide and reveal itself without throwing errors.

Look at any of our examples that use moving labels, such as http://cesium.agi.com/CesiumViewer/index.html?source=gallery/simple.czm&play=1&loop=1 You'll notice that the Label flickers as it moves. I'm pretty sure this is because it's not aligning the text to pixels. I'm not sure if this should be an option, or if Labels should always snap to pixels to avoid this type of artifact.

Turning off the sky atmosphere after adding a sensor changes the CentralBody's center to the apex of the sensor.
Add this line to the end of any sensor example in the Sandbox:

primitives.getCentralBody().showSkyAtmosphere = false;

The current implementation of JulianDate.createFromIso8601 uses Date.parse which according to ECMAScript 5 supports ISO8601 dates. This has two major problems:

1. ISO8601 supports fractional milliseconds but Date is only accurate to the millisecond, so any conversions with fractional milliseconds are rounded and less accurate.
2. ISO8601 and JulianDate both support leap seconds, but Date does not; called Date.parse with a leap second generates an invalid date.

The solution is to simply re-implement createFromIso8601 ourselves, making sure we handle all valid date specifications. This eliminates the middle-man Date approach and maintains accuracy and leap seconds. I've added a test to Core/JulianDateSpec.js, "Construct a date from ISO8601 on a leap second.", which is currently ignored with xit that shows the problem.

Check the Skeleton2D, which now has key handlers to morph between modes. After starting in 2D by calling .to2D, morphs to 3D or Columbus View don't load imagery after zooming. If you take out the call to .to2D, imagery works after morphing. It looks like SceneTransitioner has logic in morphTo2D/3D/etc that is absent from the non-morphing to2D/3D/etc.

When the camera's transform is constantly change, e.g., for TEME to psuedo-fixed as discussed on the mailing list, camera control becomes difficult. @bagnell believes we need to convert to world coordinates inside the camera when computing the view matrix.

We should also add support for spinning the globe, i.e., putting the viewer in TEME, perhaps by adding computeTemeToPseudoFixedMatrix to Transforms, where it lived once before.

Need to re-think the mouse controls in Columbus View so that a user who doesn't know fancy shift-key tricks can still get around and see all sides of the patent-pending Columbus map. There should be a set of controls in CesiumWidget for navigating this view, but ideally just "mousing around" without the keyboard should get you to the coolest and most interesting views.

• Turn on/off polygon lighting
• Fix lighting in 2D and columbus view when the light is at the viewer location.

We haven't implemented techniques like http://blogs.agi.com/insight3d/index.php/2008/09/03/precisions-precisions/ yet. Since we are starting to see some artifacts, we should implement them soon. In particular, rectangular sensors with a large non-infinite radius have artifacts on AMD. I'm not 100% convinced that this artifact is caused by jittering, but it's my current best guess. Clipping the sensors to the view volume or taking a closer look at the fragment shader precision may also fix the problem.

Including translucency for each layer, and overall z-order. Let's discuss more before implementing.

Use a png with alpha info for the texture on the diffusemap material. When it's displayed on Cesium, the image has no transparency.

Here's one I'm having issues with.
http://ccmc.gsfc.nasa.gov/ccmc-google_earth/FokRC_e-_precip.png