First list of needed functions
Marc PETIT
Sadly, I won't be going to SIGGRAPH this year. However, I already have started working on a 3D service for my own needs, so here are my two cents.
First, let me introduce the thing I've been working on. In order to understand what we could do with WebGL (I work in a power utility company), I started working on a proof of concept 3D asset management application. Presentation and model are in PHP, and as I knew I would need some 3D functions, I wrote from the beginning a 3D RESTful service. I started fairly basic and added functions as I needed them (remember, I only did this to mess a bit with WebGL, not as an actual project).
The first thing clearly needed was some sort of rendering. It was necessary both for thumbnails and in order to get some renders in the page showing each item (in the case the model was too big to download or render easily, or if the user didn't have WebGL available). I didn't want to suppose that the user would do the renders himself, or even supply the viewpoints (that way, even an external application could easily publish a model without prerequisites). That added the need to compute some default viewpoints (top, front, side), which in turn implied to have the bounding box.
Actualy, after playing a bit with the system, it became obvious that I also needed to expose the computed viewpoints. The reason is that when visualizing the model in WebGL, we need to set a sensible viewpoint that may not be included in the model. Since the bbox is needed on the service side (for viewpoints), exposing this function has near to no cost and can be useful too.
Those first tests thus lead me to a first bunch of needed functions :
1. Computing BBox (I used AABB, since only axis aligned viewpoints where computed in this first experiment, but OBB should be interesting too).
2. Computing viewpoints (default axis aligned viewpoints is a good start, but being able to compute direction from position or position from the rotation would be more interesting).
3. Rendering. A viewpoint and a resolution should be passed as parameters. Rendering the color of each pixel is obviously a good start, but it would also be interesting to add depth and normal in order to allow interesting effects (like the kind of cheating Alain Chsenais talked about in his keynote at Web3D 2011 ;-). Other kind of data could also be considered.
Those first functions are pretty easy to add to any service. There could be constraints (like virtualization, for example, which is quite mainstream in large companies) that make rendering far from real-time (thus leading to some kind of asynchronous architecture), but it is the only issue.
In order to get things easy, I only considered X3D at first. This allowed me to use the same format for managing data and for rendering (through X3DOM). However, this is quite a limiting factor, that leads me to another need :
4. Transformation between formats. Being able to export to at least one format easily usable with WebGL is a must have. Being able to translate between several formats would be great.
This is a complex one. Different formats have different expressing power. Translating complex structures to simpler ones (e.g. BReps to triangle lists) implies having a good understanding of the complex structure and of the constraints on the exported objects (precision). When similar structures exist, however, they should be translated from high level structure to high level structure. This makes me wonder if it wouldn't be necessary to have some "profile" system (basic profile without translation, web profile with import of several different formats, translator profile with true translation capabilities ...).
WebGL also has some constraints of its own. The limited size of vertex buffers and of possible draw calls (because of JavaScript) has an impact on the models that can be used. Some transformations on the models should be possible. There are at least two :
5. Merging meshes. Just to reduce the number of draw calls. This implies that there is a way to get the scene graph so that the application can chose which nodes to merge.
6. Reducing mesh complexity. This one is tough, but removing tiny details or degenerate triangles could make things easier on the presentation part.
Those last two may be hard, and can usually be done by people knowing what they are doing in some kind of "level editor". However, there are more and more cases where we want to make 3D edition available to non specialized people, who don't necessarily have the tools or knowledge available. The "profiles" possibility might be interesting here too.
This is the current state of my thoughts about the subject. I'm sorry about the length of this mail for a list of just 6 "functions", but after one or two conversations about the subject, I realized that some points weren't obvious without some context. I hope you guys have a great conversation at SIGGRAPH. Maybe someone could record it for those that won't be able to make it there ?
Best regards.
Marc
Rémi Arnaud
Hi Marc,
Welcome to this working group !
This is great that you provide a use case and ideas regarding the API.
Let me try to address your points, see if the rest of the group agrees/disagree..
1. Computing BBox (I used AABB, since only axis aligned viewpoints where computed in this first experiment, but OBB should be interesting too).
Yes it is one of the main goal of the 3D REST API to provide information about the 3D models before the user decides to download the model in its application. Bounding boxes of various kinds make sense as a request for this API
2. Computing viewpoints (default axis aligned viewpoints is a good start, but being able to compute direction from position or position from the rotation would be more interesting).
I am not so sure that is necessary, my thoughts are the app should be able to calculate this from the info retrieved from the rest API. This said, I can imagine cases where it is not possible to calculate such position, but instead store camera information and metadata with the model could make sense. For example, a building would have a camera that show the front of the building, which would not be possible to calculate without knowing where is the front…
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 explicitly defined -> specialized services could then be discovered on-the-fly and made accessible over a wide network.
Yes, extensibility is build in the spec, and a by product of url / namespace. I tried to write this down in the ‘spec’. Versioning the API is also built-in.
4. Transformation between formats. Being able to export to at least one format easily usable with WebGL is a must have. Being able to translate between several formats would be great.
I am not thinking about this API in term of file format per say. I can imagine to be able to request the data in whatever format it is stored into. Some servers like ourbrick covert everything to collada and that is what is provided if you ask for downloading the data. Some servers store the original file, and may provide a different format as well. Some store the file in many formats. So, yes, the API should provide access to those, but… I do not see the need to conversion as I see the API to be able to provide information about the model, returning values in XML/JSON/… , and possibly the app to use this to reconstruct what it needs. This will probably require several iterations over the API to provide enough queries, and understand what the return values should be. For instance, what seems to be the right return format for WebGL or other webapp seems to be typed array instead. So I can imagine an API asking to return specific data from a model, expresses how the data should be encoded in a typed array, and use the model ..
5. Merging meshes. Just to reduce the number of draw calls. This implies that there is a way to get the scene graph so that the application can chose which nodes to merge.
Yes, all kind of data processing could be available, and combined as you may not want to spend time downloading/uploading when several processes need to be applied on a model.
6. Reducing mesh complexity. This one is tough, but removing tiny details or degenerate triangles could make things easier on the presentation part.
Sure, that too. I can envision even some web services providing such service for a fee if they provide a good quality implementation. Or maybe crowdsourcing.
Regards
-- Remi