MODO, procedural modeling and me

June 21, 2016

Matt Cox, lead developer on 10.1, gives the inside story

MODO 10.1 produced imageImage courtesy of Yuya Takeda

I am not a 3D modeller; I've tried and failed many times. I can create basic objects, but the skill to create complex creations with elegant polygonal flow is one I've sadly never mastered. When it comes to computer graphics, I've always been more interested in the technical side of things, such as building complex rigs and creating tools to achieve the results I want. I suppose my interest and excitement over procedural modeling goes back to that simple concept.

My personal history with MODO goes back to 2005, when MODO was still in its infancy. At the time MODO was a simple 3D modeling application, with one promise: to allow people to model at the speed of thought. Despite having absolutely no modeling skills whatsoever, like many others I bought into the idea of MODO as a tool. It had the promise of being so much more, and was clearly designed in a way that set it up as an application of the future. Over the years, MODO has grown from being solely a modeling application into something much more complex and powerful.

At university I studied computer animation, with a focus on rigging and character animation. Despite MODO having none of these features at the time, I continued to use it as a platform for tools, experiments and custom plug-in development, to see if I could push the MODO SDK to achieve things that weren’t possible within the core application. In 2011, these experiments were noticed and I joined the team at The Foundry (Luxology at the time), initially working on automated testing suites and tools for tracking stability, eventually migrating into feature development to work on MODO 701, MODO 801, Colorway 1.0, and MODO 901, among other projects.

Despite being part of the development team, my experiments continued, and in 2012 I started toying with exploring the concept of procedural modeling in MODO. The technical artist and animator inside of me was fascinated with generating geometry dynamically that could be animated and changed over time. Compared with the power of the final procedural system we have now, these initial experiments were quite naive and simple, yet they demonstrated the potential of procedural geometry.

The direct modeling toolset inside of MODO has always been a one-way street, with any edits performed on the mesh being uneditable after the fact—artists are unable to go back to an earlier mesh edit and modify it in some way. It is this behaviour that makes MODO such a powerful and fast direct modeling application, but for some workflows—such as exploring shape and form, or creating motion graphics and visual effects—this can often limit the workflow. During the development of MODO 901, it became apparent that MODO needed a procedural geometry toolset that could be used to solve some immediate workflow challenges, but could also provide a foundation that could be built on for years to come. Understandably I leapt at the chance, and helped form a small development team with some simple goals: to provide a strong, future-proof foundation for a procedural modeling toolset, and to deliver that power and functionality to the users in an artist-friendly workflow, without limiting the power of the system for more technically minded artists. We also wanted to create a system that felt at home within MODO, directly integrated with the existing MODO feature set, resulting in a toolset that felt familiar to users.

The procedural system has been in development for almost two years, and represents a significant update to the core application. In a way, the procedural toolset is breaking new ground for MODO; however, one of the things we discovered when we began working on the project is that MODO has always been designed to work this way. At the heart of MODO is the evaluation engine. I am sure many MODO artists aren't fully aware of the power of this system; it allows lazy evaluation, caching, parallel evaluation and much more. In my opinion, it is one of the most powerful evaluation engines in any modern DCC application. To implement the procedural modeling system, we had to introduce the concept of geometry that could change its topology over time and be evaluated differently for every time step. Thankfully, the MODO evaluation engine, implemented by Stuart Ferguson in the initial versions of MODO, was built with this concept in mind. Despite MODO for many years having no concept of procedural modeling, the powerful evaluation engine was designed and engineered to support a procedural system from day one.

The evaluation of procedural meshes is essentially a stack; at the bottom of the stack is the base mesh that can be edited using direct modeling tools. On top of this base is a series of procedural layers that modify the mesh in some way and pass it on. The artist can animate, modify and easily reorder any of these layers, and the stack will be re-evaluated to create a final mesh. For performance, every layer in the stack is cached, so if the artist is editing a single operation at the top of a stack of 50 nodes, it will be as efficient and fast as editing a single layer on top of a stack containing a single node. If this concept sounds familiar, it may be because this is identical to how systems such as the shader tree and deformation work inside of MODO.

One of the goals of the procedural system was to avoid reinventing the wheel; for years MODO has had best-in-class direct modeling tools, and rather than spend months developing a new bevel tool (for example), our goal was to support the existing tools in a new procedural context. The layers in the procedural stack are essentially direct modeling tools, with tool attributes replaced by channels that can be animated and rigged. Selecting a tool in the stack allows its tool handles to be displayed and directly manipulated by the user as if they are using a direct modeling tool. A familiar concept in the stack for many will be the tool pipe, allowing multiple tools to be combined to create new and interesting behaviours, without requiring technical knowledge. For example, combining a sweep effector with a path generator allows shapes to be extruded along a curve; however replacing the sweep effector with a text operation allows text characters to be distributed along the same curve. Our goal was to replicate this behaviour in the procedural stack, so as more tools are introduced in subsequent releases, it not only adds one or two extra tools, but potentially many more combinations.

The power of the procedural system doesn’t end with the front-facing feature set. One of the main things we wanted to achieve with this release was to provide an SDK that allowed for rapid development of new procedural tools. I’m particularly proud of the work we’ve done in this area, as the simplicity of the procedural SDK allows new operations to be added with minimal code; in many cases, existing tools can be converted to procedural tools with less than 10 lines of code. To ensure we reached these goals, we “ate own our dog food”, by developing every single procedural tool using the publicly available SDK. I’m really looking forward to seeing what some third-party developers can make of this system and how they expand the feature set in ways we haven’t imagined.

There are many more features in this release that I’d love to expand on and enthuse about—from the ghosting feature of the stack, to B-Spline support, to the powerful selection system—but I’m running out of space. The team has done an awesome job on this release and I want to thank them all for putting in the extra effort to make this release what it is. We’re all excited to get 10.1 into the hands of some real artists, and to see what amazing work can be created.


Images courtesy of Steve Barret, Matt Cox and Yuya Takeda


Matt Cox

Matt has been working on the MODO team since 2011, where his background in animation and rigging is being put to good use as he leads the procedural modeling feature development.

Share this story 

blog comments powered by Disqus