In this paper, we discuss possible Declarative 3D Use-Cases and Requirements. The origin of this position paper is a set of users' requirements, wants and needs collected as the initial part of a research project. We focused our investigations on the analysis of existing implementations of galleries/marketplaces of 3D objects. Our project is currently in its initial phase, therefore we cannot go further in the analysis of derived technical requirements and in the description of the design phase. However, some of the technical requirements can be directly available and understandable from the descriptions of the use cases, others can be topics for discussion for the workshop itself.
Copyright © 2012 for the individual papers by the papers' authors. Copying permitted only for private and academic purposes. This volume is published and copyrighted by its editors.
Galleries and marketplaces similar to TurboSquid are different from typical web museum galleries as described in the Declarative 3D Community Group Wiki [2]. A gallery-marketplace of 3D objects is often a collection of 3D objects that have a correspondence in the ‘real’ world: they can represent existing art pieces, monuments, buildings, or something no more existing but existed in the past.
Galleries and marketplaces focused on 3D virtual cultural heritage have different requirements from those of web museum galleries, and have also a greater extension of needs and constraints than generic 3D object galleries: in brief, a set of typical processes and patterns not only to browse and experience 3D objects in the gallery, but also to upload 3D objects to the same gallery, and different approaches for the content fruition.
Galleries and marketplaces can be described in terms of functional blocks as a set of several basic functions: a web application frontend and a back-end, with several modules: an import, validation and preview module; an indexing module, an export and adaption module; a search module; plus other building blocks, like a storage module, external authoring tools and end–user applications for content fruition (see Figure 1).
Browsing 3D objects in a gallery-marketplace can require more criteria selection and more visualization options. Criteria can be, besides those typically related to the cultural relationships that the 3D object has with the original (by artist, by date, by art movement, by geographical origin, by size, by activity, etc), related to the intrinsic characteristics of the 3D object (by file dimension, by complexity of the geometry, by format and representation, by approximation method, etc.), or related to available visualizations and renderings (by surface, by textures, by effects, etc.).
Filtered objects can be visualized inside a web page, allowing multiple 3D object visualizations in different parts of the page at the same time, each with different visualization options selected. Rotations and translations of the same 3D object rendered multiple times in the same page but with different visualization options can be applied at the same time to all the visualizations.
Such galleries and marketplaces require users to upload 3D objects to populate the database. The uploading process typically requires several steps, that can be implemented as a sort of wizard, through which the modeler/artist is assisted in the process, or as a multiple web page procedure. In fact, users need to upload more than one file, or a single package with all the files inside. Some files can ‘contain’ the 3D description of the object, others can be different textures or images for the surface of the object, etc. With TurboSquid, users have to provide also images and thumbnails showing the final results of the 3D object renderings under certain standard conditions. 3D objects can be used in static photorealistic context, such as creation of a brochure, or in a interactive real-time environment such as a gaming or simulation one. Therefore, in our perspective, besides a photorealistic rendering provided by the designer, a rendering of the 3D object in a real-time context should also be performed on-the-fly during the upload process, or in any case executed during the browsing and viewing activities, using the 3D rendering capabilities of declarative 3D.
The 3D content fruition can be improved, implementing some interactions between the UI of the web page and the 3D renderings. Visitors should be able to vary light conditions, textures, viewpoints and check the variations on the 3D object renderings directly on the web page. The same content should be available through different platforms (desktop, mobiles, tablets, etc.) with as close as possible results.
Today most 3D rendering systems in web applications follow a
(proprietary) browser-plugin approach. From our perspective,
those solutions have some drawbacks that a declarative approach
can overcome: (
An X3DOM model can be useful to overcome these drawbacks, delegating the rendering phase to the browser, allowing the support of multiple platforms without the need to develop different ad-hoc plugins and also reaching a better integration with the web application: having a DOM model into the browser architecture that can manipulate 2D and 3D objects, opens a space for new interactive rich media content application scenarios. Furthermore, a declarative approach in the context of a 3D web marketplace raises some issues that need to be evaluated more in depth, such as protection of intellectual property, in order to ensure the sustainability of the business model. In our research project we will study some methodologies and technologies that can be used in the following use cases (e.g. XML binary encryption, 3D watermarking, 3D model mesh degradation and so on).
From the previous set of typical processes and patterns, we can derive a set of possible use cases. We define some typical users: David, Mark and Penny.
David is a 3D artist, and uses the marketplace to show and sell his 3D creations. Mark is a 3D author, and uses the marketplace to browse and select several objects for enriching and populating his 3D worlds. Penny is a museum curator and works on a virtual museum exhibition, collecting and organizing the 3D objects on her website.
David gains the access to the marketplace website using his username and password and starts the process to upload a new 3D object. In the first page he enters basic information about the new object, the copyright, the acceptance of rules and restrictions about the uploading process.
After, he proceeds with the selection of several files on his hard disk that need to be uploaded onto the marketplace servers. Then, David starts the upload process and waits until the server returns him a confirmation page. The server stores the original 3D object and also transforms it into X3D format.
David can see in the confirmation page a preview of the 3D object uploaded, with different renderings. Preview renderings are done following settings and information entered before. This phase can be more or less interactive, allowing David to change settings, files, information about the kind and the nature of the 3D object, so to call and invoke the right rendering functions. Other settings can be adjusted in real time (e.g. using sliders or radio buttons to choose or define parameters for rendering solutions or effects). Once David is satisfied with his choices and settings, he can confirm the upload of the 3D object and wait for next validations from the server. Such validations can be performed in almost real time or be postponed later (due to 3D model and/or validation complexity and time consumption). The results of such further validations can be checked directly by David on the proper web page (e.g. a ‘My uploads’ in the David’s profile section of the website) or sent by email to David, with proper rendering inside the email client itself.
Mark can search for special 3D objects to complete his own storytelling and his 3D virtual scenario. The search can be a multi-faceted one, with live results on a specific section of the web page. As a reminder, specific search settings can be used to render a ‘dummy object’ to represent the set of 3D selected options (e.g. only tri-, only quad-, formats, etc.). This ‘dummy object’ works like a visual reminder for Mark, who can easily understood which filters and criteria are active in his current search, just looking at it (as an additional or alternative way of providing that information, usually given through multiple sets of checkboxes).
Mark selects some of the results of his search and asks the marketplace to compare their previews in a special page. He can change and select some rendering options and see how those variations have effects on the selected 3D objects, on a side-byside comparison. Furthermore, he can select a previously uploaded 3D world to be used as the virtual world where to render and compare the selected 3D objects. In other terms, he is no more comparing them as ‘floating’ objects within a web page, with a standard, fixed background, with few clues about how they will render, behave and perform in a specific scenario. Actually he can be able to check all those aspects, evaluating and comparing them as parts of a bigger 3D world.
After a comparison with other three objects, Mark selects a 3D object to buy and download for his own 3D world. This requires few more passages: at least a confirmation page where to check once more time all the characteristics and features of the object, with all the available details. This passage typically can require bigger and more detailed preview renderings, with more visualization and rendering variables and options available. Mark is also interested in knowing how the object (before buying it) will behave and perform differently on several platforms and browsers.
Some 3D objects can have several parts to be bought as alternate options or as add-ons. Mark can therefore select these options with the mouse and immediately see the effect of such selections in the in-page 3D rendering previews. As an example, a car can have different wheels; Mark can choose to buy a specific set or more than one. In another example, different textures can be priced differently, and Mark can choose if he wishes to spend more for a very important object, or to choose the cheapest option available.
Penny is organizing her own web gallery of art pieces for the current exhibition. Her aim is to organize objects, their sequence on the web page and through web pages, to add description, comments, and other additional reference or features to allow exhibition visitors to have a rich experience. She is able to define if an object should be viewed and rendered alone on the page, or together with other art pieces; if objects should appear as ‘floating’ on the web page or ‘embedded’ into standard or custom ‘virtual 3D exhibition rooms’. Penny can organize and manage galleries, sub-galleries, groups of objects; apply specific settings to them or to single objects; see immediately in-page the effects of her choices.
We described here in brief six different use cases to explain and highlight the importance of Declarative 3D in the case of web galleries and marketplaces. For us the most important aspects are: • • • the ability to enrich the interactivity on the web page between the visitor and the 3D objects and between the 3D object and other elements of the same web page; the opportunity to exploit and embed 3D effects and typical scene compositions in the web page; the opportunity to support different platforms delegating the renderer task to browsers.
A further refinement of these use cases should be preparatory for the definition of associated and derived requirements.
The authors gratefully acknowledge the support to this work by the regional project “Innovating Content”, a collaborative research project partially funded by Regione Piemonte and FinPiemonte through the instrument of the “Polo della creatività digitale e della multimedialità”.