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

doug sanden highaspirations at hotmail.com
Sat May 10 06:21:44 PDT 2014


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
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
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 (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 
> Date: Sat, 10 May 2014 04:26:02 +0300 
> Subject: Re: [X3D-Public] DASH-X3D new profile - Interoper abilitypoint 
> To: highaspirations at hotmail.com 
> CC: 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>> 
> 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> 
> 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>>> 
>> 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/> 
 		 	   		  


More information about the X3D-Public mailing list