Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

14.
scenes<br />A COLLADA document can contain several scenes, or none. <br />Can contain physic scene<br />Only one ‘visual_scene’ reference the specific scene to be visualized by default. <br />This is because 99% of modelers do not know how to handle multiple scenes. <br />

15.
nodes<br />Nodes define a local coordinate system, hierarchy transform<br />Nodes have no semantic, they do not convey a specific action.<br /> (i.e. no LOD, switch… nodes)<br />Maybe they should have been called ‘places’<br />Transforms in a node are to applied in the same order they appear.<br />

17.
id and names<br />id are used to reference an element, when instancing for example. They have to be UNIQUE in a document<br />name are used to store human readable information. It’s like a <extra> tag. names are not unique, the type has been relaxed in 1.5 (xs:NCName has too many restrictions)<br />COLLADA reference card page 2<br />

20.
instances<br />Instances are basic building block of COLLADA<br />nodes define local coordinate system where geometry is instanced<br />nodes, with their attached geometry can be instanced. They can be stored in the node library rather than enumerated in the scene<br />Instanced elements can be modified at binding point<br />e.g. material bind is done when instancing a geometry<br />

29.
WebGL<br />WebGL is OpenGL ES 2.0 for javascript<br />Rendering with OpenGL ES 2.0 requires the use of shaders. Shadersmust be loaded with a source string (shaderSource), compiled (compileShader), and attached to a program (attachShader) which must be linked (linkProgram) and then used (useProgram).<br />

52.
6 constraints for a RESTful API<br /><ul><li>Client–server Clients are separated from servers by a uniform interface. Clients are not concerned with data storage, Servers are not concerned with the user interface or user state. Servers and clients may also be replaced and developed independently, as long as the interface is not altered.

53.
Stateless Client context is not stored on the server between requests. Each request from any client contains all of the information necessary to service the request, and any session state is held in the client. The server can be stateful; this constraint merely requires that server-side state be addressable by URL as a resource

54.
Cacheable As on the World Wide Web, clients are able to cache responses. Responses must therefore, implicitly or explicitly, define themselves as cacheable, or not, to prevent clients reusing stale or inappropriate data in response to further requests. Well-managed caching partially or completely eliminates some client–server interactions, further improving scalability and performance.

55.
Layered system A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way. Intermediary servers may improve system scalability by enabling load balancing and by providing shared caches. They may also enforce security policies.

56.
Code on demand Servers are able to temporarily extend or customize the functionality of a client by transferring logic to it that it can execute. Examples of this may include client-side scripts such as JavaScript.

57.
Uniform interface The uniform interface between clients and servers simplifies and decouples the architecture, which enables each part to evolve independently. The four guiding principles of this interface are:Identification of resources (e.g. URI), Manipulation of resources, Self-descriptive messages, Hypermedia as the engine of application state</li></ul>http://http://en.wikipedia.org/wiki/Representational_State_Transfer<br />

58.
methods<br />PUT and DELETE are defined to be idempotent - multiple identical requests should have the same effect as a single request<br />POST is not necessarily idempotent, and therefore sending an identical POST request multiple times may further affect state or cause further side effects<br />See also HEAD, OPTIONS and TRACE methods<br />Potential use:<br />http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html<br />

79.
convert – covert a model from one format to another as a web service.</li></li></ul><li>insert your use case here<br />Join the discussion:<br />http://groups.google.com/group/3d-rest<br />http://rest3d.org<br />