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

kostas kapetanakis kapekost at gmail.com
Sat May 10 07:27:52 PDT 2014


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>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
> 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/>
>




-- 
*Kostas Kapetanakis*
​
​Project coordinator - R&D
McLab​ -​ Media Content Laboratory
Informatics Engineering
​
T​EI​​ of Crete​
www.medialab.teicrete.gr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20140510/7bd1da87/attachment-0001.html>


More information about the X3D-Public mailing list