Hello and welcome to another tutorial from Elara. Today, I’m going to unpack the design process used to build this ricochet Max Creation Graph. Like any other tool, MCG has a learning curve. And in my experience, the steepest slope of that curve was at the very beginning. While I walk you through the content of this specific graph, I’ll share with you the method I’ve learned that got me over that initial hump.
The best way to get into MCG is to approach it with a specific goal in mind. For this ricochet tool, the goal was to place a tube in a vein in a way that looked more physical than just running it down the middle of vasculature. Our idea was to bounce a spline back and forth from face to face, then normalize that spline to soften the edges. MCG has such a vast range of possibilities that you really need the seed of an idea to motivate you through the research and development process.
All right, let’s dive right into building this graph. I like to start from the outside and work my way in. The center is a black box, an unknown function. But I have a hunch as to what needs to go at the very beginning and at the very end. The output is easy. I know I want a curve. Input is a little trickier. My best guess is that I’ll need an object to ricochet against and a point to shoot my ray from. There’s probably more I’m not thinking of at this stage, but that’s okay. As we build in the center of the graph, those extra inputs will become readily apparent.
Now we’re going to fill out the tool by working from the right side of the graph to the left. The advantage of this method is that you can focus on solving smaller problems, piece by piece, rather than worrying about every part of your graph at once. It also means you can get a working visualization up and running early on in the process. It might not be doing what you want it to quite yet, but if you’re running into a bug or if your tool has a build error, you can undo a few steps to a working tool.
This process can still be challenging. You might not know how to procedurally generate an array or how to calculate multiple reflection vectors, or any number of challenges that deal with abstract data. Just realize that you don’t have to solve these problems all at once. Instead of generating a procedural array, make one manually. Instead of calculating a series of reflection vectors, try calculating a single one. By solving these simpler problems, you’ll build yourself a framework that allows you to tackle the abstract and unknown piece by piece.
Keep in mind that you’re probably going to end up making portions of compound graphs and blocks of code that already exist. When I was preparing this tool, I knew I would need to find a formula that took the normal of a face and spat out a reflection vector. I found the formula online, and was fully prepared to recreate it in my graph, until I learned that it’s been hard-coded in already. And that’s okay. MCG nodes work best when you understand exactly when and how to use them. It’s better to start off with a strong understanding of just a few of them rather than superficial knowledge of the entire list. There are a few fundamentals that you’ll want to become familiar with, specifically, the higher order functions. There’s a fantastic Autodesk blog post, written by Christopher Diggins, that describes each of these in-depth, and gives a rundown of the thought process behind functional programming in general. I’ve included a link below, and I highly recommend checking it out if you’re looking for a comprehensive introduction to MCG.
You’ll reach a point while developing your tool where you’ve reduced the undefined portions of your graph to a few key points. In the case of the ricochet tool, I knew I needed to repeat the bounce effect with a repeat node, but the initial data type and the resulting data type didn’t match. In addition, my tool was working as expected when the object was at the world space origin point without any rotation, but once it started moving it around, it didn’t behave as expected. In both cases, I ended up splitting off the nodes into a separate graph to find solutions. I recommend this method of branching code so that you have a clear point to return to once you’re ready to proceed. This has the added benefit of forcing you to rebuild the area of the graph that’s producing aberrant behavior. I cannot count the number of times that rebuilding a piece of a system has helped me identify the area that’s breaking down.
I solved my issue with the repeat node by piping more data into it, then discarding that data that I didn’t need later by using a for each node. For the object transform, I simplified how collisions were being calculated by converting everything into world space coordinates. Then, just before the end of the graph, I converted it back to local space.
The great thing about these solutions is that they’re both about node order, essentially, just refinements to our existing code. Unless you change the scope of your tool, there’s nothing left to do but iron out any bugs and optimize what you already put in place.
Thanks for viewing the tutorial. Don’t forget to check below to download the ricochet tool. Please check out Elara on the web, and reach out if you’d like to join the Elara team.