By Ian Hollidae, 2024/10/23

In the early 2000's, I ran across my first example of VRML (Virtual Reality Markup Language). It was a panaramic photo someone had stitched together. The image was used as an image texture on a circular wall and the user, sitting in the middle of the circle, could swirl around 360 degrees to view it. The swirling didnt work very well but the idea of VR web comtent was fascinating. I wondered in general about what else could be achieved.

Unfortunately, I never got the time or had the need to dive in further. Eventually, VRML faded away. It didn't seem to really make that much of an impact to begin with. Flash won the plug-in wars and that was about the limit users were willing to put up with in slowing down the browsing experience.

Fast forward to 2020, and just by chance, I stumbled upon VRML's successor, X3D. It was a complete surprise the effort was still around. Out of curiosity, I began browsing through the documentation. Just as before, I began asking who would be interested in using VR on the web in the age of walled-off social media. However, as I kept reading, the one thing that stood out was that a plug-in was no longer a needed. It was all pure XML and Javascript.

My own personal interest was rekindled.

Fortunately, I was able to find the time to truly get into X3D. I spent several weeks making small demos in order to get a handle on things. Eventually, I decided to create my own basic tutorial, VRIGNETTE, so others could make use of X3D. It was also to aid my own learning.

During my exploratory process, I discovered existing X3D examples and while most were good for visual demonstrations, they weren't very useful. After some time, it became clear my main goal for using X3D was for interactive webapps. Some of the possibilities of interest include:

1. 3D photo presentation (Example)
2. 3D photo galleries
3. VR product showcase picture (Example)
4. Simple games
5. Virtual space demonstrations

I'm sure there are plenty more uses than the ones I listed. It seems the only limit is your own imagination. Of course, items such as performance comes into play. The larger your application is, the more you need to download, constraints have to be applied. You get the picture.

So now that I've been using X3D for a year, I thought it would be a good post to share a brief assessment. This is in no way a comprehensive review. Just some thoughts about what has stood out the most.

X3D As A Markup Language

The XML-based script integrates well with HTML along the lines of SVG. In fact, there are some rough parallels between the two.

The grouping of objects, transforms and object reuse are a large part of both markups. The X3D 2D component, the ability to draw 2D objects in a 3D world, is basically an SVG equivalent.

The ability to create custom shapes in X3D using prototyping goes well beyond the SVG <PATH> tag. But even if you don't want to go that far, there are several path-like constructs that get the job done on the customization front.

For simple embedded displays, no javascript or complex animation, getting up and running is no more difficult than standard web development.

X3D Libraries

What you get out of X3D is largely dependent on the library you use. The two libraries I know of are X3DOM and X_ITE. Both have somewhat different approaches to providing X3D functionality.

X_ITE is a full blown player and framework. It's programmable and configurable. It also seems to be a more complete implementation of the two.

X3DOM, on the other hand, is closer to a straightforward library for web use. Fewer moving parts and not much different from other standard javascript libraries in usage.

Each library has plenty of benefits and I use them both.

X3D Tools

A generic text editor will do the job for basic and moderate tasks. For now, this is what I do. But for more advanced content, dedicated software is needed. It seems there are two choices: Sunrize and Blender.

I currently don't know much about Sunrize (I wanted to focus my learning on direct coding efforts) but Blender has long been considered a beast. And Blender isn't specifically an X3D tool. It just exports content to the X3D format.

Will tools be a problem for X3D down the line? Given the size of X3D, compared to HTML and SVG, it's possible. And the more complex the construct, the more cumbersome X3D can become without dedicated tools. Where those tools will come from is anyones guess.

The Past Is The Present?

As I said before, my main use for X3D is embedded web apps. In a lot of ways, this sorts of mirrors the old days of Flash and Java applets. However, there doesn't seem to be the huge performance issues Flash and applets suffered from. At least for small things.

One other difference from the past is that X3D implementations are all javascript based and X3D is an open standard. Anyone can provide an implementation and that means there is fair chance that X3D development won't get bogged down by corporate concerns.

Conclusions To This Point

I think X3D has a lot of potential to offer content creators and developers. Will X3D get broader adoption? Like any other technology, it's hard to say. I think it really is a matter of finding appropriate uses.

Obviously, one person may or may not make a difference but for my part, trying to output regular content is one way to help spur adoption. Besides my basic tutorial, I created a portfolio page to show what can be done. Who knows how things will unfold. Maybe a year from now, I'll write a two year assessment of X3D where everything has changed.