[RFC] 3d-REST scope/plan
Thomas Paviot
I recently joined this 3D-REST group and read with a lot of interest the post from Marc Petit "First list of needed functions" (http://groups.google.com/group/3d-rest/browse_thread/thread/5c51bfb49902e74f). This is a very intersting attempt to get started with a kind of feature requests, however I still feel a bit confused with the intents of this 3D-REST project in order to comment this post or contribute any other request/proposal.
Actually the expression "3D" in 3D-REST covers a wide domain and may be understood in different ways according to the domain application you're coming from. I'm from the CAD/CAM area, in which the creation/exchange/use of 3D assets becomes more and more important for many years so far. In the automotive, aerospace or shipbuilding industries, 3D models are used by many different players along the product lifecycle, each of them running business specific processes: modeling, visualization, inspection, project review, manufacturing, exchange, rendering etc.
I carefully read the REST-3D blog (http://rest3d.wordpress.com/), the slideshare slideshow (http://www.slideshare.net/remi_arnaud/6-10presentation) and I also watched the related youtube video (http://www.youtube.com/watch?v=w9KSRThsRm8). According to this material, the scope of the 3D-REST API project here discussed seems quite huge, and it should be useful IMO to first discuss the scope and aim of this API, in terms of application domain, before going down into technical discussions dealing with the functions/classesmethods/objects to be accessed and exchanged in a RESTful manner. I have then a few unstructured questions/comments:
1. does this 3D-REST project aim at being application domain independant? That is to say that the provided services could be used as-is by any 3D interested user whereever he comes from. These services would then have a very small granularity ;
2. would you like having business specific cases adressed by the API? In such a case, the granularity would be greater, but a lot of business needs would have to be clearly defined and specified. This may lead to many and interoperable sets of services, in the same way the ISO 10303-STEP standard was divided into Application Protocols ;
3. do you expect these 3D-REST services to be extensible? In case we state that it's impossible to specify the complete set of possible (and needed) services, the way to specify a specialization of the services in regard with a generic model would have to be explicitely defined -> specialized services could then be discovered on-the-fly and made accessible over a wide network.
4. do you epxect this 3D-REST to be compliant with the most famous industrial standards, or, even better, to rely on usual data models used for product reprentation/presentation? I especially think about the STEP and COLLADA standards.
5. do the 3D-REST adress sync or aysnchronous collaboration over a 3D model? From my experience and knowledge, industrial workflows currently only support asynchronous collaboration.
6. In the "Use Case 3-content repository" (from the slideshow), what do you exactly mean with "update - modify an existing model"? Would this be BRep based? subdivision surfaces? CSG? Would you expect to modify the topology of a shape or only its dimensions?
7. In the "Use Case 3-content repository" (from the slideshow), what do you exactly mean with "diff/merge"? Do you wish to diff/merge 3D models or diff/merge attached metadata? Did you already think about a suitable workflow (similar to usual PDM checkin/checkout? subversion revisions based? a GIT branches model?)
I maybe offtopic with such questions, sorry for the noise if they have already been answered. My current concern deal with webservices in an industrial context, especially the OMG PLM Services, OMG CAD Services, PLCS Services and the way to make them better. I'd like to contribute making CAD/CAD collaboration a step further in terms of workflows and underlying software/network architectures, and I'd be glad that this work meet some of your expectations. That's why I need a bit more feedback about them, in order to check whether or not this place if the good one for such discussions.
Best Regards,
Thomas
coderextreme
On Jul 22, 3:07 pm, Thomas Paviot <tpav...@gmail.com> wrote:
> 1. does this 3D-REST project aim at being application domain independant?
> That is to say that the provided services could be used as-is by any 3D
> interested user whereever he comes from. These services would then have a
> very small granularity ;
subsets thereof (make 3D models browseable).
> 2. would you like having business specific cases adressed by the API? In
> such a case, the granularity would be greater, but a lot of business needs
> would have to be clearly defined and specified. This may lead to many and
> interoperable sets of services, in the same way the ISO 10303-STEP standard
> was divided into Application Protocols ;
an example of how to use the API.
> 3. do you expect these 3D-REST services to be extensible? In case we state
> that it's impossible to specify the complete set of possible (and needed)
> services, the way to specify a specialization of the services in regard with
> a generic model would have to be explicitely defined -> specialized services
> could then be discovered on-the-fly and made accessible over a wide network.
wrong. URIs are pretty extensible.
> 4. do you epxect this 3D-REST to be compliant with the most famous
> industrial standards, or, even better, to rely on usual data models used for
> product reprentation/presentation? I especially think about the STEP and
> COLLADA standards.
STEP and COLLADA. Do STEP or COLLADA specify a URI standard?
> 6. In the "Use Case 3-content repository" (from the slideshow), what do you
> exactly mean with "update - modify an existing model"? Would this be BRep
> based? subdivision surfaces? CSG? Would you expect to modify the topology of
> a shape or only its dimensions?
updating models (but avoiding sql injection). These updates would
have to be validated by (signed) the server for true security. That
is, use web keys to reference a particular update on the server. The
update would have bind parameters for extensibility. Also, queries,
updates and inserts could be handled similarly. This is probably not
3D REST though.
Mark Barnes
On Jul 22, 3:07 pm, Thomas Paviot <tpav...@gmail.com> wrote:I expect it to be independent and orthogonal of (but still support)
> 4. do you epxect this 3D-REST to be compliant with the most famous
> industrial standards, or, even better, to rely on usual data models used for
> product reprentation/presentation? I especially think about the STEP and
> COLLADA standards.
STEP and COLLADA. Do STEP or COLLADA specify a URI standard?
COLLADA documents are XML documents that reference elements using standard URI. I wrote a blog about how important I think this is it a couple of months. See http://collada.xs.com/2011/05/collada-and-uri-processing/ .
COLLADA 1.5 is one of the approved visualization formats for STEP, by ISO TC184/SC4, and is in the process of becoming an ISO PAS specification.
Regards,
Mark
Mark Barnes
Chief Scientist, Mechnicality, Inc.
http://www.mechnicality.com
Khronos COLLADA work group chairman
Rémi Arnaud
Hi Thomas,
Thanks for this post, and welcome to the working group.
Here’s my personal view about your questions.
1. does this 3D-REST project aim at being application domain independant? That is to say that the provided services could be used as-is by any 3D interested user whereever he comes from. These services would then have a very small granularity ;
The granularity is a good question, I think that granularity will start high in the first ‘release’ of the API, and will probably get finer as the API gets refined. This is for practical design considerations and for enabling feedback / extensions / experimentation. For example on how fine the grain could be, in my previous email I envisioned an API call to return low level information in a typed array ,which format would be provided as a parameter to the query.
2. would you like having business specific cases adressed by the API? In such a case, the granularity would be greater, but a lot of business needs would have to be clearly defined and specified. This may lead to many and interoperable sets of services, in the same way the ISO 10303-STEP standard was divided into Application Protocols ;
We are in midst of collecting use cases right now, and we should then consider which use case we need to focus on to start with. Granularity of first version will come from use case, and will probably not be uniform across the API services. In other words I do not see a clear design restriction to impose regarding what level of granularity or integration the API should have, or if it should be uniform. But this group has a desire not to re-invent the wheel, and certainly not to create YAF (yet another format)
3. do you expect these 3D-REST services to be extensible? In case we state that it's impossible to specify the complete set of possible (and needed) services, the way to specify a specialization of the services in regard with a generic model would have to be explicitely defined -> specialized services could then be discovered on-the-fly and made accessible over a wide network.
Yes, it’s already in the ‘spec’, a by-product of namespace. Basically http://bla/rest3d/[version]/[my_extension_name_space]/[feature] Discovery is probably going to be done through the /version call already defined in the spec
Could you take the time to think about and propose what the /version function should return to present the extension set so they can be discovered on-the-fly. IMHO, there is no real need to give tons of details per extensions, as a programmer would have to be involved to take advantage of the API, but links to where the documentation is would be a good thing to have.
4. do you epxect this 3D-REST to be compliant with the most famous industrial standards, or, even better, to rely on usual data models used for product reprentation/presentation? I especially think about the STEP and COLLADA standards.
Mark Barnes already addressed this question. I’d add that the rest-3d server should be able to provide the model in the format or formats that is useful for their business case, and get access to the model through the 3d Rest API, but IMHO the value of the 3D rest API is to provide information about the model, using XML/JSON/html to encode the return values of the function, to provide information about the model BEFORE the model is downloaded, or/and provide features to process the model in the server, again before any model is downloaded back into the client. So 3d-rest is not at the same level of functionality/description than STEP or COLLADA. This said, if you see an existing REST API specification that could be used already, please forward this to this working group as it is not our intent to re-invent the wheel.
5. do the 3D-REST adress sync or aysnchronous collaboration over a 3D model? From my experience and knowledge, industrial workflows currently only support asynchronous collaboration.
That’s a good question. But it is a bit too early to discuss solution, before spending time explaining the problem that need to be solved. Could you please write up a use case (using the already posted use cases as a model) and submit to this working group, that would require synchronized collaboration over a 3D model?
6. In the "Use Case 3-content repository" (from the slideshow), what do you exactly mean with "update - modify an existing model"? Would this be BRep based? subdivision surfaces? CSG? Would you expect to modify the topology of a shape or only its dimensions?
This is open for discussion, and once again this will depend on proposed use cases. The advantage of working with a client/server architecture is that the server can maintain a representation, or serveral representations, enable the (3d-rest) API to manipulate this model, and return a simpler model for the client to use. I can imagine a use case where a B-REP model, or a Second Live primitive model, or any other specific representation maintained by a server, while still sending back simple triangulations to the client. I can see 3d-rest to be the same API used to communicate with a server, whether this server is a BREP, CAD, second-life based server, and make it transparent to the (web) application
> I maybe offtopic with such questions, sorry for the noise if they have already been answered
Absolutely not, you are asking the right questions. I hope you will find the time to continue this discussion and submit use cases that support your needs.
-- Remi
Philipp Slusallek
Am 03.08.2011 00:33, schrieb R�mi Arnaud:
> 1. does this 3D-REST project aim at being application domain
> independant? That is to say that the provided services could be used as-is
> by any 3D interested user whereever he comes from. These services would then
> have a very small granularity ;
>
> The granularity is a good question, I think that granularity will start high
> in the first �release� of the API, and will probably get finer as the API
> gets refined. This is for practical design considerations and for enabling
> feedback / extensions / experimentation. For example on how fine the grain
> could be, in my previous email I envisioned an API call to return low level
> information in a typed array ,which format would be provided as a parameter
> to the query.
I agree with the approach in general. Things are reasonably easy as long
as you talk about entire scenes or at least self-contained subscenes
(which are essentially the same thing). As soon as you address
individual primitives of the scene, we face the problem of having to
define their interfaces and how they all relate to each other. This
essentially boils down to defining a common reference model for 3D
scenes -- something that has eluded the community for a very long time.
VRML/X3D and Collada defining something like this but I am not sure that
they are a good match for the APIs we seem to have in mind. Collada for
example is designed as an exchange format, which has very different
goals than a 3D-API.
There is also the new W3C Community Group on "Declarative 3D for the
Web" that we are starting right now (official W3C-Link should come next
week). An API is in the charter of this group and so there may be good
synergies, depending on where this group plans to go. Specifically,
since that group will have to define some reference model itself and
since the Web and Services go well together, anyway.
I have issues with you suggestion of going down to typed arrays. 3D
content inherently has a rich internal structure (which is the core of
the problem). A vertex array without a shader to interpret the data does
not make much sense these days and so we immediately have all the
difficult issues in the boat as well.
> 2. would you like having business specific cases adressed by the API?
> In such a case, the granularity would be greater, but a lot of business
> needs would have to be clearly defined and specified. This may lead to many
> and interoperable sets of services, in the same way the ISO 10303-STEP
> standard was divided into Application Protocols ;
>
> We are in midst of collecting use cases right now, and we should then
> consider which use case we need to focus on to start with. Granularity of
> first version will come from use case, and will probably not be uniform
> across the API services. In other words I do not see a clear design
> restriction to impose regarding what level of granularity or integration the
> API should have, or if it should be uniform. But this group has a desire not
> to re-invent the wheel, and certainly not to create YAF (yet another format)
We need to very carefully select the use cases that we plan to address
and work from the top down as you suggest. We should also clearly define
what is not in scope.
The mere mentioning of STEP makes me worry. This is an extremely complex
standard that took essentially decades to define. Its also very specific
to CAD, which is a potential political mine field. For the W3C
initiative we explicitly excluded CAD (which does not mean that we are
not looking at their requirements, they are just not a specific target
right now).
From my point the level of granularity has to gradually grow while we
are trying to define the necessary reference model in a top down
fashion. Again there are nice links to the 3D for the Web activities,
which has to do the same.
> 4. do you epxect this 3D-REST to be compliant with the most famous
> industrial standards, or, even better, to rely on usual data models used for
> product reprentation/presentation? I especially think about the STEP and
> COLLADA standards.
>
> Mark Barnes already addressed this question. I�d add that the rest-3d server
> should be able to provide the model in the format or formats that is useful
> for their business case, and get access to the model through the 3d Rest
> API, but IMHO the value of the 3D rest API is to provide information about
> the model, using XML/JSON/html to encode the return values of the function,
> to provide information about the model BEFORE the model is downloaded,
> or/and provide features to process the model in the server, again before any
> model is downloaded back into the client. So 3d-rest is not at the same
> level of functionality/description than STEP or COLLADA. This said, if you
> see an existing REST API specification that could be used already, please
> forward this to this working group as it is not our intent to re-invent the
> wheel.
You seem to be saying that 3D-rest is mostly looking at complete scenes
or self-contained sub-scenes (parts/objects/whatever). I believe this
makes a lot of sense at least for a first version. Still we need to
define, what is the information that can be meaningfully retrieved from
a scene/object in the generic case that you describe. Even something
like changing a shader is difficult, as an object may have many of them
and we would need to define a way to address shaders as separate objects
as well (plus have exchangeable versions of them, etc.).
> 5. do the 3D-REST adress sync or aysnchronous collaboration over a 3D
> model? From my experience and knowledge, industrial workflows currently only
> support asynchronous collaboration.
>
> That�s a good question. But it is a bit too early to discuss solution,
> before spending time explaining the problem that need to be solved. Could
> you please write up a use case (using the already posted use cases as a
> model) and submit to this working group, that would require synchronized
> collaboration over a 3D model?
Synchronous collaboration promises to pulls in essentially the entire
set of issues of online virtual worlds. Really interesting, but I would
not go there, at least yet.
> 6. In the "Use Case 3-content repository" (from the slideshow), what
> do you exactly mean with "update - modify an existing model"? Would this be
> BRep based? subdivision surfaces? CSG? Would you expect to modify the
> topology of a shape or only its dimensions?
>
> This is open for discussion, and once again this will depend on proposed use
> cases. The advantage of working with a client/server architecture is that
> the server can maintain a representation, or serveral representations,
> enable the (3d-rest) API to manipulate this model, and return a simpler
> model for the client to use. I can imagine a use case where a B-REP model,
> or a Second Live primitive model, or any other specific representation
> maintained by a server, while still sending back simple triangulations to
> the client. I can see 3d-rest to be the same API used to communicate with a
> server, whether this server is a BREP, CAD, second-life based server, and
> make it transparent to the (web) application
Yes, but exactly in the case of updates this breaks down. How do you
handle an update to the triangle structure, when the original model is a
Spline model?
Again from my point of view, we should carefully start from the top and
purposefully restrict our scope to the issues that we know how to solve.
Once we have a basis for this, we can dive deeper.
Thanks,
Philipp
--
===> Please note my new DFKI telephone number 0681 85775 5377 <===
-------------------------------------------------------------------------
Deutsches Forschungszentrum f�r K�nstliche Intelligenz (DFKI) GmbH
Trippstadter Strasse 122, D-67663 Kaiserslautern
Gesch�ftsf�hrung:
Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender)
Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats:
Prof. Dr. h.c. Hans A. Aukes
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973, Steuernummer: 19/673/0060/3
---------------------------------------------------------------------------
Rémi Arnaud
that we are starting right now (official W3C-Link should come next week). An
API is in the charter of this group and so there may be good synergies,
depending on where this group plans to go. Specifically, since that group
will have to define some reference model itself and since the Web and
Services go well together, anyway.
I agree.
> I have issues with you suggestion of going down to typed arrays. 3D
content inherently has a rich internal structure (which is the core of the
problem). A vertex array without a shader to interpret the data does not
make much sense these days and so we immediately have all the difficult
issues in the boat as well.
Of course there should be a rest-3d API to query all aspect of 3D content,
whereas it is geometry, dependencies (textures and all), shaders, physics,
and other type of data, in the form that is the most appropriate to the use
case. If the request is to carry this back to the application using embedded
X3D content within XHTML then why not? If the user desires to get vertex
data in typed arrays, then why not? If the user want a iFrame containing a
webGL viewer (or other form of 3D viewer) then why not?
Rest-3d is not there to replace formats, or impose one way to deal with 3D
content, but to provide client/server queries that enable managing 3D
content without having to do everything on the client application.
> Yes, but exactly in the case of updates this breaks down. How do you
handle an update to the triangle structure, when the original model is a
Spline model?
Easy enough, the triangle structure is created from the Spline model, and
the API provide features that act on the source model only.
> We need to very carefully select the use cases that we plan to address and
work from the top down as you suggest. We should also clearly define what is
not in scope.
I agree, and that's where we are at with this project.
IMHO, scope will be defined by the amount of work poured by all of us in
this, and the amount of time we give ourselves to get to 1.0
On one hand we could limit ourselves to ourbrick/warehouse usage model and
get a spec out quickly
On the other hand we could address more use cases and provide more services
with 1.0. This will depend on how much work gets done by this group.
> Again from my point of view, we should carefully start from the top and
purposefully restrict our scope to the issues that we know how to solve.
Once we have a basis for this, we can dive deeper.
We are in agreement, with maybe a slightly different way of handling this.
I personally do not want to put a hardline to what is in scope and what is
not. But I do want to clearly prioritize use cases and make sure we give
ourselves a milestone - target date for v1.0. So we make sure that we
release something useful for the use cases that are the most relevant to
this group, and directly reflect the amount of work put by individuals in
this project.
Regards
-- Rémi
-----Original Message-----
From: 3d-...@googlegroups.com [mailto:3d-...@googlegroups.com] On Behalf
Of Philipp Slusallek
Sent: Wednesday, August 03, 2011 6:24 AM
To: 3d-...@googlegroups.com
Cc: Rémi Arnaud
Subject: Re: [3D-REST] [RFC] 3d-REST scope/plan
Hi Remi,
Am 03.08.2011 00:33, schrieb Rémi Arnaud:
> 1. does this 3D-REST project aim at being application domain
> independant? That is to say that the provided services could be used
> as-is by any 3D interested user whereever he comes from. These
> services would then have a very small granularity ;
>
> The granularity is a good question, I think that granularity will
> start high in the first ‘release’ of the API, and will probably get
> Mark Barnes already addressed this question. I’d add that the rest-3d
> server should be able to provide the model in the format or formats
> that is useful for their business case, and get access to the model
> through the 3d Rest API, but IMHO the value of the 3D rest API is to
> provide information about the model, using XML/JSON/html to encode the
> return values of the function, to provide information about the model
> BEFORE the model is downloaded, or/and provide features to process the
> model in the server, again before any model is downloaded back into
> the client. So 3d-rest is not at the same level of
> functionality/description than STEP or COLLADA. This said, if you see
> an existing REST API specification that could be used already, please
> forward this to this working group as it is not our intent to re-invent
the wheel.
You seem to be saying that 3D-rest is mostly looking at complete scenes or
self-contained sub-scenes (parts/objects/whatever). I believe this makes a
lot of sense at least for a first version. Still we need to define, what is
the information that can be meaningfully retrieved from a scene/object in
the generic case that you describe. Even something like changing a shader is
difficult, as an object may have many of them and we would need to define a
way to address shaders as separate objects as well (plus have exchangeable
versions of them, etc.).
> 5. do the 3D-REST adress sync or aysnchronous collaboration over a
3D
> model? From my experience and knowledge, industrial workflows
> currently only support asynchronous collaboration.
>
> That’s a good question. But it is a bit too early to discuss solution,
Thanks,
Philipp
> 902e74 f). This is a very intersting attempt to get started with a
-------------------------------------------------------------------------
Deutsches Forschungszentrum für Künstliche Intelligenz (DFKI) GmbH
Trippstadter Strasse 122, D-67663 Kaiserslautern
Geschäftsführung: