Seems buggy...?

[Unregistered]

I downloaded WWJ two days ago, and it seems buggy to the point of being unusuable. Please excuse me if these have already been discussed elsewhere... I couldn't find it.

First, when I resize the demo window (either AWT1Up or BasicDemo) the image flickers back and forth between two sizes.

Secondly, when zooming way in to a location I haven't looked at before, it takes some time to download the new images (ok, that's fine) and then sometimes it crashes with no useful information.

I tried running it with the logger option, and it was constantly spooling out errors. Here are some:

FINE: Exception encountered while repainting
java.lang.NoSuchMethodError: com.sun.opengl.util.texture.Texture.upda teSubImage(Lcom/sun/opengl/util/texture/TextureData;IIIIIII)V
at com.sun.opengl.util.j2d.TextureRenderer. sync(TextureRenderer.java:661)
at com.sun.opengl.util.j2d.TextureRenderer. getTexture(TextureRenderer.java:293)
at com.sun.opengl.util.j2d.TextureRenderer. endRendering(TextureRenderer.java:600)
at com.sun.opengl.util.j2d.TextureRenderer. end3DRendering(TextureRenderer.java:535)
at com.sun.opengl.util.j2d.TextRenderer.end Rendering(TextRenderer.java:720)
at com.sun.opengl.util.j2d.TextRenderer.end 3DRendering(TextRenderer.java:605)
at gov.nasa.worldwind.PlaceNameRenderer.end DrawNames(PlaceNameRenderer.java:234)
...

May 17, 2007 11:46:35 AM gov.nasa.worldwind.BasicRetrievalService $RetrievalExecutor afterExecute
FINE: Execution exception during retrieval of http://worldwind25.arc.nasa.gov/lstile/lstile.aspx?T=esat_worlddds&L=5&X=4477&Y=1784 Read timed out

Anyone have any ideas?

Thanks

[withak]

My word, it sounds like you are using a bare-bones demo application of a pre-alpha SDK! :p

Anyway, the second error looks like a network problem and the first may be a result of that.

[Unregistered]

I agree... it does sound like some sort of networking problem, but I'm not sure exactly what. The networking obviously isn't totally screwed, since the textures do load properly for the most part, and I can zoom way in, but then sometimes it just doesn't work.

I'm puzzled...

[tag]

This looks like the machine you're using either has an old version of JOGL installed somewhere or the JVM doesn't meet the requirements. Please see the "Having Problems" section at http://worldwind.arc.nasa.gov/java and follow the instructions there.

[nlneilson]

Read timed out - I get this most of the time when tiles are being downloaded.
SDK 20070915 - - about 44Kbps is the max for my dialup connection

Tried increasing the time in KeyPollTimer.java but still have the "Read timed out" exception. Where can the time be set higher?

edit: in URLRetriever.java line 36: private int readTimeout = Configuration.getIntegerValue(AVKey.URL_ READ_TIMEOUT, 150000); //was 5000
Same problem.

WWJ runs fine.

[tag]

Setting the key polling timer won't help you. You'll need to edit config/worldwind.properties to specify a longer timeout. Set the URLConnectTimeout to some larger number than the current 8000 (milliseconds), and set theURLReadTimeout higher as well.

We've really not designed for dial-up connections.

[Chade]

I'm not sure that trying to run either WW.NET or WWJ over a dial-up connection is a good idea in the first place, too...

[what_nick]

As T_Servo will note WW.NET runs(barely) over dial-up and I have used it on very rare occasions with GPRS. With some serious tweaking it should be possible, may be we can supply ascii images :p

Cheers,
what_nick.

[TomServo]

WW.net does work on dialup, sluggish but it works. Now with WWJava if it works, I have not noticed.. if anything it downloads 10-20x's slower than WW.net.

[nlneilson]

Thanks Tag, changing the config/worldwind.properties makes it work. Maybe an If statement like If kbps<100 then URLReadTimeout = 150000; would make it so others could use it on dialup also. Changing the:
URLConnectTimeout=80000
RetrievalPoolSize=2
RetrievalQueueSize=20
RetrievalStaleRequestLimit=90
made it work for me. Some may not be necessary. Had to change the queue size in WW .NET before.

The download time is much longer also as TomServo pointed out. Some of the DigitalOrtho in WW .NET are as small as 30K in .jpeg format while all of the .dds seems to be 348K, hence the > 10 times as long.

I will convert my cache from WW that was all kept in the .jpeg format to the WWJ .dds format but it is good to be able to download directly in WWJ when necessary. Most of what I will be doing will be off line, did that with an Alt+o toggle and James_In_Utah made menu changes to work off line in WW .NET.

Thanks for the help.

[tag]

The dds images come across the wire gzipped, which deflates them 70-80% to something less than 100k. They generally also contain mipmaps and transparency. WWJ will download and save jpg (or png) if the layer is configured at start-up to do so. It will also download jpeg and png and convert it to dds on the client. You could try to minimize download times doing the latter or just storing jpg in the cache.

