[Fiware-miwi] A Candidate AssetPipe: glTF aka. Collada JSON

[Toni Alatalo]

Hi - just a quick note that we’ve now added glTF loading to WebTundra.

A minimal example with the canonical Duck is in the repo & on-line: http://playsign.tklapp.com:8000/WebTundra/examples/gltf/example-gltf.html

We also have the old-optimised-9-blocks Oulu model as glTF but no demo of that configured to WebTundra on the web yet — the original test with the non-threejs glTF web viewer from before is at http://playsign.tklapp.com:8000/glTF-webgl-viewer/

The WebTundra integration works now so that if the mesh ref is to a .gltf file, then the loader that was recently added to three.js is used. So the relevant xml3d snippet in that test is:

            <group>
              <mesh id="duck" src="./duck/duck.gltf" type="triangles"></mesh>
            </group>

.. the whole doc is https://github.com/realXtend/WebTundra/blob/dev/examples/gltf/xml3d-scene-gltf.html . (the test is standalone, doesn’t need Tundra server, but reads the scene from a xml3d file - that mesh tag there results in creation of a mesh component for the entity defined by that group, so the code that loads the mesh from the ref is the same also when connecting to Tundra)

I invented that .gltf extension there myself to make it work, the default .json wouldn’t work with the current loading logic as also three’s mesh and scene files can have .json extensions. Mrdoob has pondered changing those to .3geom and .3scene etc in three’s tracker. I haven’t checked yet whether the Khronos folks have considered some more exact file suffix, but will do.

Simultaneously, but just by coincidence, Jonne has been working on improving COLLADA .dae support in native Tundra now. A possible solution to our asset pipeline is to author as collada, then use the .dae files directly on the server for collision geom when necessary, and glTF to the browser clients. The larger size of .dae files perhaps doesn’t matter on the servers. Of course is nice if glTF is good otherwise if we can get support for that to native Tundra as well at some point (can come ~free if assimp adds it).

Let’s return to this and other asset pipeline matters later but this just as a quick heads-up info now.

Cheers,
~Toni

On 10 Dec 2013, at 07:57, Philipp Slusallek <Philipp.Slusallek at dfki.de> wrote:

> Hi all,
> 
> Important discussion -- thanks!
> 
> My impression is that Khronos is open for better suggestions. I believe we have some and should bring them forward. This would be a great step for the project as well to be able to point active standardization work in this area as well.
> 
> If people are interested we could maybe start Jan's implementation and the position paper as a starting point for such a proposal. It seems we now also have extensive models to test scenes with (probably we could even use our unit test framework for automating this).
> 
> Having a solid transfer format is the main goal from my POV. Whether Collada ist the best intermediate option is up for debate (and testing!). Specifically, there are often many other data items associated with meshes that need to be transferred, where Collada is likely to loose quite a few of them (portable shader formats come to mind here, for example).
> 
> One thing that would be good to include as well is the POP-Buffer idea from IGD (http://x3dom.org/pop/files/popbuffer2013.pdf). This is pretty much orthogonal and simply needs some sorting in the converter and a little bit of rounding computations in the vertex shader. If we can download the binary data in chunks, this is a great and automatic solution for LOD (based on the same idea as the best generic LOD algorithms from Georgia tech at the time), still my favorite today, despite all the others that were developed).
> 
> Another issues that we could jointly address is the chunk loading of binary data. Here it might make sense to write a short paper (1-2 pages, maybe officially supported by the audio guys and the Dec3D group) highlighting the necessity (again we could use/reference the position paper for details). This could then be sent to our contacts at the browser vendors as well as W3C.
> 
> I think we could really affect the industry as a whole here.
> 
> What do you think?
> 
> 
> Best,
> 
> 	Philipp
> 
> Am 28.11.2013 11:03, schrieb Kristian Sons:
>> Hi Toni,
>>> There’s still way to go with the glTF pipeline so for now (probably
>>> for a month still) our recommendation for getting scenes simply from
>>> e.g. Blender to Three.js is the Three JSON format (used in the master
>>> branch of the city rendering repo & live demo), and CTM for an
>>> optimized solution (but it requires custom setup to set materials). Am
>>> very curious to hear what the DFKI gfx / XML3D folks think of this —
>>> some of you perhaps attended the SIGGRAPH sessions even?.
>> 
>> yes, we were really active in this area. I presented together with
>> Fabrice Robinet at the WebGL and COLLADA BOF at Siggraph last year. We
>> also had discussions with the transmission format group at the Ninth AR
>> Standards Community Meeting this year and at Web3D2013 in San Sebastian.
>> Especially the discussions with Neil in San Sebastian were really good.
>> From our experiences of the XML3DRepo paper we created a position paper:
>> http://www.perey.com/ARStandards/[Klein]3dtf-position-paper_Ninth_AR_Standards_Meeting.pdf
>> 
>> 
>> As also mentioned in the paper, I see three issues:
>> 1. The minimum of number of request is given by the number of meshes.
>> For scenes with many meshes, this will be the bottleneck. Additionally,
>> this minimum can only be reached if the attribute data is interleaved
>> and not indexed. I don't know the status for current exporters, but I
>> guess most exporters would just support interleaving for very specific
>> signatures
>> 2. The registry for compressors is way better than a fixed set of
>> compression methods and Khronos has a good practice of extension
>> registries. However, I think that 3D data is so inhomogeneous that even
>> this is not flexible enough. Instead we propose to use a "Code on
>> demand" appraoch, which means that a fallback decoder implementation
>> could be downloaded if the rendering system has no built-in (possible HW
>> accelerated) decompressor for a data set. Neil liked this idea, I don't
>> know if maybe glTF has moved into this direction
>> 3. Using the GL buffers as common ground for all mesh formats is a good
>> idea. However, finding a suitable abstraction layer for materials and
>> animations is way harder and not even solved in a high abstraction
>> format such as COLLADA
>> 
>> BTW, it would probably be easy (and interesting) to implement a glTF
>> plug-in for XML3D.
>> 
>> Jan (in CC) is a PhD student in our group who started to design and
>> implement a transmission format that addresses the requirements we
>> collected in the position paper above. It is very generic and allows to
>> stream structured binary data and to decode the data in parallel.
>> Currently it's not possible to chunks of a request if ArrayBuffers are
>> requested (this is only possible for text requests). We identified this
>> issue in the W3C CG together with Fraunhofer IGD (and some Audio guys
>> who are interested in the same feature). If we had this, it would be
>> perfect cause everything could be in one request.
>> 
>> In a next step, we will implemnt some encoder/decoders. We want to show
>> that some of the decoding could be achieved in the vertex shader (e.g.
>> decoding of quantized vertex attributes) other could be decoded using
>> Web Workers/Xflow and/or WebCL. Neil is also very open for good
>> technical solutions.
>> 
>> Best regards,
>> Kristian
>> 
>> 
>> 
>> 
> 
> 
> -- 
> 
> -------------------------------------------------------------------------
> Deutsches Forschungszentrum für Künstliche Intelligenz (DFKI) GmbH
> Trippstadter Strasse 122, D-67663 Kaiserslautern
> 
> Geschäftsführung:
>  Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender)
>  Dr. Walter Olthoff
> Vorsitzender des Aufsichtsrats:
>  Prof. Dr. h.c. Hans A. Aukes
> 
> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
> USt-Id.Nr.: DE 148646973, Steuernummer:  19/673/0060/3
> ---------------------------------------------------------------------------
> <slusallek.vcf>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-miwi/attachments/20140305/412250c5/attachment.html>