Nov 6, 2019 - OpenSimulator in Docker Containers

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

Oct 6, 2019 - Where have I been

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

Oct 7, 2018 - PWMHAT and ROS2

To learn robotics and eventually program robot brains I’ve started building some ROS2 modules. I have several Raspberry Pi 3B’s so I bought some stepping motors and an Adafruit 16-channel PWM HAT and set about building some ROS2 packages.

Well, I soon discovered that, while ROS2 is a modernization of the original ROS (which grew organically over the last decade plus), it is not all done. There are many, many features, modules, and conventions that are not complete. So, I scaled my project back a little and started building some basic modules so I could learn the state of things.

First thing I published is a fork of Christian’s raspicam2_node which compiles and runs under the latest ROS2 build (bouncy). This lead me to needing a version of ROS2 on Raspbian. ROS2 is targeted at the latest versions of operating systems and tools. So ROS2 wants that latest version of Linux and also wants 64-bit hardware. But everything hasn’t caught up – the latest version of Raspbian is 32-bit and the previous LTS version of Ubuntu.

To build ROS2 on Raspbian, I created a script in ROS2OnPiTools that fetches and builds ROS2 on Raspbian. It takes several hours but it results in a directory that can be copied onto multiple Raspberry Pi’s.

Future blog posts will describe the details of this project but the first step is a ROS2 node to drive the Adafruit 16-channel PWM HAT. So the project ros2_adafruit_pwmhat_node is a simple, Python only node that subscribes to several topics and sets the PWM values on the HAT.

Now that I have stepping motors moving, I will work on capturing images and animating my little camera project. Future blog posts will describe this as it comes together.

Comments

Jul 17, 2018 - Convoared Regions

I’ve updated Convoar to version 1.1 and started converting a collection of OARs. These sample OARs are available on a Converted OARs page at https://misterblue.com/oars/ . This gives pointers to various optimized GLTF scene conversions, downloads of all the scene files (ZIP and TGZ), as well as a download of the original OAR file.

There is also a VIEW button which opens another browser page with a simple ThreeJS viewer on that version of the GLTF file. Be sure to close that view page as having several views open at the same time till greatly overtax any graphics card.

I’ve had a lot of luck running Convoar in a Docker image. This has solved most of the problems with getting the correct .Net/Mono environment on Linux machines. Even conversions that crash under Windows 10 (usually out-of-memory) work with the Docker image.

On a Linux system with Docker installed, I do the following:

mkdir /tmp/frog
cd /tmp/frog
cp OARFILE.oar .
docker image pull herbal3d/convoar
docker run --user $(id -u):$(id -g) --volume $(pwd):/oar herbal3d/convoar OARFILE.oar

The --volume parameter maps the container /oar directory to the current directory (which contains the OAR file named OARFILE.oar or whatever you wish). The --user parameter sets user and group IDs of the Docker container to the current user’s so the container can write into the mapped directory. Then the container is run which reads the OAR file and writes all the output files to the mapped directory. If there are any parameters for Convoar, they go before the OAR file filename. When it’s done, you have the original OAR file and all the GLTF files in the mapped directory.

Cool.

Comments

Jul 1, 2018 - Convoar and Converting OARs

I’ve been working on an OAR file converter. For those of you not in the OpenSimulator community, an OAR file is a region archive format – saving the contents of a region for loading into another region. So it contains all the meshes, textures, scripts, and assets that completely define a region’s contents.

Convoar reads an OAR file and outputs a GLTF scene and image files containing most of the region information. Most specifically, textured mesh representation of all the objects described in the OAR file.

Convoar is evolving. The current version reads an OAR file and outputs either an unoptimized GLTF scene file or a “material reorganized” GLTF scene. The output GLTF is not packed or binary so the output GLTF is a JSON .gltf file, one or more .buf files (containing the vertex information), and an images directory with the texture files for the mesh materials. By default, the output textures are either JPG or PNG format depending if there is any transparency in the texture.

The unoptimized GLTF conversion is a simple conversion of the OAR primitives which creates many, many meshes and is very inefficient for rendering but is good for editing (importing into Blender, for instance).

The “material reorganized” scene has object corresponding to each unique material (texture/color/features) and the meshes have been assigned to each of these material objects. This renders the scene uneditable but this should greatly reduce the number of draw calls needed to render the scene in OpenGL/WebGL.

Future versions of convoar with either contain or have tools to perform other optimizations to the scene and the object therein.

Roadmap-wise, Convoar is a first step in developing code that makes OpenSimulator content displayable in a web browser.

Comments