If you have a specific performance scenario in which you're seeing 30x less performance -- or even 10x -- I'd like to know what it is and investigate it.

[nlneilson]

I have not actually timed anything but on dialup at 40-45Kbps it takes about 4 minutes for a Meg.
Tinkering a bit found LoggingControl.java where the download exceptions can be watched on the console panel in Eclipse. Before sometimes monitoring the amount the data downloaded of 5 Meg would only increase the cache size 1/2 Meg or none at all. Viewing the exceptions they were almost all Read time out.

In WW 1.4 there is a panel that can be pulled up to watch what is being downloaded and the same tile would be in the queue and downloaded 6 times in a row, a few other tiles would download and then the first downloaded several more times. Reducing the queue size seemed to solve the problem in WW, I may have done something else also but do not recall. That is why I reduced the queue size in WWJ, if it has a better method of checking what is in the queue like it does the cache this may not be necessary.

In WW I would zoom in until the tiles wanted just became visable, I had it set up to show which layer, level and tile No. near the center of the tile, then pan to cover the area wanted and let it run while doing something else and then pan again.

Just as a real rough guess with the few hours tinkering with WWJ and several months since doing anything with WW it may take only 2 times as long or maybe the same time. If the NASA servers only have the data in .jpeg it should take the same time once the bugs are gone, if the data is in .dds then it will take longer.

How could WWJ be setup to save the tiles in .jpeg for the main layers rather than .dds so each time an update to WWJ comes out the code would not have to be changed for the .jpeg rather than .dds? Got tired of that in WW and used the same WorldWindow.cs file and only made changes to that file if it was important.

[Chiss]

I will convert my cache from WW that was all kept in the .jpeg format to the WWJ .dds format

Have a look at http://forum.worldwindcentral.com/showthread.php?t=10265 if you need a tool to help with the conversion.

Chiss!

[nlneilson]

[QUOTE=tag;49201]WWJ will download and save jpg (or png) if the layer is configured at start-up to do so. It will also download jpeg and png and convert it to dds on the client. You could try to minimize download times doing the latter or just storing jpg in the cache.

If a tile is not in the WWJ cache then loading it from the WW cache would be good, has anyone worked on code to do this or could the jpg/jpeg files from WW be copied into the WWJ cache and then converted to .dds when loaded?

I do not have any downloaded cache packs.

[Chiss]

If a tile is not in the WWJ cache then loading it from the WW cache would be good, has anyone worked on code to do this or could the jpg/jpeg files from WW be copied into the WWJ cache and then converted to .dds when loaded?

As far as I understand it, you could just take your WW cache and convert it to the WWJ format with the tool I have done (link 2 posts above), and manually merge it with your WWJ cache...

This is assuming you have a layer in WWJ that will actually look for it, with the proper extension... For exemple, if you add BMNG tiles to your WWJ cache, then they must be in the .DDS format because this is what the layer is looking for. Just remember that converting images from one format to the other is not sufficient, you really need a layer that is looking for them.

Hope this helps!

Chiss!

[nlneilson]

Chiss

I downloaded and looked at your tool code but have not had the time to figure out how to use it yet.

This would be very helpful.

Does every layer as in the cache packs need to be done alone, USGSDigitalOrtho 7, - -8 etc and then each layer of the UrbanAreaOrtho?

I am used to .bat files to do things like this.

Could the retriever code be changed to look for the .jpeg as well as the .dds files?

edit: Looked at your code and apparently this is to be run from inside WWJ, no "main" and needs DDSConverter.java. A .bat file could pull up all files in a directory and sub dirs and run a DDSConvert.jar (as an independent app) to replace the .jpeg files.

The code you have is above me. Do you have any domumentation/instructions on how this is to be used.

[Chiss]

Hi !

Does every layer as in the cache packs need to be done alone, USGSDigitalOrtho 7, - -8 etc and then each layer of the UrbanAreaOrtho?

I coded this so people would typically point the tool to the root of a specific layer in the cache, not at the top/root of the cache itself.

Could the retriever code be changed to look for the .jpeg as well as the .dds files?

All the code is doing is changing the name of the files to conform to the WWJ convention (no zero-padding, unlike the WW.net), so you could technically have files with the extension .xyz and it would still work. It's only when you want to convert the files to .DDS on-the-fly that the files have to be recognized as images by the javax.imageio.ImageIO class (in the JDK).

Looked at your code and apparently this is to be run from inside WWJ, no "main" and needs DDSConverter.java.

No, the class does have a "main" method (look closer! ;)), what you need to do is to compile it while having the WWJ SDK on your classpath (so it finds the DDSConverter class included in the WW SDK), and then launch it by typing something like "java com.chiss.wwj.CachePackConverter -cp worldwind.jar" (although I much prefer working with IDEs, less typing to launch files! Have you tried NetBeans ? I could send you the whole project if you want, minus the WW SDK...).

