[X3D-Public] DASH-X3D new profile - Interoper abilitypoint

doug sanden highaspirations at hotmail.com
Sat May 10 14:54:29 PDT 2014

Thanks for the detailed explanation. Some interesting possibilities we'll have to keep an eye on. Keep up the good work.

> From: kapekost at gmail.com 
> Date: Sat, 10 May 2014 17:27:52 +0300 
> Subject: Re: [X3D-Public] DASH-X3D new profile - Interoper abilitypoint 
> To: highaspirations at hotmail.com 
> CC: x3d-public at web3d.org 
> Dear Sanded, 
> I think we could include the .x3z format when it becomes web3d 
> standard, it solves many problems regarding the X3D distribution. Your 
> statements were reasonable and completely understood. Very interesting 
> method to deliver a complete scene with all the required files (images 
> etc). The local storage can also take place for browser players (using 
> the HTML5 storage mechanism) 
> Additionally, we could consider the BASEurl (or a new) element of the 
> MPD file (manifest), as base url for the required files. Even better if 
> a server side application could be used to generate the representations 
> (Several quality instances). It could export the path for its resources 
> (in the MPD file)--less work for the clients. The described layers of 
> the MPD allow us to consider a 3D scene as a mixture of 3D objects, and 
> split the references according to their resolution. 
> The scenario with the proximity sensor may be included only if we have 
> some information about the position of the object in our MPD file in 
> each representation(calculate it during its generation process) 
> The MPEG-DASH in our minipages is using a video element (texture), to 
> provide adaptive smooth HD video stream in the 3D world. 
> The streaming example on the other hand (websocket) triggers a web 
> service to deliver the chunks which we also used for real-time chunking 
> in a fast example which we did not conduct speed measurements yet. 
> (this implementation runs for Indexed faces, and color vectors as 
> texture). We need more research on the chunking algorithm. 
> At this point I focus on a general description for the X3D in DASH for 
> a simple scenario, with an existing repository of the multiple quality 
> instances per model, for a scene. The proximity sensor as I searched 
> quickly is not implemented in X3DOM and the player I was considering to 
> provide (for the interoperability point (profile)) to the DASHif 
> community is an extended DASH.js player for the web. To begin with , 
> we can calculate the available bandwidth, and/or make some assumptions 
> using the FPS measurement from the X3DOM runtime... and help the 
> browser keep a good FPS value using the proper models depending on each 
> case. .. 
> On Sat, May 10, 2014 at 4:21 PM, doug sanden 
> <highaspirations at hotmail.com<mailto:highaspirations at hotmail.com>> 
> wrote: 
> Kostas, 
> freewrl implements .x3z using a common opensource C library minizip 
> that just unzips the contents to a local folder, so freewrl can do what 
> it normally does for local files. x3z isn't in the web3d standards 
> (yet) - it's an experiment to see if 'bundling' catches on. 
> OK I see the MPEG-DASH on your page 
> www.medialab.teicrete.gr/index.php/minipages<http://www.medialab.teicrete.gr/index.php/minipages> 
> I gather X3D-DASH is conceptually similar -smooth transition between 
> resolutions- except for whole scenes, or parts of scenes? 
> -Doug 
> more.. 
> web3d ProximitySensor node 
> www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/envsensor.html#ProximitySensor<http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/envsensor.html#ProximitySensor> 
> in combination with a Switch node, can be used to switch between 
> resolutions of parts-of-scene as the avatar approaches/recedes. 
> more.. 
> .x3z was implemented in freewrl in 2013 -it's not part of any standard 
> yet. When porting freewrl to Blackberry tablet, I noticed the tablet 
> didn't use browser plugins. Instead it would download a file for you, 
> to 'disk', and offer to open it with a standalone app. The problem was 
> in the .x3d scene file if image urls were relative, then the app 
> couldn't find them, because they weren't downloaded too, and -unlike a 
> browser plugin- the app wasn't handed the absolute url of the scene 
> file. Somewhere between downloading the file to local, and opening with 
> an app the absolute url is lost. For example scene 
> http://dug9.users.sourceforge.net/web3d/tests/26.x3d 
> refers image resource: 
> absolute 
> url='http://dug9.users.sourceforge.net/web3d/tests/helpers/front.gif' 
> relative url='helpers/front.gif' 
> x3d allows for multiple urls 
> multiple url='"helpers/front.gif' 
> 'http://dug9.users.sourceforge.net/web3d/tests/helpers/front.gif'" 
> so if the browser can't find one it can try another. But not everyone 
> authors their scenes that way. It seemed like the Blackberry tablet 
> would prefer to download a BLOB (Binary Large OBject) all in one shot. 
> Which reminded me of GoogleEarth's .kmz zipped files. So I did the 
> equivalent for x3d. 
> For browsers to do this, have the browser register the mimetype for 
> .x3z model/x3d+zip when installing. Then when opening the .x3z, use 
> function library like minizip to open, and write all the files to a 
> temporary folder on disk, and remember the folder and delete it when 
> closing. Then open doc.x3d and all the urls are relative and all the 
> files are local and relative. 
> However if instead of downloading a BLOB/.x3z, a manifest was 
> downloaded as file to local disk, and the app opened the manifest as a 
> local file, and the manifest had absolute URLS to scene files, then the 
> browser app could open the manifest and see the absolute part of the 
> url, and before forgetting the absolute part it could concatonate the 
> absolute part to all the relative image urls. 
> So, much like we did with 
> www.cloudvr.net/x3z.html<http://www.cloudvr.net/x3z.html> (implemented 
> with node.js code on the server) there could be a web service that 
> generates a manifest for a legacy .x3d file 'on the fly'. 
> Perhaps there could be a web service that generates reduced resolution 
> images and meshes/geometry/indexedfacesets on the fly, so a manifest 
> can refer to different resolutions that don't yet exist, but will be 
> created on demand by the web service on request. 
> ________________________________ 
>> From: kapekost at gmail.com<mailto:kapekost at gmail.com> 
>> Date: Sat, 10 May 2014 04:26:02 +0300 
>> Subject: Re: [X3D-Public] DASH-X3D new profile - Interoper abilitypoint 
>> To: highaspirations at hotmail.com<mailto:highaspirations at hotmail.com> 
>> CC: x3d-public at web3d.org<mailto:x3d-public at web3d.org> 
>> x3z seems to be interesting, we might include it in future 
>> implementations, or as additional mime-type in the DASH 
>> interoperability point. Are there any players supporting this format? 
>> or the developer has to temporary download the zip, uncompress and then 
>> give the sources to the player? 
>> In our example we focused more on the delivery protocols, and less on 
>> chunking methods, for the partial streaming tests we used serial and 
>> area short chunking mechanisms, generating autonomous chunks of indexes 
>> and indexedFaceSet. 
>> Regarding the DASH Interoperability point: To begin with, we will 
>> consider an existing repository with existing versions of a model in a 
>> variety of qualities. (the file format can be described as a mime time 
>> of the representation, and the chunking mechanism should inform the 
>> client on how to dynamically compose the final model) 
>> The client will decide according to the available resources which chunk 
>> will be requested, on a second pass the delivered (low quality) models 
>> will be replaced with higher-quality ones (or a transformation - 
>> morphing algorithm at this point would be interesting, sacrificing 
>> hardware resources to minimize the network bandwidth demand) . The 
>> replacing process has to be transparent to the user to maintain good 
>> Quality of Experience (e.g. smooth interaction). In a future work we 
>> might consider the significance of each model to prioritize the most 
>> significant. 
>> On Fri, May 9, 2014 at 10:13 PM, doug sanden 
> <highaspirations at hotmail.com<mailto:highaspirations at hotmail.com><mailto:highaspirations at hotmail.com<mailto:highaspirations at hotmail.com>>> 
>> wrote: 
>> Kostas, 
>>> http://www.medialab.teicrete.gr/index.php/minipages 
>> Very interesting - I'll take a closer look. 
>> Q. what about the .x3z scene zipping 
>> www.cloudvr.net<http://www.cloudvr.net><http://www.cloudvr.net> 
>> which is like googleEarth .kmz - a doc.x3d in the root of a .zip file, 
>> and /images subfolder - or other docx style resource bundling - does 
>> that fit with the manifest and chunking methods you use, or does your 
>> method replace/obsolete these bundling methods? 
>> -Doug 
>>> Dear Sanden, 
>>> The MPEG-DASH approach we are currently working on (for my master's 
>>> dissertation) will present 3d models in several resolution instances 
>>> and inspite of the BASEurl, the MPD will provide proper information for 
>>> dynamic adaptation mechanisms to 3D players (browser-based or not). The 
>>> content will be delivered and rendered client-side, as X3DOM originally 
>>> works right now (and any other plug-in based player). 
>>> ... 
>>> The approach with html5 canvas and gesture messages to a remote 
>>> renderer having sessions, is one of the implementations we performed 
>>> using Java X3D player, during our research in a project we are working 
>>> in collaboration with other departments, (i-promotion) (greek content 
>>> description : http://www.ipromotion.gr/) . There is a lot of 
>>> optimization needed for such an application to be published, the delay 
>>> is almost unacceptable. 
>>> There is a procedural streaming approach we tested and published in a 
>>> minipage (during model loading you can navigate in the world). 
>>> Utilizing Websockets, simple http requests and a batch request 
>>> http://www.medialab.teicrete.gr/minipages/x3domstream/ 
>>> furthermore, if you are interested some of our research demos are here: 
>>> http://www.medialab.teicrete.gr/index.php/minipages 
>>> On Fri, May 9, 2014 at 8:57 PM, doug sanden 
> <highaspirations at hotmail.com<mailto:highaspirations at hotmail.com><mailto:highaspirations at hotmail.com<mailto:highaspirations at hotmail.com>><mailto:highaspirations at hotmail.com<mailto:highaspirations at hotmail.com><mailto:highaspirations at hotmail.com<mailto:highaspirations at hotmail.com>>>> 
>>> wrote: 
>>> Kostas, 
>>> Not sure how you use DASH with x3d. What does it look like? 
>>> -Doug 
>>> more.. 
>>> I had an idea -and may get to it in the next year- for something I call 
>>> 'Server-Side Rendering' or SSR for short. If you've got beautiful Crete 
>>> 3D tourist scenery -in X3D format- and want web surfers to be able to 
>>> go around in 3D -but without heavy-duty x3dom .js, and without plugins- 
>>> then the idea is that the client swipes/drags a 2D Html5 canvas which 
>>> causes a 3D grid of construction lines to be redrawn as if navigating 
>>> through the grid in 3D. When they lift their finger/mouse button at the 
>>> end of the swipe/drag, the cumulative navigation is sent to the server, 
>>> which moves the avatar in the scene and renders the snapshot from the 
>>> new viewpoint pose, and ajaxes the view back to the client. 
>>> This would need an x3d renderer capable of holding session state -if 
>>> the scene state is different for each user- or else passing back the 
>>> cumulative navigation in a cookie or restful url after correcting for 
>>> collision and gravity to the cumulative navigation. 
>>> Perhaps DASH-X3D is something like that, except the client has no 
>>> control over the path, and instead of ajaxing snapshots a movie-like 
>>> MPEG stream is sent. 
>>>> to whom it may concern, 
>>>> In multimedia content laboratory of TEI of Crete, we are working on a 
>>>> new profile/interoperability point, for 3D scenes delivery (X3D). 
>>>> My first approach is based on ISO/IEC 23009-1. 
>>>> I would kindly ask if anyone else is currently working on 3D scene 
>>>> delivery for MPEG-DASH to contact me. Additionally, I would like more 
>>>> information on how to describe a new interoperability point (the 
>>>> documents which should be delivered for review according to 
>>>> http://dashif.org/identifiers/how-to-register/ ). 
>>>> Best Regards, 
>>>> -- 
>>>> Kostas 
>>>> ​ ​ 
>>>> Kapetanakis 
>>>>>>>>>>>> ​Project coordinator - R&D 
>>>> McLab​ -​ Informatics Engineering 
>>>>>>>> T​EI​​ of Crete​ 
>>> -- 
>>> Kostas 
>>> Kapetanakis 
>> -- 
>> Kostas Kapetanakis 
>>>> ​Project coordinator - R&D 
>> McLab​ -​ Media Content Laboratory 
>> Informatics Engineering 
>>>> T​EI​​ of Crete​ 
> www.medialab.teicrete.gr<http://www.medialab.teicrete.gr><http://www.medialab.teicrete.gr/> 
> -- 
> Kostas Kapetanakis 
>> ​Project coordinator - R&D 
> McLab​ -​ Media Content Laboratory 
> Informatics Engineering 
>> T​EI​​ of Crete​ 
> www.medialab.teicrete.gr<http://www.medialab.teicrete.gr/> 

More information about the X3D-Public mailing list