Hi,
Just wondering how to derive lat/long from within CentralBodyVS.glsl in a way that works in 2d, Columbus & 3d? I have tried a few things but with no success. I had thought it might be something along the lines of…
mix(u_tileExtent.st, u_tileExtent.pq, vec2(textureCoordinates.x, textureCoordinates.y))
But I assume this isn’t working due to the modified model view matrix.
Thanks,
Chris
p.s. How has AGI fared with the hurricane?
Hi Chris,
There’s not any reliable way to do this with the current vertex shader. In general, we tend to get precision / jittering problems when zoomed in close anytime we try to work with geographic coordinates in shaders, so we avoid it. But if that’s not a problem in your case, you can easily change CentralBodySurface to pass the geographic coordinates of the southwest corner of the terrain tile to the shader as a uniform. Then, add the result of the mix line you mentioned below to that southwest corner to compute the geographic position of the current vertex.
If you can tell me a little more about what you plan to do with the geographic coordinates, I may be able to recommend a more robust solution. If you’ll allow me a shameless plug, Patrick Cozzi and I wrote a book, 3D Engine Design for Virtual Globes, that has a couple of chapters with a pretty good discussion of some of the problems (and solutions) that come with rendering planet-sized scenes on single-precision GPUs.
AGI weathered the hurricane without too much incident, though lots of folks still don’t have power. Are you located anywhere near the east coast?
Kevin
Thanks Kevin,
I’m on the east coast, but of Australia (Sydney). I was watching the hurricane on the Cesium imagery layers example though and thinking it might be over where you are located.
I think the technique you mention should be fine for now. I’m just revisiting the geometry push as per the image I posted in another thread [0]. As well as the push down it now reveals an imagery layer instead of the red. As it’s all shader based the user can interactively shift the edge. I’d like to still support the imagery layer reveal in the 2d views as well so that’s the reason for the query. For now the edge is a straight line, but in the future I might support an extent or even poly so would prefer to work in geographic coords.
Cheers,
Chris
[0] https://groups.google.com/d/msg/cesium-dev/TPiWWF8TNdM/_cmec2KnrxwJ
I got something working by passing through the full tile extent as a uniform vec4 and blending in the vertex shader. It’s working fine in all views with the default projection. However if I change to a WebMercatorProjection for 2d it fails.
At the moment within CentralBodySurface.js tile loop I’m just doing…
realTileExtent.x = tile.extent.west;
(etc)
I notice there’s some special treatment of 2d WebMercatorProjection in CentralBodySurface.js so tried doing something similar but no go. The thing that’s confusing me is that I’m currently only using east/west values so thought there’d be no special handling required for the alternate 2d projection.
Thanks,
Chris
Sorry my bad. The above works fine in all views. Apologies for the noise…