Over the last several months I have been working on the Project Apollo metaverse-server for the Vircadia project. The Internet is awash in virtual world projects – both small and large. Because of this, I have been thinking lot about this project and why I would spend any time on Yet Another Virtual World. This captures some of where I think Vircadia could go to be a growing and interesting addition to the sea of virtual world technologies.

First, what is Vircadia? Vircadia is a volunteer, open-source, virtual world server and viewer project based on the High Fidelity code base. A small collection of interested people have pulled this code dump into a project and a community that chats, plays trivia games, and watches movies together while working to improve the code and content of the virtual world. The goal is to make a free, open-source, distributed, and non-corporate owned virtual world that could be useful for education, training, meeting, and socialization. The community and their passion for this particular virtual world technology keeps the project alive.

I have spent years working on the OpenSimulator virtual world technology. and more recently on my Herbal3d and Basil viewer projects. These are all for virtual worlds and the communities they create. I have watched OpenSimulator putter along with hobbyists running their own virtual world grids and small communities enjoying the ability to socialize and hyper-grid/teleport among the many worlds. But, in general, OpenSimulator never grew beyond its SecondLife dispora and the project has dwindled over time. It’s still alive and interesting, but it is not making a new and interesting addition to the virtual world ecosystem.

I got involved with Vircadia because of the great people and they needed some server-side software and that is one of my interest areas.

But, now that I’ve invested in this project, I don’t want it to slowly die as people move on and/or just get lost in the virtual world sea of projects.

There is the “marketing” direction which consists of building communities and finding creators and applyers (like teachers or trainers) to increase the number of people using the project. But I’m more of a tech person so I see some technologies to focus on in Vircadia development that would attach it to other technology focused communities and grow and enhance its application. The goal of these directions is to attach Vircadia to other like-minded technical, volunteer, and passionate communities.

So, the two directions I’d like to help Vircadia go in are:

• develop the technology for a decentralized virtual world community, and
• generalize the virtual world viewer for new and different rendering engines.

Decentralized Virtual World Community

Let’s talk decentralization.

One of the main motivators of the Vircadia project and many other hobbyist and open-source development projects is the idea of creating a non-centralized service/application/resource. And by “centralization” most think of the large, ad-based concentrators like Google or Facebook.

So, by “decentralization”, most projects want there to be no single owner of all the data, no single one place everything is stored, and no one place that is necessary for the project to exist.

I feel like there are two approaches to this “decentralization”: 1) decentralized storage and linking and 2) decentralized infrastructure.

“Decentralized infrastructure” is where multiple people host a common infrastructure and the service/application is spread across these hosts. So, like Tor or BitCoin, the service is not in a single location but it spread out across multiple hosts so, one host going down or being compromised, does not stop the service/application and no one entity holds or owns the service/application.

“Decentralized storage and linking” is where multiple people host their own stuff (no single owner or storer) and there are conventions for naming, addressing, and fetching content and services. In this case, data is spread out across the Internet and availability and access is arranged and controlled by the source of the data or service.

“Decentralized storage and linking” is more about linking together smaller island while “decentralized infrastructure” is more about creating one large island. Both of these have their excellent uses but, for creating a set of virtual world communities, I’m leaning more toward the original inter-net, web focus of tying communities together.

Hope you’re still with me here.

“Decentralized storage and linking” is the original design of the World Wide Web where everyone hosted their own site and there were hyper-links to get from one hosted resource to another. W3C is the World Wide Web standards body that carries on this architectural direction and has recently published several “social community” standards which enable applications for decentralized social communities.

These are the standards ActivityStreams and ActivityPub which support social sharing services like Mastodon, PeerTube, and many others.

The model presented by ActivityPub is of actors that have “streams” of “activities”. Thus, a person can have a newsfeed, a community could have a stream of newsletters, an event could have a stream of events, and a myriad other combinations. The standard allows for publishing and subscribing to streams.

This creates a collection of hosts that are created for an interest area, a community, or just for fun and the hosts exist for as long as the hoster wishes. There is no central control or ownership. Just interested and passionate individuals.

This architecture is useful for Vircadia for two reasons:

1. It matches how I see developer based virtual worlds growing – as small hosted “grids”, and
2. Linking the “girds” together with an existing socialization standard pulls the community into a larger socialization world of like-minded developers and users.

So, how do I see this playing out?

I see the continued development of a metaverse-server to act as the center of a “grid” of virtual world spaces (“domain-servers”). This metaverse-server would provide the services to tie this collection of virtual world spaces together – account creation, storage, and permissions, domain-server registry and discoverability, and any cross-domain communication). This provides the basis for anyone to create their own, independent virtual world.

Then, adding to this, extending the metaverse-server with an ActivityPub interface. For multiple grids, this allows the grids to share some account identity/profile information, have interest groups that span grids, have conversations that span grids, and other sharing.

For wider usage, one could use existing ActivityPub based tools to share and communicate with users in the virtual worlds. For instance, use Mastodon to chat with or check the presence of people in the virtual world. Or use one of the many gateway applications (like ActivityPub to Discord) to connect between social groups and virtual world groups.

One way of looking at it, this makes [Vircaida] the virtual world extension of ActivityPub or maybe the virtual world version of Mastodon.

Check out The-Federation and Fediverse.Party for some of the other federation-based, decentralized communities.

Generalize the Viewer

This was all about the socialization side of Vircadia, but what about the viewer. There are many people very passionate about the technologies and devices for viewing virtual worlds.

The existing viewer is a custom C++ engine. It combines world logic (avatars, location, scripts), with simulator interface (TCP and UDP communication), with the rendering engine (and the interfaces to all the different VR devices).

A presentation by Sam Gateau (the High Fidelity core engine team lead) suggests the rendering part of the viewer is separated from all the world logic by a scene representation that is acted on by “transactions” that come from the world logic. This gives a good beginning to separate the virtual world logic from the renderer.

So, what I’m suggesting is that the interface between the “scene” and the world logic (the “transactions”) be formalized and refactored to make code pieces separable. Then, the project could go in different directions. The rendering engine could be replaced (some people have suggested that the Unreal Engine is a candidate).

Or, building on my Herbal3d architecture ideas, build a system where multiple world logic interfaces can talk to the same renderer and thus allowing viewing multiple virtual world systems with the same viewer rather than requiring a different viewer for each virtual world.

Conclusion

I believe that by adding an interface to existing and growing distributed social network systems and by separating the renderer pieces, the Vircadia project can attract many new developers, users, and advancers and live on as a vibrant community.

Well, that’s way too much typing. Back to coding.

Comments

I’m on a get-work-done kick. This means more updates here. I considered moving to Medium to get a wider audience but that is not my goal. My purpose of these pages is for me and I’m not working on my career and my visability.

So, just more updates.

This push toward organization and making visible progress is coming from my recent interest in all the project that Elon Musk has started. Between SpaceX, Boring Company, NeuraLink, and others, this man is changing things.

I could go on-and-on about what I think about these companies but, what applies to this post is that this one person is making world changing things happen. Reading about what he has made happen makes me think: “I have some big ideas that could change things. Why aren’t I doing big things?”.

So, more organization and more visible work.

Comments

I just can’t leave the Basil OpenSimulator viewer alone. I need to tweek and change and make improvements.

Well, I’ve updated BasilJS which is the browser/JavaScript based version of the viewer. The protocol was simplified into a more streaming form to better fit with the bi-directional WebSocket connection. Also, the protocol change from an Entity/Instance explicit form to a more Entity/Attibute construction. This required refactoring and debugging BasilJS all over again.

You can see the load-a-single-GLTF-file test mode of BasilJS on Misterblue OAR Collection where pressing “View” invokes BasilJS to load the converted OAR scene.

Then BasilTest was refactored to use the new protocol and to reorganized how SpaceServers are implemented so the OpenSimulator region modules can be simplified by using the common code. This made for major changes to the common C# code libaries (HerbalCommonEntitiesCS, HerbalTransportCS, and OSAuthModule).

The last refactor part is to redo the OpenSimulator region modules (Loden and RaguOS). Then I need to find a way of building an online demo so people can try it out.

That last idea (of “trying it out”) lead me to think of building a straight OpenSimulator viewer. This has been made especially critical as SecondLife development has veared away from compatible protocol and viewer changes. So, I’ve taken my old LookingGlass viewer and did a rehack to allow plugging in either the Godot or Stride (previously Xenko) rendering engines. Thus BasilG or BasilS will eventually exist building on all the logic I had in LookingGlass for using [libOpenMetaverse] to talk LLLP (Linden Lab Legacy Protocol). We’ll see how much progress I make.

The other task is getting all the web pages together.

Comments

Working on cloud services lead me to create Dockerfiles for deploying OpenSimulator as Docker containers. The [Github] repository https://github.com/Misterblue/opensim-docker contains instructions and files for building and deploying OpenSimulator using docker-compose.

The hardest part was the tweaking of OpenSimulator configuration because there are so many files that need changing and I wanted to have both packaged configurations and the ability to completely replace the simulator’s configuration without changing the Docker image.

So, as is explained in the repository, the setup is to pretty much null out all the default configuration files (those in config-include) and replace them with copies in bin/config. This allows pre-packaged configurations to be included in the images (set with environment variable CONFIG_NAME) or to completely replace the configuration by mounting over the bin/config directory.

Happy Virtual World’ing.

Comments

Haven’t said much the past year. I have been moving to other projects that don’t have as much blogging interaction.

A year ago, I did a bunch of playing with robotics and ROS2. This culminated in a small, multi-node setup with a camera that tracks faces. What I learned was captured in a presentation that I gave at our local ROS Meetup.

After that, I played with the Basil virtual world viewer by creating several OpenSimulator modules that convert and present a region to Basil. This included Loden which converts OpenSimulator primitive objects into meshes and eventually a GLTF format file.

This virtual world conversion idea came from the Sirikata project that was done at Stanford over a decade ago. Any continued work would build on the many papers available on things like automatic LOD generation of scenes. Things to do.

Then RaguOS adds to OpenSimulator a WebSocket interface talking the Basil protocol and making available all the assets created by Loden. From this, Basil can display the region contents. Extended RaguOS’s operation with some authorization stuff (OpenSimulator module OSAuth) but haven’t gotten all the way to adding the JWT tokens that will eventually underly all the authentication/authorization.

This led me to wanting to put up a sample region that people could try out. Deployment got me working on Docker and the creation of images for consistant operation of OpenSimulator. The output of this has been a repackaging of OpenSimulator into a set of scripts to build and deploy OpenSimulator as Docker containers.

With all that done, I’ve become overwhelmed with the amount of work that still needs to be done. Also, the on-line virtual world environment has changed. Augmented reality is the Cool Thing at the moment. The latest incarnation of virtual world companies have grown, stumbled, and needed to regroup. The Big Guys (Facebook, Amazon, Microsoft, …) have started to deploy their hardware and infrastructures. So, my little hobby project seems a dead end. Like it will never have all the capabilities that the virtual world community needs and my dreams of bigger impact seem out of reach.

This means I will probably moth-ball the whole Herbal3d project, bring documentation up to date, complete the architecture ideas, and then move on.

What will ‘moving on’ look like? I’m thinking robotics. I expect to get back to ROS2, Docker deployment of node logic, and playing with things using transformer neural networks to build model predictive controllers. Will be fun.

Comments