Terrain servlet question

[mortac8]

We are trying to make our own independent Terrain servlet (we use JBoss).  We tried just making a fairly simple proxy that uses the encodeHeightFloatsAsIntegers method but it fails on the client side.  Also, in the Chrome debugger, the terrain tile shows up as a broken image however if we copy the exact link address and paste that URL into a new tab, we get the image that's needed.

Do you have any ideas what the problem is?  Why did you guys need to use HttpExchange and Continuation in your TerrainTranscodingHandler?  Is that where we're going wrong do you think?  

Any ideas are appreciated!  Thanks!

[Kevin Ring]

Hi Ashley,

My first guess is that you're running into a CORS problem.  Is your terrain servlet running on a different hostname or different port from the HTML page that is hosting Cesium?  If so, the image requests are considered cross-origin requests, and the terrain servlet has to allow this scenario by including a CORS header.  This is a WebGL requirement.  You should see a message about a cross-origin failure in the Chrome debug console if this is the case.  

For  information about enabling CORS, see here: http://enable-cors.org/

Kevin

[Kevin Ring]

Actually, since you're using JBoss, this is probably what you need to enable CORS:

http://software.dzhuvinov.com/cors-filter-installation.html

[mortac8]

I can try that but our ProxyServlet is pretty much the same as the one we use to serve our normal map tiles to Cesium.  Our servlet(http://localhost/map/terrain/) is running on the same server that serves our Cesium globe(http://localhost/map/map.html).

http://localhost:8445/map/terrain/?http%3A%2F%2Fgeoapp%2FArcGIS%2Frest%2Fservices%2Fsrtm250mNE%2FImageServer%2FexportImage%3Fformat%3Dtiff%26f%3Dimage%26size%3D64%252C64%26bboxSR%3D4326%26imageSR%3D3857%26bbox%3D-1.4285714285714286%252C-85.7261377383765%252C181.42857142857144%252C0.6750089585698936 

[Scott Hunter]

The HttpExchange and Continuation stuff is all from Jetty, which is the embedded web server that we use for convenience.  We could have used the regular Java Servlet API, which Jetty supports too, but at the time I had an easier time combining all the handlers together if I stuck with the lower-level Jetty API.  The Continuation code is because it's an asynchronous API, which means threads can be yielded while the IO is blocked on the ArcGIS server.  

None of that is really necessary, so your approach should work.  A plain servlet should be fine, and you can use any API to make the request to ArcGIS and download the TIFF as a byte stream for use with encodeHeightFloatsAsIntegers.

I think Kevin is right to suspect CORS failures, especially if the images display correctly if you go directly to the URL in a new tab.  Keep in mind that a different port number counts as a different origin too.

--
You received this message because you are subscribed to the Google Groups "cesium-dev" group.
To view this discussion on the web visit https://groups.google.com/d/msg/cesium-dev/-/gqvdUT8fQb0J.
To post to this group, send email to cesiu...@googlegroups.com.
To unsubscribe from this group, send email to cesium-dev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/cesium-dev?hl=en.

[mortac8]

Thanks again for the quick reply!  I will play with the CORS settings and see if that helps.

Note that the URL which fails in my Network tab yet works when pasted directly into the URL bar is going through our servlet both times.

http://localhost:8445/vega/terrain/?http%3A%2F%2Fgeoapp%2FArcGIS%2Frest%2Fservices%2Fsrtm250mNE%2FImageServer%2FexportImage%3Finterpolation%3DRSP_BilinearInterpolation%26format%3Dtiff%26f%3Dimage%26size%3D64%252C64%26bboxSR%3D4326%26imageSR%3D3857%26bbox%3D-1.4285714285714286%252C-0.6750089585698935%252C181.42857142857144%252C85.72613773837648 

[Jonah Taylor]

Hey guys, we are still not having much luck with this.  Our original problem with chrome not downloading the terrain images was because it had an issue with the response header.  I can now see terrain images coming through our servlet just fine, however we still get a black globe.  Everything is being run from the same host and port, so it does not seem like it could be a CORS problem.  I have also tried disabling web security in chrome and using a plugin in firefox called force cors and still get a black globe.

Chrome is giving us this error, but the firefox console shows no problems.

Tile 0, 0, 0 UDiff: 2.220446049250313e-16 VDiff: 0.28682304967257977 Cesium.js:54615

Tile 0, 1, 0 UDiff: 2.220446049250313e-16 VDiff: 0.28682304967258015 Cesium.js:54615

3GL ERROR :GL_INVALID_OPERATION : glDrawElements: attempt to access out of range vertices in attribute 0 map.html:1

Tile 1, 1, 0 UDiff: 2.220446049250313e-16 VDiff: 0.28682304967258015 Cesium.js:54615

7GL ERROR :GL_INVALID_OPERATION : glDrawElements: attempt to access out of range vertices in attribute 0 map.html:1

WebGL: too many errors, no more errors will be reported to the console for this context. map.html:1

Tile 1, 0, 0 UDiff: 2.220446049250313e-16 VDiff: 0.28682304967257977 Cesium.js:54615

Tile 0, 3, 1 UDiff: 2.7755575615628914e-16 VDiff: 0.1854728848111637 Cesium.js:54615

Tile 0, 0, 1 UDiff: 2.7755575615628914e-16 VDiff: 0.18547288481116297 Cesium.js:54615

Tile 1, 1, 1 UDiff: 2.220446049250313e-16 VDiff: 0.11632959717291691 Cesium.js:54615

Tile 0, 2, 1 UDiff: 2.7755575615628914e-16 VDiff: 0.11632959717291708

Any thoughts on what could be going wrong here?  I am going to get our servlet version running in the development setup and will be posting that shortly.  Thanks in advance for your help. 

[Kevin Ring]

Hi Jonah,

I'm not sure what's going on, but I can suggest some ways to start debugging it.

If you haven't already, make sure that the Chrome debugger is configured to stop on all exceptions, not just handled ones.

First, make sure you're getting to the transformGeometry function in ArcGisImageServerTerrainProvider.  If you are, that means the image is being retrieved successfully.  Then, stop in the HeightmapTessellator in the web worker.  It loops over the heightmap and creates vertices for each height.  Make sure that the heights are as you expect.  If all that looks good, let me know and I can suggest some next steps.

Kevin

[Jonah Taylor]

Hey Kevin, I can step through and see vertices data coming back from the vertices promise.  When I tell the chrome debugger to break on all errors, the webgl errors still go right through.

I have verified that our terrain servlet works fine in the cesium dev environment in the siggraph_demo_esri_terrain branch.  Terrain tiles from our arcgis server work fine on this branch, but we get the black globe on the imagery layers branch which seems the most up to date and the most in sync with our code.  I guess I am going to try to pull in old pieces of ArcGisImageServerTerrainProvider from the demo branch until I see the problem go away since I cannot debug the webgl errors.  Do you have any other ideas to check? 

[Kevin Ring]

Are you using ArcGisImageServerTerrainProvider?  Or your own custom terrain provider based on it?  

--

You received this message because you are subscribed to the Google Groups "cesium-dev" group.

To view this discussion on the web visit https://groups.google.com/d/msg/cesium-dev/-/vzWUyroBTNAJ.

[Jonah Taylor]

Just using the ArcGisImageServerTerrainProvider. 

[Scott Hunter]

Try setting setThrowOnWebGLError to true on the context.  If you have a Scene, you can do: 

scene.getContext().setThrowOnWebGLError(true); 

in your setup code.  This will slow things down a lot, but I think it make it throw a JS exception when the GL error occurs, which might help track it down.

To view this discussion on the web visit https://groups.google.com/d/msg/cesium-dev/-/DTfq7OzV3J4J.

[Jonah Taylor]

Thanks for the input Scott.  That did make the debugger stop on the error, but I am not sure if that helps.

function throwOnError(gl, glFunc, glFuncArguments) {

var error = gl.getError();

if (error !== gl.NO_ERROR) {

throw new RuntimeError(_createErrorMessage(gl, glFunc, glFuncArguments, error));

}

}

The console says:

Visited 1 Rendered: 1 Culled: 0 Needed: 1 Max Depth: 0 Cesium.js:58327

GL ERROR :GL_INVALID_OPERATION : glDrawElements: attempt to access out of range vertices in attribute 0

I ended up cloning a new repo and pulling in a fresh build of the imagery branch into our application, but still the same error. Even when I use you guys' new proxyless terrain server, I still get this error. Were you able to get Terrain Scott when you modified the Skeleton to run stand alone? That's what I am about to check out next.

[Jonah Taylor]

Part of my response looks like it cut off, but shows up in the reply.  Trying again...

Even when I use you guys' new proxyless terrain server, I still get this error. Were you able to get Terrain Scott when you modified the Skeleton to run stand alone? That's what I am about to check out next.  

[Scott Hunter]

When you get the JS exception, can you copy/paste the full stack trace?  In Chrome, you should be able to expand the triangle for the exception in the console after it's thrown to see the entire stack trace.

Other than that, if you're seeing the same error with the TileMapServiceTerrainProvider accessing the pre-tiled files from cesium.agi.com, that rules out any problems with your servlet.

What video card are you using?  Are the drivers up to date?  I'm not seeing those errors on a 9800GT on Win7 and a Radeon 6630M on OS X 10.7.

[Jonah Taylor]

I got it by modifying the skeleton to run standalone.  And I found that somehow my version of createVerticesFromHeightmap.js was missing this part.  I guess that's what I get for picking up the branch while it is still in work.

var arrayWidth = parameters.width;

        var arrayHeight = parameters.height;

        if (parameters.skirtHeight > 0.0) {

            arrayWidth += 2;

            arrayHeight += 2;

        }

        var vertices = new Float32Array(arrayWidth * arrayHeight * 5);

where before it was just

var vertices = new Float32Array(parameters.width * parameters.height * 5);

[Jonah Taylor]

Thanks guys for your suggestions and help.  That was a tough one to track down along with the proxy servlet headers problem.