A diversity of contributors is the lifeblood of any open-source project. Michael Pollind, an embedded software developer, has worked on improving the core stability of the Open 3D Engine (O3DE) project, critical to the long-term viability of the project’s success. In this interview, Michael shares his path into open source and O3DE, his experiences as a novice contributor, and ways in which the engine has evolved since its inception.

Tell us a little bit about yourself.

As an embedded developer, I’ve been working on the sort of health monitoring equipment you’d find next to the bedside in a hospital setting. In terms of game-related stuff, I was in a game development club as a high schooler at UCI in VGDC, where I mainly worked on XNA Unity. XNA Unity was in a very early state at the time and a lot of game development centered around building things from scratch. XNA was an improvement since it dramatically simplified the process of making games.

How did you get into open source?

Toward the end of my time at university, I started contributing to a Java-based, Minecraft-like game called Terasology. I also participated in Google Summer of Code and Google Code-in. The most fun part of all that was mentoring. While I was never admitted as a student for Google Summer of Code, I stuck around and continued contributing for a couple years and got into the mentoring side of it in the end.

How did you get involved with Open 3D Engine?

I originally heard about it through Twitter, actually. I started sending in a couple of patches and then got more and more involved with it. When I started, it was really early and, admittedly, kind of buggy. I kept submitting patches. I focused primarily on Linux-related bugs as I’m mainly on Linux.

What are some of the things you’ve worked on in O3DE so far?

I find it’s nice to just clean up stuff. Sometimes I’ll make a patch to tweak the API, so I can consolidate or remove stuff, cleaning up the codebase to make it more usable and cleaner.

I’ve certainly encountered some odd bugs! One I remember is where you’d drag a window away, and then you could do the pop-out, and suddenly you couldn’t drag the window anymore due to some behavior with how it worked in Linux, so you’d end up with these little functionality hiccups.

Bugs can be kind of annoying to deal with and create a poor user experience, so there was a real need for bug fixing earlier to ensure a smoother experience and to build confidence between users and the framework. In the case of internal tools, people are likelier to overlook problems, but people have higher expectations of quality for public-facing tools, so bug fixing has been critical to the longer-term success of the project.

What were some of the stability fixes you addressed?

One of the most recent patches I submitted was to fix an issue with it not compiling properly because Ubuntu comes with a newer version of Open SSL, so I helped fix that.

You’ve worked a lot on the White Box Gem. Can you talk more about that?

Sure. For context, the White Box Gem is essentially a very simple means of creating placeholder-level geometry before building the final scene in an application like Blender or Maya. It’s great for letting developers sketch out a level in basic terms to iterate on quickly before making everything look pretty. The term comes from architecture where you’d ‘white box’ out a building or scene to get the overall dimensions and rough shapes planned out before going into more detail.

When I saw it, I became interested in helping with it by fleshing out functionality. At the time, in the default mode, you could only extrude and then move in that plane where you pulled the face from. I helped by adding a new “sub” Component Edit Mode inside the White Box Tool called Transform Mode that allows precise control of some primitives like edges, faces, and vertices. It’s still in preview (behind a feature flag) and there are still a few things I need to fix and polish, but it’s in a state where SIG-UI/UX can play around and give feedback and help us iterate on it and improve it. We want to avoid the mentality of perfect being the enemy of good!

I’m continuing to add more functionality, and provide options and freedom and, of course, squashing bugs as they come up.

What sort of bugs have you seen there?

Early on, there were little annoying bugs that cropped up when you tried to use it. For example, the selected face sometimes would end up disappearing, so you couldn’t see it. It turned out it was Z fighting. When editing a white box mesh with a collider, it would keep making instances of new colliders. Another bug involved the button to toggle the color and visibility, where, if you changed the color of the white box, you couldn’t toggle the visibility. Weird sort of things like that.

Are there any other things you’ve worked on in O3DE?

I had a couple of contributions to the math part of the library. I’m interested in consolidating the three different places, those being CryMath, MCore (EMotionFX), and AzMath. They each have their own vectors and matrices, so it’s a good direction to try to consolidate them.

How has the project evolved since its inception?

Today, the project is much more stable. I don’t notice the same kinds of bugs as much anymore. Now you can just open the editor and play around with stuff, and you don’t run into the same sorts of issues as much. It used to be where you would be one click away from an issue. Now, you just don’t run into these same kinds of bugs anymore.

What has your experience been like interacting with the community?

I’ll submit a pull request (PR) and get a response pretty quickly, which has been great to learn some programming practices for C++. There’s a lot of nitpicking with little things in the code—an extra carriage return, or recommendations to use something from the standard library instead of something else—but it’s nice to learn more about features of C++, which I wouldn’t have otherwise learned.

What would you like to see added to the Open 3D Engine to help new users?

I’d certainly enjoy seeing announcements of how the engine is used in places. I saw Blender do smaller self-contained movies to improve the functionality of Blender. For example, Tears of Steel was used to build out the video editing tools for Blender. I could see O3DE doing something similar.

Michael Pollind

Software Engineer

GitHub: https://github.com/pollend
Twitter: https://twitter.com/MPollind
LinkedIn: https://www.linkedin.com/in/michaelpollind/