OpenCPN Beta test 4.1.1108 Release

[bdbcat]

@did-g...

Do I understand correctly that you can reproduce the quilting problem from Hakan's VDR recording?

I still cannot reproduce it.

Dave

[.Paul.]

Originally Posted by bdbcat

@did-g...

Do I understand correctly that you can reproduce the quilting problem from Hakan's VDR recording?

I still cannot reproduce it.

Dave

Dave,

I reproduced the problem. Screenshots attached.





Win10, OpenCpn built yesterday, 14 Nov 2015.

Paul


Edit: I don't see the screenshots, above.

[seandepagnier]

Is this specific to quilted cm93 charts then? I panned around this same lat/lon and tried with cm93 detail level set to zero, and cannot find any faults here, but I have seen in other locations where when panning, the chart cells selected for the quilt quickly switch.

Can you give an example of where the nodta area isn't rendered correctly? It's currently a bit annoying how it's done. It must first fill the entire chart area with the nodta color then render the chart which in many cases is a waste of time. It would be nicer if it could precompute the nodta area to the minimum number of triangles needed.

[Hakan]

Of course a "silly" question when I don't have the knowledge to follow your discussion but -- all details are correct in OCPN ver 4.0, as seen in the video, what's the difference??

Håkan

[.Paul.]

Sean,

I think this is specific to CM93 charts. I used "CM93 jan 2011" to reproduce the problem that shows up while playing Hakan's VDR recording. The CM93 detail slider was set to +5. The VDR was played back at maximum speed. Here is a shot that showing the screen appears to be mostly correct. Most of the right half of the screen shows spot soundings, depth contours and text labels. There is a region south of St Dagholmen (lat=58N) that is rendered in shallow depth blue without spot soundings.



Here is a shot showing the screen with missing detail. Except for the top right corner, most of the right half of the screen is missing soundings, depth contours and text.



From this point in time OpenCPN oscillates between the above two chart images as the red boat moves approximately NNW and the chart scrolls to keep the red boat centered on the screen. The AIS targets also move on the screen (as they should). The FPS is about 20. The scale is 42300 (0.50x).

This problem is related to the CM93 version that is used. With "CM93 jun 2000" in use the chart display does not oscillate between showing detail and missing detail. Screen shot follows.



Paul

[seandepagnier]

And it flickers also in single chart mode?

[did-g]

Originally Posted by Hakan

Of course a "silly" question when I don't have the knowledge to follow your discussion but -- all details are correct in OCPN ver 4.0, as seen in the video, what's the difference??

Håkan

cm93 has multiple charts for the same area with different scales A,B...G
A lower to G with greater details and Z for whole world.

When rendering OCPN chooses on lat/lon and zoom which ones it uses.
for example a B chart with low detail first and a C above it.

Moreover cm93 charts out there are often with 'holes' , for example there's a B and D but C is missing, switching between B and D is very visible.

let say OCPN chooses to display a B and a D chart with D covering most of the screen.

When panning if OCPN wrongly chooses to display only the B because it thinks the D is too underzoom or outside the view you get what your are seeing, a switch to a screen with very low detail.

It's compounded with accelerated panning, in this mode OCPN only redraws the new unmasked areas:
- you have a D chart on screen or part of the screen.
- you pan a little, OCPN wrongly thinks it should use only B charts. But only the new rectangle, previously hidden, is rendered with these low B. Not very visible, most of the old detailed D is still on screen.
- if for whatever reason (overlay, info buble, even without user action), OCPN has to redraw the whole screen it will use only low details charts and that is noticeable.

Recently Sean made changes with a lot of improvements but a few regressions...
either in the new code or old sleeping bugs are now triggered.

[did-g]

Originally Posted by Hakan

did-g, Dave
No, didn't helped, still the same.

And to complete my list from above when this happens:
- the occasionally missing details issue is only valid when "auto follow - F2" is active.

Thanks
Håkan

Håkan, Dave

I was able to reproduce it but it seems I can't do it anymore.
- I'm using the latest git code.
- I deleted cover set cache.
opencpn_CM93-2012___coverset_sigp.?

