My situation
I want to build a cross platform application, with a gui, that displays a 3d view of some simple cubes, that the user can interact with. Qt seemed like a good tool for the job and I think I have the gui part sufficiently down for the most part. For the 3d part OpenGl or the qt/3d implementation seemed like the right tool, but it does not work. When I try to run the examples from Qt, that use a 3d view, they are unstable, they crash, show a black window and on the offchance, that I find one, that does work there is aggressive flickering and my entire system becomes unresponsive when I only try to resize it. I don't know what is wrong, I don't think I can do a better job, than the official examples and I don't think, that trying to debug the examples is the way to go. (If someone has an idea how to fix this tell me, but I don't even have an error message)
My question:
Is there a simple framework, that would allow me to display simple 3d shapes and include that in a Qt application. I don't need shadows, or reflections or transparency or anything more fancy, than ambient light. Just some solid coloured boxes I can rotate and click on. I think it would even be fine, if it ran on CPU rather than GPU. It would be nice, if I could keep using C++, but if it only exists in another language, what gives. I don't really want to build a framework from scratch. How could I include such a foreign framework in Qt?
I am using ubuntu 20.04 with intel graphics, but as I said, I want the resulting application to work on as many platforms as possible.
I am working on an application that uses Qt3D with then OpenGL renderer. Deploying the app to a handful of users, I found some severe issues with Intel Integrated Graphics, ranging from crash to rendering bugs like flickering. This unfortunately doesn't comes from Qt or OpenGL itself but more from how Intel implements their OpenGL drivers.
The crash bug seems to impact older intel chips, very few references of that apart some random minecraft FAQ on reddit: https://www.reddit.com/r/Minecraft/comments/48ktct/19_faqs/
But what is claimed there seem to align with what my users are experiencing.
The flickering bug has only been reported recently and I unfortunately don't have the right hardware to replicate it yet...
I know it's like random, not sourced information but I thought that personnal experience might help.
I used osgQt many years ago. It looks active still. I know the military likes them.
https://github.com/openscenegraph/osgQt
Related
Anyone who has experimented with Qt QML and 3D OpenGL, I am interested in 2 frameworks I've read about, but it is not clear to me if in fact they are the same framework. The most interesting of the two is outlined in this Qt Developer Days 2013 video presentation by Krzysztof Krzewniak:
http://www.youtube.com/watch?v=29wCpA0DBZI
While very interesting, unfortunately I cannot find anywhere else online some source code for this, or even the name of the framework discussed.
There is QtQuick3d:
http://doc.qt.digia.com/qt-quick3d-snapshot/
However, I cannot tell if in fact this is describing the same framework from Dev Days or if they are separate (and apparently somewhat similar) frameworks? My initial look at the API in comparison to the video suggests they are different, which seems rather redundant to have 2 significant projects in the Qt community attempting to do the same thing.
Can anyone with some knowledge in this area of QML provide some pointers here?
Right, so let us start with some history behind...
Qt was initially a 2D framework for rendering computer graphics UI for simple desktop applications.
Qt3D was developed earlier than qml became mature as an extension to the 2D world provided by the QtGui module, or even QtOpenGL.
It was a 3D Qt api for rendering 3D content on the screen. It had different aspects to deal with 3D objects, build them, put them on the screen, compute intersection, and so on.
The idea was to bring easy to create application concept into Qt rather than always going through QtOpenGL or lower-level API for creating games, simulators, cad applications, and so on.
Right, when QML came out and kept maturing, the Qt3D contributors in Brisbane thought that it would be nice to put a QML API on top of the existing Qt3D C++ API for easy use in QML application. That is how we come to QtQuick3D.
When Nokia decided to shut the Brisbane office done, the Qt3D module pretty much became unmaintained and abandoned only getting a few bugfixes from the community every now and then.
There is some work in progress by KDAB to re-architecture and re-design the module, but it is not mature yet, and it can be found in a separate branch.
The video you are referring to is not dealing with the unmaintained Qt3D module. Rather, it tries to build 3D based on the new scene graph introduced in Qt. Since, there is no Qt3D module working nicely with the new SG in Qt 5, people become pragmatic and move on. That is what you see in the video.
Now, as you can see this is not quite a duplication, but... In the future, the new Qt3D architecture might be acting better with the new scene graph. In fact, KDAB has put a lot of effort into bringing the OpenGL support into QtGui up to real world.
That was the foundation for the Qt3D module which will probably be used in the future (hopefully) by 3D applications written based on Qt, but in the meantime... the video shows how to build hardware accelerated 3D UI based on what we have today.
These two 3d libraries are not the same, you are correct.
There is plenty of reference information you've already linked to online regarding Qt3d 1.0 and QtQuick 3d which are similar and related.
The OpenGL work in the video presentation is something much newer. It is directly laid on top of the QSceneGraph and QQuickWindow functionality.
My recommendation is to not use the approach in this video or the Qt3d/QtQuick3d library. Instead, wait for the KDAB to finish Qt3d 2.0 (which may already be out, you should check). Qt3d 2.0 is a full library for QML that will let you do what is demonstrated in this video.
(http://qt-project.org/wiki/Qt3D-wip-newapi-Overview, http://prezi.com/u-ewejoqxqj2/qt3d-20/)
There are quite a lot of outdated info floating around wikis, and finding useful info and a non-obsolete repository was a pain. So here's what I learned a few months back:
The correct and, as far as I know, the only currently valid git repo is this:
git://gitorious.org/qt/qt3d.git
The "There is some work in progress by KDAB...not mature yet...found in a separate branch." paragraph of Laszlo Papp's answer seems to refer to wip/newapi branch, while master branch seems to be maintained in compilable state (meaning, I have been able to compile it the few times I've tried, YMMV). Master branch should be fine for playing around with Qt3D, but looks like API is going to change.
I played with it a few months ago on Windows 8.0, the MinGW toolchain that is installed with SDK, and using native full OpenGL drivers (which I had to fetch from ATI web site for my card, default Windows drivers are not enough). And looks like it has not broken to bit rot, an example still built and I have a moon rotating on this screen.
It has README file, which will tell you how to build it, starting with building Qt5. Here another good link for that, since the qt3d README is not very comprehensive. And if you're on Windows, just skip Webkit and its deps, unless you really need it, because those extra deps can be a bit of hassle.
I'm a Rails/web developer with little experience with C++, so I'm not totally sure what direction to head in: I'm looking to build a simple simulator that I can use to test an algorithm I'm building that converts standard images to radial coordinates, and all I really need to be able to do is to plot points (which will represent LEDs) on a blank window and continuously refresh them (the LEDs blink). I don't want to build a gui; command line is fine, as I'll be the only person using the tool.
I'm not sure whether this is even possible or not... I did some Java programming years ago and I remember being able to pretty easily open a window and render images in it. Is there a C++ equivalent?
Thanks in advance!
What you are describing is a perfect fit for a GUI application, rather than command line, as far as I understand.
But if you want something really simple, and not spend some time learning a GUI development framework (MFC, Qt, WxWidgets, etc), you should check the following resources:
character based basic console graphics
some more advanced console graphics with blinking, box drawing, etc.
using full GDI graphics on console
It's not that easy in C++, because there is no standard way in doing this. It's not part of the language. There are a lot of frameworks though, some lightweight and some bloating. It also depends your platform. Anyhow, I think I would use OpenGL and do that calculation thing in a shader. That way you don't have to recompile and rerun all the C++ code. You can even do it in way that updates the GPU shader whenever you save your shader file giving you immediate results.
I have a simulation software (C++) that runs on the command line. It is platform independent (currently compiling and running on Windows, MacOS X and Linux). When the simulation ends, I visualize the result with SDL; it is a very basic 2d view, mainly color squares next to each other.
I would like to have a user interface on top of the simulation so that I can start and pause the simulation, and change the parameters on the fly. Something pretty simple I guess. Well, ideally I will also add a grapher somewhere to see the evolution over time of some parameters.
Now, I am wondering what direction I should go.
Should I try to use one of the UI libraries for SDL ?
Or maybe wxwidget in conjunction with SDL ?
Or simply wxwidget and get rid of SDL ?
Do you have any experience with this ?
Thanks in advance
Barth
PS: I tried to use AGAR, a SDL UI library. It seemed very promising but I couldn't get it working. Not even the helloworld.
It may be worth you time to look into Qt. It is generally the most mature free Gui framework available. It is cross platform. And it has hardware accelerated rendering if your drawing needs some speed.
Here is a comparison posted on WxWidgets site.
In the end if your windowing needs are minimal you should choose the framework you are most comfortable with.
Probably using wxWidgets without SDL would be the easiest way to go. SDL is a media layer -- it's supposed to allow cross-platform media application development. As you only need graphical display, you only need wxWidgets -- and it will be a lot easier too!
You would benefit from SDL if:
you'd need very fast blitting of very large amount of surfaces (we're talking the 60fps range here)
you'd use RLE, color keying or other graphics operations
you'd use other media (sound, advanced real-time input, etc)
you'd need to run the software on embedded systems (handheld consoles, etc)
If the answer to all 4 is "no", then you won't benefit from SDL, and using wx alone will be much easier.
I am exploring a possibility to write a kind of a notebook analogue that would reproduce the look and feel of using a traditional notebook, but with the added benefit of customizing the page in ways you can't do on paper - ask the program to lay ruled paper here, grid paper there, paste an image, insert a recording from the built-in camera, try to do handwriting recognition on the tablet input, insert some latex for neat formulas and so on. I'm pretty interested in developing it just to see if writing notes on computer can come anywhere close to the comfort plain paper + pencil offer (hard to do IMO) and can always turn it in as a university C++ project, so double gain there.
Coming from the type of project there are certain requirements for the user interface:
the user will be able to zoom, move and rotate the notebook as he wishes and I think it's pretty sensible delegate it to OpenGL, so the prospective GUI needs to work well with OGL (preferably being rendered in it)
the interface should be navigable with as little of keyboard input as user wishes (incorporating some sort of gestures maybe) up to limiting the keyboard keys as modifiers to the pen movements and taps; this includes tablet and possible multitouch support
the interface should keep out of the way where not needed and come up where needed and be easily layerable
the notebook sheet itself will be a container for objects representing the notebook blurbs, so it would be nice if the GUI would be able to overlay some frames over the exact parts of the OpenGL-drawn sheet to signify what can be done with given part (like moving, rotating, deleting, copying, editing etc.) and it's extents
In terms of interface it's probably going to end up similar to Alias' Sketch Book Pro:
picture.
As far as toolkits go I'm considering Qt and nui, but I'm not really aware how well would they match up the requirements and how well would they handle such an application.
As far as I know you can somehow coerce Qt into doing widget drawing with OpenGL, but on the other hand I heard voices it's slot-signal framework isn't exactly optimal and requires it's own preprocessor and I don't know how hard would be to do all the custom widgets I would need (say color-wheel, ruler, blurb frames, blurb selection, tablet-targeted pop-up menu etc.) in the constraints of Qt. Also quite a few Qt programs I've had on my machine seemed really sluggish, but it may be attributed to me having old PC or programmers using Qt suboptimally rather to the framework itself.
As for nui (http://www.libnui.net/) I know it's also cross-platform and all of the basic things you would require of a GUI toolkit and what is the biggest plus it is OpenGL-enabled from the start, but I don't know how it is with custom widgets and other facets and it certainly has smaller userbase and less elaborate documentation than Qt.
The question goes as this:
Does any of these toolkits fulfill (preferably all of) the requirements or there is a well fitting toolkit I haven't come across or maybe I should just roll up my sleeves, get SFML (or maybe Clutter would be more suited to this?) and something like FastDelegates or libsigc++ and program the GUI framework from the ground up myself?
I would be very glad if anyone had experience with a similar GUI project and can offer some comments on how well these toolkits hold up or is it worthwhile to pursue own GUI toolkit in this case.
Sorry for longwindedness, duh.
Have you tried FLTK? It is made with 3D graphics programming in mind and has interfaces to OpenGL. I wrote some FLTK->Scheme bindings and found the API to be real fun to work with.
OpenGL font support is terrible, in my experience. It sounds like you're going to have to develop all your own custom widgets anyway so don't even bother with a toolkit. You'll spend more time learning the toolkit, trying to figure out how to get that toolkit to work with OpenGL, and and trying to figure out how to make your special widgets in that toolkit than you will just rolling your own. I wouldn't give this advice in just any situation but it sounds like your application and your widget set is going to be very unique. Make a superclass for all widgets, define a draw method, even handler methods, etc., for override, and you've already done most of what those frameworks would do for you.
Also I'm sure you know this but this is an enormous project so you should initially narrow it down to a few simple objectives for a first iteration.
I've been challenged with a C++ 3D application project that will use 3 displays, each one rendering from a different camera.
Recently I learned about Ogre3D but it's not clear if it supports output of different cameras to different displays/GPUs.
Does anyone have any experience with a similar Setup and Ogre or another engine?
At least on most systems (e.g., Windows, MacOS) the windowing system creates a virtual desktop, with different monitors mapped to different parts of the desktop. If you want to, you can (for example) create one big window that will cover all three displays. If you set that window up to use OpenGL, almost anything that uses OpenGL (almost certainly including Ogre3D) will work just fine, though in some cases producing that much output resolution can tax the graphics card to the point that it's a bit slower than usual.
If you want to deal with a separate window on each display, things might be a bit more complex. OpenGL itself doesn't (even attempt to) define how to handle display in multiple windows -- that's up to a platform-specific set of functions. On Windows, for example, you have a rendering context for each window, and have to use WGLMakeCurrent to pick which rendering context you draw to at any given time.
If memory serves, the Windows port of Ogre3D supports multiple rendering contexts, so this shouldn't be a problem either. I'd expect it can work with multiple windows on other systems as well, but I haven't used it on any other systems, so I can't say with any certainty.
My immediate guess, however, is that the triple monitor support will be almost inconsequential in your overall development effort. Of course, it does mean that you (can tell your boss) need a triple monitor setup for development and testing, which certainly isn't a bad thing! :-)
Edit: OpenGL itself doesn't specify anything about full-screen windows vs. normal windows. If memory serves, at least on Windows to get a full screen application, you use ChangeDisplaySettings with CDS_FULLSCREEEN. After that, it treats essentially the entire virtual desktop as a single window. I don't recall having done that with multiple monitors though, so I can't say much with any great certainty.
There are several things to be said about multihead support in the case of OGRE3D. In my experience, a working solution is to use the source version of Ogre 1.6.1 and apply this patch.
Using this patch, users have managed to render an Ogre application on a 6 monitors configuration.
Personnaly, I've successfully applied this patch, and used it with the StereoManager plugin to hook up Ogre applications with a 3D projector. I only used the Direct3D9 backend. The StereoManager plugin comes with a modified demo (Fresnel_Demo), which can help you to set up your first multihead application.
I should also add that the multihead patch is now part of the Ogre core, as of version 1.7. Ogre1.7 was recently released as a RC1, so this might be the quickest and easiest way to have it working.