Re: Construction of Skybuck's UFO Alert Tool log
Skybuck Flying <[email protected]> Sat, 20 Aug 2022 13:45:54 -0700 (PDT)
| Newsgroups | alt.comp.periphs.videocards.nvidia |
|---|---|
| Message-ID | <[email protected]> |
********************************************************************************************** Day 9, 19 august 2022, Explored the H3Index coordinate system, want the IJK coordinate system. ********************************************************************************************** Video log of my activities of Day 9: https://youtu.be/8mrw1Kzvu_c 9.1 H3Indexes coordinate system explored/visualized in 3D/Sphere/Globe with TGLFlatText from GLScene. 9.2 Wanted to explore IJK coordinate system but was not yet possible because of 8.4 and 9.3: 9.3 Came to the conclusion that the missing UBER H3 API: _h3ToFaceIjk was a serious shortcoming and would prevent the implementation of hexagon routing. Thus a solution should be found to get this API working. Different solutions came to mind and the ammount of time needed for each solution was considered and described. 9.4 Decided to wait a day to see if I or anybody else could come up with a solution and to give this a bit of a rest for today, instead of beginning a "crazy C to Delphi port" ;) :) to save myself a lot of time on the long run and to benefit from future improvements and versions of the UBER H3 library and saving myself a lot of days/time. ********************************************************************************************************************************************* Day 10, 20 august 2022, Multiple spheres idea tried, UBER H3 DLL fixed, IJK Indexes Explored, 3D hooking described, Server Protocol described ********************************************************************************************************************************************* Video log of my activities of Day 10: https://youtu.be/_Q23Jb3JL2U 10.1 Showed the zooming ideas I had in folder/document: Plans and Designs/Zooming.txt (To be tried and implemented on a later day) 10.2 Described the server protocol, still more work to do to flesh it out. 10.3 Came to the conclusion that it is very important to get IJK coordinate system working. It will most likely affect the design of the algorithms, such as the peer assignment algorithm inside the server for assigning/allocating peers to the main hexagons. 10.4 Decided to shift gears and try to fix the UBER H3 DLL/LIBRARY by manipulating the C source codes slightly to try and export the needed _h3ToFaceIjk function implementation. Did so successfully. 10.5 Later discovered some feedback (from github user: isaacbrodsky) on github how to issue the correct CMake build command to export ALL functions: https://github.com/uber/h3/issues/643 Step 2: Configure for DLL release: cmake ..\h3 -DBUILD_TESTING=OFF -DBUILD_SHARED_LIBS=ON -DCMAKE_WINDOWS_EXPORT_ALL_SYMBOLS=ON Step 3: cmake --build . --config Release This fixes the H3.DLL and makes sure all function/api implementations are present, at least it should, at least the _h3ToFaceIjk function implementation was present. 10.6 Examined and explored and visualized the IJK coordinate system in 3D/Spheres for the hexagons at different resolutions, such as resolution 0, 1, 2 and even 3. 10.7 Explored and visualized the multiple/scaled up spheres, one sphere for each resolution. This could be used to visualize how peers are connected for the routing protocol (in the future once this routing protocol is implemented). This is what I called "3D Hooking", the peers conceptually hook into this 3D-multi-level/multi-resolution multi-hexagon-grid structure. 10.8 Uploaded Delphi bindings for UBER H3 library to github and issued a pull request to try and link their bindings documentation to (my) Delphi bindings. Skybuck Flying's Delphi bindings for UBER H3 Library (plus some extra helpfull TH3CellIndex record/unit) currently at my internal folder/unit version 0.05: https://github.com/SkybuckFlying/h3_delphi UBER H3 bindings for other languages document: https://github.com/uber/h3/blob/master/website/docs/community/bindings.md Skybuck Flying's modified UBER H3 bindings for other languages document: https://github.com/SkybuckFlying/h3/blob/DelphiBindings/website/docs/community/bindings.md 10.9 Signed some UBER H3 CLA agreement to be able to do pull requests/commits on UBER H3 github/master: https://cla-assistant.io/uber/h3?pullRequest=645 10.10 For now came to the conclusion that the decision taken at 9.4 was a good/correct decision. The UBER H3 DLL/library was fixed, at least for now it seems to be in a good/complete state. However keep in mind it does seem to depend on external DLLs/runtimes, I will sum them up in here just in case, according to TDUMP, so it might still be usefull to port UBER H3 to Delphi to reduce dependency failures/risks on missing DLLs on end-user systems: I am not sure about this, but for now, to me, it seems like this is the case: Dependencies for release version of UBER H3 DLL/Library (for Microsoft Windows operating system): 1. VCRUNTIME140.dll 2. api-ms-win-crt-heap-l1-1-0.dll 3. api-ms-win-crt-math-l1-1-0.dll 4. api-ms-win-crt-stdio-l1-1-0.dll 5. api-ms-win-crt-runtime-l1-1-0.dll 6. KERNEL32.dll Maybe there is a way to get rid of some of these DLLs to reduce the chance/risk of a dependency failure. For now the gain in days/time (for not having to port it to Delphi) is nice, but it might bite this project and it's users in the ass later, time will tell, if so a port could still be attempted. One benefit would be that by then the UBER H3 library has advanced, however it could also mean more code to port. In case many many new features would be added to UBER H3 library an older version 3 could also be ported, which is the version this project uses for now. However the ammount of changes to UBER H3 will probably be somewhat limited, probably mostly some API renames, then again time will tell. New powerfull features would be welcomed by me anyway, the library already has many powerfull features it seems. 10.11 A quick glance/exploration was taken into an alternative geogrid called DGGRID: https://github.com/sahrk/DGGRID 10.11.1 However there are a couple of issues with it: First of all is it truely an API library ? Or just an application to generate files ? 10.11.2 Second the library depends/requires GDAL which byself requires many many many many other libraries and this would turn into dependency and make and build hell, and what cost a lot of time trying to build/make this, and I wasn't even sure if it offers an IJK coordinate system, because that was the reason why I looked into it as initially the UBER H3 library had some issues with the IJK coordinate system and missing APIs for it, but fortunately that problem/issues with the UBER H3 library has been solved. A quick glance was taking into the manual of DGGRID it does not seem to be suited for API/Library usage and I could also not find any reference/documentation about an IJK coordinate system. So my decision was to stay and stick with UBER H3 library and attempt to fix it, which was done in two seperate ways.