Hi, I am adding Jan Sutter to the loop as he has thought about that a bit as well. Its certainly something we are very interested in. POP or progressive loading is certainly not straight forward to add to glTF or BLAST. As you point out, the whole point is to load things onyl when needed, which is not what BLAST was mainly designed for at the time (goals was to minimize number of HTTP queries). However, this does not mean that it cannot be applied together. One way would be to indicate early in the file what sections should be loaded anyway and keep the rest on the server. The loaded part would then contain enough information to query the progessive parts separately, which is what we want anyway. In summary oly the coarse part of the mesh would be downloaded initially and the rest could be still in the BLAST "file" but be downloaded only on demand or would be in a separate file anyway. Just my 2 cents. Best, Philipp Am 08.04.2015 um 07:19 schrieb Toni Alatalo: > Hi, > > no, no real development activities yet. > > In the discussion with Adminotech about Meshmoon's need the conclusion > so far is that continuing(*) with glTF should work well. > > So current plan is to check glTF status and update & improve(**) the > support for that. > > We've checked the status a little so far and there seems to be some traction: > > 1. OpenOffice (I think actually LibreOffice, the open for of > openoffice) has added glTF support. So you can embed 3d models in > documents as glTF. It also supports reading in COLLADA (and was it > also other?) files but internally uses glTF for storage also then. > Thanks to that work there's also c++ code to parse & view the format. > This happened last fall, November 2014 or so. > > 2. Some Autodesk (-related?) person has been writing FBX -> glTF > converter, using Autodesk's FBX SDK. This is good news because one of > the weak points of glTF has been going via COLLADA and the > questionable status of COLLADA exports in some places. In for example > Blender I think FBX export is what many people use when making games > (with Unity or Unreal) and COLLADA less (is used to Second Life and by > some other folks too). > > 3. The glTF working group within Khronos is aiming at having the 1.0 > spec by SIGGRAPH in autumn. > > https://github.com/KhronosGroup/glTF has pointers for more info about > these, for example: > http://zolnaitamas.blogspot.fi/2014/08/3d-models-in-impress-libreoffice-43.html > https://github.com/cyrillef/FBX-glTF > > And footnotes to clarify our current status: > > (*) WebTundra 1.0, current master, supports glTF with the old code. > The spec has changed a bit since then, Tony Parisi is updating the > three.js loader. Meshmoon uses the dev2 / upcoming 2.x WebTundra code > which doesn't have glTF loading yet. > > (**) > We currently support only loading a whole glTF (scene) for a Mesh component: > <mesh src="myscene.gltf" /> > > Plan, and the need for Meshmoon, is to add support for using glTF > properly as bundles: > <mesh src="myassets.gltf#car" /> > <mesh src="myassets.gltf#tree" /> > > Hopefully this clarified our understanding so far! > > Oh and one more thing, about POP-buffers vs. asset bundles. > > Initially I was thinking that we could use POP-buffers and glTF > together -- like thought for some reason that you are using > POP-buffers or something like it in/with BLAST. To get progressive > loading and LoD. > > But then when writing plan texts / starting feature descriptions for > the wiki realized that the ideas are not directly compatible and it > wouldn't just work: > > AFAIK with POP-Buffers the idea is that one big mesh is in one binary, > ordered so that vertices for low LoD version are first and then > further details later in the file. So it can be showed nicely > progressively as it loads e.g. over the net. > > In glTF binary idea is that many small meshes from a big scene can be > in one binary, one after another. So loading that file you get meshes > one-by-one, is not possible to load a little of them all first as > that's just not how the file is organized. > > Only way I see for using POP-Buffers style progressive loading would > be to have a separate file for each mesh. Which would be doable by > bending glTF so that the master JSON points to the different files. > But that'd loose the benefit of having the single binary which is > faster & lighter to load to get the whole -- the reasons for using > bundles. > > So my understanding so far is that glTF and bundles in general work > when have a scene with a lot of separate meshes. And POP-Buffers for > single large objects that are good to load progressively. Perhaps > could be mixed so that e.g. in a glTF JSON some meshes would point to > the bundled binary and a few big ones to separate POP-Buffers for > which progressive loading would be used. > > We figured that would start from updating & adopting glTF as is first > -- the simple and already known things -- and then look at progressive > loading later again. > > ~Toni > > On Sat, Apr 4, 2015 at 8:23 AM, Philipp Slusallek > <philipp.slusallek at dfki.de> wrote: >> 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 >> --------------------------------------------------------------------------- -- ------------------------------------------------------------------------- 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/20150408/4f37d512/attachment.vcf>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy