I haven’t been updating this blog lately so I thought I’d add something today.

I’ve been working on adding webrtc voice to OpenSimulator using the Janus webrtc server.

To use the Janus server, I’ve created a Docker container for running the server configured up for OpenSimulator. Check out os-webrtc-janus-docker for details. That allows the running of the voice service separate from a region or a grid server and, hopefully, eventually allows scaling. I’m using the audio bridge plugin in Janus to create “rooms” for group and region sessions. That allows the mixing of audio for an area. Initially, there won’t be spacial voice mixing but I expect future work to add that to a fork of the audio bridge plugin for Janus.

I’ve submitted a presentation for this project to OSCC24 that happens in early December so I have a deadline. Insert “freak out” emoji.

Comments

It’s been a long year and I’ve done a bunch of misc project support but haven’t done any of the larger projects I listed last year. No major deliverables.

So, what’s up now? I’m still interested in the OpenSimulator virtual worlds but have been spending time supporting various spin-offs:

NGC

CrystalFrost

So, what do I want to accomplish in the next few months? Some possibilities are:

• AIS Inventory: add newer SL inventory interfaces to OpenSimulator. This means coding the inventory capability. It would contain the base code with the HTTP interface separate so that the code could be used for both OpenSimulator core (as a region module) and in NGC as a service.

• ASync Interface for libreMetaverse: Several viewer projects are using libreMetaverse as their connection to the simulator. The internal API needs an update from the callback form to the newer Task model. Along the way, I’d like to document the internal API and thus make it easier for new people to use.

• OpenSimulator interface for GLTF content: I had the odd idea of creating a “capability” (modular API unit of the client/simulator interface) that returned GLTF versions of assets. That is, rather than inventing a new way of fetching GLTF items like I did for the Basil viewer , a viewer could see that the feature is available (in the list of available capabilities received at login) and thus fetch the GLTF versions. This is would incorporate convoar code in a way usable by different systems. I think this also might include adding WebTransport communication connection to OpenSimulator for browser based viewers.

The last project is a slightly different approach to what I did for Basil. I had created a new protocol and built region modules (Ragu, Loden, …) to implement the protocol. I still like the idea of creating a Wayland-like protocol for separating the viewer from world logic but that’s for another time.

Comments

I’m at a decision point – there are so many possible software projects and I can’t decide which one to choose. Here is a possible list:

• Basil viewer: this is advancing the features of the viewer. It includes implementing avatars, adding scene rendering features (water, …), and updating the UI to be the WASM modules that run in the client to provide world and UI operation.
  • Avatar movement
  • Avatar implementation
  • Shaders for water, lighting, scene
  • Child/adjacent regions
  • WASM UI implementation
  • Reactor into peoperty updates and optional sync back to server
• Loden: work on creating the assets for the browser viewer. These things are also useful in other projects (like Convoar and Unity viewer). There are some refactoring (textures) but mostly is creating the 3d tiles version of the region. Also use the real asset database.
  • Integration with grid asset server (solve the access key (capabilities?))
  • Move texture resizing out of the GLTF generator
  • S3 asset storage
  • Create individual GLTF assets on demand
  • Create region 3dTiles down to the individual assets
  • Create avatar to GLTF
    • Close to VRM format and can be used with https://github.com/vrm-c/UniVRM and Unity
• OpenSimulator 3d voice service: OpenSimulator needs a spacial voice replacement. On candidate is the voice mixer from HiFi/Overte. The work is figuring out how the scalable service is invoked and then adding a Vivox API to the mixer (that already has a WebRTC-data and Overte interface). Probably should have a plain WebRTC interface also. That could make it generally useful for other VWs.
  • Research the Overte voice service
  • Research the Vivox protocol (viewer to server)
  • Research the avatar position protocol (simuilator to audio server)
  • Understand OS capabilities: how generated and passed around
• GLTF Avatar for OpenSimulator: Related to the Loden work, making a GLTF version of the OS avatar would be useful in many places. The avatars could be used in other VWs as well as the CrystalFrost viewer (see (UniVRM)[https://github.com/vrm-c/UniVRM] ).
  • Research VRM format
  • Research OS avatar format
    • Seems to be Bento bones but a lot of work on mesh modes with sliders
    • (Viewer-Character)[https://github.com/vrm-c/UniVRM]
• Convoar: Based on the changes to Loden, add GLTF extensions that contain all of the OpenSimulator asset information (creator, transferable, …).
  • Add GLTF extensions that includes the raw OS prim information
  • Add GLTF extension to hold ownership, etc
  • Add Identity to creator
    • This might include DIDs or some other identity info

There could be more.

Comments

I’ve been working on this project¹ where I’m compiling different C++ libraries and statically linking them together. I had problems with undefined symbols. And the undefined symbols were mangled C++ symbols. If you didn’t know, C++ creates “mangled” symbols for all your human readable symbols to solve the global namespace problems that C++ inherited from C. The article How To Mangle And Demangle A C++ Method Name explains it well.

The problem I had was that one library had the symbol _ZNK16btCollisionShape17getBoundingSphereER9btVector3Rd and another library referenced _ZNK16btCollisionShape17getBoundingSphereER9btVector3Rf . What was different?

Well, the above referenced article references the “well known” tool of c++filt.

Of course!!

user@ubuntu ~> c++filt _ZNK16btCollisionShape17getBoundingSphereER9btVector3Rd
btCollisionShape::getBoundingSphere(btVector3&, double&) const
user@ubuntu ~> c++filt _ZNK16btCollisionShape17getBoundingSphereER9btVector3Rf
btCollisionShape::getBoundingSphere(btVector3&, float&) const
user@ubuntu ~>

Looks like I am building one library with double precision turned on and the other was referencing it with double precision turned off. Now I know what to fix.

There are just so many tools in Linux.

Comments