File Format
43 views
Skip to first unread message
Makis Tracend
Nov 9, 2012, 1:31:49 AM11/9/12
to 3d-...@googlegroups.com
Hello,
I just read what I think is the latest version of the spec:
I found reasonable information on the web service operations but I'm wondering if the file format is part of the scope.
There was a mention in setting header info based on the 3d content but is the prospect to deliver every individual part (geometry, animation, textures...) separately or as a bundle? And if it's a bundle should it have a specific extension?
I'm fond of the concept of decoupling the components - especially by using versioning numbers the assets can be "upgraded" in the course of time (for example a model might just get a new texture) I'm just concerned about the amount of (initial) requests a server will get till the content is cached.
Also, any thoughts on LOD in the file name?
Sorry if this has been answered before, I did try to review some posts.
Cheers,
Makis
Rémi Arnaud
Nov 12, 2012, 11:29:33 PM11/12/12
to 3drest
Hi Makis,
Thank you for your interest and feedback.
The 'spec' is currently a very early draft with purpose to state the core principles and scope.
You are correct that the 'file format' is out of the current scope. However your questions are very relevant and to the core of the matter.
Please allow me to use a simplified model for illustration:
Rest is fundamentally an API, not a format. A format describes a data structure and syntax. A 'file format' is implying that the data is stored in a file, so that the entire dataset is available at once. An API on the other hand provides access to specific elements, returning handles to hierarchical structures, down to basic data type.
So in theory one could design an API that let you browse all elements and sub elements of a 3D model, down to simple types and have no idea what 'format' used to store the data really is. In practice this won't work as the API would be really complicated and slow.
On the other hand one could design a format that contains everything and there will be no need for an API at all, http get is altready there. This also is not practical as this would limit the applications that can directly take advantage of the format.
In fact I'd say there are at least 3 'formats'. The format the data is stored in the server backend, the format used for transporting the data to the client, and the format the client is using internally.
So in practice we need to find the right balance between API and data structures returned by the API.
In the presentation I just did for the WebGL meet-up and posted recently, I am taking a top-down design approach, assuming that there exists several applications and associated formats, and looking into exposing the steps of browsing, searching, converting, transfering, caching, and the hight level assets (models, images, shaders), and progressivelly digging into other assets that group or are included in those (scenes, meshes..).
Just like html does not define the format that an <img>, a <video> or even a <script> is, there will probably no need to define the specific format for rest3D assets. In fact, once the rest3D API is used to locate, search or create an asset, it should get out of the way as the application can access what it needs directly through an URI.
I hope this make sense, it will probably make more an more sense as I progress in developing the prototype and demonstrate how this could work.
Regards
- RemI
Thank you for your interest and feedback.
The 'spec' is currently a very early draft with purpose to state the core principles and scope.
You are correct that the 'file format' is out of the current scope. However your questions are very relevant and to the core of the matter.
Please allow me to use a simplified model for illustration:
Rest is fundamentally an API, not a format. A format describes a data structure and syntax. A 'file format' is implying that the data is stored in a file, so that the entire dataset is available at once. An API on the other hand provides access to specific elements, returning handles to hierarchical structures, down to basic data type.
So in theory one could design an API that let you browse all elements and sub elements of a 3D model, down to simple types and have no idea what 'format' used to store the data really is. In practice this won't work as the API would be really complicated and slow.
On the other hand one could design a format that contains everything and there will be no need for an API at all, http get is altready there. This also is not practical as this would limit the applications that can directly take advantage of the format.
In fact I'd say there are at least 3 'formats'. The format the data is stored in the server backend, the format used for transporting the data to the client, and the format the client is using internally.
So in practice we need to find the right balance between API and data structures returned by the API.
In the presentation I just did for the WebGL meet-up and posted recently, I am taking a top-down design approach, assuming that there exists several applications and associated formats, and looking into exposing the steps of browsing, searching, converting, transfering, caching, and the hight level assets (models, images, shaders), and progressivelly digging into other assets that group or are included in those (scenes, meshes..).
Just like html does not define the format that an <img>, a <video> or even a <script> is, there will probably no need to define the specific format for rest3D assets. In fact, once the rest3D API is used to locate, search or create an asset, it should get out of the way as the application can access what it needs directly through an URI.
I hope this make sense, it will probably make more an more sense as I progress in developing the prototype and demonstrate how this could work.
Regards
- RemI
-- Remi
From: Makis Tracend <makis....@gmail.com>
Sender: 3d-...@googlegroups.com
Date: Thu, 8 Nov 2012 22:31:49 -0800 (PST)
To: <3d-...@googlegroups.com>
ReplyTo: 3d-...@googlegroups.com
Subject: [3D-REST] File Format
Makis Tracend
Nov 13, 2012, 6:06:47 PM11/13/12
to 3d-...@googlegroups.com, re...@acm.org
Hi Remi,
Thanks for the response. I read through your presentation slides and appreciate the approach.
Thanks for the response. I read through your presentation slides and appreciate the approach.
I agree there needs to be a balance between API calls and decoupled components.
Keeping a record of available assets (on the client) may be helpful, checking the available resources, and if an asset is not available all related resources could be downloaded in one request - but I guess that can be left as a task for the application developer.
Following established principals of other media delivery (like video) I believe it also makes sense to request a low quality version of the asset first and then upscale if the bandwidth/client spec allows it.
I like the idea of a working example, I'm a hands on person after all ;)
Cheers,
Makis
Reply all
Reply to author
Forward
0 new messages