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

Philipp Slusallek Philipp.Slusallek at dfki.de
Tue Dec 10 06:57:52 CET 2013


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
---------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: slusallek.vcf
Type: text/x-vcard
Size: 441 bytes
Desc: not available
URL: <https://lists.fiware.org/private/fiware-miwi/attachments/20131210/884cb6fa/attachment.vcf>


More information about the Fiware-miwi mailing list

You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy   Cookies policy