My bad, after more testing it still there, using Paul setup at level 5

[seandepagnier]

Originally Posted by did-g

cm93 has multiple charts for the same area with different scales A,B...G
A lower to G with greater details and Z for whole world.

When rendering OCPN chooses on lat/lon and zoom which ones it uses.
for example a B chart with low detail first and a C above it.

Moreover cm93 charts out there are often with 'holes' , for example there's a B and D but C is missing, switching between B and D is very visible.

let say OCPN chooses to display a B and a D chart with D covering most of the screen.

When panning if OCPN wrongly chooses to display only the B because it thinks the D is too underzoom or outside the view you get what your are seeing, a switch to a screen with very low detail.

It's compounded with accelerated panning, in this mode OCPN only redraws the new unmasked areas:
- you have a D chart on screen or part of the screen.
- you pan a little, OCPN wrongly thinks it should use only B charts. But only the new rectangle, previously hidden, is rendered with these low B. Not very visible, most of the old detailed D is still on screen.
- if for whatever reason (overlay, info buble, even without user action), OCPN has to redraw the whole screen it will use only low details charts and that is noticeable.

Recently Sean made changes with a lot of improvements but a few regressions...
either in the new code or old sleeping bugs are now triggered.

When it switches the cell, it should be forced to redraw the entire screen, but maybe the logic is wrong?

The quilting logic specific to cm93 has a hole in it somewhere and it's now exposed.

I have now found occasionally the pixel offsets it calculates for accelerated panning are wrong which is annoying and difficult to reproduce, this leaves vertical lines in the chart when panning.

Also, the chart outlines for cm93 sometimes change scale, and calculate the scale incorrectly when doing accelerated panning.

Now, I know the logic is completely bugged when quilted for the area in northern russia because it doesn't have a Z scale chart but does have smaller charts, but it was always buggy here, even before. At least it works in single chart mode.


If you can describe how to reproduce the fault it isn't difficult to fix. I am having trouble reproducing the errors mentioned. In the meantime I will do extensive testing to try to fix all of these glitches.

[Hakan]

did-g..
re: "Recently Sean made changes with a lot of improvements but a few regressions...
either in the new code or old sleeping bugs are now triggered"

Thanks for the description, most is clear.
I suppose the place I happened to record the VDR is tricky with a lot of mix between cells at different scales. So when the charts are jumping around in "F2" mode the rendering is disturbed all the time. Hopefully this is a place you excellent coders can use to do your best for a compromise we users and testers can trust, at least not switch to "A" or "B" cells, when "C/D" are available, as ver 4.0 did, or? If nothing else can the chart jumping in F2 mode be slowed down?

Thanks for your efforts.
Håkan

[.Paul.]

Originally Posted by boat_alexandra

And it flickers also in single chart mode?

Single chart mode works well in beta 4.1.925 and yesterday's build 4.1.1114. The only problem is that the chart changes when crossing 11 44.5E (only about half the screen shows a CM93 chart). Spot soundings, depth contours and texts are constantly displayed for the chart under the red boat at the center of the screen with a quick chart/background chage when crossing 11 44.5E.

Paul

[did-g]

Originally Posted by boat_alexandra

When it switches the cell, it should be forced to redraw the entire screen, but maybe the logic is wrong?

The quilting logic specific to cm93 has a hole in it somewhere and it's now exposed.


.

Theses charts have updates and OCPN doesn't seem to do the right thing with them, it adds every objects to the list when it should clearly replace some. Maybe many overlapping regions trip the logic.

For the other unrelated issues:

1- chart with nodata zone not render in single chart mode, in single mode this chart also switches to C when it should stay in D. It's Jersey island 49°10" N , 2° 6" W, could be the chart though.

from the log with DebugCM93=1

on SetVPParms, cmscale:4, D
cm93chart::SetVPParms   ll_lon: -2.21443  ll_lat: 49.0867   ur_lon: -1.82797   ur_lat:  49.2142  m_dval: 3
cm93chart::GetVPCellArray   Adding 4171071
cm93chart::GetVPCellArray   Adding 4171074
 chart D contains clat/clon
