Transform Inspection in the Vortex Editor

Posted on May 30, 2016 by Ale

This week I finished implementing the Transform Panel of the properties view. This is a huge step towards providing a WYSIWYG interface to the Vortex Engine!

The now-complete properties panel. Notice how rotation and scale are now correctly displayed.

This work encompassed being able to select any entity and inspect its properties, namely, its position, rotation and scale.

As I described in my previous post, I reworked the way entities store their transforms in order to be able to keep properties separate, only combining them for rendering purposes. Moving entities to the new Transform construct was simpler that I had anticipated, as entities encapsulate and manage the scenegraph nodes that the Vortex renderers expect.

The next step now in the Properties Panel saga is to add editing capabilities to the UI, so that modifying the values presented in the transform will alter the entities in the 3D world.

The only major issue that I see here is that, as I start to add more editing capabilities to the UI, it becomes ever more pressing to start implementing the undo/redo stack. It will be necessary as the Editor becomes more powerful.

This begs the question of the stack commands going through a centralized front controller, as opposed to having each UI component modify entities on its own. Now, a centralized component for actions must be carefully designed, as it can also provide the native backend for an (eventual) engine scripting system – something I’ve also started to research, but that requires a post on its own : )

The plan for this week is then: add “write” capabilities to the properties panel and start implementing the undo/redo stack. Stay tuned for more!

Visual Editing of Transformations through the Vortex Editor UI

Posted on May 23, 2016 by Ale

This week I started implementing the properties panel (sometimes called the “inspector” panel) for the Vortex Editor.

The redesigned Transformation Panel in the Vortex Editor vertical slice.

I originally wanted to go with a table design for the UI. I though it would give me the flexibility of adding as many editable entries as necessary. I even implemented a mockup in the UI that can be seen in previous screenshots of the Editor.

The problem that I found however was that both, the difference in font and text spacing, between the left and right panels of the UI made the layout look uneven. I knew I wanted something more symmetrical for what’s essentially the “home” view of the Editor, so I came up with a new design that can be seen in the image above.

Here, the Transform Panel consists in a custom UI component that is created dynamically and parented to the docked panel on the right. This provides a more uniform layout with two advantages: first, any number of property panels can be created and they will be nicely stacked one after the other in the panel (this will be useful in the future). Second, because the properties panel is detachable, it still allows the user to customize the Editor layout to her liking.

Now, one minor roadblock I’ve encountered from the engine standpoint for fully realizing this idea is the way Vortex currently represents Entity transformations.

All transformations in Vortex are represented as a 4×4 Matrix. The driving force behind this decision was to avoid having to convert between rotation representations at render time, thus saving some time down the line at during any scenegraph traversal passes.

So what does a generic transformation matrix look like in Vortex?

Matrices are a 4×4 list of values representing values in the homogeneous coordinate system:

$\begin{array}{cccc} sr_{00} & r_{01} & r_{02} & t_{x} \\ r_{10} & sr_{11} & r_{12} & t_{y} \\ r_{20} & r_{21} & sr_{33} & t_{z} \\ 0 & 0 & 0 & 1 \end{array}$

In this matrix, (tx, ty, tz) correspond to the translation component of the Entity and we can easily extract this information to populate the Transformation Panel. But what happens with the rotation and scale?

Rotation and Scale are mixed in together in the matrix (represented by the overlapping sr components), so we can’t really extract the original scale and rotation that generated this matrix. This means that we will only be able to show and edit the position of the Entity and not its rotation or scale.

This is a limitation that has to be lifted.

The plan is to provide a higher-level contraption for describing transformations. Indeed a Transform class that will keep separate tabs for position, rotation and scale but will also provide a convenience method for computing on-demand the transform matrix that this transform represents.

A tentative interface for the Transform class could be:

namespace vtx {
class Transform
{
  public:
    void setPosition( float x, float y, float z );
    void setRotationEuler( float rx, float ry, float rz );
    void setScale( float sx, float sy, float sz );

    vtx::Matrix4 matrix() const; // used for the rendering pass

    // Other getter methods omitted
};
}

namespace vtx {

class Transform

{

public:

void setPosition( float x, float y, float z );

void setRotationEuler( float rx, float ry, float rz );

void setScale( float sx, float sy, float sz );

vtx::Matrix4 matrix() const; // used for the rendering pass

// Other getter methods omitted

};

}

I think this will be a good change for the Engine. Working with Entities using a position-rotation-scale mindset instead of having to the deal with the cognitive overhead of thinking in terms of representing these as matrix operations will help users be more productive (and save precious keystrokes).

This coming week I will be working on finalizing this implementation and finally exposing full Entity transformation control through the UI. Stay tuned!

The GLSL Shader Editor

Posted on May 9, 2016 by Ale

This week we take a break from work in the Vortex Editor to revisit an older personal project of mine: the GLSL Shader Editor, a custom editor for OpenGL shaders.

The UI of my custom shader editor.

The idea of the editor was to allow very fast shader iteration times by providing an area where a shader program could be written and then, by simply pressing Cmd+B (Ctrl+B on Windows), the shader source would be complied and hot-loaded into the running application.

This concept of hot-loading allowed seeing the results of the new shading instantly, without having to stop the app and without even having to save the shader source files. This allowed for very fast turn-around times for experimenting with shader ideas.

As the image above shows, the UI was divided in two main areas: an Edit View and a Render View.

The Edit View consisted in a tabbed component with two text areas. These text areas (named “Vertex” and “Fragment”) are where you could write your custom vertex and fragment shaders respectively. The contents of these two would be the shader source that was be compiled and linked into a shader program.

The shader program would be compiled by pressing Cmd+B and, if no errors were found, then it would be hot-loaded and used to shade the model displayed in the Render View.

The status bar (showing “OK” in the image), would display any shader compilation errors as reported by the video driver.

The application had a number of built-in primitives and it also allowed importing in models in the OBJ format. It was developed on Ubuntu Linux and supported MS Windows and OS X on a number of different video cards.

Application Features

Built entirely in C++.
Supports Desktop OpenGL 2.0.
Qt GUI.
Supported platforms: (Ubuntu) Linux, MS Windows, OSX.
Diverse set of visual primitives and OBJ import support.
Very efficient turn-around times by hot-loading the shader dynamically – no need to save files!
GLSL syntax highlighting.
Docked, customizable UI.

Interestingly, this project was developed at around the same time that I got started with the Vortex Engine, therefore, it does not use any of Vortex’s code. This means that all shader compiling and loading, as well as all rendering was developed from scratch for this project.

I’ve added a project page for this application (under Personal Projects in the blog menu). I’ve also redesigned the menu to list all different personal projects that I’ve either worked on or that I’m currently working on, so please feel free to check it out.

Next week, we’ll be going back to the Vortex Editor! Stay tuned for more!

Basic Entity Instancing and Positioning

Posted on May 2, 2016 by Ale

This week, I’ve continued working on the Editor, adding Entity instancing through the UI and (simple) position editing.

An animated gif showing very basic entity creation and positioning in the Vortex Editor.

The image above features a rough preview that helps show how any number of Entities can be created now. The next steps will be to refine this to add Mouse-based selection, as well as a more comprehensive UI that allows for finer control over Entity position, rotation and scale.

Once these and a few more Editor features are in, I will create a higher quality video showcasing the creation of an environment by means of Entity editing.

Stay tuned for more!

Alejandro Segovia Azapian

Rendering and Systems Engineering

Monthly Archives: May 2016

Transform Inspection in the Vortex Editor

Visual Editing of Transformations through the Vortex Editor UI

The GLSL Shader Editor

Basic Entity Instancing and Positioning