[Development] Adding new third party component three.js to Qt?

[Keränen Pasi]

Hi Louai,

The changes required to the library were originally quite large. But
thanks to the bug fixes in V4VM, maturing of Canvas3D and writing of some
wrapper classes to make e.g. Image loading look and smell like in HTML
land, the delta has been getting smaller and smaller. Here is a pretty
complete list based on quick compare between the R69 original three.js and
the Canvas3D port of the R69 release of three.js. There might be something
I’m forgetting to mention here. But as I said the delta has been getting
smaller and should get even smaller in Qt 5.5 and 5.6. But there will be
some delta always as QtQuick is not HTML.

* We don’t have performance timers in Qt Quick JS, so the Clock class must
be modified to not use those.

* In some files the class is declared with syntax of ( function (THREE) {
blahblabh }( THREE ) ); that V4VM seems to dislike and in some cases self
executing functions don’t seem to work, V4VM just refuses to load the
file. I haven’t been able to replicate this behaviour with a small
example, so probably it’s relates to some complex situation arising when
loading a large JavaScript file OR then there is some minute detail in
that self executing function that I can’t spot.

* Resizing of images has to be modified as that is usually done with HTML
trickery that doesn’t work at the moment with Canvas3D.

* Accessor functions defined in prototypes with:
get x() { return this._x },
set x(value)  { this._x = value; this.onChangeCallback(); }

* Must be rewritten with the (older?) syntax of:
this.__defineGetter__("x", function(){return this._x;});
    this.__defineSetter__("x", function(value){this._x =
value;this.onChangeCallback();});

* Canvas3DRenderer is new code, ported from WebGL. Main differences are to
do with initialization differences between Canvas3D and WebGL. Handling of
some Canvas3D Tech Preview quirks like the handling of TypedArray wrappers
(should be ok to remove in 5.5 when we have proper V4VM TypedArrays in
place and function overloading should work). And I’ve wanted to support
the logging features of Canvas3D objects, by setting the .name attribute
of some objects so that when you turn on logging you can see what
UniformAttribute, what Shader3D object you are looking at in the logs..
Plus a couple of workarounds for weird behavior (e.g. boolean as attribute
name in the renderer causes V4VM not to load the file, but again a minimal
example of this doesn’t have this problem so can’t replicate it). Again,
the delta should get smaller with WebGLRenderer, but I’d expect there to
always be some delta.

That is all the delta I can list quickly, if you are interested in details
just get the R69 release from three.js git and the stable branch of
QtCanvas3D port and do a detailed compare of those.

Reagrding this delta I’ve thought a bit how to reorganise the delta so
that it could live in a separate folder inside three.js. If I can make
that happen, then maybe it would be possible to get these few changes in
to three.js upstream and make it possible to always use the latest from
there as well if one so wishes. But that will require a bit more work on
V4VM I think before we’re there. E.g. Add support for binary file loading
with XMLHttpRequest and track down why those few anomalies occur when
loading self executing functions declared in the manner they are in
three.js so that the upstream code should run as much as possible
unmodified on top of Canvas3D with just the few changes we need in place.

Regards,
Pasi



On 08/01/15 12:54, "Al-Khanji Louai" <louai.al-khanji at theqtcompany.com>
wrote:

>> On Wednesday 7. January 2015 06.03.14 Keränen Pasi wrote:
>> > Hi,
>> >
>> > I¹d like to open the discussion on including the three library as
>>part of
>> > Qt 5.6 and onwards. Mainly because this would give our users a better
>> > experience if we¹d bundle the right, tested version of Three.js
>>together
>> > with the Qt version it was tested on.
>> >
>> > I¹ve been pushing the Qt Canvas3D component onwards and timewise it
>> should
>> > be landing to Qt 5.5 release. The WebGL-like API (non-conformance
>>tested)
>> > it offers is very low level and most users will not like to work on
>>that
>> > level. To that end I¹ve ported the WebGL based Three.js scenegraph
>>library
>> > available at http://threejs.org on top of Canvas3D. You can find the
>> > latest version from master branch at
>>https://github.com/tronlec/three.js
>> >
>> > The reason for picking this particular library over others are:
>> > * It¹s one of the most active WebGL scene graph projects out there.
>> > * It¹s well done, with examples, API documentation etc.
>> > * It has excellent support form community in the form of tutorials,
>> > websites, discussion forums etc.
>> > * It is available under permissive MIT license:
>> > https://github.com/mrdoob/three.js/blob/master/LICENSE
>> >
>> > In Qt 5.5 we¹ll include a few examples that will have this library as
>>part
>> > of the examples.
>> >
>> > The library will for now at least need some porting effort to make it
>>run
>> > on top of Canvas3D as there are some HTML depencencies that need to be
>> > handled, plus V4VM has a few quirks that need to be accounted for.
>> > Hopefully some of the V4VM quirks are bugs and will be fixed in due
>>time,
>> > but the HTML dependencies do remain. And my current experience with
>> > graphics APIs is that you want to test the whole stack together. If we
>> > e.g. add support for new extensions in Canvas3D, that can activate new
>> > codepaths in Three.js that again need testing and possibly new Qt
>>specific
>> > delta must be added to the three.js for those parts.
>> >
>> >
>> > Comments? Thoughts?
>> 
>> Sounds like a good idea to me. What's the size (lines of code) that we
>>are
>> talking about here? Is it just one big "minified" .js file?
>> 
>> 
>> Simon
>
>Out of curiosity, how large are the changes that were required to port
>the library?
>
>-- Louai
>
> 
>
>_______________________________________________
>Development mailing list
>Development at qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development