big one

[kedzie]

-Implemented configurable view limits on all axis. This can restrict user from moving camera outside a geographic sector -Animation framework for camera position or object positions. Allows animated transition from perspective to overhead views, similar to the Trimble demo -Per-frame statistics framework -status bar showing network status and map position -Configurable Layer opacity. Any layer can be rendered semi-transparently -Geographic calculation functionality -Debug rendering of bounding volumes -Texture mip map loading -Multitexture support -Fixed perspective viewing frustrum to allow view to zoom in closer and render from lower altitudes. -Fixed 2-finger scale gesture detector to allow smooth zooming into low altitudes -Fixed view pitch rotation so that camera does not go underground in perspective views -Implemented a configurable Horizon distance modifier, which can control how far into the horizon the imagery is rendered while in perspective view. -Implemented on-the-fly ETC1 Texture Compression support (with Alpha channel) when loading uncompressed imagery from datasource -Implemented pre-compression of imagery data as it is downloaded from WorldWind data server. This saves the imagery to internal memory cache in ETC1 format (with Alpha channel) which saves storage space and loading time. -Added automatic clocked-rendering mode in addition to the existing on-request rendering mode. Each frame is automatically scheduled using a configurable frame-rate. This results in smoother animation and position updates. -surfaceshape and prerendering infrastructure -pick frustruma.

[nicastel]

Wow... impressive!

[ndorigatti]

Thats really impressive guys. Thank you both for the huge contribution. We have some pulls to perform on the repo too and this merge will be a huge but impressive work. O think that this is the most important week for world wind android SDK!

Sent from my Nexus 4 Il 23/mag/2014 19:56 "nicastel" notifications@github.com ha scritto:

Wow... impressive!

— Reply to this email directly or view it on GitHubhttps://github.com/TrilogisIT/WorldWind_Android/pull/6#issuecomment-44041343 .

[ndorigatti]

Hi @kedzie I'm trying to merge all the things to a new branch but I have some issues, for example in the class: SurfaceTileDrawContext there is a reference to "Rectangle" which cannot be found. this class seems to be needed in the method: computeEdgeIntervalsPerDegree of AbstractSurfaceShape I did manage most of the other errors, but this remains here. I've created a raw inner class that emulates "awt.Rectangle" but i'd like to know your point.

Last error that i can't fix is in the application, the CustomBox class points to: R.raw.abstractshapevert, R.raw.abstractshapefrag which are neither in the library, nor in the application.

I'll push the new branch in a few minutes, so you (and nicastel) can also compare the different repos.

[kedzie]

I wasn't compiling the sample at all sorry.. I haven't looked at that. I use Android.graphics.Rect. let me look at compilation issues and repost. On May 25, 2014 3:16 PM, "Nicola Dorigatti" notifications@github.com wrote:

Hi @kedzie https://github.com/kedzie I'm trying to merge all the things to a new branch but I have some issues, for example in the class: SurfaceTileDrawContext there is a reference to "Rectangle" which cannot be found. this class seems to be needed in the method: computeEdgeIntervalsPerDegree of AbstractSurfaceShape I did manage most of the other errors, but this remains here. I've created a raw inner class that emulates "awt.Rectangle" but i'd like to know your point.

Last error that i can't fix is in the application, the CustomBox class points to: R.raw.abstractshapevert, R.raw.abstractshapefrag which are neither in the library, nor in the application.

I'll push the new branch in a few minutes, so you (and nicastel) can also compare the different repos.

— Reply to this email directly or view it on GitHubhttps://github.com/TrilogisIT/WorldWind_Android/pull/6#issuecomment-44144349 .

[kedzie]

was nicastle pushing etc1 compression? how is merging gonna go? my etc1 code supports alpha channel (etc1 format is rgb) stored in a separate texture, and also loading mipmaps from filesystem. it can compress while downloading if u set the texture format to pkm in a tile layer and file extension to pkm. I intended on updating the sample to show this working but didnt, it also stores the alpha channel if tile layer uses transparency. I'm not sure what the other user added for etc1. On May 25, 2014 3:16 PM, "Nicola Dorigatti" notifications@github.com wrote:

Hi @kedzie https://github.com/kedzie I'm trying to merge all the things to a new branch but I have some issues, for example in the class: SurfaceTileDrawContext there is a reference to "Rectangle" which cannot be found. this class seems to be needed in the method: computeEdgeIntervalsPerDegree of AbstractSurfaceShape I did manage most of the other errors, but this remains here. I've created a raw inner class that emulates "awt.Rectangle" but i'd like to know your point.

Last error that i can't fix is in the application, the CustomBox class points to: R.raw.abstractshapevert, R.raw.abstractshapefrag which are neither in the library, nor in the application.

I'll push the new branch in a few minutes, so you (and nicastel) can also compare the different repos.

— Reply to this email directly or view it on GitHubhttps://github.com/TrilogisIT/WorldWind_Android/pull/6#issuecomment-44144349 .

[ndorigatti]

@kedzie ,thank you. If you can push onto the "keidze-master" branch it would be easier to merge.

We are now dealing with alpha channel for ETC1 and Opacity, despite our ETC1 and Alpha textures are ok (alpha channel is data with greyscale coloring), we have some issues showing the texture, it seems to be always half transparent (even with opacity to 1) and the black color from the textures is not shown (or is too transparent). Do you know what could be the problem? I think is something messed up by my colleague in the usage of frag functions, i think you are serializing the usage of fragment functions, right?

We did some tests with mipmaps but it showed a slow down in general, probably your implementation deals better with them, we will try it.

About the compression on the go, I have to check better the code, but I think I will propose a change; we should add a new parameter in layers xml that indicates the "download format" or "download mime" for layers. If not specified or the same as "texture format", we will work as before (no compression, no changes, just write the texture as it is downloaded). If it is different, data will be downloaded in "download format" and compressed to "texture format" on the fly. This will allow to download data from a server which already provides PKM/ETC1 Data (see @nicastel work on a geoserver plugin and the android usage of it). This can improve a lot the performances while downloading data (less data to download, no time to recompress downloaded data if it is done serverside).

I Suggest you to take into account and look at @nicastel "texture-compression" project, he has done and benchmarked texture compression on the fly (from JPEG) on android, comparing SDK,Java and Renderscript performance. As you can see, renderscript is very fast and could be used also by you to compress textures. Let me know what you think.

We did instead on a pure Desktop (Swing) application the conversion from a PNG file (or BufferedImage) to a PKM+Alpha. This Code will be available in a few days (I hope) and is a swing application that uses a modified version of Desktop WorldWind SDK.

I also did a look on some of your classes that I don't know how to use (or if they are automatically used), like WorldWindImpl, the GLTextRenderer and others. It would be useful to have some short description of them.

[kedzie]

i used mali texture compression tool.

the texture formats work just like u described. there is extension property which controls how tiles are saved. textureformat property controls how it is loaded. it only compresses if data is uncompressed, otherwise saves directly.

i added layer opacity functionality.

about black transparency, that is done in abstractsownloadretriever i think. image postprocessing converts a color to transparency.

all my compression code uses etc1util which is native c++.

@kedzie https://github.com/kedzie ,thank you. If you can push onto the "keidze-master" branch it would be easier to merge.

We are now dealing with alpha channel for ETC1 and Opacity, despite our ETC1 and Alpha textures are ok (alpha channel is data with greyscale coloring), we have some issues showing the texture, it seems to be always half transparent (even with opacity to 1) and the black color from the textures is not shown (or is too transparent). Do you know what could be the problem? I think is something messed up by my colleague in the usage of frag functions, i think you are serializing the usage of fragment functions, right?

We did some tests with mipmaps but it showed a slow down in general, probably your implementation deals better with them, we will try it.