If for some reason this doesn't work, you could also comment out the DDS conversion stuff, and then the CachePackConverter could run as a stand-alone app, just compile it and run it like any other Java class with a main method.

Let me know if you need more help, and good luck!

Chiss!

[nlneilson]

I tried in Eclipse and got the no main error, probably something I did wrong.
I could not get WWJ to run in NetBeans but it was setup very good for Eclipse and ran without problems. I was using Netbeans before so with the whole project may be able to get your app working, a few instruction on getting the WWJ SDK added to the classpath in NB would be good also.

Is WWJ set up to read the .jpeg files after your app takes care of the zero padding?
Could I delete one specific .dds tile and replace that tile with the .jpeg and manually take care of the zero padding or is something else needed?

[Chiss]

a few instruction on getting the WWJ SDK added to the classpath in NB would be good also.

The easiest way is to start a new project from scratch, then copy the SDK sources in the project's src folder, just as if you had created them yourself. You can just then rebuild the whole source tree. You then need to add the various JOGL's jars to the project's library (right-click the Library node, then Add...)

The alternative is to add the WWJ's jars directly to the "Library" node as described above.

The last trick is to right-click the project, select "Properties" and then set it to have its working directory the directory containing the various JOGL's .DLLs files, otherwise JOGL complains about its missing ressources (Unsatisfied link error if memory serves me well).

Is WWJ set up to read the .jpeg files after your app takes care of the zero padding? Could I delete one specific .dds tile and replace that tile with the .jpeg and manually take care of the zero padding or is something else needed?

As I said earlier, the layer using those tiles must look for .jpg files. As fas as I know, the layers that come with the SDK are all looking for .dds. As a result, you can't mix and match images types like you suggest. What you could do for a quick test is to convert your few jpgs to dds using either my program or a program called DDSView (on Windows, use Google to find it). My program is just renaming the first part of the file names, so yes, you could do it yourself if you don't have that many pictures.

Good luck!

Chiss!

[tag]

I don't know which version this article refers to, but it looks pretty simple ... http://wiki.netbeans.org/wiki/view/HelloWorldWindJavaSDK

[nlneilson]

Thanks for the information Chiss. Knowing that the layers in the SDK all are looking for .dds files closes the option for .jpg files.

Downloaded the DDSViewer and tried it on a tile and it works OK even though the file size is smaller.

I usually use Irvanview so downloaded the plugins that has the .dds converter also, I have not tried it yet.

Now that it is clear what is needed I should be able to understand your app, I will try it in Netbeans when I have the time to tinker with it.

[nlneilson]

I have spent at least 10 hours of and on trying to get WWJ to work in netbeans trying to follow HelloWorldWind. First on Vista with NB6.0. I had uninstalled nb5.5.1 so installed it again and still no luck. Same thing on another computer with XP.

An excellent job was done on setting this up for XP/Eclipse, it ran the first time clicking on the .jar files and runs fine in Eclipse on XP. I have not been able to get WWJ to run under Vista which has been a real pain from day 1, waiting for Vista SP1.

[Chiss]

I have spent at least 10 hours of and on trying to get WWJ to work in netbeans trying to follow HelloWorldWind. First on Vista with NB6.0. I had uninstalled nb5.5.1 so installed it again and still no luck. Same thing on another computer with XP.

That's weird... What kind of error messages do you get? What are the symptoms? Since it works under Eclipse, it can't be your video card, so then it must be a stupid setting in NetBeans that you forgot/haven't found.. Let me know, maybe I'll be able to help! For a (maybe) slightly different approach than the Wiki example, look up Geertjan's blog: http://blogs.sun.com/geertjan/entry/nasa_world_wind_on_the


Good luck!
Chiss!

[nlneilson]

Just from memory the main errors were regarding jogl, gluegen etc. Even files that could be opened in the editor there were errors they were not on the path or could not be found even after copying the files including jogl, gluegen into the libs and other places. I even copied the whole WWJ into the NB project directory. This was after trying to set the path to the files/dirs.

After getting WWJ to work in Eclipse on XP I gave up on NB for WWJ. The link to Geertjan's blog seems to cover the same/similar problems.

Have you tried your .dds converter code in Eclipse?

[Chade]

I have. It works great. :)

[Chiss]

Just from memory the main errors were regarding jogl, gluegen etc. Even files that could be opened in the editor there were errors they were not on the path or could not be found even after copying the files including jogl, gluegen into the libs and other places. I even copied the whole WWJ into the NB project directory. This was after trying to set the path to the files/dirs.

You need to add the WWJ jars to the library of your project, and you need to put the .dlls in the root of your project (the directory containing the src, build, dist, etc...) or alternatively you set the project to start in the directory containing those dlls.

But then again, if you got it working in one IDE, maybe you don't need to make it working in another...

Good luck!

Chiss!