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//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//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//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//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//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//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//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//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
#6 (comment)
.

[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!