cm93chart::SetVPParms   ll_lon: -2.21443  ll_lat: 49.0867   ur_lon: -1.82797   ur_lat:  49.2142  m_dval: 3
cm93chart::GetVPCellArray   Adding 4171071
cm93chart::GetVPCellArray   Adding 4171074
cm93chart::SetVPParms   ll_lon: -2.21443  ll_lat: 49.0867   ur_lon: -1.82797   ur_lat:  49.2142  m_dval: 3
cm93chart::GetVPCellArray   Adding 4171071
cm93chart::GetVPCellArray   Adding 4171074

on SetVPParms, cmscale:4, D
cm93chart::SetVPParms   ll_lon: -2.18606  ll_lat: 49.0867   ur_lon: -1.79959   ur_lat:  49.2142  m_dval: 3
cm93chart::GetVPCellArray   Adding 4171071
cm93chart::GetVPCellArray   Adding 4171074

 VP is not in M_COVR, adjusting cmscale to C
It's false VP is in D 
 chart C at VP clat/clon is present
cm93chart::SetVPParms   ll_lon: -2.18606  ll_lat: 49.0867   ur_lon: -1.79959   ur_lat:  49.2142  m_dval: 12
cm93chart::GetVPCellArray   Adding 4141068

2- picture viewport > 180° without opengl.

3- picture viewport > 180° with opengl, missing line around Africa.

[bdbcat]

Hakan, did-g, Sean, etc...


Various Regressions:

1. Hakan's jumping scale problem is provisionally resolved. The problem only occurs in OpnGL, without FBO enabled, like most MSW/Intel configurations. You can induce it in linux by forcing FBO's off.

Nothing wrong with the basic cm93 quilting logic. But the S57 renderer must obey exactly the specified render region for the logic to work.

The location and scale specified in Hakan's test is especially complex, to wit:

a. The base scale requested by zoom and detail slider is F. There is a tiny sliver of F scale cell available at the left side of the display. In full-screen quilting mode, this sliver controls the cm93 quilt compositor. So the little F scale piece gets rendered.
b. The main area of the screen is filled with E scale cell, since there is no F-scale available here.
c. There is another tiny sliver on the right that is not covered by F, E or D. So the logic retires to C scale. And the C scale render sometimes gets it wrong, writing over the entire area by not honoring the region logic.

I made a provisional fix in s57chart.cpp, applied only to cm93. May be slower for complex cm93 quilting situations.
@Sean, please review and comment.

2. did-g Issue 1:
Problem identified as failure of region logic as cm93 cells are loaded.

@Sean: cm93chart::IsPointInLoadedM_COVR() does not produce the same result for the two available conditional paths. Try it with VP centered at (49 08.5000 N, 001 59.0000 W), single chart mode, scale set so as to load D-scale chart. The old way works, the new way does not, at least in single-chart mode.

I fixed this provisionally. Probably slower than the new llRegion method, but works.

Associated issue: Missing NODTA areas:
@didier, what you are seeing is the water area of the GSHHS world chart, rendered in error behind the cm93 cell, and thus showing through in the NODTA areas. Verify by setting Display category to Mariners Standard, and clearing all Feature types. You will see the same color blue on the right half of the display.

Not sure what is causing this, may be related to LON0. I'll investigate.
@Sean, please take a look.

Dave

[Hakan]

I'm impressed of your knowledge and passion to solve a complex issue.
I understand it's not finalized but couldn't resist to test.

In quilt mode it's now much better but gave another effect in none quilt mode when close to a F part, see shoot.

Håkan

[Ptizef]

Coming back to "my" CM93 display problem on an entire zone, I tested the very last git and compared it to 4.0.0

I don't know if it's linked to those described by Hakan and did-g, but it's clearly a regression as 4.0.0 shows the impacted zone normally with the same set of charts on the same machine

It seems not related to openGL mode as it happens in both configurations, but it's clearly linked to quilting mode. No quilting works fine.

Here you can find in the screens shots the same zone at two different zoom levels 1108 compared to 4.0.0

Jean Pierre