action requested
Rémi Arnaud
Dear 3d-rest group member,
I accepted Henrik invitation to present the rest 3d effort at the next WebGL meet-up, this Friday on the Google Campus.
What I really need from all of you is to send in your use case for the rest 3d API ASAP, so I can represent the overall goal of the group, and not just my opinion of what we should be covering.
Please take 10 minutes to write your favorite use case and send it to the group now.
Best Regards
-- Remi
Rchadwic
stores" for their platforms. For example:
A user pulls up a GUI from their game engine's scene editor tool. This
dialog contains fields for search by title, description, and keyword,
as well as a field for maximum number of polygons or size of textures.
The user enters "horse" in description, "any" for number of polygons,
and hits "search". The engine plugin that creates the GUI hits the
"search" endpoint of the REST service. This returns a list of
identifiers that match the search parameters. The tool iterates over
the list, and calls the "thumbnail" endpoint to retrieve the thumbnail
for each result. The tool then requests the metadata for each search
result from the "metadata" REST endpoint, and builds a GUI panel with
a grid of thumbnails and titles. When a user clicks on a thumbnail,
the GUI shows the entire metadata, and an "Import" button. The user
clicks "import", and the plugin accesses the "model" REST endpoint to
retrieve the model. The REST service returns a status of HTTP
Unauthorized, because the Authorization header is blank in the
request. The plugin notes this HTTP status code, and prompts the user
for credentials. After the user enters credentials, the plugin repeats
the request with the Authorization header, and the REST service
returns the model data. The plugin then sends the model data to the
game engine's asset loading system. When the asset loading system
finds a reference to a texture in the model, a callback triggers in
the plugin. The plugin sends the unique identifier for the model, name
of the referenced texture, and the user credentials to a "texture"
REST endpoint, which finds the correct image file in the repository
and returns it to the game engine. The model appears in the viewport,
or the asset library of the user.
SurFuFu GMail
Here’s a use case I would like to propose:
I am thinking about a simple database to get/generate some 3D data easily formated for speed. This may be use for instance like an exporter from a 3D software.
but ...
- This can also be used as asset management tools to put and get data on it :
- This can be linked with many other set of data and some temporal information (xD management, i.e. 4D, 5D, 6D ... ).
- Those data may be more in "editor" format, this mean with a lot of information/data and with more the source data than the optimized data. (for instance can be store as nurbs or as complex data from).
- those data can be generated as optimized via complex request may be spacial (lod) or temporal one. (temporal may mean many things : this be linked to animation form or to many set of data stored by asset date or data stored as data date.
- The request may be simple : get node, get scene, get animation, get mesh ... get texture ...
- The request may be more complex :
- get the full scene view from this camera point of all this world this send a full optimized set of polygon (in case of a big world mesh) linked the world view by the camera with all the material / texture full object node with animation ... etc ...
- get the delta scene view linked to a translation or a rotation in the world to add more polygon / object to the local cache linked to the new view.
- get full object list linked to a portal view
- ../...
- The data may contain some real spatial information (gps/googlemap), or temporal one (date)
- We need to define a way to include and use multi animation on node/squelton with many storage dimentions too
- ... /... to be continue
Tony Parisi
Requirements:
- Store world/game level data for specific users' or groups' scenes and objects
- Allow users/groups to customize attributes of their specific scenes
- Store model and other asset data for item catalogs (objects for purchase etc.)
- Allow users to upload new model and asset data
- Potentially support zone/area of interest type of queries for objects/scene fragments in a region of space or within a given distance
- Potentially support queries by object type, size, other attributes
Remi do you need more specifics than this? Or additional prose?
Tony
Tony Parisi tpa...@gmail.com
CTO at Large 415.902.8002
Skype auradeluxe
Follow me on Twitter! http://twitter.com/auradeluxe
Rémi Arnaud
Hi Tony,
Thanks a lot for this use case.
What would be great is if you can propose a api/group for those features. Some group of features will be overlapping between use cases, some will be specific for a use case, that would help converting use cases into action items for the specification.
This is how I read this use case and how I would group functionality: first 2 are about user data/scene, the next two seem very close in functionality?, the next two are about queries (spatial and other criterias). User data/scene seems specific to this use case, storing will overlap with content management, query is mentioned by almost all the use cases so far.
Regards
-- Rémi
Rémi Arnaud
Would it be possible for you to write an introduction email to this group,
so you can tell a little bit about yourself, such as you name :-)
Regarding this use case, I agree it is aligned with what we'd like to cover
with rest3d.
One suggestion I have is that the rest3d API will make it easier for the
application to manage the dependencies. In other words, there is no need for
the application to download and parse the model, a list of dependencies
(texture images, shaders), should be available via the API directly.
Regarding authentication, this API is compatible with http authentication
and encryption mechanism. So authentication with a specific server will be
done before the rest3d API can be accessed. Some mechanism will require the
rest api calls to be encoded before they can be sent to the server.
Regards
-- Rémi
-----Original Message-----
From: 3d-...@googlegroups.com [mailto:3d-...@googlegroups.com] On Behalf
Tony Parisi
The second two are about storing model data based on properties, object types etc. Catalog stuff. Vs. the first two which are about spatially organized scenes that contain model data.
I won't have time to get into the specific API proposals for a few weeks.
Tony
coderextreme
(LOD). If we could somehow combine the two, that would be really
cool.
Something like Layar would be cool too, bringing back categories of
detail or dependencies (show me all door knobs in this 10 block area,
show me all shaders of spheres).
