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

doug sanden highaspirations at hotmail.com
Wed Oct 16 06:52:51 PDT 2013


> Doug,
>
>> 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:
>
> "data:" URIs are required to be either base64- or percent/hex-encoded (or
> were; I'm not aware of any updates to the standard but haven't really been
> paying attention, either). That's an automatic 33% (or more) increase in
> file size, and you won't get it back with on-the-fly compression, either.
>
> http://tools.ietf.org/html/rfc2397
>
> Greg
>

Thanks Greg - great to have access to your compression knowledge from your work on zlib.

Summary: the web3d equivalent to GoogleEarth's .kmz/.zip file approach of resource bundling would compress ~33% smaller than equivalent single-file data:URI approach, as well as being more convenient for multi-scene/level scenarios such as games where scenes/subscenes/levels/externProtos can be bundled and loaded on demand during the play action.

-Doug

>>>
>>> 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 id=
>> ea
>>>> 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, als=
>> o
>>> 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_ur=
>> i.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 remaini=
>> ng
>>> 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
> 		 	   		  


More information about the X3D-Public mailing list