OpenCPN Beta test 4.1.1108 Release

[bcn]

Originally Posted by bdbcat

Hakan...

re:

Multiple Dashboards:
The mouse right click  view/hide check boxes are not working.

No problem here on Win7.

Anyone else tested this?

Thanks
Dave

Works correctly on W8.1 (Jon's build from this morning)

Hubert

[seandepagnier]

Originally Posted by transmitterdan

Regarding texture cache I wonder if this is really necessary. I have a lot of RNC charts because I try to work O hard to expose problems. My texture cache is reported as 10.9GB. Is it really worth it to have texture caching with such a large set of data?

A future goal of mine is that once the cache is generated, then the chart files are no longer needed. This means you can keep the charts on external storage, and the internal storage requirements are not bad.

I presume we have this feature for hardware platforms that are less powerful from a graphics standpoint. But can these low power systems afford such huge cache files?

Yes, probably. I have 18gb of raster charts. With 64gb disk it's enough. For smaller disks, you might have only the charts for part of the world loaded at a given time.

Originally Posted by bdbcat

NahanniV....

Regarding the Radar window docking.

"Expedient" is the word. We are soon going to release Version 4.2.

Any plan to move OCPN away from wxWidgets display base is longer term, and has no real design nor resource allocation yet. Lots of questions here, but the main one in my mind is: "What if user doesn't have OpenGL, for whatever reason."

Dave

Sorry, I didn't realize it was so easy to make it dockable with wxaui, my mistake. That of course is a good plan for now.

Originally Posted by bdbcat

TDan...

Raster texture cache is pretty important. Generating the multiple scaled chart tiles (mipmaps) from raw .KAP files is very CPU intensive. Without caching, this would have to be done on every chart load, in real time.

So the cache allows you to load precompressed small scale tiles to display an entire chart without having to load the large scale data. This results in much less disk access and no work because now the cpu has not to decompressing bsb, scaling, and recompressing the texture.

[Hakan]

Originally Posted by bdbcat

Hakan...

Multiple Dashboards:
The mouse right click view/hide check boxes are not working.

No problem here on Win7.............
Dave

Dave
Thanks for testing. I found the bug in my own branch:

for( size_t i = 0; i < m_ArrayOfDashboardWindow.GetCount(); i++ ) {
        DashboardWindowContainer *cont = m_ArrayOfDashboardWindow.Item( i );
        wxMenuItem* item = menu->AppendCheckItem( i+1, cont->m_sCaption );
        item->Check( cont->m_bIsVisible );

In some merge I must have missed a conflict in this so I had "i" instead of "i+1"

Thanks again and sorry for the inconvenience.
Håkan

[Hakan]

Originally Posted by bdbcat

Rick...

re:

I am not able to manually build the Texture Cache because it is greyed out. Where do I turn it on?

Sounds like you may be running with the Windows GDI Generic OpenGL driver. This will cause Texture caching to be disabled, since this OpenGL driver is not very compatible with the standard. It is missing several functions we need, and is known to be very slow.

Have you changed your configuration lately?
Please post your logfile entries for OpenGL, and we will take a look.

Thanks
Dave

Dave, Rick
I updated 1108 on my navigational PC equipped with the Intel 965 chipset.
Now suddenly my OCPN log file also says "Windows GDI Generic" and no catch and no raster charts ---
The last 1108 update on that PC was some week ago.
Håkan

[Hakan]

Dave, Rick ......Windows GDI Generic OpenGL
I don't know why me, and maybe others as well, so easily stuck to OCPN updates on any problem. Sorry -- I've to sometimes start thinking before acting.
What was the problem:
Well, a Windows update before my OCPN update installed a new Intel graphic driver. And I think this is valid for all HP/Compaq, IBM/Lenovo PCs with a Intel 965, or equal, graphic driver. Windows found a newer driver direct from Intel but these are not feasible on this PCs. You've to take the Intel driver from the PC maker instead, even if it's older than Intel's own.
Now when I've "downgraded" the graphic driver everything is fine again.

Håkan

[rgleason]

I've been using Nvidia Geforce GT 540M for Opencpn by setting Opencpn.exe to use the Geforce instead of the onboard Intel HP Graphics Group 3000.

Recently that stopped working and my use of Opencpn choked up using the Intel Graphics on board because it does not support OpenGL as well.

Today I have tried many ways to get Opencpn to use the Nvidia Geforce including
1. Resetting the Opencpn program settings from within the Nvidia Control. Many times.
2. Reboots many times.
3. Uninstall Nvidia and reinstall. Then re configure the Opencpn settings within Nvidia Control.
4. Disable Intel HP Graphics - Complete meltdown, black screen. Had to reboot to safe mode, the shutdown and reboot to normal mode.

None of these techniques were effective at getting OpenCPN to recognize the NVIDIA adapter. The drivers are installed and working properly. The Nvidia Control Panel works and I have set Opencpn to use Nvidia in the control panel.

Therefore I believe something has changed in the way OpenCPN loads the graphics driver. I have tried to contact Nvidia for suggestions but chat was very busy so I have emailed. Dell would be unhelpful.

Most recent example. Yet the Nvidia drivers work and Opencpn.exe is set to use Nvidia.

1:06:26 PM: Creating glChartCanvas
1:06:26 PM: Detected display size (horizontal): 344 mm
1:06:26 PM: Detected display size (horizontal): 344 mm
1:06:27 PM: OpenGL-> Renderer String: Intel(R) HD Graphics Family
1:06:27 PM: OpenGL-> Version reported: 3.0.0 - Build 8.15.10.2342
1:06:27 PM: OpenGL-> Detected Intel renderer, disabling stencil buffer
1:06:27 PM: OpenGL-> Texture rectangle format: de1
1:06:27 PM: OpenGL-> glGenerateMipmap unavailable
1:06:27 PM: OpenGL-> Detected Windows Intel renderer, disabling Vertexbuffer Objects
1:06:27 PM: OpenGL-> Vertexbuffer Objects unavailable
1:06:27 PM: OpenGL-> Using Framebuffer Objects
1:06:27 PM: OpenGL-> Using FBO Stencil buffer
1:06:27 PM: OpenGL-> Using Depth buffer clipping
1:06:27 PM: OpenGL-> Using s3tc dxt1 compression
1:06:27 PM: OpenGL-> Compressed tile size: 128kb (6:1)
1:06:27 PM: OpenGL-> Minimum cartographic line width: 1.0
1:06:27 PM: OpenGL-> Minimum symbol line width: 1.0

The good news is that Using Intel HP Graphics without OpenGL is pretty good and responsive. Its just under OpenGL it is a dog. T

Collapse/Expand GRAPHICS INFORMATION
Graphics Product [1] Intel®HDGraphics3000 Video Memory 4.0 GB
Graphics Product [2] Intel®HDGraphics3000 Video Memory 1.7 GB

[rgleason]

Is there some way to force OpenCPN to load the Nvidia drivers and use them?

[rgleason]

Vast difference in performance!
And I have absolutely no clue why it would just start using Geforce finally!

4:36:10 PM: OpenGL-> Renderer String: GeForce GT 540M/PCIe/SSE2
4:36:10 PM: OpenGL-> Version reported: 4.4.0
4:36:10 PM: OpenGL-> Texture rectangle format: de1
4:36:10 PM: OpenGL-> Using Vertexbuffer Objects
4:36:10 PM: OpenGL-> Using Framebuffer Objects
4:36:10 PM: OpenGL-> Using FBO Stencil buffer
4:36:10 PM: OpenGL-> Using Stencil buffer clipping
4:36:10 PM: OpenGL-> Using Scissor Clipping
4:36:10 PM: OpenGL-> Using s3tc dxt1 compression
4:36:10 PM: OpenGL-> Compressed tile size: 128kb (6:1)
4:36:10 PM: OpenGL-> Minimum cartographic line width: 1.0
4:36:10 PM: OpenGL-> Minimum symbol line width: 1.0
4:36:10 PM: Warning: iCCP: known incorrect sRGB profile
4:36:11 PM: Detected display size (horizontal): 344 mm
4:36:11 PM: Detected display size (horizontal): 344 mm

[rgleason]

I had started manually building a texture cache. Then 1/4 way through stopped it.
Then it seemed like Nvidia was working, I checked and it was. What do I know, not much.

Is this something that I should bring to Opencpn attention?
There's a hole in Block Island Sound, RI ?



PS: Second Generation Intel Processors with HD Graphics 2000/3000 support only up to OpenGL 3.1

[rgleason]

Here's another hole in Grand Manan Island, Canada.
I don't know if this is a Noaa cartographer error or something to do with O.
Sometimes these get fixed, but I don't know if they should be reported.

PS: Congratulations guys, I think this Nvidia Geforce adapter is working faster.
Seeing 50 - 65 fps when ingesting charts by scrolling around.

[seandepagnier]

Originally Posted by rgleason

Here's another hole in Grand Manan Island, Canada.
I don't know if this is a Noaa cartographer error or something to do with O.
Sometimes these get fixed, but I don't know if they should be reported.

I see the same hole.

I went back to version 4.0 and I can see how much faster ENC parsing is now, but the same hole is there. So maybe there is no enc chart there.

[rgleason]

Thanks Sean. Yes, it certainly is faster!

[P_Dub]

Originally Posted by rgleason

Here's another hole in Grand Manan Island, Canada.
I don't know if this is a Noaa cartographer error or something to do with O.
Sometimes these get fixed, but I don't know if they should be reported.

PS: Congratulations guys, I think this Nvidia Geforce adapter is working faster.
Seeing 50 - 65 fps when ingesting charts by scrolling around.

I see no hole there, probably an inset is missing in your data of charts. ENC S57 are OK. (Using 4.1.1108).
Bye

[P_Dub]

Originally Posted by P_Dub

I see no hole there, probably an inset is missing in your data of charts. ENC S57 are OK. (Using 4.1.1108).
Bye

The chart missing is 4342 CHS or NOAA-----
Bye

[Gilletarom]

Hello Dave,

Sorry but I remain in my comments very simple things and away from your technical discussions.

I just opened on my Lenovo U41, the plugin window to start the download Grib a Grib file. Unable to expand. It is far too high. In the bottom right, illegible button .... And the characters are not legible.