[Fiware-webui] 3d asset formats and containers revisited

[Toni Alatalo]

Hi,

I unfortunately can't make it to the weekly today (am driving a car
then) but there shouldn't be urgent matters as things were clear with
the webtundra&synchronization bundle last week already (as Henar noted
earlier it already was published in the FIWARE Lab's catalog etc - I
somehow didn't see it in the list when had checked earlier).
Documentation in the fiware catalog entry should be improved still
about how to instantiate the blueprint etc. but that we can only
really do when it works.

Here however a brief heads-up of further 3D-UI roadmap work, based on
what we discussed with Tommi, Adminotech's CEO some days ago:

The Recommended Asset Pipeline was already a major feature in earlier
FIWARE 3DUI work:
http://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.Feature.MiWi.3D-UI-WebTundra.RecommendedAssetPipeline

In the WebTundra 1.0 release we support two alternatives, as described
in the manual: three.js's JSON for small assets, and Chronos's glTF
for efficient binary that's fast to transfer over the web & load to
the GPU -- hence good for large objects or scenes.

Also, there are the POP-buffers from Fraunhöfer for which DFKI has
added support to XML3D.js and also created the BLAST container.

Long story short: we now plan to re-evaluate the situation and
continue the work to get a good solution. Meshmoon has business
interest for an efficient format & loading code, currently they don't
support any of these techs yet but only the less efficient and
otherwise rarely used Ogre formats.

Options include continuing with glTF, possibly by adding support for
POP-buffers there for progressive loading & level-of-detail (LoD), or
adopting BLAST. Like BLAST, glTF also supports any compression for the
geometry binary so I think POP-buffers should be possible to use there
too. BLAST I don't know too well yet so studying it, and also the
current status with regards to glTF support out in the world is how
this work would begin then.

We haven't scheduled nor allocated people to this yet so this is just
a pre-info that this is planned to appear in the roadmap once get to
that.

Additionally, this work will include design & implementation of some
kind of good mapping between these scene asset bundles & the realXtend
scene model. Currently we can say this in WebTundra 1.0 and it simply
becomes a single entity with a Mesh component -- the hierarchy from
the glTF scene JSON is not dissected to individual Tundra scene
entities etc:

<mesh src="myscene.gltf" />

Actually when CIE added support for COLLADA asset bundles to the C++
Tundra back in the days, we already got the design for this which is
perhaps fine to reuse here:

<entity>
<mesh src="myscene.gltf#car">
</entity>
<entity>
<mesh src="myscene.gltf#bike">
</entity>
<entity>
<mesh src="myscene.gltf#house_at_street_x_y">
</entity>

(that xml3d notation for a realxtend scene is a bit fake: in xml3d the
rex entities are actually <group> and not <entity>, but I use the
entity term now in the email here to keep it more familiar to
realxtend folks)

That's one way we can use asset bundles for efficient downloading but
still point to the individual assets in the Tundra scene level. This
allows for example live collaborative editing of the scene normally as
the individual asset references can be changed in the component
attributes and hence get synched over websockets etc.

We don't need to link to the asset bundle explicitly as AFAIK it works
fine to load the bundle as a kind of side effect from the first
reference to it (for additional references we then need to note inside
WebTundra's Asset module that the bundle is already (being)
downloaded).

Looking forward to seeing how those things are on the BLAST side as
well when get to that. Will read the docs and perhaps we can have a
dedicated talk about this etc.

Cheers,
~Toni