Re: [Development] Qt 3D Maintainership
Hi all, I'd also like to say a big thank you for all the work you have put into Qt 3D. It is a great graphics API and is getting better with each release. I would be more than happy to be a co-maintainer of Qt 3D Render and will also help out with Qt 3D Core and the other modules. I agree with Laszlo that it is a good idea to sync up on the future of Qt 3D and the Qt graphics stack. We need a clear vision of what the scope of Qt 3D should be and how we should handle existing and new features that fall both inside and outside of this scope. As we add support for more backends, we also need to decide on how much of the underlying graphics API, such as OpenGL flags, should be abstracted away. The transition to Qt 6 is a good opportunity to make some changes in this area. It will be great to have a unified 2D-3D engine that can run on top of the different graphics backends and be a flexible foundation for both Qt Quick's Scene Graph, Qt 3D Studio, and other modules like Qt Charts and Qt Data Visualization. Cheers, Svenn-Arne On 14. sep. 2018 15:52, Laszlo Agocs wrote: > Hi guys, > > Thanks, Qt 3D is almost certainly going to be an important piece in Qt 6. > Once the dust settles and we have a clear view of the new maintainership > structure, we should definitely sync up on the state of things and plan a bit > ahead since there's plenty to be done and think about, especially with Qt 6 > and its potentially unified 2D-3D engines in mind. (renderer optimizations, > graphics API abstractions (RHI), shader graphs, some new features of course, > , fun times ahead :) ) > > Cheers, > Laszlo > > -Original Message- > From: Development On > Behalf Of Lars Knoll > Sent: fredag 14. september 2018 14.50 > To: Tuukka Turunen > Cc: Qt development mailing list ; Sean Harmer > > Subject: Re: [Development] Qt 3D Maintainership > > Hi Sean, > > First of all thank you for all the great work on Qt 3D over the last years. > Qt 3D has become a very important part of Qt, and I believe that parts of it > will get a much more central role in our graphics stack when we move towards > Qt 6. > > I’ve been discussing a bit with the graphics team in Oslo, and I think the > idea of having Laszlo as a co-maintainer is good. I would also like to > propose that we have Svenn-Arne as the co-maintainer for the renderer > component. He’s been doing a lot of good work in that area over the last year. > > We’re also trying to find candidates to help with some of the other modules, > and I hope we’ll at least one more person we can nominate there next week. > > Cheers, > Lars > > >> On 14 Sep 2018, at 12:47, Tuukka Turunen wrote: >> >> >> Hi Sean, >> >> Yes, Qt 3D certainly growing both in size and importance. Happily also the >> number of people working on it has been growing nicely. >> >> In addition to you and Paul, I believe we should be able to find 1-2 >> additional from developers of The Qt Company working on Qt 3D. >> >> Would it be possible to have someone from KDAB to maintain Qt 3D Extras? >> That is an area we have not touched that much. >> >> Yours, >> >> Tuukka >> >> On 14/09/2018, 13.29, "Development on behalf of Sean Harmer via >> Development" > behalf of development@qt-project.org> wrote: >> >> Hi All, >> >> my time available for Qt 3D outside of work, has as of late, been >> reduced due to increased family commitments - the good kind, but time >> consuming nonetheless. >> >> Given how Qt 3D has grown from our simple experiments in making 3D >> possible with Qt to the highly-configurable, multi-module, data >> processing monster it is today I feel it is no longer possible, nor >> wise, for me to maintain alone. Additionally, it looks as if Qt 3D will >> form an important piece of the graphics stack for Qt 6. >> >> As such I would like to propose that we split the maintainership and I >> would propose that Laszlo Agocs becomes co-maintainer. I am still happy >> to co-maintain and I have plenty of ideas about improvements we can make >> both within the Qt5 and Qt 6 time frames. We have learned a lot whilst >> developing Qt 3D and I think we can make it even better for Qt 6. >> >> I would also suggest that we find maintainers or co-maintainers for the >> sub-modules. I would propose Paul Lemire as (co-)maintainer for the >> render module. I'm happy to keep driving the animation module and help >> with qt3dcore. Other nominations are of course welcome. >> >> Kind regards and have a great weekend, >> >> Sean >> ___ >> Development mailing list >> Development@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> >> >> ___ >> Development mailing list >> Development@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >
Re: [Development] Programmable delegate selection for QML views
On 08/06/2018 05:03 PM, Mitch Curtis wrote: -Original Message- From: gr3...@gmail.com On Behalf Of Pierre-Yves A default delegate looks like the sensible way to go indeed. But should we REQUIRE one ? Why can't we just not instantiate something when no fitting delegate is found ? That's what I believe #1 is actually doing. It's an interesting question. :D Personally I don't see the point. The behaviour for views has always been that there will always be a delegate available when it is needed. How would "missing" delegates work? I would imagine that would mess up something, somewhere internally in Qt Quick view classes. Or to ask it a different way: why do you have data in your model if it shouldn't be displayed? Sounds like it would be useful to filter data in a view. For instance, if you have multiple views of the same data, but want only certain data categories in each view. This could also be used to create dynamic filters with a custom delegate chooser. That being said, we already have existing and powerful mechanisms to filter data in Qt, and I'm not sure if adding yet another mechanism to choose from is a good idea. However, I see many users setting the "visible" property of their delegates based on some logic as a hacky filter implementation today (just search for "how to filter data in QML"). This is typically because subclassing QSortFilterProxyModel is too much hassle for a simple list, for instance if all you need is a ListModel with 50 items and a search box. I don't have a complete overview of models/views in QML, so please correct me if there are other simple, yet more elegant ways of filtering in these simple cases. Otherwise, this might be worth keeping in mind in this discussion. Svenn-Arne ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] clang-format
On 07/03/2018 10:26 AM, Lars Knoll wrote: On 2 Jul 2018, at 16:52, Tor Arne Vestbø <mailto:tor.arne.ves...@qt.io>> wrote: > > > >> On 2 Jul 2018, at 16:49, Lars Knoll >> <mailto:lars.kn...@qt.io>> wrote: >> >> >>> On 2 Jul 2018, at 13:35, Tor Arne Vestbø >>> <mailto:tor.arne.ves...@qt.io>> wrote: >>> >>> >>>> On 2 Jul 2018, at 12:56, Svenn-Arne Dragly >>>> <mailto:svenn-arne.dra...@qt.io>> wrote: >>>> >>>> There are also many nice options set in the clang-format config found in Qt >>>> Creator's sources[2] which I think are interesting. For instance, >>>> "BinPackParameters: false" and "BinPackArguments: false" makes sure you to >>>> either put all arguments on one line or give if arguments will have one >>>> line each. This might be in the controversial category, but it is nice to >>>> enable while developing. It makes clang-format reflow the code consistently >>>> just by moving a single argument to a new line and running clang-format >>>> afterwards. >>> >>> I oppose mandating this style, through clang-format or otherwise. >> >> Having a common style that we start following is worth something. And yes, >> everybody will always find some details he won't like. So we won't get >> anywhere if everybody wants it exactly his way. > > Why not ease into this with the non-controversial style-rules first? clang-format will produce one way how the output is formatted. It will reformat your sources a certain way with less definitions in the file as well. So it's most likely better to have more rules defined as it'll give something closer to our implicitly used coding style. Cheers, Lars Not necessarily. With fewer options set, clang-format does leave some things as is, so the output is not always the same. For instance, if you leave "BinPackArguments" unset and set "ColumnLimit: 0", clang-format will respect your choices regarding argument placement. The following code is for instance kept intact in that case: auto result = myFunction(arg1, arg2, argument3, arg4, argument5, 0, nullptr); And similarly, this is kept intact: auto result = myFunction(arg1, arg2, argument3, arg4, argument5, 0, nullptr); Setting "BinPackArguments: false" or "ColumnLimit: 100" does on the other hand make clang-format reformat the above function call accordingly. I agree with you, Tor Arne. I think it is better to start out with a config with only uncontroversial settings enabled. This already gets us pretty far and we'll have fewer arguments about style. And to be clear, I also don't want to mandate setting "BinPackArguments: false". I wanted to mention it because I found it nice to enable locally, even though it is far from perfect. If anything should be mandated with regards to argument placement, it should probably be more sophisticated or simply rely on a fixed column count. However, a comprehensive clang-format config would be the best in the long run. So even though I think we should start with a minimal config, I also think we should start discussing the controversial options in separate threads/code reviews. Going through the different options in Creator's config is a good start. Svenn-Arne ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] clang-format
On 06/20/2018 01:01 PM, Tor Arne Vestbø wrote: Good point, I was imagining it used only to verify style, not to auto-format. Still, starting out with a few non-controversial rules would be a good thing. I agree. For instance, it is clear from the patch discussion[1] that line length/column count is controversial. I think it would be best to set this to 0 for now to be able to move forward and get the benefits of clang-format for all the other things that we do agree on. Setting it to 0 means that clang-format will respect your decisions about line length unless you contradict other rules. There are also many nice options set in the clang-format config found in Qt Creator's sources[2] which I think are interesting. For instance, "BinPackParameters: false" and "BinPackArguments: false" makes sure you to either put all arguments on one line or give if arguments will have one line each. This might be in the controversial category, but it is nice to enable while developing. It makes clang-format reflow the code consistently just by moving a single argument to a new line and running clang-format afterwards. Svenn-Arne [1] https://codereview.qt-project.org/#/c/233051/ [2] https://github.com/qt-creator/qt-creator/blob/master/dist/clangformat/.clang-format ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt for WebAssembly
On 03/09/2018 03:53 PM, Jason H wrote: While I am excited about this, I still wonder that it's the right approach. By right, I mean scalable. After evaluating the WebGL platform (which I was excited about as well) had having extreme performance issues, I foresee that this will has performance issues as well, because of one defect: You're rendering to a canvas what the browser can draw natively. If people want to serve Qt apps to the web, then the best approach (IMHO) is to use a server to send a client which is defined in HTML5 (name clash with Q_OS_HTML5) as non-canvas DOM elements (unless you're using a QPainter). This will leverage the browser in the best way possible, and let it handle the low-level drawing. To this end QMLWeb is an existing approach (https://github.com/qmlweb/qmlweb). I think this depends on the use case. QMLWeb is doing a great job of bringing the QML language to web applications, which I personally find much more appealing than working with HTML and CSS. And it is probably best to leverage the browser to draw efficiently in cases where using DOM elements makes sense. This is likely the case for social media applications, news readers, ticket services, database browsers, etc. However, for use cases where a canvas already is the main element, either for 2D or 3D content, I think Qt for WebAssembly makes a lot of sense. The difference then is just what language and framework you use to produce the code that ends up drawing the canvas. And you will still have plenty of UI elements available with buttons, sliders, and checkboxes for your menus. This could be a good fit for image editing, painting, 3D modeling, data visualization, games, simulators, etc. I also think Qt for WebAssembly is exciting because it opens up the possibility to show a minimal demo of a full application in the browser. Instead of showing a video of the application on a product page, a small demo with limited features can be presented. Sure, it might not be as fast and doesn't have the same features as the full application (after all, you want to keep the download size to a minimum for the demo), but it will give the user a much better idea of what your application really is like. And the best part is that you can create the demo from the same code base as you used in the full application. Svenn-Arne ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Interest] [Qt3D] Mixing C++ and QML
A typical pattern in QtQuick is that a QQmlListProperty is the
default property, so declared children are automatically added. But
instead you have to declare the Components first, and then also add
them to a vector. Why is that? It seems needlessly cumbersome to
me. If Components are naturally always children of Entities,
^ that is your broken assumption. Components do not have to be children of the
entity. We actually started out with that but found that it prohibits sharing
components which can sometimes be handy.
“sometimes”… so maybe add declared child Components to the vector
automatically, but also allow sharing them by ID when necessary?
I would rather say "often" than "sometimes" for this one. In simple
examples, each component is often used only in one entity, but in more
realistic use cases, components like materials tend to be shared. While
I would also prefer a solution that "just works" when you add components
as children to an entity, I think this is hard to get right.
The naive solution is to allow both uses and just add them to the
parent's vector, but because you would typically add shared components
as children of some root component, this would end up drawing the root
entity as a mix of all shared components in addition to the entities
using those components. I.e., this would draw the mesh three times:
Entity {
id: root
Mesh { id: mesh }
Material { id: material }
Transform { id: transform1 }
Transform { id: transform2 }
Entity { components: [ transform1, material, mesh ] }
Entity { components: [ transform2, material, mesh ] }
}
To work around that issue, we could detect any sharing of components and
remove it from its parent if it's shared, but this seems like a bad
solution in my opinion.
Alternatively, we could add `shared` property to each component that
should not be added to its parent's vector:
Entity {
id: root
Mesh { id: mesh; shared: true }
Material { id: material; shared: true }
Transform { id: transform1; shared: true }
Transform { id: transform2; shared: true }
Entity { components: [ transform1, material, mesh ] }
Entity { components: [ transform2, material, mesh ] }
}
Or we could introduce some new node that isn't an Entity and can hold
the shared components, while any component added as a child to an entity
becomes added to the parent's vector:
Entity {
id: root
SharedComponents {
Mesh { id: mesh }
Material { id: material }
Transform { id: transform1 }
Transform { id: transform2 }
}
Entity { components: [ transform1, material, mesh ] }
Entity { components: [ transform2, material, mesh ] }
}
I think last option is the best of the three, but there might be better
alternatives. And neither is much better than the current API, in my
opinion.
Svenn-Arne
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Coding style and C++11
On 09/15/2017 06:42 AM, André Hartmann wrote: I'd like to push this discussion, because if code is converted to a new base, it should be clear to everyone HOW to do so. Great initiative! It would be great if the guidelines could be updated to reflect the new standard. What I like to add, is to encourage the use of C++11 member initialisation. They are already used in QtSerialBus (from the beginning) and QtCreator (ongoing changes to existing codebase). +1 What do you think? I was right now wondering if `typedef` or `using` is preferred in new code. And if `using` is preferred, what to do when there are existing typedefs in nearby code? Personally, I think we should prefer `using`, and update nearby typedefs accordingly, but it should also be safe to do a search-replace in the entire codebase if we are already doing that for other things. Is there a way we could formalize this discussion a bit? Perhaps a wiki-page where we could list the suggested changes and we could have some kind of voting mechanism? It could make it easier to separate the things everybody agrees on from the more interesting discussions. Best regards, Svenn-Arne ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] GPL tooling in Qt module?
On 01. feb. 2017 18:01, Sean Harmer wrote: As such addons need to run within the blender runtime which is GPL, the addon also needs to be GPL licensed. I don't think this is the case for addons. They are scripts run by Blender's Python interpreter, but (usually) don't link Blender's libraries. Blender.org even hosts addons with other licenses. For instance, "Reproject image" has an MIT license: https://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/UV/Reproject_image Best regards, Svenn-Arne ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Error in running Qt3D app
Hi, Are you trying to run the example on Android? If so, try to make a simple Qt3D example with a QML Scene3D object, like this: https://doc.qt.io/qt-5/qt3d-scene3d-example.html I have had some trouble with running the other Qt3D examples on Android, but I have not seen the same error message as you got. It has often helped to run it through a Scene3D object, however. This is of course only a long term solution if you are working on a QML project. But, testing the example will give you a good indication of whether Qt3D in general works on your device or not. If not, there might be some issue with getting access to an OpenGL context on your device. Then I would try to find a simple OpenGL example for Android in Java just to check. Cheers, Svenn-Arne On 26. juli 2016 05:55, swarit wipra wrote: Hi, I am getting following error, when running Qt 3d app. 05-19 19:26:06.857 17339 17339 W libClimateHMI.so: (null):0 ((null)): Can't find surface 2 05-19 19:26:06.869 221 628 D AudioFlinger: mixer(0xab962fb0) throttle end: throttle time(3) 05-19 19:26:06.877 17339 17339 W libClimateHMI.so: (null):0 ((null)): Can't find surface 2 05-19 19:26:47.118 221 628 D audio_hw_primary: out_set_parameters: enter: usecase(0: playback) kvpairs: routing=2 out->devices(2) adev->mode(0) 05-19 19:26:47.169 17339 17434 E libEGL : call to OpenGL ES API with no current context (logged once per thread) 05-19 19:26:47.248 17339 17339 I System.out: ClimateServiceIFClient : onPause 05-19 19:26:47.248 17339 17339 D libClimateHMI.so: (null):0 ((null)): ClimateHmiIF : NotifyOnPause --- 0xf7452b34 05-19 19:26:47.248 17339 17339 D libClimateHMI.so: (null):0 ((null)): UIClimateNotification : NotifyOnPause --- 0xf7452b34 05-19 19:26:47.290 17339 17405 W art : Native thread exiting without having called DetachCurrentThread (maybe it's going to use a pthread_key_create destructor?): Thread[10,tid=17405,Native,Thread*=0xab7c3548,peer=0x12d330a0,"QtThread"] Please guide me to fix it. Best Regards ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] 5.5.0 snapshot please ?
On 19. feb. 2015 13:04, Sean Harmer wrote: On Thursday 19 Feb 2015 11:56:18 Massimo Callegari wrote: Hi Sean, this one: https://bugreports.qt.io/browse/QTBUG-44497 Hmm I'm still unable to reproduce that. Given the configuration space, it's certainly possible there's still a bug there and that you've done nothing wrong. The trace file on that patch is not loading properly for me. I'll try updating my apitrace to the latest and try again. The same type of crash happens on my system too (Ubuntu 14.04 64 bit with Nvidia drivers). It is a bit random, but I've been completely unable to run some examples because of this bug. I just thought there was something wrong with my system or the specific examples. Is there anything I can do (collect a trace, for instance) that would help you debug this? Best regards, Svenn-Arne ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Error in compilation while compiling qt5 with qt3d
Hi, In my experience you also need to check out the dev branch of qtbase, qtdeclarative, qtimageformats (optional) and qtxmlpatterns. Afterwards I configure and compile with make module-qt3d This is on linux, and I'm not sure if it works with nmake, but that way you only compile the necessary submodules of Qt for Qt3D, reducing the chances of having trouble with other interdependencies between the Qt modules. I think I had the same error as you get before, and that it was caused by not checking out the dev branch in the qtbase folder. Best regards, Svenn-Arne On 22. jan. 2015 10:30, Arjun Das wrote: Hi, I Checked out dev branch of qt and dev branch of qt3d as per the previous email. I have given the following configuration: configure -debug-and-release -opensource -platform win32-msvc2012 -opengl desktop -nomake examples -nomake tests nmake The following error occurs after a long time of compilation of all other modules.Once it reaches qt3d: backend\rendertexture.cpp(248) : error C2039: 'TextureComparisonOperators' : is not a member of 'QOpenGLTexture' d:\qt5\qtbase\include\qtgui\../../src/gui/opengl/qopengltexture.h(51) : see declaration of 'QOpenGLTexture' backend\rendertexture.cpp(248) : error C2065: 'TextureComparisonOperators' : undeclared identifier backend\rendertexture.cpp(249) : error C2039: 'setComparisonFunction' : is not a member of 'QOpenGLTexture' d:\qt5\qtbase\include\qtgui\../../src/gui/opengl/qopengltexture.h(51) : see declaration of 'QOpenGLTexture' backend\rendertexture.cpp(249) : error C2039: 'ComparisonFunction' : is not a member of 'QOpenGLTexture' d:\qt5\qtbase\include\qtgui\../../src/gui/opengl/qopengltexture.h(51) : see declaration of 'QOpenGLTexture' backend\rendertexture.cpp(249) : error C2061: syntax error : identifier 'ComparisonFunction' backend\rendertexture.cpp(250) : error C2039: 'setComparisonMode' : is not a member of 'QOpenGLTexture' d:\qt5\qtbase\include\qtgui\../../src/gui/opengl/qopengltexture.h(51) : see declaration of 'QOpenGLTexture' backend\rendertexture.cpp(250) : error C2039: 'ComparisonMode' : is not a member of 'QOpenGLTexture' d:\qt5\qtbase\include\qtgui\../../src/gui/opengl/qopengltexture.h(51) : see declaration of 'QOpenGLTexture' backend\rendertexture.cpp(250) : error C2061: syntax error : identifier 'ComparisonMode' Thanks Regards Arjun On Wed, Jan 21, 2015 at 12:31 AM, Sean Harmer sean.har...@kdab.com mailto:sean.har...@kdab.com wrote: On Tuesday 20 January 2015 22:39:09 Arjun Das wrote: Hi, I am a beginner to QT framework, however i have solved all errors till now. But I am stuck on this one. Compilation of qt5 with qt3d module is failing for me in windows. I have given the following configuration: Be sure to get a recent checkout of the dev branch of qtbase. The metatype declaration of QSurface was added fairly recently. Qt 5.4 is not new enough. Cheers, Sean -- Dr Sean Harmer | sean.har...@kdab.com mailto:sean.har...@kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Error in compilation while compiling qt5 with qt3d
Hi, In my experience you also need to check out the dev branch of qtbase, qtdeclarative, qtimageformats (optional) and qtxmlpatterns. Afterwards I configure and compile with make module-qt3d This is on linux, and I'm not sure if it works with nmake, but that way you only compile the necessary submodules of Qt for Qt3D, reducing the chances of having trouble with other interdependencies between the Qt modules. I think I had the same error as you get before, and that it was caused by not checking out the dev branch in the qtbase folder. Best regards, Svenn-Arne On 22. jan. 2015 10:30, Arjun Das wrote: Hi, I Checked out dev branch of qt and dev branch of qt3d as per the previous email. I have given the following configuration: configure -debug-and-release -opensource -platform win32-msvc2012 -opengl desktop -nomake examples -nomake tests nmake The following error occurs after a long time of compilation of all other modules.Once it reaches qt3d: backend\rendertexture.cpp(248) : error C2039: 'TextureComparisonOperators' : is not a member of 'QOpenGLTexture' d:\qt5\qtbase\include\qtgui\../../src/gui/opengl/qopengltexture.h(51) : see declaration of 'QOpenGLTexture' backend\rendertexture.cpp(248) : error C2065: 'TextureComparisonOperators' : undeclared identifier backend\rendertexture.cpp(249) : error C2039: 'setComparisonFunction' : is not a member of 'QOpenGLTexture' d:\qt5\qtbase\include\qtgui\../../src/gui/opengl/qopengltexture.h(51) : see declaration of 'QOpenGLTexture' backend\rendertexture.cpp(249) : error C2039: 'ComparisonFunction' : is not a member of 'QOpenGLTexture' d:\qt5\qtbase\include\qtgui\../../src/gui/opengl/qopengltexture.h(51) : see declaration of 'QOpenGLTexture' backend\rendertexture.cpp(249) : error C2061: syntax error : identifier 'ComparisonFunction' backend\rendertexture.cpp(250) : error C2039: 'setComparisonMode' : is not a member of 'QOpenGLTexture' d:\qt5\qtbase\include\qtgui\../../src/gui/opengl/qopengltexture.h(51) : see declaration of 'QOpenGLTexture' backend\rendertexture.cpp(250) : error C2039: 'ComparisonMode' : is not a member of 'QOpenGLTexture' d:\qt5\qtbase\include\qtgui\../../src/gui/opengl/qopengltexture.h(51) : see declaration of 'QOpenGLTexture' backend\rendertexture.cpp(250) : error C2061: syntax error : identifier 'ComparisonMode' Thanks Regards Arjun On Wed, Jan 21, 2015 at 12:31 AM, Sean Harmer sean.har...@kdab.com mailto:sean.har...@kdab.com wrote: On Tuesday 20 January 2015 22:39:09 Arjun Das wrote: Hi, I am a beginner to QT framework, however i have solved all errors till now. But I am stuck on this one. Compilation of qt5 with qt3d module is failing for me in windows. I have given the following configuration: Be sure to get a recent checkout of the dev branch of qtbase. The metatype declaration of QSurface was added fairly recently. Qt 5.4 is not new enough. Cheers, Sean -- Dr Sean Harmer | sean.har...@kdab.com mailto:sean.har...@kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt3D on iOS
Hi, Does the current development version of Qt3D 1.0 (master) or Qt3D 2.0 (wip/newapi) build on iOS? We tried building both versions, but we get the following error with Qt3D 1.0: No rule to make target `/repos/qt3d/build-qt3d-wip-Release/lib/libQt53D.a', needed by `../../lib/libQt53DQuick.dylib'. We tried to use the wip/newapi branch to see if Qt3D 2.0 works, but still get a similar error: No rule to make target `/repos/qt3d/build-qt3d-wip-Release/lib/libQt53DCore.a', needed by `../../lib/libQt53DRenderer.5.4.0.dylib'. This seems to be some kind of linker error that is specific to iOS, as the project builds fine on Mac OS X. However, except for a few minor quirks, the master branch seems to build fine if we comment out SUBDIRS += quick3d imports in src.pro. Has anyone else been experiencing this or do you have any suggestions on how to debug this issue? We have been building the project via Qt Creator 3.2.1 on Mac OS X 10.9 with Qt 5.3.1 Best regards Svenn-Arne Dragly ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt3D Examples
On 13. okt. 2014 13:13, Simon Hausmann wrote: On Monday 13. October 2014 11.49.01 Sean Harmer wrote: Hi, somewhat of a meta question around Milian's recent email. Qt3D is obviously going to need a lot of examples to show how to implement various techniques and methods. 3D work in general is notorious of requiring fairly large assets to make interesting and visually pleasing examples e.g. textures (diffuse, specular, bump, alpha, etc) and meshes being the most common. Rather than clogging up the main Qt3D git repo with these, do you think that we should have a separate repo for the Qt3D examples and their assets? Is there a precedent for this or any other options? I don't have an authoritative answer, but one possible option would be an sub-module that contains the assets for examples or (easier?) separate the Qt 3d examples and their assets into a standalone git repository. I support this. Having large Qt3D examples in a submodule seems like a good solution. However, I would still like smaller examples that are easy to run and test to be available in the default git repository (and binary installations). Such as simple lighting, camera handling, animation, etc. This will make it easier for newcomers to test Qt3D without having to download the huge asset repository. Best regards, Svenn-Arne Dragly ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] StereoViewport for Qt3D
On to. 21. nov. 2013 kl. 09.40 +0100, Fabian Bumberger wrote: while working on this, the temporary frame buffer used for picking had a size set to 8x8 pixels(!). For picking the whole scene is rendered using the pick painter for every performed pick. And afaik, if you swich on picking then a pick is performed for every mouse event (including mouse move events). So I guess having such a small FBO was because of performance and memory reasons. But I also noticed that picking is quite unreliable with that. I think you are absolutely right - the new implementation will be a performance hit, but it is reliable. The previous implementation appears to render only a smaller part of the viewport for picking (around the mouse cursor). It might be that a bug in this implementation was causing it to be unreliable? In any case, the previous implementation was more complicated, making it harder to maintain and harder to build upon for stereoscopic viewing, in my opinion. What I could do to yield better performance is to reuse the picking buffer from last time if it the scene has not changed. That way the same scene should be painted only twice - once for the view and once for the picking buffer. This is what is done in QGLView. Svenn-Arne ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] StereoViewport for Qt3D
On to. 21. nov. 2013 kl. 10.17 +0100, Svenn-Arne Dragly wrote: What I could do to yield better performance is to reuse the picking buffer from last time if it the scene has not changed. That way the same scene should be painted only twice - once for the view and once for the picking buffer. This is what is done in QGLView. I take that back. There's a bit of logic in Viewport that calls the render() method on each mouse move already, likely because picking could initiate something that would require a re-rendering of the scene (for instance if the user changes an object's color on an hover event). I think I'll just leave it as is for now, even though there is a performance impact this way. Svenn-Arne ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] StereoViewport for Qt3D
On Wed 06 Nov 2013 12:54:07 PM CET, Rutledge Shawn wrote: On 28 Oct 2013, at 10:35 PM, Svenn-Arne Dragly wrote: Secondly, I was missing a stereo option for the default QML Viewport element, and decided to have a look at the implementation in QGLView to see if I could port that to the QML Viewport element. Luckily this was quite easy (thanks to Qt3D being well designed) and I have uploaded the resulting StereoViewport element to a GitHub repository: https://github.com/dragly/stereoviewport This should compile with Qt5.1.1 and the latest master branch of Qt3D. Cool. Are you using it with an Oculus Rift, 3D TV or something else? Both and Oculus Rift and a 3D TV, actually. I have tested the stereo mode where the viewport is split in two thoroughly, with one half of the screen for the left eye and the other for the right. It works quite well and seems to be stable. Now, I'm wondering if this feature should be a part of the original Viewport element. Should I contribute this into the main Qt3D repository? If so, what steps should I take before doing this, apart from those listed in the Qt Contributing Guidelines? I'm for instance not sure if I might have introduced some bugs or damaged any features of the original Viewport element. How should I verify that I haven't done so? I don't know much about that but I'm sure you will get a reply from someone who does. But it sounds like a good feature to have. I hope so too, but if I don't hear anything I'll just try pushing it to gerrit and see how it goes. Svenn-Arne ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] StereoViewport for Qt3D
Hi, I've become amazed by the ease of use, flexibility and features in Qt3D, so first of all I want to thank all of you who have contributed to Qt and Qt3D. Secondly, I was missing a stereo option for the default QML Viewport element, and decided to have a look at the implementation in QGLView to see if I could port that to the QML Viewport element. Luckily this was quite easy (thanks to Qt3D being well designed) and I have uploaded the resulting StereoViewport element to a GitHub repository: https://github.com/dragly/stereoviewport This should compile with Qt5.1.1 and the latest master branch of Qt3D. Now, I'm wondering if this feature should be a part of the original Viewport element. Should I contribute this into the main Qt3D repository? If so, what steps should I take before doing this, apart from those listed in the Qt Contributing Guidelines? I'm for instance not sure if I might have introduced some bugs or damaged any features of the original Viewport element. How should I verify that I haven't done so? By the way, my StereoViewport class is almost exactly the same as the traditional Viewport class, so if you want to port this back to Viewport, just search/replace StereoViewport with Viewport in the stereoviewport.cpp and stereoviewport.h files and you should be good to go. The rest of the files in the repository are just copies of private files already in Qt3D that I needed to compile. Best regards, Svenn-Arne Dragly ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
