This question and answer, in Oct 2015, implies it is possible to change Qt3D mesh and update it:
Question
I want to use Qt3d in a situation that involves dynamic runtime
changes of geometric data on the application side.
What is the best way to dynamically change a mesh for an entity?
I'd rather do all this on the C++ side, but QMesh doesn't seem to
provide an API for changing the mesh data.
I looked at some other examples of making a custom QAbstractMesh class
and QAbstractMeshFunctor. It looks like I could possibly make a custom
mesh type to do what I need but I have a question. If I keep a
reference to the QMeshDataPtr that I make from the functor, can I
simply modify the mesh data whenever I want and the entities that
reference it will update automatically?
Answer
The API for this has changed a little in 5.6. The geometric data is
now contained in one or more QBuffer objects and is referenced by one
or more QAttributes that describe the data layout in the buffers. The
QAttributes are rendered by adding them to a QGeometryRenderer
component.
You can either update the above objects on the main thread and call
update() or as before you can also use a functor to have the backend
generate the dynamic data.
Now, my question is about calling update(). Exactly what section of Qt3D API is referred to?
There is a test available at Qt installation directory on my Linux machine:
/home/{user}/Qt5.12.6/5.12.6/Src/qt3d/tests/manual/custom-mesh-update-data-cpp/
which I discovered by following this link when searching Google for qt3d mesh update keywords.
The above test is using Qt3DRender::QBuffer API to update mesh data:
void QBuffer::updateData(int offset, const QByteArray &bytes)
Updates the data by replacing it with bytes at offset.
Note: This function can be invoked via the meta-object system and from QML. See Q_INVOKABLE.
Code looks like this:
Qt3DRender::QBuffer *vertexDataBuffer;
// ...
QByteArray updateData;
// ...
vertexDataBuffer->updateData(pos,updateData);
// ...
I have the following situation.I have a renderer based on OpenGLES 2.0-3.0 APIs.I need to embed it into Qt based desktop widget app.I have read about Qt GL wrappers ,which is one way to use GL ES API in Qt App.But in my case I cannot afford rewriting the whole engine rendering code to use Qt's GL wrappers not only because of the scope, but mostly because of portability issues.So I tried to include GL/GLES3.0/gl3.h headers which are exposed in Qt SDK. Doing this I am getting all sort of header collision errors, for example like this one:
D:\Qt\5.8\msvc2015\include\QtANGLE\GLES3\gl3.h:73: error: C2371:
'GLsizeiptr': redefinition; different basic types
So how can I use just raw OpenGL ES API in Qt?
For Desktop OpenGL I know I should build the SDK with desktop opengl flag on,and then use some GL loader lib like GLEW to init all the GL func pointers.Does it mean I must do something similar for GLES? For example ,building the SDK without ANGLE,then link with ANGLE lib explicitly?
I have asked this question also on Qt's forums.Received no answer.
UPDATE:
I examined some Qt headers to see where the above mentioned collision happens.So Qt has qopengl.h header which declares GL functions and types.But it also has ANGLE's gl headers,which I try to include and which declare the same stuff.So this causes the collision.I don't understand why they allow both headers into the SDK.How to get rid of qopengl.h and run with ANGLE headers only?
I have a 3D environment done in Unity which I wan't to have as an Item in Qt (QML). I've tried a few different paths, but none has proved to be efficient enough or I'm unable to get it to work.
My current working solution is to do the following each frame
In Unity, use ReadPixels of my RenderTexture (GPU) to get a regular Texture (RAM).
Encode to JPG and send bytearray through TCP socket.
In Qt, instantiate a QImage from the data and save it for later use.
In the render function of QQuickFramebufferObject::Renderer, use glTexImage2D to render the image to my active texture.
Obviously this is not an optimal solution. This performs maybe 10 fps with a 128x64 texture size (for testing). My understanding is that the bottleneck is transferring data from gpu and back.
In my latest attempts I have tried to get the ID of the RenderTexture using renderTexture.GetNativeTexturePtr(). Then in Qt I'm trying to get the pixel data through glGetTexImage, but I keep getting 0's in the data. When later using glDrawPixels, the Qt application crashes.
So my question now is, do anyone know if it's possible to share the texture between processes and if so, how?
Considering :
http://doc.qt.io/qt-4.8/qdeclarativebasictypes.html
there is no strict equivalent of "byte" in QML.
Nonetheless, I have to manipulate some datas in a whole project, and QML file are an intermediate for communications. And some of these datas are some byte...
What can I do ?
(found some links about QVariant but I don't feel like I can use it in QML)
I've already seen your question in Qt forum, but left with the intention that someone with better knowledge can help you.
Could you please tell about your necessity to use a byte in QML. If it is going to be standalone application, you can handle (and only can - I think) it using a C++ datatype like char and display/present it from the QML side.
If it just going to be a QML file, then I think you have to create a byte like object with Qt C++ and use it to store the values.
I definitely don't think that QML can handle file operations, neither can it access any serial port services. So the C++ can handle these situations without any difficulties.
If you don't actually use those bits in QML you might be able to save in an integer and then get those back.
I want to use OpenCV's image processing functions, but not the OpenCV GUI. I'm using OpenCV 2.0. I will use either Qt4 or WxWidgets for GUI functions. I compile with VC++ 2008 Express (VC++ 9.0).
I guess it breaks down to two or three questions:
Is it necessary to do something to disable OpenCV's higui so it does not interfere with the preferred GUI library, and if so, how?
How to convert an OpenCV image into something (bitmap?) that the preferred GUI can display (and perhaps save)?
(Optional) How to convert an image that was loaded using the preferred interface into a form that OpenCV can use?
Okay. I've got the answer to my own question for WxWidgets. One key is not to fight openCV City Hall about RGB sequence. OpenCv really likes "BGR". WxWidgets uses "RGB" only. The opencv data structure has a field for byte sequence, but it is seldom honored. Even the highGui function (on MS Windows) that displays an image will put up spectacularly blue tangerines if the byte sequence is set to "RGB". I stubbornly fixed that bug in my local installation, but other operations failed also. So, I just sigh and set the byte order on the opencv side to "BGR" and do the byte swapping as necessary.
The C++ code below requires that the openCV images that it converts to wxImages are RGB, sequence "BGR", 8 bit depth and 3 interleaved channels, and have width_step = width*3. The routines don't check compatibility. Use at your own peril. A ready-for-primetime version would provide for regions of interest (ROI) and other fanciness.
#include "wx/wx.h"
#include "cv.h"
#include "highgui.h" // Optional
void copy_and_swap_rb(char *s, char *d, int size) {
// Copy image data source s to destination d, swapping R and B channels.
// Assumes 8 bit depth, 3 interleaved channels, and width_step = width*3
const int step = 3;
char *end = s + size;
while (s<end) {
d[0] = s[2];
d[1] = s[1];
d[2] = s[0];
d += step; s += step;
}
}
void wx2cv(wxImage &wx, IplImage *ipl) {
// Copy image data from wxWidgets image to Ipl (opencv) image
// Assumes ipl image has seq "GBR", depth 8, and 3 channels, and
// has the same size as the wxImage, and width_step = width*3.
copy_and_swap_rb((char*)wx.GetData(), ipl->imageData, ipl->imageSize);
}
void cv2wx(IplImage *ipl, wxImage &wx ) {
// Copy image data from Ipl (opencv) image to wxImage
// Assumes ipl image has seq "GBR", depth 8, and 3 channels, and
// has the same size as the wxImage, and width_step = width*3.
copy_and_swap_rb( ipl->imageData, (char*)wx.GetData(),
wx.GetWidth()*wx.GetHeight()*3);
}
IplImage *cv_from_wx(wxImage &wx) {
// Return a new IplImage copied from a wxImage.
// Must be freed by user with cvReleaseImage().
IplImage *ret = cvCreateImage(cvSize(wx.GetWidth(), wx.GetHeight()),
IPL_DEPTH_8U, 3);
wx2cv(wx, ret);
return ret;
}
wxImage wx_from_cv( IplImage *cx) {
// Return new wxImage copied from a compatible IplImage.
// Assumes ipl image has seq "GBR", depth 8, and 3 channels
// Fear not. The copy on return is cheap; does not deep-copy the data.
wxImage wx(cx->width, cx->height, (unsigned char*) malloc(cx->imageSize), false);
cv2wx(cx, wx);
return wx;
}
I know I'm super late to this discussion, but I just happened across it. Anyways, I've been using OpenCV and wxWidgets together quite happily for a few years now, so I thought I'd pitch in:
Is it necessary to do something to disable OpenCV's higui so it does not interfere with the preferred GUI library, and if so, how?
Not generally. There are a couple hiccups that you can run into for specific versions of OpenCV and Windows. For the most part, though, the integration is very smooth. I routinely use wx for my front end and the parts of highgui that enable image capture. I've done this on several versions of Windows, Ubuntu, and OS X.
How to convert an OpenCV image into something (bitmap?) that the preferred GUI can display (and perhaps save)?
An alternative to copying back and forth between a wxImage is stuffing the IplImage's data directly into an OpenGL texture and painting it on a wxGLCanvas. One big advantage for this strategy is that you can then draw on top of the texture using standard OpenGL methods.
(Optional) How to convert an image that was loaded using the preferred interface into a form that OpenCV can use?
Don't :) I use wxFileDialog etc to let the user specify paths, but all of the backend is directly OpenCV.
(begin self plug)
Code I've written to do a lot of this is part of a project called MADTraC, which is a GUI/application framework for real-time computer vision applications.
(end self plug)
Is it necessary to do something to disable OpenCV's higui so it does not interfere with the preferred GUI library, and if so, how?
Answer: I don't see why it should not be doable or it is a poorly designed library (which I don't think OpenCV is).
For your other questions (and the "How" of question 1), I did a quick search on QtCentre and found an interesting thread about OpenCV integration with Qt. There is some source code examples that you can look at.
If you don't find what your are looking for in that thread you can start a new one.
Or google for OpenCV integration in Qt or search on Google Code, there is some projects using both Qt and OpenCV (OpenCV Stereo Vision is one).
Good luck.
Well I don't know much about OpenCV, but I work with wxWidgets alot.
I highly recommend wxWidgets simply because of its intuitive structure and code layout.
Also, QT is only available under the LGPL on Windows, so licensing may be an issue. wxWidgets can be used in commercial projects without restrictions.
As for converting images back and forth, wxWidgets has a large number of classes/functions for working with images.
I have made a little progress. The GUI part of OpenCV does seem to stay out of the way. I have even used it in a WxWidgets application to show an image, and nothing bad seemed to happen. That was on a Windows XP box using VC++ 2008. The only interaction that OpenCV/highGUI appears to have with the windowing system is to make direct Windows API calls and to monitor the event queue for keyboard events, which it passes on.
I'm working on how to convert from OpenCV images to WxWidgets images and back. A big help you guys are. :-)