Events in X3D are the means for generating and handling behaviors. All changes in the state (including geometry, appearance, animation; but not animated images) are because at least one event was generated and processed. Events can be generated by timers, user interactions, response to other events, or from external sources. Events are routed fro a particular field of a node to another field of a different node. This cycle repeats throughout the time the scene is running. 

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.

I have been doing a lot of thinking and talking with people working in computer-based 3D graphics to determine what the next generation of X3D should look like. There are important considerations and practices that need to be addressed. This post is an attempt to summarize the current state of X3D and the industry (primarily non-X3D) process of creating 3D scene. The next part will outline some of the options for the next generation.

In starting any new effort, it is important to identify the goals of the project. Goals are important because they provide a focus for the most desired outcome. They are not necessarily the destination of a project, as there are a number of factors that may limit (or expand) the initial goals.

I am working on developing the standard for the next generation of declarative 3D graphics. The current version is called X3D. At this time that name I am using for this is X3D V4. Final naming is not up to me.

For 20 years, the Web3D Consortium has developed and maintained a open, royalty free, ISO ratified and well documented standardized markup language for transmitting and displaying 3D content on the web called X3D.