<div dir="ltr"><div class="gmail_default" style="font-family:georgia,serif">Dear Sanded,</div><div class="gmail_default" style="font-family:georgia,serif">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) </div>
<div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">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.</div>
<div class="gmail_default" style="font-family:georgia,serif">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)</div>
<div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">The MPEG-DASH in our minipages is using a video element (texture), to provide adaptive smooth HD video stream in the 3D world.</div>
<div class="gmail_default" style="font-family:georgia,serif">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.</div>
<div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">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. ..</div>
<div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif"><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, May 10, 2014 at 4:21 PM, doug sanden <span dir="ltr"><<a href="mailto:highaspirations@hotmail.com" target="_blank">highaspirations@hotmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Kostas,<br>
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.<br>
OK I see the MPEG-DASH on your page <a href="http://www.medialab.teicrete.gr/index.php/minipages" target="_blank">www.medialab.teicrete.gr/index.php/minipages</a><br>
I gather X3D-DASH is conceptually similar -smooth transition between resolutions- except for whole scenes, or parts of scenes?<br>
-Doug<br>
more..<br>
<br>
web3d ProximitySensor node <br>
<a href="http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/envsensor.html#ProximitySensor" target="_blank">www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/envsensor.html#ProximitySensor</a><br>
in combination with a Switch node, can be used to switch between resolutions of parts-of-scene as the avatar approaches/recedes.<br>
<br>
more..<br>
.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<br>
<a href="http://dug9.users.sourceforge.net/web3d/tests/26.x3d" target="_blank">http://dug9.users.sourceforge.net/web3d/tests/26.x3d</a><br>
refers image resource:<br>
absolute url='<a href="http://dug9.users.sourceforge.net/web3d/tests/helpers/front.gif" target="_blank">http://dug9.users.sourceforge.net/web3d/tests/helpers/front.gif</a>'<br>
relative url='helpers/front.gif'<br>
x3d allows for multiple urls<br>
multiple url='"helpers/front.gif' '<a href="http://dug9.users.sourceforge.net/web3d/tests/helpers/front.gif" target="_blank">http://dug9.users.sourceforge.net/web3d/tests/helpers/front.gif</a>'"<br>
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.<br>
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.<br>
<br>
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.<br>
<br>
So, much like we did with <a href="http://www.cloudvr.net/x3z.html" target="_blank">www.cloudvr.net/x3z.html</a> (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'.<br>
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.<br>
<br>
<br>
<br>
<br>
________________________________<br>
> From: <a href="mailto:kapekost@gmail.com">kapekost@gmail.com</a><br>
> Date: Sat, 10 May 2014 04:26:02 +0300<br>
> Subject: Re: [X3D-Public] DASH-X3D new profile - Interoper abilitypoint<br>
> To: <a href="mailto:highaspirations@hotmail.com">highaspirations@hotmail.com</a><br>
> CC: <a href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a><br>
<div class="">><br>
> x3z seems to be interesting, we might include it in future<br>
> implementations, or as additional mime-type in the DASH<br>
> interoperability point. Are there any players supporting this format?<br>
> or the developer has to temporary download the zip, uncompress and then<br>
> give the sources to the player?<br>
><br>
> In our example we focused more on the delivery protocols, and less on<br>
> chunking methods, for the partial streaming tests we used serial and<br>
> area short chunking mechanisms, generating autonomous chunks of indexes<br>
> and indexedFaceSet.<br>
><br>
> Regarding the DASH Interoperability point: To begin with, we will<br>
> consider an existing repository with existing versions of a model in a<br>
> variety of qualities. (the file format can be described as a mime time<br>
> of the representation, and the chunking mechanism should inform the<br>
> client on how to dynamically compose the final model)<br>
><br>
> The client will decide according to the available resources which chunk<br>
> will be requested, on a second pass the delivered (low quality) models<br>
> will be replaced with higher-quality ones (or a transformation -<br>
> morphing algorithm at this point would be interesting, sacrificing<br>
> hardware resources to minimize the network bandwidth demand) . The<br>
> replacing process has to be transparent to the user to maintain good<br>
> Quality of Experience (e.g. smooth interaction). In a future work we<br>
> might consider the significance of each model to prioritize the most<br>
> significant.<br>
><br>
><br>
> On Fri, May 9, 2014 at 10:13 PM, doug sanden<br>
</div>> <<a href="mailto:highaspirations@hotmail.com">highaspirations@hotmail.com</a><mailto:<a href="mailto:highaspirations@hotmail.com">highaspirations@hotmail.com</a>>><br>
<div class="">> wrote:<br>
> Kostas,<br>
>> <a href="http://www.medialab.teicrete.gr/index.php/minipages" target="_blank">http://www.medialab.teicrete.gr/index.php/minipages</a><br>
> Very interesting - I'll take a closer look.<br>
><br>
> Q. what about the .x3z scene zipping<br>
</div>> <a href="http://www.cloudvr.net" target="_blank">www.cloudvr.net</a><<a href="http://www.cloudvr.net" target="_blank">http://www.cloudvr.net</a>><br>
<div><div class="h5">> which is like googleEarth .kmz - a doc.x3d in the root of a .zip file,<br>
> and /images subfolder - or other docx style resource bundling - does<br>
> that fit with the manifest and chunking methods you use, or does your<br>
> method replace/obsolete these bundling methods?<br>
> -Doug<br>
><br>
>><br>
>> Dear Sanden,<br>
>><br>
>> The MPEG-DASH approach we are currently working on (for my master's<br>
>> dissertation) will present 3d models in several resolution instances<br>
>> and inspite of the BASEurl, the MPD will provide proper information for<br>
>> dynamic adaptation mechanisms to 3D players (browser-based or not). The<br>
>> content will be delivered and rendered client-side, as X3DOM originally<br>
>> works right now (and any other plug-in based player).<br>
>><br>
>> ...<br>
>> The approach with html5 canvas and gesture messages to a remote<br>
>> renderer having sessions, is one of the implementations we performed<br>
>> using Java X3D player, during our research in a project we are working<br>
>> in collaboration with other departments, (i-promotion) (greek content<br>
>> description : <a href="http://www.ipromotion.gr/" target="_blank">http://www.ipromotion.gr/</a>) . There is a lot of<br>
>> optimization needed for such an application to be published, the delay<br>
>> is almost unacceptable.<br>
>><br>
>> There is a procedural streaming approach we tested and published in a<br>
>> minipage (during model loading you can navigate in the world).<br>
>> Utilizing Websockets, simple http requests and a batch request<br>
>> <a href="http://www.medialab.teicrete.gr/minipages/x3domstream/" target="_blank">http://www.medialab.teicrete.gr/minipages/x3domstream/</a><br>
>><br>
>> furthermore, if you are interested some of our research demos are here:<br>
>> <a href="http://www.medialab.teicrete.gr/index.php/minipages" target="_blank">http://www.medialab.teicrete.gr/index.php/minipages</a><br>
>><br>
>><br>
>><br>
>> On Fri, May 9, 2014 at 8:57 PM, doug sanden<br>
>><br>
</div></div>> <<a href="mailto:highaspirations@hotmail.com">highaspirations@hotmail.com</a><mailto:<a href="mailto:highaspirations@hotmail.com">highaspirations@hotmail.com</a>><mailto:<a href="mailto:highaspirations@hotmail.com">highaspirations@hotmail.com</a><mailto:<a href="mailto:highaspirations@hotmail.com">highaspirations@hotmail.com</a>>>><br>
<div class="im HOEnZb">>> wrote:<br>
>> Kostas,<br>
>> Not sure how you use DASH with x3d. What does it look like?<br>
>> -Doug<br>
>> more..<br>
>> I had an idea -and may get to it in the next year- for something I call<br>
>> 'Server-Side Rendering' or SSR for short. If you've got beautiful Crete<br>
>> 3D tourist scenery -in X3D format- and want web surfers to be able to<br>
>> go around in 3D -but without heavy-duty x3dom .js, and without plugins-<br>
>> then the idea is that the client swipes/drags a 2D Html5 canvas which<br>
>> causes a 3D grid of construction lines to be redrawn as if navigating<br>
>> through the grid in 3D. When they lift their finger/mouse button at the<br>
>> end of the swipe/drag, the cumulative navigation is sent to the server,<br>
>> which moves the avatar in the scene and renders the snapshot from the<br>
>> new viewpoint pose, and ajaxes the view back to the client.<br>
>> This would need an x3d renderer capable of holding session state -if<br>
>> the scene state is different for each user- or else passing back the<br>
>> cumulative navigation in a cookie or restful url after correcting for<br>
>> collision and gravity to the cumulative navigation.<br>
>> Perhaps DASH-X3D is something like that, except the client has no<br>
>> control over the path, and instead of ajaxing snapshots a movie-like<br>
>> MPEG stream is sent.<br>
>><br>
>><br>
>>><br>
</div><div class="HOEnZb"><div class="h5">>>> to whom it may concern,<br>
>>><br>
>>> In multimedia content laboratory of TEI of Crete, we are working on a<br>
>>> new profile/interoperability point, for 3D scenes delivery (X3D).<br>
>>> My first approach is based on ISO/IEC 23009-1.<br>
>>> I would kindly ask if anyone else is currently working on 3D scene<br>
>>> delivery for MPEG-DASH to contact me. Additionally, I would like more<br>
>>> information on how to describe a new interoperability point (the<br>
>>> documents which should be delivered for review according to<br>
>>> <a href="http://dashif.org/identifiers/how-to-register/" target="_blank">http://dashif.org/identifiers/how-to-register/</a> ).<br>
>>> Best Regards,<br>
>>><br>
>>> --<br>
>>> Kostas<br>
>>> <br>
>>> Kapetanakis<br>
>>> <br>
>>> <br>
>>> Project coordinator - R&D<br>
>>> McLab - Informatics Engineering<br>
>>> <br>
>>> TEI of Crete<br>
>>><br>
>><br>
>><br>
>><br>
</div></div><span class="HOEnZb"><font color="#888888">>> --<br>
>> Kostas<br>
>> Kapetanakis<br>
><br>
><br>
><br>
><br>
> --<br>
> Kostas Kapetanakis<br>
> <br>
> Project coordinator - R&D<br>
> McLab - Media Content Laboratory<br>
> Informatics Engineering<br>
> <br>
> TEI of Crete<br>
> <a href="http://www.medialab.teicrete.gr" target="_blank">www.medialab.teicrete.gr</a><<a href="http://www.medialab.teicrete.gr/" target="_blank">http://www.medialab.teicrete.gr/</a>><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><font face="courier new, monospace" color="#000000"><b>Kostas Kapetanakis</b><br></font><div>
<font face="courier new, monospace" color="#000000"><span style="line-height:19.5px"><div style="display:inline"></div></span><span style="line-height:19.5px">Project coordinator - R&D</span></font></div><div><font face="courier new, monospace" color="#000000"><span style="line-height:19.5px">McLab - Media Content Laboratory</span></font></div>
<div><font face="courier new, monospace" color="#000000"><span style="line-height:19.5px">Informatics Engineering </span></font></div><div><font face="courier new, monospace" color="#000000"><span style="line-height:19.5px"><div style="display:inline">
</div></span><span style="line-height:19.5px">TEI of Crete</span></font></div><div><span style="line-height:19.5px"><a href="http://www.medialab.teicrete.gr/" target="_blank"><font face="courier new, monospace" color="#000000">www.medialab.teicrete.gr</font></a></span></div>
</div>
</div>