About the compression on the go, I have to check better the code, but I think I will propose a change; we should add a new parameter in layers xml that indicates the "download format" or "download mime" for layers. If not specified or the same as "texture format", we will work as before (no compression, no changes, just write the texture as it is downloaded). If it is different, data will be downloaded in "download format" and compressed to "texture format" on the fly. This will allow to download data from a server which already provides PKM/ETC1 Data (see @nicastelhttps://github.com/nicastelwork on a geoserver plugin and the android usage of it). This can improve a lot the performances while downloading data (less data to download, no time to recompress downloaded data if it is done serverside).

I Suggest you to take into account and look at @nicastelhttps://github.com/nicastel"texture-compression" project, he has done and benchmarked texture compression on the fly (from JPEG) on android, comparing SDK,Java and Renderscript performance. As you can see, renderscript is very fast and could be used also by you to compress textures. Let me know what you think.

We did instead on a pure Desktop (Swing) application the conversion from a PNG file (or BufferedImage) to a PKM+Alpha. This Code will be available in a few days (I hope) and is a swing application that uses a modified version of Desktop WorldWind SDK.

I also did a look on some of your classes that I don't know how to use (or if they are automatically used), like WorldWindImpl, the GLTextRenderer and others. It would be useful to have some short description of them.

— Reply to this email directly or view it on GitHubhttps://github.com/TrilogisIT/WorldWind_Android/pull/6#issuecomment-44192885 .

[kedzie]

i dont know what u mean about frag functions. but the black is converted to transparent in tiles. i combine the rgb and alpha textures using a fragment shader. i do that in world map and compass layers. anyway, if all nicastel did is etc1 i would suggest taking anything he has done better and add/replace to my etc1 code. as my other changes basically cover the entire project.

as far as your other questions

worldwindowimpl is used as main worldwindow functionality. it is extended by gltextureview and glsurfaceview classes. the text renderer renders text...

i should update the sample to show some functionality like the apk i sent u. including the clocked rendering that runs lot smoother than the old render when dirty .

ill pusg again the compile fixes and pribably a working sample. i planned on packagimg the rajawali stuff as an external plugin, what u think¿ On May 26, 2014 5:29 PM, "Marek Kedzierski" mark.kedzierski@gmail.com wrote:

i used mali texture compression tool.

the texture formats work just like u described. there is extension property which controls how tiles are saved. textureformat property controls how it is loaded. it only compresses if data is uncompressed, otherwise saves directly.

i added layer opacity functionality.

about black transparency, that is done in abstractsownloadretriever i think. image postprocessing converts a color to transparency.

all my compression code uses etc1util which is native c++.

@kedzie https://github.com/kedzie ,thank you. If you can push onto the "keidze-master" branch it would be easier to merge.

We are now dealing with alpha channel for ETC1 and Opacity, despite our ETC1 and Alpha textures are ok (alpha channel is data with greyscale coloring), we have some issues showing the texture, it seems to be always half transparent (even with opacity to 1) and the black color from the textures is not shown (or is too transparent). Do you know what could be the problem? I think is something messed up by my colleague in the usage of frag functions, i think you are serializing the usage of fragment functions, right?

We did some tests with mipmaps but it showed a slow down in general, probably your implementation deals better with them, we will try it.

About the compression on the go, I have to check better the code, but I think I will propose a change; we should add a new parameter in layers xml that indicates the "download format" or "download mime" for layers. If not specified or the same as "texture format", we will work as before (no compression, no changes, just write the texture as it is downloaded). If it is different, data will be downloaded in "download format" and compressed to "texture format" on the fly. This will allow to download data from a server which already provides PKM/ETC1 Data (see @nicastelhttps://github.com/nicastelwork on a geoserver plugin and the android usage of it). This can improve a lot the performances while downloading data (less data to download, no time to recompress downloaded data if it is done serverside).

I Suggest you to take into account and look at @nicastelhttps://github.com/nicastel"texture-compression" project, he has done and benchmarked texture compression on the fly (from JPEG) on android, comparing SDK,Java and Renderscript performance. As you can see, renderscript is very fast and could be used also by you to compress textures. Let me know what you think.

We did instead on a pure Desktop (Swing) application the conversion from a PNG file (or BufferedImage) to a PKM+Alpha. This Code will be available in a few days (I hope) and is a swing application that uses a modified version of Desktop WorldWind SDK.

I also did a look on some of your classes that I don't know how to use (or if they are automatically used), like WorldWindImpl, the GLTextRenderer and others. It would be useful to have some short description of them.

— Reply to this email directly or view it on GitHubhttps://github.com/TrilogisIT/WorldWind_Android/pull/6#issuecomment-44192885 .

[ndorigatti]

@kedzie : you used mali texture compression, and it seems it converts them as we do, i try yo attach the textures converted to PNGs to show you.

Here as you can see, in the alpha PNG there is in white what to draw, but then the texture is shown with all the black pixel as transparent, and we dont want them to be transparent. We want to be transparent only the pixels that are black in the alpha, without knowing the RGB value of the normal texture (first picture, green). I've also noticed that adding alpha file for textures, makes all the texture to be semi transparent even if the layer opacity is set to 1. Probably we should send you some screenshot to better understand what happens. Do you know if we can change the "black pixel transparent" behavior? I had a look at the fragment shader used for that but did not find references to black pixels.

Nice you've already used the two values for saving/downloading data, I'll use it! We are trying to use layer opacity but something seems to be not so nice to see. In your apk example sent, the compass is not showing, so i dont know if is an application error or library problem...

I wrote the wrong class, i meant the WorldWindowGLTextureView.. It would be nice (but this is for our knowledge) to have a short explanation to the two rendering modes you have introduced (probably a new issue here on github?)

I do think that the rajawali stuff is well to be added as external plugin until WW can run even without it (at least basic functionalities)

[nmeneghini]

Hi, @kedzie I tried your code and there are many fantastic features but I found a problem that occurs when the tilt has a certain angle. First, you see a small part of world(Look the screenshots), I think it's caused by the far clip distance too small.

Then the view is shaking (it seems to keep changing the tilt) when you touch the screen and get this error:

05-28 17:29:22.374: E/gov.nasa.worldwind(10022): Clip distances near=7,363.57 and far=6,109.002 are invalid 05-28 17:29:22.379: E/gov.nasa.worldwind(10022): Exception while drawing WorldWindow 05-28 17:29:22.379: E/gov.nasa.worldwind(10022): java.lang.IllegalArgumentException: Clip distances near=7,363.57 and far=6,109.002 are invalid 05-28 17:29:22.379: E/gov.nasa.worldwind(10022): at gov.nasa.worldwind.geom.Matrix.setPerspective(Matrix.java:1808) 05-28 17:29:22.379: E/gov.nasa.worldwind(10022): at gov.nasa.worldwind.BasicView.applyProjectionMatrix(BasicView.java:332) 05-28 17:29:22.379: E/gov.nasa.worldwind(10022): at gov.nasa.worldwind.BasicView.apply(BasicView.java:316) 05-28 17:29:22.379: E/gov.nasa.worldwind(10022): at gov.nasa.worldwind.SceneController.applyView(SceneController.java:393) 05-28 17:29:22.379: E/gov.nasa.worldwind(10022): at gov.nasa.worldwind.SceneController.doDrawFrame(SceneController.java:326) 05-28 17:29:22.379: E/gov.nasa.worldwind(10022): at gov.nasa.worldwind.SceneController.drawFrame(SceneController.java:296) 05-28 17:29:22.379: E/gov.nasa.worldwind(10022): at gov.nasa.worldwind.WorldWindowGLSurfaceView.drawFrame(WorldWindowGLSurfaceView.java:227) 05-28 17:29:22.379: E/gov.nasa.worldwind(10022): at gov.nasa.worldwind.WorldWindowGLSurfaceView.onDrawFrame(WorldWindowGLSurfaceView.java:164) 05-28 17:29:22.379: E/gov.nasa.worldwind(10022): at android.opengl.GLSurfaceView$GLThread.guardedRun(GLSurfaceView.java:1523) 05-28 17:29:22.379: E/gov.nasa.worldwind(10022): at android.opengl.GLSurfaceView$GLThread.run(GLSurfaceView.java:1240)

You have already found this error?

[kedzie]

So a couple of things here. I haven't seen a far clip that drastic on my end.. Only thing I can think of is that I put a multiplier in on the far clip distance (for performance). If that is set to 1 you should have normal far clip distance. It is in the BasicView class, in the APK I sent u it is set in the options. There is also a commented line in the BasicView computeFarClipDistance method, I experimented with using 2 methods for calculating the horizon distance, one is using the elevation above sea-level, and another is using elevation above the ground. I think currently it is using the ground elevation. The WorldWindJava calculates both and uses Math.max. I can make that change and push it when I push my other changes later.

I see in the error that the near clip distance is bigger than the far distance, could be a multiplier problem. Near clip distance should never be wrong because it uses that actual measured distance from the eye point to the point on the ground the camera is focused on. So you should never see near clipping, as I never did.

I'm not sure why the compass wasn't in the apk I sent u, unless the device you are running on doesn't support ETC1. I made the compass and worldmap layers use etc1 images, but they should fallback to PNG if etc1 not supported, but I haven't tested the fallback functionality.

I have to admit I haven't tested layer opacity thoroughly, but if you look in the shaders, there is a uniform value that gets set to layer opacity that value is combined with the uniform/vertex colors to get a final fragment color. Layer opacity has nothing to do with the black transparency..

As for the black pixle transparency, that is not in a shader. It was existing code in the AbstractDownoadPostProcessor I think. It post-processes the pixels in an image. It takes the useTransparency, and transparentColor properties from layers (not the exact names, but something similar) and processes the downloaded image replacing pixels that are the transparent color with 0 alpha. This is to handle RGB tiles which are supposed to support transparency. i.e. one color is used to represent transparency. The default is black.

On Wed, May 28, 2014 at 10:59 AM, Nicola Meneghini <notifications@github.com

wrote:

Hi, @kedzie https://github.com/kedzie I tried your code and there are many fantastic features but I found a problem that occurs when the tilt has a certain angle. First, you see a small part of world(Look the screenshots), I think it's caused by the far clip distance too small.

[image: screenshot_2014-05-28-17-28-16]https://cloud.githubusercontent.com/assets/7700001/3106875/ec72b7a2-e67f-11e3-83da-36cdedda0e98.png [image: screenshot_2014-05-28-17-28-54]https://cloud.githubusercontent.com/assets/7700001/3106876/ec751f9c-e67f-11e3-9e09-1ab1db272fbc.png

Then the view is shaking (it seems to keep changing the tilt) when you touch the screen and get this error:

05-28 17:29:22.374: E/gov.nasa.worldwind(10022): Clip distances near=7,363.57 and far=6,109.002 are invalid 05-28 17:29:22.379: E/gov.nasa.worldwind(10022): Exception while drawing WorldWindow 05-28 17:29:22.379: E/gov.nasa.worldwind(10022): java.lang.IllegalArgumentException: Clip distances near=7,363.57 and far=6,109.002 are invalid 05-28 17:29:22.379: E/gov.nasa.worldwind(10022): at gov.nasa.worldwind.geom.Matrix.setPerspective(Matrix.java:1808) 05-28 17:29:22.379: E/gov.nasa.worldwind(10022): at gov.nasa.worldwind.BasicView.applyProjectionMatrix(BasicView.java:332) 05-28 17:29:22.379: E/gov.nasa.worldwind(10022): at gov.nasa.worldwind.BasicView.apply(BasicView.java:316) 05-28 17:29:22.379: E/gov.nasa.worldwind(10022): at gov.nasa.worldwind.SceneController.applyView(SceneController.java:393) 05-28 17:29:22.379: E/gov.nasa.worldwind(10022): at gov.nasa.worldwind.SceneController.doDrawFrame(SceneController.java:326) 05-28 17:29:22.379: E/gov.nasa.worldwind(10022): at gov.nasa.worldwind.SceneController.drawFrame(SceneController.java:296) 05-28 17:29:22.379: E/gov.nasa.worldwind(10022): at gov.nasa.worldwind.WorldWindowGLSurfaceView.drawFrame(WorldWindowGLSurfaceView.java:227) 05-28 17:29:22.379: E/gov.nasa.worldwind(10022): at gov.nasa.worldwind.WorldWindowGLSurfaceView.onDrawFrame(WorldWindowGLSurfaceView.java:164) 05-28 17:29:22.379: E/gov.nasa.worldwind(10022): at android.opengl.GLSurfaceView$GLThread.guardedRun(GLSurfaceView.java:1523) 05-28 17:29:22.379: E/gov.nasa.worldwind(10022): at android.opengl.GLSurfaceView$GLThread.run(GLSurfaceView.java:1240)

You have already found this error?

— Reply to this email directly or view it on GitHubhttps://github.com/TrilogisIT/WorldWind_Android/pull/6#issuecomment-44427358 .

[kedzie]

question: why are you using a tool to compress surface tiles? I only used the mali tool to compress the WorldMap, Compass, and the Blue Margle surface image (which was dds). These images are all packaged as part of the code. For surface tiles the compression is done during the download, same as the existing code did when the WMS service gave PNG and layer file extension was set to DDS. Otherwise, if the saved data is PNG and textureformat is set to PKM/DDS, it compresses while loading the imagery. I wrote this exactly like WorldWindJava handled the compression.

All of the functionality I added, except for the rajawali models, was directly ported from WorldWindJava.

You asked about the Rajawali plugin. The Rajawali functionality is a RajawaliRenderableLayer and a RajawaliRenderable. The other WorldWind code is in no way dependent on Rajawali. That is why I suggested a plugin so we wouldn't have the dependency requirement. You may have noticed the pull request I sent doesn't have any Rajawali dependency.

-Mark

On Wed, May 28, 2014 at 1:16 PM, Marek Kedzierski <mark.kedzierski@gmail.com

wrote:

So a couple of things here. I haven't seen a far clip that drastic on my end.. Only thing I can think of is that I put a multiplier in on the far clip distance (for performance). If that is set to 1 you should have normal far clip distance. It is in the BasicView class, in the APK I sent u it is set in the options. There is also a commented line in the BasicView computeFarClipDistance method, I experimented with using 2 methods for calculating the horizon distance, one is using the elevation above sea-level, and another is using elevation above the ground. I think currently it is using the ground elevation. The WorldWindJava calculates both and uses Math.max. I can make that change and push it when I push my other changes later.

I see in the error that the near clip distance is bigger than the far distance, could be a multiplier problem. Near clip distance should never be wrong because it uses that actual measured distance from the eye point to the point on the ground the camera is focused on. So you should never see near clipping, as I never did.

I'm not sure why the compass wasn't in the apk I sent u, unless the device you are running on doesn't support ETC1. I made the compass and worldmap layers use etc1 images, but they should fallback to PNG if etc1 not supported, but I haven't tested the fallback functionality.

I have to admit I haven't tested layer opacity thoroughly, but if you look in the shaders, there is a uniform value that gets set to layer opacity that value is combined with the uniform/vertex colors to get a final fragment color. Layer opacity has nothing to do with the black transparency..

As for the black pixle transparency, that is not in a shader. It was existing code in the AbstractDownoadPostProcessor I think. It post-processes the pixels in an image. It takes the useTransparency, and transparentColor properties from layers (not the exact names, but something similar) and processes the downloaded image replacing pixels that are the transparent color with 0 alpha. This is to handle RGB tiles which are supposed to support transparency. i.e. one color is used to represent transparency. The default is black.

On Wed, May 28, 2014 at 10:59 AM, Nicola Meneghini < notifications@github.com> wrote:

Hi, @kedzie https://github.com/kedzie I tried your code and there are many fantastic features but I found a problem that occurs when the tilt has a certain angle. First, you see a small part of world(Look the screenshots), I think it's caused by the far clip distance too small.

[image: screenshot_2014-05-28-17-28-16]https://cloud.githubusercontent.com/assets/7700001/3106875/ec72b7a2-e67f-11e3-83da-36cdedda0e98.png [image: screenshot_2014-05-28-17-28-54]https://cloud.githubusercontent.com/assets/7700001/3106876/ec751f9c-e67f-11e3-9e09-1ab1db272fbc.png

Then the view is shaking (it seems to keep changing the tilt) when you touch the screen and get this error:

05-28 17:29:22.374: E/gov.nasa.worldwind(10022): Clip distances near=7,363.57 and far=6,109.002 are invalid 05-28 17:29:22.379: E/gov.nasa.worldwind(10022): Exception while drawing WorldWindow 05-28 17:29:22.379: E/gov.nasa.worldwind(10022): java.lang.IllegalArgumentException: Clip distances near=7,363.57 and far=6,109.002 are invalid 05-28 17:29:22.379: E/gov.nasa.worldwind(10022): at gov.nasa.worldwind.geom.Matrix.setPerspective(Matrix.java:1808) 05-28 17:29:22.379: E/gov.nasa.worldwind(10022): at gov.nasa.worldwind.BasicView.applyProjectionMatrix(BasicView.java:332) 05-28 17:29:22.379: E/gov.nasa.worldwind(10022): at gov.nasa.worldwind.BasicView.apply(BasicView.java:316) 05-28 17:29:22.379: E/gov.nasa.worldwind(10022): at gov.nasa.worldwind.SceneController.applyView(SceneController.java:393) 05-28 17:29:22.379: E/gov.nasa.worldwind(10022): at gov.nasa.worldwind.SceneController.doDrawFrame(SceneController.java:326) 05-28 17:29:22.379: E/gov.nasa.worldwind(10022): at gov.nasa.worldwind.SceneController.drawFrame(SceneController.java:296) 05-28 17:29:22.379: E/gov.nasa.worldwind(10022): at gov.nasa.worldwind.WorldWindowGLSurfaceView.drawFrame(WorldWindowGLSurfaceView.java:227) 05-28 17:29:22.379: E/gov.nasa.worldwind(10022): at gov.nasa.worldwind.WorldWindowGLSurfaceView.onDrawFrame(WorldWindowGLSurfaceView.java:164) 05-28 17:29:22.379: E/gov.nasa.worldwind(10022): at android.opengl.GLSurfaceView$GLThread.guardedRun(GLSurfaceView.java:1523) 05-28 17:29:22.379: E/gov.nasa.worldwind(10022): at android.opengl.GLSurfaceView$GLThread.run(GLSurfaceView.java:1240)

You have already found this error?

— Reply to this email directly or view it on GitHubhttps://github.com/TrilogisIT/WorldWind_Android/pull/6#issuecomment-44427358 .

[ndorigatti]

Hi @kedzie regarding the two answers: For far clipping, we'll look at it, for near clipping, we saw some of it, and seen that setting near clip to 0.01 removes it (altough i think is wrong setting it fixed). In the apk you sent compass is not available on Nexus 7 2012, Nexus 4 and Nexus 10 (that are all ETC1 capable), so don't know why... For the black pixels, it should not be there our problem since data is not downloaded on mobile but copied over from desktop, so the Download Post processor is never called... I've seen the uniform color somewhere and I think is that one that makes the sky all white (in our Gplay app sky is not a single color).

Response 2: We use a tool (custom) on desktop because we have a particular workflow: Users download GeoTiff from their sources, open our app, set bound limits and start the "create tiles" work, that creates a zip file with all the tiles for that layer/layers. Because the app needs to work Offline ONLY. We compress to ETC1 from desktop and not on-the-fly because it is way faster to load the texture directly than compressing it every time. I know desktop handles like this, but desktop has a lot of more power...

For Rajawali i dont know what could be better; Having in a plugin could lead to be an "unknown" feature, but having inside requires the Rajawali lib to be there always. Probably handling the project with android studio could help better...

[kedzie]

When you say "our app" I imagine you are making some application which uses WorldWind, as am I. I would imagine any custom workflow functionality should belong in the application end and keep the WorldWind library a generic WorldWind port; so it can be used by anyone. Are we on the same page?

as for the sky, it still uses vertex colors. the uniform color is option when using some shaders, it is used for Paths when vertex colors are not specified, for example.

I do use IntelliJ, I've never had a apklib which depends on another apklib, which we would need to do for Rajawali to be a dependency of the worldwind library. i'll try it though.

again I'll try to push my latest tomorrow, was busy doing other stuff today for work.

On Wed, May 28, 2014 at 2:59 PM, Nicola Dorigatti notifications@github.comwrote:

Hi @kedzie https://github.com/kedzie regarding the two answers: For far clipping, we'll look at it, for near clipping, we saw some of it, and seen that setting near clip to 0.01 removes it (altough i think is wrong setting it fixed). In the apk you sent compass is not available on Nexus 7 2012, Nexus 4 and Nexus 10 (that are all ETC1 capable), so don't know why... For the black pixels, it should not be there our problem since data is not downloaded on mobile but copied over from desktop, so the Download Post processor is never called... I've seen the uniform color somewhere and I think is that one that makes the sky all white (in our Gplay app sky is not a single color).

Response 2: We use a tool (custom) on desktop because we have a particular workflow: Users download GeoTiff from their sources, open our app, set bound limits and start the "create tiles" work, that creates a zip file with all the tiles for that layer/layers. Because the app needs to work Offline ONLY. We compress to ETC1 from desktop and not on-the-fly because it is way faster to load the texture directly than compressing it every time. I know desktop handles like this, but desktop has a lot of more power...

For Rajawali i dont know what could be better; Having in a plugin could lead to be an "unknown" feature, but having inside requires the Rajawali lib to be there always. Probably handling the project with android studio could help better...

— Reply to this email directly or view it on GitHubhttps://github.com/TrilogisIT/WorldWind_Android/pull/6#issuecomment-44456717 .

[ndorigatti]

Yes, when we say "our app" we intend our specific android application that uses the WorldWindAndroid library project. Now a first version of the app is available at: https://github.com/TrilogisIT/FAO_Application There is android and desktop application. Unfortunately, not all the workflow can belong to the application, because, for example, tiling data from GeoTIFF is impossible on an android device (the input data can be over 2gb per file). Anyway, the custom port is opensourced at the given link (it does not so much).

I hope to have the time to look at the sky class because in our code (before your Pull request) it is better looking (i dont like the full white so much); About this, we see far clip distance to be a bit reductive since looking at the whole world (our customer could look to the whole africa for example), you see about half of that black (on top). It was an addition with your code and i saw that in the apk you sent. In the desktop version this does not happen.

Thanks for your sharing and help.

[kedzie]

I haven't gotten to fixing my branch yet but I am still gonna do it and update the pull request. Maybe I broke the SkyGradient layer somehow, i wasn't paying attention to it. About the far distance, I updated my code to match the java version which will guarentee it never will be too short.

-mark

On Thu, May 29, 2014 at 6:54 AM, Nicola Dorigatti notifications@github.com wrote:

Yes, when we say "our app" we intend our specific android application that uses the WorldWindAndroid library project. Now a first version of the app is available at: https://github.com/TrilogisIT/FAO_Application There is android and desktop application. Unfortunately, not all the workflow can belong to the application, because, for example, tiling data from GeoTIFF is impossible on an android device (the input data can be over 2gb per file). Anyway, the custom port is opensourced at the given link (it does not so much).

I hope to have the time to look at the sky class because in our code (before your Pull request) it is better looking (i dont like the full white so much); About this, we see far clip distance to be a bit reductive since looking at the whole world (our customer could look to the whole africa for example), you see about half of that black (on top). It was an addition with your code and i saw that in the apk you sent. In the desktop version this does not happen.

Thanks for your sharing and help.

— Reply to this email directly or view it on GitHub https://github.com/TrilogisIT/WorldWind_Android/pull/6#issuecomment-44524211 .

[ndorigatti]

Ok, my colleague has moved to a strict deadline so he could not go far on the integration, but i hope he could take a look at sky gradient... I'll wait for your updates before changing anything on the repo

[ndorigatti]

@kedzie I think we found why layers are not rendered transparently when we have also the alpha pkm texture: the texture simply is not considered... In line 356 of "TiledImageLayer" there is the comment: // TODO: apply opacity and transparent texture support

And this is clearly a todo that needs to be done :) I've checked the compass (we manage to make it work with pkm with no modifications, probably your PKM could not be read (didn't dig on it). Anyway, the compass transparency is working even if we compress the PNGs with "our" compressor, so the problem is that the alpha texture for tiles is not applied. I've done a fast research of when the etc1alphafrag is used, and it is used Only in the compass and in the worldmap layers! So i think that the transparent tiles are allowed but not used, and should be included, but we are thinking if we should create a new specific frag+vert or concatenate the one there is now, and the etc1alphafrag. Did you already do it?

[ndorigatti]

@kedzie We managed to fix the support for pkm+alpha textures, and we also managed to make it work even if the alpha file is not there (so no exceptions, no problems), just using a different SurfaceTileRenderer for double tiles layers. We also fixed the skygrandientLayer, there was a boolean not set for uUseVertexColor (should be set to true). We also (maybe) fixed the frustum problem, I saw that you were doing the minimum height between eye eight and "near" height. That was working for almost perpendicular views, but for almost horizontal views, that lead to a farClipDistance too close to actual position. We also fixed the "touch to show" position, it was a missing call to the "computeRayFromScreenPoint" when converting screen point to coordinates. Now it is working nice!

I'm dealing with picking support now, that's a bad beast... If you have any improvement or change, feel free to comment!