Preliminary Proposal for X3D V4 in HTML5
This post follows X3D Futures: Structure of the Next Version and uses concepts and descriptions presented there. It also assumes the presentation environment is an HTML5 compatible browser.
These ideas are presented as a starting point for discussion and are not intended as a full or complete specification. The goal is to maintain the capability to display X3D content and provide for dynamic interaction at run-time. It uses the Profile mechanism to fit into the existing structure; however, there is deviation from the existing structure in that the defined Profiles may not necessarily be defined by X3D Components. That is still an open issue.
Two new profiles are defined that correspond to the stages of development used in the industry today. The profiles are Model and HTML5. These names were chosen to describe the content and are an accurate statement; however, better names may be found. These profiles will require some minor changes to the existing nodes so that they function in the manner described. The initial concept of a Model profile is for regular (i.e., mesh) objects. It may be necessary to define extensions to this profile to support CAD, Geospatial, Volume, and other vertical markets.
The Model profile is to be used to contain all manner of static or keyframe-animated content. It does not support user or system interaction. It is intended that content developers create an individual model per file using this profile. The model is textured and keyframe-animated. This is compatible with the way current 3D modeling programs work. The textures can be stored in (as PixelTexture) or external to this file. This profile includes all of the mesh creation, primative geometry, TimeSensor, interpolator, container, and appearance nodes that are not dynamic (no shaders, multi-texture). Files using this profile have a well-defined set of interactions with content external to the file. This can be thought of as a model-level API. It is used to control the animation of the model. The model developer defines what actions are controllable and the names to trigger those actions.
There are a number of issues that need to be resolved. Mostly these have to do with providing the right interface or API to make things work. It may be necessary to reduce the set of ROUTEable events or provide standard libraries for basic functions. The following partial list gets more specific as to the open issues.
- What (X3D) events can be generated and handled
- Are new events needed
- How to handle non-unique tag ID's when importing from various files
- Does a standard interaction library need to be defined or just developed
- What is the appropriate SAI for these profiles
- Should a Text node be part of the Model profile, not included at all, or done in HTML
- Should there be an HTML node that allows HTML content to be loaded and manipulated within the X3D scene
- Are there any scenes that could be done in X3D V3.3 that could not be done here
If you have any additional open issues, comments, or other concerns, please post a comment in the forum.