Idea to render charts in browser using WebGL 3D

[mgrouch]

I initially explained it here https://github.com/OpenCPN/OpenCPN/issues/2714

Since then I've made better progress on this idea. The idea is to render S57 ENC vector charts in browser natively using WebGL. It actually looks quite promising. I took S57 parser and render in Java from OSM. https://www.javatips.net/api/josm-plugins-master/seachart/src/s57/S57dec.java

I've converted it into Kotlin. (Both parser and renderer which uses AWT canvas). Rnderer is coded to render all objects specified in chart. (Not by icons, but by actual code writing on canvas) See here: https://github.com/mgrouch/kotlin-sandbox/tree/main/kotlin-s57 Parser is very very close to be running in browser using Kotlin JS. I've tested it a little on JVM already. Renderer should be possible to port from AWT canvas to WebGL in Kotlin). Might be using https://github.com/revaultch/gwt-awt (converted to Kotlin)

Caching for performance in browser can be handled using IndexedDB of browser. Might use: https://github.com/JuulLabs/indexeddb or something else

Conversion of depth contour lines into 3D mesh using triangulation libraries in Kotlin can be done with: https://github.com/slaviboy/DelaunatorKotlin https://github.com/ricardomatias/delaunator

3D rendering or 2D with WebGL:

https://github.com/Pozo/threejs-kotlin https://github.com/markaren/three-kt-wrapper

https://github.com/openrndr/openrndr

I've played with WebGL and 3D rendering of reliefs with it too in Kotlin https://github.com/mgrouch/kotlin-sandbox/tree/main/kotlin-webgl

Rest of UI can be done using kvision https://github.com/rjaros/kvision

What do you think? I'll code more but, more people helping would be better. Kotlin and IntelliJ really make it way easier than anything I could think of.

Thanks

[wellenvogel]

Basically a nice idea. I was already struggling with similar ideas for a while. The issues I see: (1) Where are legal sources for S57 charts that are open (i.e. unencrypted). Is there a reasonable amount of charts being available in this format so that it is worse the effort? And compare the available charts to freely available raster charts that already easily can be used this way. (2) There seem to be some applications on the web that follow a similar approach - like https://app.nvcharts.com/ (you need a free account there). If you select verctor charts it feels terribly slow even on a desktop browser. Not sure how this would run on a mobile device. I compare with e.g. ocharts in AvNav. Not sure how far they have been gone with optimizing - but at least for me this somehow makes the approach questionable. (3) rendering bugs and workarounds. Within AvNav I use the OpenCPN o-charts plugin to render the vector charts (server side). Beside the licensing stuff one of the reasons was to rely on some relatively stable and mature renderer that at least has gone through a long way of bugfixing and implementation of special stuff. Not saying that this cannot be repeated - but I would not underestimate this part. (4) caching: When rendering in the browser most probably the complete caching would also have to take place there. One of the questions: How much caching space will you have available? In my ocharts plugin the caches (server side again) reach typically > several 10 to 100 MB. When I was designing the server side rendering with the o-charts stuff I was thinking a lot about user experience. For sure caching the rendered stuff is not optimal as you have to throw away the cache whenever you change some settings. On the other hand a server side cache is nice as it can be shared by all clients - and the filling can be done in the background without any influence to the user experience. Additionally considering the fact that underway you change your viewport slowly this works really well (even on a Pi 3B + older android device). (5) client performance requirements Just consider the need for some special devices on board ("sunlight readable"). Typically it's already rather hard to find suitable devices at all. Potentially they are older (slightly outdated browsers) , they have limited resources - or you even try to run the browser on a Pi with a nice screen attached (performance even worse). So this could be another limiting factor.

Conclusion (to me) currently: As much as I would like to see this being implemented (because architecturally it would be really cool) I would not really spend to much effort on it right now.

[mgrouch]

I've already managed to port s57 parser into Kotlin. Today I was able to draw first few charts. I'm attaching screenshot. Considering that I started coding it just 5 days ago I think it's big progress. Take a look at the code https://github.com/mgrouch/kotlin-sandbox/tree/main/kotlin-s57 Parser seems mature. Renderer is quite capable. All objects seems coded. IntelliJ and Kotlin is pleasure to work with.

(1) All NOAA ENC US charts are free. See coverage here https://charts.noaa.gov/InteractiveCatalog/nrnc.shtml

(2) Phones are actually much better with 3D GL than even raspberry pi. The app needs to be designed smart. 256 by 256 points mesh in 3D works with no lag whatsoever on iphone browser. It's more objects than you typically would have on viewable area of vector chart. I do not see an issue there.

(3) OpenCPN is getting harder and harder to maintain. This (Kotlin) solution is using one of most productive languages and one of must portable and safe.

(4) Idea is to cache on browser side. They all have standard IndexedDB implementation built in.

(5) Mobile devices browsers are quite good with hardware accelerated graphics.

[mgrouch]

First screenshot from first version that was able to render something

https://github.com/mgrouch/kotlin-sandbox/blob/main/kotlin-s57/screenshots-progress/2022-06-13.png

[mgrouch]

I've checked https://app.nvcharts.com/ About same as NOAA. If you stick to tiles generated for you then you are not in control what is displayed. Not color. Not shades for depth. Not objects visible based on your zoom level. You just displaying bitmaps. When you in control of the rendering you can do your own contour line widths, etc. You are not dependent on what is fed to you. You have freedom of optimizing user experience.

Most of the ppl I had on my boat even had issues with standard coloring. They always think lighter color means shallower. Which is exactly opposite in NOAA ENC and https://app.nvcharts.com/ but in night mode it's opposite. Why deeper is not darker in any mode night or day?

There is no shadowing of bottom relief whatsoever. Which is done in commercial plotters.

BTW: the code seems to handle OSM charts as well. There is also nothing wrong with overlaying bitmap layers on top.

[wellenvogel]

Not really answering any of my questions...

Anyway: If you finally manage to implement everything I would be hapoy to integrate something.

[wellenvogel]

No further activity - so closing this.