Windows libraries / Qt 6.4 support ?

[u-an-i]

Hello,

I guess the distributed binary libraries are Linux libraries?

I wanted to build your awesome looking project (just what I need :) ) for Windows Qt 6.4 64-bit MingW but I receive a "makefile" error 255 (which I also receive when building for Qt 5.15 both shared and _shared_andstatic for CONFIGURE in the .pro file)

I had to perform some modifications to get it compile for Qt 6.4 as well as to get it compile for Qt 5.15 on Windows 64-bit MingW:

    QOpenGLFunctions *f = QOpenGLContext::currentContext()->functions();

    f->glFunctionCall();

in void Qt3DWidget::paintGL()

and add LIBS += -lOpengl32 in the .pro file

Also, Qt 6.4 exclusively: replace opengl by openglwidgets in the .pro file and use Qt3DRender::QRenderAspect::Automatic instead of Qt3DRender::QRenderAspect::Threaded

See https://forum.qt.io/topic/140693/opengl-make-error-255

[florianblume]

Hey,

thanks for your feedback :) I'm usually only on Linux so it didn't really occur to me to test it on Windows. And yes, you're right, the binaries are Linux binaries. Looks like Windows and newer Qt versions need some checks in the .pro file and in the code itself, too. But I take it from your issue that you made it work?

If your updated version is running on Linux and Windows as well I'd be happy to receive a merge request from you!

[u-an-i]

Hi :)

PR created https://github.com/florianblume/qt3d-widget/pull/7 ,

but the test exe errors and I don't know why:

note the already copied dlls (see the PR comment)

[florianblume]

Cool thanks for the quick pull request! I think we should still solve the issue of the platform plugin before performing the merge.

So it seems like the test program doesn't finde Qt in the first place, right? Because I remember when I built the Linux app I was able to launch it. I suspect that in your case you need to make the folder plugins/platforms of your Qt distribution available to the program. Either by copying it to the same folder but better would be if we solve that it doesn't find Qt. Do you have any thoughts on that?

[u-an-i]

The exe does run when run from inside Qt Creator.

It does not run when launched from the build folder.

The app for which I decided to employ Qt3DWidget shows the same behaviour even when going back to using Qt3DExtras::Qt3DWindow thus I assume it's unrelated to your widget or my build but my system and I unfortunately have something to figure out for my installation.

One thing I wondered was why the .dll and an .a was created having a 2 in the filename.

[u-an-i]

"i" figured it out : https://forum.qt.io/topic/140753/build-launches-form-within-qtcreator-but-exe-cannot-find-qt-dll-s-when-launched-from-folder

[florianblume]

Ah I remember I had similar issues with 6D-PAT, there I had to tell linuxdeployqt to include the libraries. I'm glad you solved it!

Not sure about the 2 in the filename, though. I'll have a look when I've got time and then merge your merge request.

I was thinking maybe to even setup a build pipeline with a build matrix to create the pre-compiled binaries for multiple OSes and distributions.

[florianblume]

And I'm intrigued, what program are you making?

[u-an-i]

:)

I want to create a replacement to KDE Marble limited to needs of another application and even further reduced in functionality which I would align with that applications author. I "know" i'm "publicising" my intent now, i like to achieve a prototype first before i inform that author.

[florianblume]

Wow that sounds like a cool and complex project! Let me know if you want help implementing it, after all these years after originally starting 6D-PAT as a university project I've got some experience with Qt3D and enjoy creating stuff with it :)

[u-an-i]

it has the potential to turn out complex, what I envision i already shaped or at least set the direction for inside my head and "all i need" is to implement it. Which I want to do first. On the other hand I could ask you if you like to implement it if you like. The challenge for me is to implement it using the API of Qt. What i currently like to implement is rather simple. I share this outline now:

Intro

KDE Marble is a provider of a (geo-)maps-mapped view (2D and 3D) and geo methods such as distance between 2 points on a globe (along the shortest distance above the globe=sphere surface) (if I remember correctly, if not i would try to align but anyway i like to implement the following). https://marble.kde.org/

It is used in an aviation flight planning software, Little Navmap. I helped updating the webserver delivered view's interface. Apparently Marble is a bit of a pita to (still) integrate into the project. This is what made me consider updating "it". https://albar965.github.io/littlenavmap.html

I heard about a Standard defining map data delivery across the internet. I found 1 service provider applying that Standard to 1 of its data. Unfortunately that Standards spec document is 129 pages of -- to my liking -- incomplete information about how data is supposed to be delivered and extracted from the delivery. However the 1 service provider I found is a "known entity" and it also delivers "classical" tiled satellite maps by http GET requests and presents good documentation itself. The Standard is https://www.ogc.org/standards/wmts and the service provider is https://developer.tomtom.com/map-display-api/documentation/raster/satellite-tile (link to "classical" map)

In my experience of the map view inside LNM it sometimes took a while to have the map data present for a zoom level and panning was not 60 fps fluid.

Vision

a 3D hardware accelerated view of those maps (so DX, Vulkan or OGL):

a TT map tile will be a texture of a quad (2D case). Per zoom level 4 quads (2x2) will be present, only 1 quad when zoomed out completely. The next zoom level's data is loaded when 1 quad would fill the viewport either in x- or y-axis. Only the active zoom levels quads shall be sent to the gpu, the once used quads shall be cached in (main) memory as far as (a custom limited) space allows. TT map tiles should additionally be cached on permanent storage for a limited time and also as far as (a custom limited) space allows.

Number of quads is to be evaluated, perhaps they better correspond to the resolution of the viewport and the texture size so that 1 "texel" is 1 pixel. Zoom behaviour is also to be evaluated experimentally.

Zooming shall (for first implementation) occur by mouse wheel around mouse pointer position. Something like a raycast from mousepointer position along the view direction is needed (I don't know whether Qt3D offers this, view direction would be depth axis in center of viewport). Perhaps an orthographic projection of/to the camera is most fitting (as the 3D projection method in the 2D case). The position on the map below the pixel of the mouse pointer shall remain the same when zooming. Panning shall occur (also ffi) by mouse drag and "flick".

Precaching for zooming and panning is to be evaluated.

Switching between 2D and 3D shall be offered.

Image superposition shall be offered (like for markers, perhaps a separate quad having that texture).

Single geodesic line drawing shall be offered (like a flight route).

Math

per zoom level n 2^n tiles are available from TT in each x and y direction
assumption: a next level's x4 tiles correspond 1:1 to the previous level tile ie the 2x2 tiles look like a sharper version of the 1 tile exactly locations-wise (not necessarily time of day, year wise)
zoom level = map data, when zooming "distance to camera" is rather a size-changing of quads while the distance of the camera from the quad remains the same (i would determine the actual way of implementation when i'm at that) orthographic projection: keeping a location constant at a viewport pixel:
let x,y be the viewport position of a location below the mousepointer wrt the top-left corner of the viewport;
let u,v be the position on the quad below the mouse pointer in the range of 0..1 each (0 left/top edge, 1 right/bottom edge);
let a,b be the position of that quads top-left corner in (virtual) viewport pixels (might be negative);
let s be the quads size (edge length) at the distance to the camera when starting zooming;
let a,b,s with suffix 2 denote their value at another "distance to the camera";
then:
a + u s = x = a2 + u s2
b + v s = y = b2 + v s2
we know x,y,a,b,s and s2 (s is the actual value changed when zooming)
...

[u-an-i]

Time

I have a weekday job which takes around 10.5 hours of my time per such weekday from waking up to be able to do something privately. In that private time I occasionally do other things than programming in particular around now although I'm energetic to progress here. I am tired rather often for which I use to prefer getting rest rather than working-through like I almost do now (already rested 4 hours after work today :) )

[u-an-i]

i put my very beginnings of the projects code into a private GitHub repo and invited you. Currently the QtDesigner designed Widgets are still hidden by the Qt3DWidget. I guess i try to prepare a frame inside QtDesigner and set that as the Qt3DWidget's parent. The code is test code only.

[florianblume]

Thanks, I accepted the invitation. I'm not sure I fully get what needs to be done but it sounds interesting. It's the same for me, I've got a full time job so there's often not much time left to do things ;) I don't think I've got the capacities to become a developer on the same level as you since it seems like a rather large project but if you for example create issues in your project I'd be happy to also take a look at them :)

[u-an-i]

👍 :)

[dragazsolt]

I have a same issue using Qt5.14 Windows version with MinGW 64

Could you please help me to find issue?

Thanks, Zsolt

[u-an-i]

@dragazsolt does https://github.com/florianblume/qt3d-widget/pull/7 help you? I fixed some Windows issues therein, albeit for Qt 6.