[X3D-Public] [FreeWRL-develop] .x3z and minizip; bundling of resources for X3D binary

[doug sanden]

Michalis,
Thanks. That explains a lot. Likely just freewrlians struggling to cope with no uridata parsing. I wonder why googlearth didn't use uridata. X3db format would be more worthwhile to support if uridata 'meat' in the scene file. Except it was probably easier to implement the zip in freewrl: once unzipped it is regular parsing. And easy to author and inspect the bundle. But it does require temp disk folder. FreeWRL has separate worker threads for parsing and texture preparation. Pros and cons. 
Yes it could be fun for games! If you anchor between rooms or indoor/outdoor scenes all those scenes can be be parsed separately as needed. Which may render faster depending on viewer. Just the startup scenefile gets the doc.x3d name. Thanks for the feedback.
Doug.

> Date: Tue, 15 Oct 2013 00:01:56 +0200
> From: michalis.kambi at gmail.com
> To: highaspirations at hotmail.com
> CC: brutzman at nps.edu; x3d-public at web3d.org; freewrl-develop at lists.sourceforge.net
> Subject: Re: [X3D-Public] [FreeWRL-develop] .x3z and minizip; bundling of resources for X3D binary
> 
> doug sanden wrote:
> >   So instead of a plugin being passed an http:// url, and
> > pulling resources one by one, a web browser may offer to DownloadFile
> > and SaveAs. Then you would open it as a local file with your web3d tool.
> >   That works well for scenes with no url resources. If it has urls with
> > relative paths, the program that opens the local file will have no idea
> > of the original base url, and won't be able to pull/download relative resources.
> 
> The data URI scheme, already supported by many VRML/X3D browsers, also 
> allows to embed any content inside a single X3D file. See 
> http://en.wikipedia.org/wiki/Data_URI_scheme , example file from 
> view3dscene demos: 
> http://svn.code.sf.net/p/castle-engine/code/trunk/demo_models/x3d/data_uri.x3dv 
> . One advantage is that it works the same in HTML, and in all other 
> formats that use URLs, and there's no need to extend the specification: 
> you can just say "everywhere where URL is allowed, data URI is also Ok".
> 
> Anyway, the idea of bundling in a zip file is also very promising. For 
> one thing, you can read X3D file 1st, and only later load the remaining 
> resources (e.g. you can decompress texture data from disk in parallel to 
> loading mesh data to GPU, if you want to go crazy with optimizing load 
> time :). This is not really possible with data URI (as you have to 
> actually download the whole data URI contents to be able to parse the 
> rest of the file). Well, assuming that zip file is compressed with 
> doc.x3d file first, but that should be perfectly possible AFAIK.
> 
> Great job, and personally I would enjoy standardizing this idea in X3D. 
> The idea of bundling resources in a zip file is common in game engines 
> (especially useful to distribute game mods), and as I'm implementing a 
> game engine using X3D --- it would be cool if it would be just a 
> standard X3D feature :)
> 
> Regards,
> Michalis
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20131014/f8592042/attachment.html>