Qt's announcement webpage & video doesn't explain it very well. This is not a "3d game engine" like Unreal/CryEngine. It's an HMI (Human-Machine Interface) library and visual design editor . Therefore, it doesn't have a "physics engine" nor does it need one.
Probably the better webpage to get an idea of the use cases of "HMI" is the original NVIDIA pages:
>Why does the example _have_ to pull in Qt Quick to show live data?
I'm only going by the Qt webpage so I can't say that it absolutely requires Qt Quick as a unavoidable prerequisite. The Qt announcements says:
- ", so that designers can easily create 3D user interfaces that are easily integrated with the rest of the application written in Qt. The UIs can then also easily be extended using Qt Quick or Qt 3D."
So the demo video is showing how the UI interface created in 3D Studio is then integrated into a Qt Quick window.
Could Qt have made a demo with zero Qt Quick controls? Maybe. I don't know.
Not sure if "3D Studio" is a good choice. Autodesk used to have a product like that. Looks like the trademark got cancelled, but still, why create confusion?
Qt is an awesome framework, but I feel like most of their promo material really makes you work to figure out what is going on... I still see people get confused at QWidgets vs. QtQuick and the various tradeoffs.
Qt Widgets: produces "classic" almost-native looking applications for Windows, macOS, and Linux. think lists, treeviews, menus, dialogs. C++ API
Qt Quick Controls: like Qt Widgets, but with a QML (a declarative markup language) API
Qt Quick Controls 2: doesn't try to look native on any platform, instead you create your own look and feel or use one of their pre-made themes (they have a Material design theme for instance). end result looks a lot like Electron applications. I believe these run on iOS and Android, as well as Windows, macOS, and Linux. QML API
Qt Quick: umbrella term for both of the previous categories
to make things worse there's very little guidance on what type of application each should be used for, and it seems like a lot of the work in the recent Qt releases has been focused on Qt Quick, making me wonder if Qt Widgets will be considered deprecated soon.
I just tried to use it back in the 5.4 days and discovered that C++ Widgets weren't an option for mobile devices, which is still the case, now with their QML focus.
Ended up using a mix of Java, C++/CX and C++ instead of Qt.
However, with every GUI toolkit pushing C++ down the infrastructure alongside something more productive to the upper layers, pure C++ devs need to get used to being polyglot for UI code.
I doubt we will see again a pure 100% C++ GUI toolkit earning the hearts of the masses, specially if you look at what is available from Apple, Google, Microsoft and Qt.
The real problem IMHO is that making a "native" yet "crossplatform" UI has become essentially impossible. You need to re-code the application for every platform.
Which makes it understandable that people just go "fuck this, I'm making a webpage".
You don't need to fully re-code the application for every platform., I was doing cross-platform before Qt even existed, back in the 16 bit days, even in Assembly between platforms with the same processors.
The point is that you need to properly layer the common code from the platform specific code, from day one.
Also writing web apps, usually means "write once debug everywhere" due to the differences between browsers and rendering engines. And in some platforms, specially embedded ones, it is back to the days of "alert()".
I'm not sure if you understood the "native yet crossplatform" part.
I'm not talking about native code, I'm talking about a native looking UI. In other words, Win32 on Windows, GTK/Qt on Linux, etc. Instead of Electron or QML.
Obviously you don't need to rewrite the backend unless you're an idiot. But in some applications, the frontend part is huge.
Sure I did, hence why I mentioned it needs to be done from day one.
The whole set of abstraction modules, need to be properly defined so that the whole architecture is able to use the best patterns from each platform without feeling a kludge.
How do you think many of us wrote portable software across Atari, Amiga, Acorn, Mac and PC?
One needs to abstract platform concept's like opening files into a modular API that accepts only the application relevant parameters, then provide an implementation using the platform specific UI toolkit.
It was harder to do with the Assembly applications, due to the hardware differences, but it was still possible to keep some code for those that shared the same processor architecture.
Still using a similar modular approach. Here using macro assemblers was a big help.
I still don't see how this is going to protect you from writing native code for all platforms. You can have all the abstractions you want, at some point you need to code to the native toolkit. The code that actually gets a window or button on screen, or receives (rather than processes) the input events.
In case it isn't clear: Qt Widgets (and WxWidgets) did this for you. You could literally compile a native looking and feeling app for the major platforms from an identical C++ codebase.
Qt emulates the platform L&F hence why Mac users "love it".
Also Qt doesn't do this for any mobile OS. You are expected to do it yourself with QML. The Quick Controls only cover the mostly used ones and still don't do iOS or UWP themes.
Yes you need to write platform specific code, but it makes use of the native UI, not emulating it, and after a while you have your in house framework, so it is not like you are writing from scratch every time.
This is the approach taken from Dropbox or Microsoft, for example.
C++/Qt Widgets does mostly work quite well on mobile. I have some similar bug reports about widget scaling. Overall, i still plan to port a desktop app like this - working around these kind of issues seems easier than rewriting the frontend for mobile.
On my case, re-writing was anyway required, so I decided to use the native languages instead of QML, specially because I would need QML versions for Android and UWP anyway.
At the risk of "cursing in the church", I think honestly UI work doesn't seem like the purpose of a systems language like C++ though, rather to give liberties in memory management to optimize intensive algorithms etc. I don't think much would be lost in performance with a C++ backed QML based interface, but much might be gained in productivity in the long run, discounting relearning.
So this allows you to make Qt interfaces that are essentially collections of models in 3D space fully rendered and providing UI interactivity / information display?
Because 3d in VR/AR feels really unnatural without a little bit of physical smoothing of movement.
At the very least easing and collisions are necessary to make interactive components.
Right now most of the game engines are total overkill for business apps but basic GUI libraries don't have the physical attributes that make for a natural, intuitive user experience. We are really lacking tools for this new experience.
I don't think Qt has solved this problem but I think it demonstrates the need exists.
I understand this is a UI tool and not a 3D game engine, but it still might be really neat to give designers the ability to use PhysX in their UI animations.
Probably the better webpage to get an idea of the use cases of "HMI" is the original NVIDIA pages:
http://www.nvidia.com/object/drive-design.html
http://www.nvidia.com/object/drive-automotive-technology.htm...
http://www.nvidia.com/object/automotive-infotainment-navigat...