Hi all, I have not followed this much. Have there been any follow up activities yet. I believe this is something that makes much sense to work on together when you get there. Best, Philipp Am 04.03.2015 um 09:04 schrieb Kristian Sons: > Hi Toni, > > some comments from my side. I put Felix and Jan into CC because they > might know better some of the current states. > > - Felix had a student working on a glTF loader plug-in for XML3D [1]. > However, I don't know what parts are supported > - We don't have POP-buffer support in XML3D currently > - We will define a standard binary asset format based on BLAST > - There is a new Blender exporter for XML3D. It's a little private > project I run. It exports assets already. I will add support for binary > assets as soon as we support it > - The main difference between BLAST and glTF is the structure of the > scene that is given for glTF but arbitrary for BLAST. > - For the <mesh src="myscene.gltf" /> approach, you have no way > changing anything inside the scene, that's why we introduced assets > which allow to override arbitrary data within the referenced scene. > > Best regards, > Kristian > > [1] https://github.com/xml3d/xml3d.js/pull/72 > [2] https://github.com/ksons/xml3d-blender-exporter > > >> 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 >> _______________________________________________ >> Fiware-webui mailing list >> Fiware-webui at lists.fi-ware.org >> https://lists.fi-ware.org/listinfo/fiware-webui > > -- ------------------------------------------------------------------------- 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: philipp_slusallek.vcf Type: text/x-vcard Size: 441 bytes Desc: not available URL: <https://lists.fiware.org/private/fiware-webui/attachments/20150404/46c903fd/attachment.vcf>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy