I-Novae Editor First Look

I would like to start this blog by thanking everyone for their patience. Those of you who follow my twitter have been anxiously awaiting this blog post and I am sorry I was unable to finish it before I went on vacation. In the end I decided to try out Blogger as a company wide platform for blogs. So far it seems to be pretty powerful and we can, at some point in the future, use RSS feeds to aggregate all of the different blogs onto a single page on the company and/or Infinity websites.

When looking at the pictures of the I-Novae Editor please keep in mind that it is a work in progress. All of the icons are currently placeholders and the final colors/look and feel has yet to be defined. At the moment we are focusing on core functionality and a polish phase will come once we are closer to public availability.

I-Novae Editor

Firstly I would like to talk about our progress on the I-Novae Editor and our current technical road map. As many of you know we announced a few months back that progress on Infinity had been delayed in favor of devoting more time to the I-Novae Engine. The primary reason for this is that we realized we needed a more robust toolset not only to make the I-Novae Engine more commercially viable for 3rd parties but also to finish Infinity itself. This diversion is primarily driven by necessity to optimize artist workflow. Artists and designers need to have powerful, flexible tools that allow them to do their job without programmer intervention (as much as possible).

To facilitate ease of use and a lower barrier to entry the I-Novae Editor is being designed with the idea that anyone with a background in industry standard applications such as Photoshop, 3D Studio MAX, Maya, Unreal Editor, etc can just step into our toolset with a reasonable amount of familiarity. The majority of our users will have invested serious amounts of time in learning these various applications and we would like those investments in time to carry over to the I-Novae Editor as much as possible.

The editor shell is being designed in a manner similar to that of Visual Studio .NET. While this may seem somewhat backwards considering that Visual Studio .NET is a programmer environment, not an artist environment, to date it has what I consider to be the best docking/layout/project system I have seen. With more and more users purchasing multiple-monitors it has become a requirement to have a robust docking system capable of leveraging these advances in available screen real-estate. We have deviated from the Visual Studio .NET layout slightly, however, with the inclusion of the Ribbon instead of a traditional menu/toolbar setup. Microsoft has been driving acceptance and adoption of the Ribbon within its own products since the launch of Vista and I believe it represents the most powerful and efficient manner to expose many different context sensitive actions to the user.

The Material Editor

The I-Novae Editor actually represents an ecosystem of sub-editors. These sub-editors consist of things like the Level Editor, Particle System Editor, Mesh Editor, etc. All of these sub-editors work together to create/edit various sets of data that the I-Novae Editor then combines to create the final game assets in a process, to use Unreal/UDK terminology, called cooking. The focus of this blog today is going to be specifically on the new Material Editor as most of the other editors have a dependency on it and therefore don't exist yet.

Before I get into the details of the Material Editor let me state that, for those of you who don't already know, a material is a set of properties that define how geometry within a virtual world is shaded. In other words if I am drawing a triangle on the screen a material is what determines the color of each pixel in that triangle.

In the game/film industries today you will typically find two types of material editors:

1. Lists of parameters such as CryEditor and Unity. These material editors have long lists of parameters that you can tweak until you get the desired effect.
2. Node graphs such as Unreal Engine 3 and Houdini. These material editors provide a list of available outputs and a list of available operations and then it is up to the user to connect sets of operations together to form the desired output.

Each of these methods have their own advantages and disadvantages but after doing a bunch of research on the inter webs it became evident that the majority of people, or at least the majority of vocal people, seemed to prefer node based material editors. Most notably there are a number of discussions comparing UnrealEd to CryEditor with the general consensus being that for creating materials CryEditor is an inferior environment. The choice to go with a node graph material editor was further reinforced for us by the fact that there are going to be other editors, such as our Procedural Planet Editor, where there simply is no intuitive way of doing it other than providing a visual graph of operations. Therefore we can share the underlying node rendering system across all of these different sub-editors.

Before work could begin on the Material Editor there were a few engine level systems that needed to be created first. For starters there has to be a set of operations that could be performed (individual nodes) and secondly there had to be a way to turn a material into shaders for each supported platform. This is further complicated by the fact that gamers are all running different hardware and the material system needs to be able to automatically scale across all of that different hardware combined with different methods of rendering (for example forward rendering vs deferred shading). The cherry on top is that different platforms also use different shading languages. For example OpenGL uses GLSL whereas D3D uses HLSL.

To automate this process we've created a material compiler that generates all of the shaders needed to represent a material across all supported hardware. By default all materials are compiled down to shader model 2 which is widely supported across the majority of PC's, consoles, and OpenGL ES 2.0 capable mobile devices. It's essentially our lowest common denominator. Within the Material Editor you can create additional versions of a material that target a specific shader model, i.e. the new shader model 5 available in DirectX 11, for fancier effects on high-end systems.

The Future

So where do we go from here? Well for starters the Material Editor isn't 100% completed yet. It's just to a point where it's usable and thus suitable for public display. There are still a number of operations (node types) that have to be added along with support for reflectance models other than Phong. What I'll probably do is delay these additions until after I finish the Mesh Editor because creating materials without a mesh to apply them to is a lot less fun.

The Mesh Editor will more or less consist of merging ASEToBin into the new I-Novae Editor and adding a few additional features. Also we need to add support for linear space lighting at some point. Currently the I-Novae Engine does all lighting calculations in gamma space. I can spend an entire blog discussing color theory (HDR The Bungie Way for a good explanation) but for now all I'll say is that this is incorrect.

Flavien has been working on porting our planetary engine to the new material system. We also decided that while he was at it he should look into upgrading it to use compute shaders on DX11+ class hardware which should greatly increase speed. Overall we're hoping to have these systems completely wrapped up by sometime in the early fall. In the meantime for those of you interested in day to day updates you can follow me on Twitter.