Missing Surface tiles

[jcoy]

Hello,

I posted a message in the technical support area but didnt receive many responses.

I am running into an issue using surface shapes. In my application I allow the user to create surface shapes. When zoomed out to see a lot of the world if you create a surface shape that covers multiple surface tiles I get the following exceptions:

SEVERE: Exception encountered while picking
java.lang.NullPointerException
at gov.nasa.worldwind.render.AbstractSurfac eObject.drawPickRepresentation(AbstractS urfaceObject.java:676)
at gov.nasa.worldwind.render.AbstractSurfac eObject.pickOrderedRenderable(AbstractSu rfaceObject.java:524)
at gov.nasa.worldwind.render.AbstractSurfac eObject.pick(AbstractSurfaceObject.java: 246)
at gov.nasa.worldwind.AbstractSceneControll er.pickOrderedSurfaceRenderables(Abstrac tSceneController.java:758)
at gov.nasa.worldwind.AbstractSceneControll er.doNonTerrainPick(AbstractSceneControl ler.java:577)
at gov.nasa.worldwind.AbstractSceneControll er.pick(AbstractSceneController.java:550 )
at gov.nasa.worldwind.BasicSceneController. doRepaint(BasicSceneController.java:27)
at gov.nasa.worldwind.AbstractSceneControll er.repaint(AbstractSceneController.java: 256)
at gov.nasa.worldwind.WorldWindowGLAutoDraw able.doDisplay(WorldWindowGLAutoDrawable .java:308)
at gov.nasa.worldwind.WorldWindowGLAutoDraw able.display(WorldWindowGLAutoDrawable.j ava:223)
at com.sun.opengl.impl.GLDrawableHelper.dis play(GLDrawableHelper.java:78)
at javax.media.opengl.GLCanvas$DisplayActio n.run(GLCanvas.java:435)
at com.sun.opengl.impl.GLDrawableHelper.inv okeGL(GLDrawableHelper.java:194)
at javax.media.opengl.GLCanvas.maybeDoSingl eThreadedWorkaround(GLCanvas.java:412)
at javax.media.opengl.GLCanvas.display(GLCa nvas.java:244)
at javax.media.opengl.GLCanvas.paint(GLCanv as.java:277)
at javax.media.opengl.GLCanvas.update(GLCan vas.java:354)
at sun.awt.RepaintArea.updateComponent(Unkn own Source)
at sun.awt.RepaintArea.paint(Unknown Source)
at sun.awt.windows.WComponentPeer.handleEve nt(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unk nown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknow n Source)
at java.awt.EventDispatchThread.pumpOneEven tForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsF orFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsF orHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents( Unknown Source)
at java.awt.EventDispatchThread.pumpEvents( Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
Mar 25, 2011 1:47:28 PM gov.nasa.worldwind.render.AbstractSurfac eObject drawOrderedRenderable
WARNING: Surface tile draw context is null

when the exceptions occur my shapes are truncated. I have attached a screenshot of the results. The red line on the attachment is the actual shape size, the white and black are the only parts that show.

I do a lot of enabling and disabling of picking and at first I thought that might be the issue so I disabled that and still had the same problem.

http://forum.worldwindcentral.com/attachment.php?attachmentid=2654&stc=1&d=1303410429
Any ideas into why the problem happens would be very helpful.

Thanks,
-Jason

[heidtmare]

Kinda seems like you have a threading issue...
are you spawing any threads of your own during this process?

[kkowalik]

Hi, I've been working with jcoy on this issue and thought I'd respond.

I'm not clear on this threading suggestion, heidtmare. Maybe it would help to mention that the exception occurs when finishing the MapShape, but the graphical issue tends to happen when moving the shape around the map. It doesn't happen on all tiles, sometimes the shape draws perfectly well. So I'm not sure how other threads factor in here... obviously the app has some other unrelated threads going, so when or where would these problematic threads be spawned that they'd be messing up drawing?

In another thread, http://forum.worldwindcentral.com/showthread.php?t=30499, TimD suggested that memory might have been the problem, due to OpenGL being starved for memory, but messing with the min and max memory of the app didn't improve the situation; it's still reproducible immediately after the WW map comes up.

The problem as far as we can tell is not with the machine the app is running on; it's reproducible on multiple PCs: WinXP and Win7, ATI and Nvidia. I have also run the SurfaceShapes demo at http://worldwind.arc.nasa.gov/java/demos/ and can't get the problem to happen there, tho our app is much more complex than that demo.

[TimD]

You mean:http://forum.worldwindcentral.com/showthread.php?t=30594.

I'm afraid I got no further in my investigations but in our case it did seem related to the heap allocation and it was reproducible in the SurfaceShapes example on different hardware (although not for the NASA guys).

I would be interested to see any resolution to this though...


In another thread, http://forum.worldwindcentral.com/showthread.php?t=30499, TimD suggested that memory might have been the problem, due to OpenGL being starved for memory

[kkowalik]

I've got a small update on how this has been going.

I've been able to figure out the reason for both the NullPointerException with pickTiles in AbstractSurfaceObject mentioned in jcoy's original post and the following warning in the console:

25-Mar-2011 09:17:21 gov.nasa.worldwind.render.AbstractSurfac eObject drawOrderedRenderable
WARNING: Surface tile draw context is null

When we add a new shape to the map (and when we move it, since it's basically removing the old shape and re-adding it in the updated location) we queue the change to occur slightly later on, in the shape layer's preRender(DrawContext) method. The bug occurred because this processing was done after calling the superclass's preRender() method. So, the new/updated MapShape never got pre-rendered before being rendered, meaning AbstractSurfaceShape.buildPickRepresenta tion() wasn't called, making pickTiles null when the shape was drawn in .drawPickRepresentation(), and SurfaceTileDrawContext not yet added for .drawOrderedRenderable().

In the normal WW repaint cycle of prerender before render this isn't expected to happen, hence why pickTiles isn't null-checked in WW before calling pickTiles.isEmpty() and why it creates a warning for the surface tile draw context. I am also guessing this is why heidtmare suggested a threading issue, that we might be rendering shapes before prerendering, but I still can't be sure what was suggested there.

Unfortunately, fixing this bug doesn't fix the issue of shapes not being drawn correctly... moving them around onto certain tiles still produces graphical issues.

I'm attaching another picture to show how badly the shape can sometimes get chopped up, using the WWJ Dashboard to show some of the tile boundaries. If you zoom in and out you can see that the chops always occur on some tile boundary, even if it's not the currently visible one. The two different colors are from before when the shape was white and after when the shape's fill color was changed to red, showing that some of the old graphics from the white shape still remain on some tiles.

[tag]

We need an example or your extended classes in order to help you with this. There are several potential causes.

[kkowalik]

We need an example or your extended classes in order to help you with this. There are several potential causes.

If we're unable to figure out the cause of this problem, I'll try to whip up an example that reproduces the issue, but there's a lot going on in our subclasses and I'd rather not take the time to put that together until we've run out of ideas.

[dcollins]

kkowalik,

You mentioned a MapShape in your previous post. Are the shapes your application works with an extension of one of World Wind's standard surface shapes? If so, can you post the code for the extended shape?

Thanks,
Dave

[kkowalik]

You mentioned a MapShape in your previous post. Are the shapes your application works with an extension of one of World Wind's standard surface shapes? If so, can you post the code for the extended shape?

Actually yes, we created a new interface that includes Movable, PreRenderable, and Renderable for convenience, plus a few new methods. I looked into whether the extended shape could be the cause of the problems, but even after stripping out all of the new methods from this MapShape and removing everything our extended shape overrode in the WW shape (SurfacePolygon) the problem wasn't fixed. So, I am now looking into the extensions we have to RenderableLayer to see if the problem is coming from there.

[TimD]

In our case the problem was seen with the WWJ built-in SurfaceShapes and was triggered by moving the camera when zoomed-in close, not moving the shapes. The layer wasn't even pick-enabled...

[tag]

We'll look more deeply into it.

[kkowalik]

A couple days ago I was able to modify our code enough to cause this bug to no longer happen in our environment for once, and have since narrowed down what exactly needed to be changed enough to fix the bug, though why it still occurs is still beyond me, and there might be a more elegant solution than what I've found.

It turns out there were two layers of ours that could cause this bug to happen, something I didn't figure out until getting rid of all layers but the shape one, which is something I only tried recently, hence why it took so long to narrow this down. The first layer that could cause the problem was our version of the shape layer, specifically the initial shapes that we add to the map that are saved from running the app previously. The second layer that was a problem was a custom one of ours that draws concentric rings on the map from a location, to visually show the distance in meters that things are from that location on the map.

For the first layer, the shape layer, we re-create our MapShapes (Movable, PreRenderable, Renderable WW shapes) that were placed on the map the previous time the app was running and stored in a database. I narrowed down the problem with adding these initial shapes to us adding the MapShapes to the layer before the layer called super.preRender(DrawContext), the "super" being RenderableLayer. When the method to add the initial shapes was directly infront of that call, shapes would produce the tearing that we've uploaded screenshots about, and when it was placed directly after that call the tearing went away. I find this extremely curious since, as I mentioned a couple posts ago, the reason we were getting an exception and warnings in the console when creating a new shape (not these initial shapes) was because the shapes were being added before this super.preRender() call, and here the fix was to do the opposite for these shapes that are added right as the app starts.

So to fix the first layer, it looks like RenderableLayer.preRender() has to be called at least once before these initial shapes are added. The tears didn't happen on all tiles before this, usually just ones in the vicinity of where the initial shapes were placed.

For the second layer, the range rings layer, the rings (regular WW SurfaceCircles) were previously being created and added as renderables to the layer via RenderableLayer.addRenderables(Iterable<? extends Renderable>) at the end of the layer's constructor. Visual tearing would normally occur around the area that the rings were located, and no-where else as long as the first layer hadn't created tears of its own. By moving the creation of the rings to later on, in the layer's preRender() method, the rings stopped creating tearing in the shapes around them, and this fixed the issue.

So in all of these instances, including the exceptions and warnings solved previously, it seems the problems were caused by adding the renderables at the "wrong time," but why these were the wrong times, I really don't understand. I have looked into the fact that our shape layer uses the "renderable override" way for our shapes via the RenderableLayer.setRenderables() method, and looked at the "ordered surface renderables" stuff to see if we're just doing something at the wrong times, but I haven't made any real progress on that either. So for now, I'm sticking with the changes I've mentioned here which fix the bugs, since I've run out of time for working on this issue and need to move on.

If this isn't enough to help you guys figure out what's wrong, I can try to create some examples of this occurring on my own non-work time now that I've pinpointed the cause, so let me know if that's necessary, but I am pretty burnt out from tracking this one down right now.

[dcollins]

kkowalik,

Thanks for following up on this issue, and for the detailed explanation of your current diagnosis. We're unable to reproduce this issue based on the information you've provided. What you describe sounds like an issue with one of your subclasses, though it could also be a design problem with the World Wind surface shapes that you've just happened to expose.

In either case, the workarounds you've had to implement should not be necessary. World Wind is designed to be extensible, so if there's something about surface shapes that's making that difficult we'll fix it.

That said, it would go a long way toward helping us diagnose and resolve this issue if we could see any custom classes related to this issue, along with the code that uses these classes. We don't necessarily need working examples, we can derive a lot of information from non-working code. Is it possible for you to post the code for these classes as attachments to this thread? If not, could you send me a private message with the files attachment?

Thanks,
Dave

[kkowalik]

Dave, I can do that, it'll just be a while before I can find the time to put it together in a way that both works and doesn't expose anything the company wouldn't want out in public domain.