Wierd AIS triangles

[GHammond]

Dear Gurus

I've been faffing around with the Navico4G plugin for a while, trying to get it to work on all the various boxes I have - it works on one, not on others, and I realized the problem is wider than the plugin.

On the same boxes that can't display the radar plugin the triangles for AIS targets are also not drawn correctly.

Here's a screenshot:

The triangles show up as mixed red and yellow, or partly red and partly unfilled. They change constantly, blur in and out.

I assume it's an openGL feature...

Boxes are arch Linux, very up to date, modern hardware, intel graphics.

Any ideas. most gratefully explored...

Pete

[GHammond]

Here's the missing screenshot - need to delete the .txt suffix.

Pete

[GHammond]

Third try at the screenshot (apologies for incompetence)....

[cagney]

What happen if you turn OpenGL off?
What happens if you start without OpenGL at all?
Check OpenGL | Official OpenCPN Homepage

Thomas

[GHammond]

Without openGL the AIS triangles are perfect. When I toggle between openGL and the inbuilt graphics engine in openCPN the triangles change immediately.

Unfortunately, the obvious answer (turn off openGL) doesn't solve my larger problem - how to use the radar plugin - because the radar plugin demands openGL.

So, I should probably have asked a more precise question: is there anything I can change to improve the openGL performance on Linux with openCPN? Specifically the triangle fill part of openGL, since that is what the 4g radar plugin depends upon to paint the radar image on the screen.

Thank you.

Pete

[bdbcat]

Pete...

It is very strange that only the AIS targets are rendered incorrectly in OpenGL. The entire OCPN chart rendering logic is based on triangle rendering, done by decomposing every drawn item into its constituent triangles. (aka tesselation). That is how GL works...

Are there any other rendering defects that you have seen under OpenGL?

Dave

[GHammond]

Dear Dave

The rendering seems most prone to fail at three points in openCPN.

First the AIS triangles and the lines that extend forward from the triangles that show the ship's projected course.

Second, the 4g radar plugin fails at the render triangle point in the code - it has data but doesn't paint it.

Third, there are frequent problems with charts made from google earth when they are quilted together. These problems show as blank rectangles in the quilt and as occasional black squares.

This third problem may however be a result of trying to quilt too many chartlets together - my maximum open charts is set at 1000 and even so the program generally chokes if I try to zoom out. Generally the best strategy is to focus in using CMap and then switch to GE chartlets since openCPN is quite happy if there are less than a dozen to quilt - much more than that and it gets confused. (ie the quilt fails and it shows a mixture of CMap and GE chartlets and blank rectangles).

I *think* I see a correlation between the AIS triangles and the google earth chartlets. If I'm showing GE charts then the AIS triangles are drawn much more sloppily; if I'm showing only CMap the AIS triangles are often fine. That seems to suggest some kind of a resource issue - it seems as if the GE chartlets need more processing power/memory to quilt and to display and that leaves less oomph to display the AIS triangles properly. Or maybe that's a red herring...

I don't think this is really a hardware limitation - it chokes more on the machine with the fastest processor and most memory.

Clearly there is something about the way openGL is behaving on these linux boxes that doesn't mesh well with openCPN.

I don't see these issues in any other program but then I don't use any other graphics intensive program so extensively so that's not really a useful data point.

If you do have any ideas about alterations I can make to the environment that would make a difference I'm more than willing to try.

Thank you.

Pete

[bdbcat]

Pete....

As in all software debugging, the first steps are to simplify, isolate, and reproduce.

It is not difficult to find bugs in a complex, asynchronous, GUI intensive application displaying uncontrolled content (i.e.charts from who-knows-where) like OCPN. I do this all day long

But to make meaningful progress, we are looking for the simplest configuration that will reliably reproduce the problem.

So:
1. Switch to single chart mode.
2. Drop Google chartlets, and use simple BSB (.KAP) charts.
3. Find a static AIS data stream file that you can feed to OCPN by using the VDR PlugIn.
4. Look for incorrectly rendered targets.
5. Successively add more complexity (ENC charts/quilting/cm93, etc.), validating the behaviour at each step. Take notes. Reproducibility is the key.
6. Report results here.

We can help along the way.
Thanks
Dave

[GHammond]

Sounds like a plan, Dave.

I'll settle down over the next day or so and see if I can find a way to break the display in a reproducible fashion. Thank you for the step by step guide.

Will report back.

Thank you.

Pete