Qt wiki will be updated on October 12th 2023 starting at 11:30 AM (EEST) and the maintenance will last around 2-3 hours. During the maintenance the site will be unavailable.
Qt and 3D QtCS2015: Difference between revisions
Jump to navigation
Jump to search
Pasikeranen (talk | contribs) mNo edit summary |
m (Added Category) |
||
Line 1: | Line 1: | ||
[[Category:QtCS2015]] | |||
==== Subject ==== | ==== Subject ==== | ||
Qt 5.5 brings: | Qt 5.5 brings: |
Latest revision as of 15:15, 11 June 2015
Subject
Qt 5.5 brings:
- Canvas3D -- WebGL-like API for QML JavaScript with three.js port available.
- Qt 3D 2.0 TechPreview -- Fully data driven C++ 3D scene graph.
Let's Discuss:
- How easy are these to approch at the moment?
- Performance expectations?
- 3D tooling requirements in Qt Scope?
- What kind of use cases should we be looking at and optimising for?
Canvas3D runthrough
- "Planets" example, planetary demo, three.js based
- "OneQt" example, cube as a UI thing, three.js based
- CarVisualizer demo, port of app done by +360 Degrees, but we tweaked it a bit:
- Animating the color changes, material properties change...
- Shows how QML animations can gracefully work with your 3D stuff
- 2 days of work (1 day was just descrambling the original code)
Qt 3D runthrough
- Sphere rotating around a torus
- Embedded into QML
- Plane flying through rings, anaglyphic stereoscopic rendering (green/red)
- It is all a scene graph in QML, including the Render Graph
- SceneGraph and camera, materials and all can be built in QML and C++
- Pretty likely that we can use Vulkan underneath it in the future
Discussion
- Writing WebGL is of course quite elaborate and tedious, but because we have three.js it can be quite nice to work with
- Builds the scene using Javascript, rather than QML, but similar level (scene, camera, objects...)
- What about performance and memory?
- Porting the Planets example to Qt 3D found some issues
- TypedArrays in V4 VM now
- The JS code is only used to build the tree. We don't run JS once the tree is running
- What about porting three.js to Canvas3D?
- Need to pick out the HTML bits and replace them by Canvas3D
- The three.js port has some convenient portability layer stuff
- Maybe we could provide some of the HTML DOM things so it "just works" with Qt
- Canvvas3D has a benefit over HTML/WebGL because once it works on top of Qt, there is nothing more needed
- For Qt 3D, the ease of use is often
- still learning what people expect from it
- need a lot more examples to show how things work
- to do Oculus 3D, take the current stereo and adapt it
- default framegraphs
- Importing models -> done using assimp
- Results in a Qt 3D subtree
- Basic description of the materials which is mapped to Qt 3D materials,
- several built in ones
- PhongMaterial, etc..
- You can't get the fancy materials.
Tooling
- Visualizer, tree visualizer
- This is something we're very likely to build
- Pick and drag and look at properties and stuff
- How much tooling do you really need.
- Qt Quick Designer
- Canvas3D component is available, but it shows up as box in the designer.
- Qt 3D scene could be a subtree in the designer?
- Qt Quick Designer
- Qt 3D can do deep bindings because it is QML all the way
- Canvas3D + three.js requires you to have JS code to pass the property values from QML to JS.
- Render same scene from multiple angles
- The FrameGraph is fully flexible and any type rendering technique can be put together
- Again, more examples are needed..
- What is the minimal. The old Qt 3D could do a model in 5 lines?
- How minimal does it make sense to have it?
- Convenience needs to be added based on what people need
- Mustardy "shit" yellow phong material
- Forwards renderer
- Can probably do better, but we're maybe around 10 lines now.
- Could we build a QML API on top of three.js?
- Could make sense as that could help in building single tooling for both Canvas 3D and Qt 3D.
- Physics?
- Qt 3D is a 3D scene system, so different aspects can do different things
- 3D sound
- physics
- picking aspect
- a physics system is just another aspect which can do work on the scene.
- We probably don't want to maintain a physics engine under the Qt project
- unless there is plenty of money in it
- Probably better to just include an open source one if it exists...
- There is a bullet aspect..
- three.js has a physics library called Physijs, not tried yet with ported three.js.
- Qt 3D is a 3D scene system, so different aspects can do different things
- What about input?
- Qt3D default picking methods?
- three.js has raycasting as primary method.