Building a Vortex Engine scene using Vortex Editor

This week I’ve been working in different several UX enhancements for the Editor to improve the scene building experience in general.

Building a scene for the Vortex Engine using the Vortex Editor.

Building a scene for the Vortex Engine using the Vortex Editor.

One thing to notice in the above image is the new horizontal grid on the floor. Each cell in the floor is exactly 1×1 world unit in size and it will help tremendously to keep a sense of scale and distance between objects when building the scene.

What I like about this image is how it shows the different components of the Editor coming together to make the Vortex Engine easier to use than ever. The more complete the Editor is, the quicker we can move on to start implementing the new rendering backend for Vortex, codename “V3”.

Stay tuned for more weekly updates!

Off-the-Shelf Native Components

At the end of last week’s article, we signed off mentioning the possibility of providing two component APIs for the Entity Component System of the Vortex Editor. Although I’m still very much in line with this idea, the more I lean towards a scripting language, the more I am concerned about performance.

I am worried that scripted components might not be able to meet the quota of updating in less that 16.6 ms once we have a few of them in any given scene. 16.6 ms is the time slice we have to update all components and render the scene on the screen in order to achieve 60 FPS.

A native component, on the other hand, could benefit from all the advantages of going through an optimizer compiler and requiring no parameter marshaling when interfacing with Vortex’s C++ API.

In the light of this, what I’ve been considering is providing a rich set of native components that are part of the Vortex API and that a script can attach to Entities. This would provide the advantage of being able to dynamically add and remove behavior to Entities, while still hitting native performance during the update-render loop.

Of course, I’m still very interested in providing a means to create components through scripts, but perhaps these can be used mostly for exploring ideas, and if performance becomes a problem, then the best practice would be to move to a native implementation of the component.

This week, as a dry-run of the Component API, I’ve implemented a simple Rotation Component that will make any Entity spin on its local axes. A custom UI widget in the Vortex Editor allows configuring the speed and rotation axis of the component in realtime, while visualizing the animation in the 3D view.

I’m pretty happy with the results, and I believe this is the way to move forward with the Entity Component System of the Engine.

Next week I will continue working on the Editor and Engine, trying to maximize what you can do out of the box. Stay tuned for more!

Entity Components in the Vortex-Engine

Last week, we got to a point were we can drag and drop an MD2 file into the 3D view and it automatically instantiate an Entity representing the 3D model. Now, because MD2 models support keyframe animation, suppose we wanted to somehow provide a way for this model to be correctly animated…

An example component driving an keyframe animation for a 3D model.

An example component driving an keyframe animation for a 3D model.

The Problem

One way to go about adding animations would be to implement the MD2 keyframe logic inside the Entity class, so that I need only send an update message to the Entity and it will update the vertex data it holds.

Because I can also instantiate Entities from static OBJ files, it doesn’t make much sense for this logic to be part of the Entity. So what could we do then?

Well, again, we could create a sub-class of Entity with the logic that we need for the animation. The problem with this approach is that sooner rather than later, we will have a huge hierarchy of classes where we will need to constantly refactor and add intermediate super-classes in order to have Entities that share some behaviors (but not others) in a way that enables code reuse.

The Entity-Component-System Model

Wouldn’t it be nice if, instead of extending and inheriting code, I could somehow cherry-pick the properties and functionality that I want for my Entities from a set of prebuilt components? Not only could we build a set of off-the-shelf tested and reusable components that we could mix and match, but also, we would be favoring composition over inheritance, effectively eliminating the need for sub-classing altogether!

This is the main idea behind the Entity-Component-System architecture of modern Game Engines, and it has been the main focus of the work in the Engine this week.

The brand new Component architecture allows adding properties (and even behavior!) dynamically to Entities in a flexible way that prevents coupling and encourages code reuse. The idea behind is simple enough: components that are added to entities will get regular update() calls (once per frame) that can then be used to affect the Entity they are attached to or the world around them.

In the image above, the “Knight” Entity has a Md2 Animation Component. This component has its update() function set so that it takes care of updating the Entity’s vertex data according to the animation it’s playing. It can also expose, by means of the Inspector, an UI that the user can access to set the currently playing animation and its properties.

Native vs Scriptable Components

At this time, as the new Component concept is introduced, the only component that the Engine provides out of the box is the Md2 Animation Component. The idea from this point on, however, is for all extra functionality that affects Entities to be implemented as components.

I envision that we will end up supporting two types of components in the future: native components (developed in C, C++ and Objective-C against the Vortex API) and scripted components.

If you have been paying attention to the Editor screenshots I’ve been uploading, you will have noticed that since day one we have had a “scripting” tab sitting alongside the 3D View tab. This is because the idea of exposing the Engine through a scripting interface is something that I’ve been interested in for a very long time. With the Component API taking shape, I think that allowing components to be developed through a scripting language is going to be a feasible option that will open the door for implementing tonnes of new features.

There is still a lot of work ahead for both the Editor and the Engine, but I’m sure that the next version of Vortex, “V3”, is going to be the most significant major update within the 6+ years of the history of the Engine. Stay tuned for more!