View source for Qt and 3D QtCS2015

[[Category:QtCS2015]]
==== 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, [https://github.com/tronlec/three.js three.js] based
* "OneQt" example, cube as a UI thing, [https://github.com/tronlec/three.js three.js] based
* CarVisualizer demo, port of app done by [http://plus360degrees.com/threejs/ +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 [https://www.khronos.org/vulkan Vulkan] underneath it in the future

==== Discussion ====
* Writing WebGL is of course quite elaborate and tedious, but because we have  [https://github.com/tronlec/three.js 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
** [https://www.khronos.org/registry/typedarray/specs/latest/ 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 [http://threejs.org three.js] to Canvas3D?
** Need to pick out the HTML bits and replace them by Canvas3D
** The [https://github.com/tronlec/three.js 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 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 [http://chandlerprall.github.io/Physijs/ Physijs], not tried yet with ported [https://github.com/tronlec/three.js three.js].

* What about input?
** Qt3D default picking methods?
** three.js has raycasting as primary method.