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 -- _______________________________________________________________________________ Kristian Sons Deutsches Forschungszentrum für Künstliche Intelligenz GmbH, DFKI Agenten und Simulierte Realität Campus, Geb. D 3 2, Raum 0.77 66123 Saarbrücken, Germany Phone: +49 681 85775-3833 Phone: +49 681 302-3833 Fax: +49 681 85775–2235 kristian.sons at dfki.de http://www.xml3d.org 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 Amtsgericht Kaiserslautern, HRB 2313 _______________________________________________________________________________
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy