SigGraph REST3D BOF

[Rémi Arnaud]

I organized a BOF at SigGraph for the REST3D group. I took a small room as I did not think many will show up based on the mailing list RSVP, but the room was full (~20 people) and several people standing. There was people from university, start-ups, and big companies such as Autodesk, as well as Neil Trevett (Khronos president), and some participants already in this email group, I did not ask for the contact information but I did create a small document that contains the information for this mailing list and the web site, so hopefully they will follow their interest by joining this Google Group.

I created a pamphlet to foster the conversation, which Rita uploaded there: http://www.scribd.com/doc/102183295

There was a lot of interest in this technology and a lot of questions. Unfortunately I was organizing, presenting and answering questions, so I did not take notes. If you were present at the meeting please add to this thread.

Most of the discussion was to introduce REST and how it can be applied to 3D. Fabrice talked about the COLLADA2Json work he had been working on as a possible service that could be access through REST3D. There was questions about how this specification could me made a 'real' standard through an IP organization - which I replied that there would not be a problem to have the API moved to a consortium if it was needed once we have done the work on the specification and proved the community interest. There was a set of questions related to how to provide authentication and control over what the user can have access to. I replied that we had already discussed this and that it was outside the scope of REST3D as there are many existing right management services that can all be used with a REST api, such as oauth for example. But still there was some doubts so this seems to be important to provide an example of such integration. Everyone seemed really excited by the work, but there was some questions about focusing on a specific services set of features first. The group suggested that we should focus on viewer first, while making sure the spec is not taking shortcuts specific to viewer and http. 

So I think the work ahead is to create a RESTful API that can provide services such as upload, search, and embedded viewer. The beauty of REST is that if the client does not know what to do with the representation of the data, it can be provided the code for the feature by the REST API, which is very easy to do in a browser through javascript/webGL. During SigGraph I have seen a lot of different work that propose data representation and viewing feature, such as X3DOM, XML3D, COLLADA2json and commercial products that could provide their service through a standard REST3D API.

BTW, right after SigGraph I had a meeting with sunglass, a startup providing client/server 3D services, with a REST API 

https://sunglass.io/api/ that is worth taking a look at.

Looking forward to comments and proposals.

Best Regards

-- Remi Arnaud

[Ina Yosun Chang]

Most of the discussion was to introduce REST and how it can be applied to 3D. Fabrice talked about the COLLADA2Json work he had been working on as a possible service that could be access through REST3D. There was questions about how this specification could me made a 'real' standard through an IP organization - which I replied that there would not be a problem to have the API moved to a consortium if it was needed once we have done the work on the specification and proved the community interest. There was a set of questions related to how to provide authentication and control over what the user can have access to. I replied that we had already discussed this and that it was outside the scope of REST3D as there are many existing right management services that can all be used with a REST api, such as oauth for example. But still there was some doubts so this seems to be important to provide an example of such integration. Everyone seemed really excited by the work, but there was some questions about focusing on a specific services set of features first. The group suggested that we should focus on viewer first, while making sure the spec is not taking shortcuts specific to viewer and http. 

Didn't get to attend the REST 3D session @ SIGGRAPH due to scheduling conflicts, so catching up.. :( 

I'm not sure why the focus should be on viewer first, as the REST 3D API (to me) seems to be essentially a datastore, providing models in at least one standard format (COLLADA, .obj, etc), that any arbitrary third party viewer can then parse and load the model. 

In either case, there are already countless 3D model viewers out there, on various platforms. (This is not counting the fact that most 3D games/apps contain a basic 3D model viewer at its foundation.) Most of these viewers lack content. The issue is that there isn't a standardized source of 3D content accessible via API (with enough content). 

 

So I think the work ahead is to create a RESTful API that can provide services such as upload, search, and embedded viewer. The beauty of REST is that if the client does not know what to do with the representation of the data, it can be provided the code for the feature by the REST API, which is very easy to do in a browser through javascript/webGL. During SigGraph I have seen a lot of different work that propose data representation and viewing feature, such as X3DOM, XML3D, COLLADA2json and commercial products that could provide their service through a standard REST3D API.

From the backend data storage perspective, it should simply be the content stored as N standard 3D file formats, with some query structure for retrieval. Again, the "embedded viewer" could be provided by any of a number of third party 3D viewers.  

I am still not sure what the goal of REST 3D is -- is it to provide a working spec for a REST-ful 3D API, or to also provide a universal data repository as well (in which case, who's funding the storage/server)? 

[Rémi Arnaud]

Please see below.

On Thu, Aug 16, 2012 at 7:10 PM, Ina Yosun Chang <yos...@gmail.com> wrote:

Most of the discussion was to introduce REST and how it can be applied to 3D. Fabrice talked about the COLLADA2Json work he had been working on as a possible service that could be access through REST3D. There was questions about how this specification could me made a 'real' standard through an IP organization - which I replied that there would not be a problem to have the API moved to a consortium if it was needed once we have done the work on the specification and proved the community interest. There was a set of questions related to how to provide authentication and control over what the user can have access to. I replied that we had already discussed this and that it was outside the scope of REST3D as there are many existing right management services that can all be used with a REST api, such as oauth for example. But still there was some doubts so this seems to be important to provide an example of such integration. Everyone seemed really excited by the work, but there was some questions about focusing on a specific services set of features first. The group suggested that we should focus on viewer first, while making sure the spec is not taking shortcuts specific to viewer and http. 

Didn't get to attend the REST 3D session @ SIGGRAPH due to scheduling conflicts, so catching up.. :( 

I'm not sure why the focus should be on viewer first, as the REST 3D API (to me) seems to be essentially a datastore, providing models in at least one standard format (COLLADA, .obj, etc), that any arbitrary third party viewer can then parse and load the model. 

RESTfull API mandate is to separate the content from its representation, but it also mandate that the server know about the data so it can provide services on such data. In other words it does not matter what format is used in the server, or what format is used to upload or download data from the server, as long as the server can understand that data, can provide representation of that data through the REST API, and can provide services  Downloading content in a specific format may be a feature specified in the REST API, but it is not necessary its main usage model.

In either case, there are already countless 3D model viewers out there, on various platforms. (This is not counting the fact that most 3D games/apps contain a basic 3D model viewer at its foundation.) Most of these viewers lack content. The issue is that there isn't a standardized source of 3D content accessible via API (with enough content). 

Yes, hopefully there would be clients applications in or outside a web browser, on various platforms that can take advantage of REST3D, This said REST3D is a API that need to be implemented by the server, and enabling servers to provide viewer code on demand is well withing the concept of RESTfull application, and also as you point out, can be implemented in a variety of ways.

 

So I think the work ahead is to create a RESTful API that can provide services such as upload, search, and embedded viewer. The beauty of REST is that if the client does not know what to do with the representation of the data, it can be provided the code for the feature by the REST API, which is very easy to do in a browser through javascript/webGL. During SigGraph I have seen a lot of different work that propose data representation and viewing feature, such as X3DOM, XML3D, COLLADA2json and commercial products that could provide their service through a standard REST3D API.

From the backend data storage perspective, it should simply be the content stored as N standard 3D file formats, with some query structure for retrieval. Again, the "embedded viewer" could be provided by any of a number of third party 3D viewers.  

I am still not sure what the goal of REST 3D is -- is it to provide a working spec for a REST-ful 3D API, or to also provide a universal data repository as well (in which case, who's funding the storage/server)? 

The goal is to apply the RESTfull design to 3D and create a common specification. Once there is a standard way to (for example expose a data repository), then this will make it easier for end users and application developers to take advantage of 3D content in the web/cloud. There are already a lot of web site providing content repository (ourbricks, sketchup warehouse, 3dvia to name a few). Would it be nice that their content could be access directly from one application, or one web application? Would it be great that one can search the content for detail information without having to download each models one by one into a local modeling tool to be able to analyse the model and know which one is the model they have been looking for?

I hope this helps,

-- Remi 

[Rémi Arnaud]

Suspicious ? :-)

Verse was a research project financed by the European Community. As a research project it had some interesting findings we should learn from.

rest3D is a not a research project, but a group of people that gathered together to put together a practical specification.. if that is what you mean by suspicious.

This said, the group has been quite dormant, except at the SigGraph BOF where we had standing audience. I have carved out time for this and will resume regular work on this soon.

Regards
-- Remi

On Tue, Oct 9, 2012 at 2:51 AM, Govert Combée <gco...@gmail.com> wrote:

I was researching how to use collada and webGL to make interactive websites without using a plugin, and one thing led to another and I ended up here.

3D rest sounds very interesting but: 

It might be me, but Rest3D sounds suspiciously like Verse ( http://quelsolaar.com/verse/index.html ) Wouldn't it be possible to use that as a foundation instead of reinventing the wheel?

Of course I might have missed some details here and there, but both projects sound suspiciously the same.

Kind regards,

Govert Combée

Catnip Games

On Friday, August 17, 2012 2:50:40 AM UTC+2, Rémi Arnaud wrote:

I organized a BOF at SigGraph for the REST3D group. I took a small room as I did not think many will show up based on the mailing list RSVP, but the room was full (~20 people) and several people standing. There was people from university, start-ups, and big companies such as Autodesk, as well as Neil Trevett (Khronos president), and some participants already in this email group, I did not ask for the contact information but I did create a small document that contains the information for this mailing list and the web site, so hopefully they will follow their interest by joining this Google Group.

I created a pamphlet to foster the conversation, which Rita uploaded there: http://www.scribd.com/doc/102183295

There was a lot of interest in this technology and a lot of questions. Unfortunately I was organizing, presenting and answering questions, so I did not take notes. If you were present at the meeting please add to this thread.

DMost of the discussion was to introduce REST and how it can be applied to 3D. Fabrice talked about the COLLADA2Json work he had been working on as a possible service that could be access through REST3D. There was questions about how this specification could me made a 'real' standard through an IP organization - which I replied that there would not be a problem to have the API moved to a consortium if it was needed once we have done the work on the specification and proved the community interest. There was a set of questions related to how to provide authentication and control over what the user can have access to. I replied that we had already discussed this and that it was outside the scope of REST3D as there are many existing right management services that can all be used with a REST api, such as oauth for example. But still there was some doubts so this seems to be important to provide an example of such integration. Everyone seemed really excited by the work, but there was some questions about focusing on a specific services set of features first. The group suggested that we should focus on viewer first, while making sure the spec is not taking shortcuts specific to viewer and http.