Why can’t we just have one solid X3D implementation and all use that?
The 19th X3D implementation was recently announced (RTI’s Firefox plugin).
For a complete list see the X3D Wiki. If I’ve missed your implementation please contact me.
I am often asked why X3D and VRML players have not consolidated down to 1 or 2 implementations. The question typically comes about due to the costs of maintaining so many different implementations. Why can’t we just have one solid implementation and all use that? Wouldn’t it be much easier if like Flash we had one system for content authors to deploy too?
I think the answer lies in how much variation there is in optimizing and deploying 3D applications. The tradeoffs for each area makes it very difficult to deploy one codebase to meet all needs. I can see at least 5 common areas that X3D is deployed in that require radically different design decisions. I doubt any one browser could excel on all of this areas.
Consumer Market - Web Browsers and Cell Phones
The consumer market is all about mass installations. The player must be easy to install, small to download and bullet proof. A lot of these devices are also memory constrained. In the case of cell phones you must heavily optimize the engine to reduce memory usage. This can have a direct affect on your runtime rendering speed. Most algorithms can trade space for speed, so you tend to pick space savings for these implementations.
Geometry Push - CAD Visualization
In the CA visualization world you have files which can be massive. A common project to visualize is a processing plant. A processing plant can have millions of pipes that can be all visible at once. In order to render this file you cannot use a retained mode structure. A common technique in 3D engines is to take a high-level description like a pipe(or Extrusion in X3D) and generate its 3D structures in a state most appropriate for the underlying hardware. This takes more memory but makes for less CPU usage. Geometry Push architectures may go the opposite direction, they will only store the pipe dimensions in memory and then generate the graphics commands each frame as needed. With this structure you can render a whole power plant but it would not perform as well as other engines on smaller content.
Texture Push
Most game engines are optimized for a Texture Push. Most consumer graphics cards are optimized for this as well. Basically as few polygons are used to approximate an object. Detail is added by high resolution photographs. State sorting is very important in this engine so it can batch expensive state changes like textures or shader programs together.
Immersive Displays
Immersive devices like Caves, Domes and PowerWalls use multiple channels to envelope the user in the space. They typically require several pipes or computers to render. A browser written for this environment can have radically different architecture such as clustered PC’s working to render one scene. Typically these implementations are multi-threaded. This has some costs but allows you to use multi cpus or cores effectively.
A goal of X3D is to provide one content standard that can be deployed across multiple environments. What is today’s Herculean content is tomorrow’s cellphone widget. The ability to repurpose your content from one environment to another makes the initial development costs more palatable. Having different implementations of X3D optimized for different environments means you get the same content running well in different environments.
I hope to see even more implementations of X3D flourish.