Introducing Qt 3D Studio | Hacker News Reader

Introducing Qt 3D Studio

blog.qt.io

132 pointsadamnemecek41 comments

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:

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...

I'm not even sure this is an HMI library. Why does the example have to pull in Qt Quick to show live data?

>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.

From watching the video it looks like you can make a demo...it just can't do anything interesting or productive.

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?

http://tmsearch.uspto.gov/bin/showfield?f=doc&state=4806:i1y...

3D Studio turned into 3D studio max which then turned into Discreet 3DS MAX which Autodesk bought out

Is this a move to enter in to the VR space. If it is then its awesome.

It's also exactly the kind of thing we'll need for mixed reality. Good to see them getting started early.

Awesome news. But is that video meant to show something? I sure cannot make out what it was trying to say.

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.

seriously, their naming scheme is so confusing:

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 get the feeling they are trying to cater to the Electron generation and hence focusing on QML and related technology.

Many new APIs are indeed QML only, like support for device and mobile UIs.

At the expense of alienating C++ devs.

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.

https://bugreports.qt.io/browse/QTBUG-42491

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()".

Say what you will, printf-debugging never dies.

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.

Also Qt doesn't do this for any mobile OS. You are expected to do it yourself with QML.

Right, that's the "did this" part. It no longer works.

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.

Oh Yes their marketing sucks but products are awesome. QtCreator is one of the best c++ editor and debugger. But the marketing just sucks.

Reminds me of Adobe Flash Pro application with tweening animations, code behind, etc. but with full 3D support.

What do you mean? It's fairly obviously showing how you can design a Qt 3D interface using Qt 3D Studio.

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?

Nvidia and Qt ? Seems very good partnership to me.

Qt 3D lacks so much extensibility and stability.

No physics library, full of crash and UB, small community and slow bug fix. It need more time to be polished.

Why would a GUI library need a physics engine?

Exactly! This isn't a game engine.

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.

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.

Source: I write AR apps.

Is this primarily for 3D design?

I think it's for designing 3D UIs.

So they built a game engine?

I think this is mainly for automotive (a space where NVidia and Qt depend on each other and want to grow).

However could be used for anything!

FTA it is my impression that this is about making 3D GUIs.

No, they built a library for 3D GUI's.

Reply on news.ycombinator.com