Standalone fluid simulator Naiad has been reborn as Maya 2015’s new Bifrost simulation system. Its co-author, Marcus Nordenstam – now product manager at Autodesk – tells us how it will stir up FX artists’ workflows.
One of the headline features of Autodesk’s 2015 animation product releases was Bifrost: the brand-new fluid simulation system built into Maya 2015.
Like Naiad, the standalone fluid simulator created by Exotic Matter, which Autodesk acquired in 2012, Bifrost uses a next-generation hybrid fluid solver. But whereas Naiad was definitely a TD’s tool, Bifrost aims to make setting up simulations a point-and-click process.
Taking its name from the bridge that linked the world to the realm of the gods in Norse mythology, Bifrost represents a bridge to the future in other ways. Although still very much a work in progress, it already enables artists to render large simulations without meshing them first – and in future versions, may lead to new workflows in which the authoring and computation of a simulation are completely decoupled, enabling studios to compute simulations in the cloud, or on specific games hardware.
Building a next-generation simulation workflow
In the interview below, we talked to former Exotic Matter CEO Marcus Nordenstam, now product manager at Autodesk, about how Bifrost compares to Naiad architecturally, and how having a true production-ready fluid simulator built into Maya will change artists’ working lives.
As a publicly traded company, Autodesk has a legal obligation not to make definite statements about future software releases that fall outside the current financial quarter – an issue around which the conversation had to steer – but we feel it provides a glimpse of what a next-generation simulation workflow might look like.
CG Channel: Let’s start with a little history. Why did you decide to sell to Autodesk when you did?
Marcus Nordenstam: It was becoming obvious that getting Naiad into the hands of a larger market was going to be an uphill battle. A lot of people were still using RealFlow; a lot of people were using Houdini. If we were to get the technology in Naiad to as many people as possible, as quickly as possible, doing it in the Autodesk family – and particularly Maya – was a free ride.
CGC: The name Bifrost suggests a bridge between two worlds. What are the two worlds?
MN: I wouldn’t read too much into that: it was originally just a code name. But I guess the two worlds are proceduralism and interactivity. And perhaps we’ll see a move over the years towards the separation of authoring and compute, so [that might be another meaning]. You might author [a simulation] in one environment but compute in another – in the cloud, for example.
CGC: How similar is Bifrost to Naiad under the hood?
MN: The similarities are the [solver codes] themselves. The fluid solver in Bifrost is definitely ported from Naiad. And the meshing is very much based on the Naiad mesher.
The differences are that Bifrost uses an adaptive data structure, and Naiad did not. In the first version, you may not see much evidence of that, but you will in the future.
Bifrost [also] scales better. It scales up to more cores and has higher performance. We always knew there were a couple of Achilles heels in Naiad … and those have been fixed so it runs faster.
And the third big difference, of course, is that it’s running in Maya. If I want [a simulation] to collide with a ship, I don’t have to export that ship out of Maya any more. It’s a simple thing to say, but the effects on the artist’s workflow are profound.
Maya’s Viewport 2.0, now the default view in Maya 2015. Bifrost builds on the Viewport 2.0 framework to display unprecendented numbers of particles in the viewport, and to display level-set data directly.
CGC: You mentioned separating authoring a simulation from actually computing it. How does that work?
MN: Before, Maya would basically calculate [a simulation] in the same thread as the user interface. So if you were doing a big sim, it made Maya pretty much useless; you’d have to wait a couple of minutes before you’d be able to scrub properly.
With Naiad, the user would compute off the command line: they’d launch a compute outside of [Naiad’s GUI], so you could still tumble around inside Naiad Studio and wait for your frames to show up in the disk cache.
We’ve ported some of those ideas into Maya itself. Bifrost, when it runs in Maya, runs in the background. You can see the timeline turn orange and green as the frames are computed, and you can still scrub. So you still have an attractive user experience even if you launch a very heavy simulation.
CGC: Can you co-opt the GPU to do the computational grunt work?
MN: The GPU is involved in visualising the data, but not in the actual compute. [There is support] for drawing the level sets directly in the viewport and also new particle displays that can handle far more particles than Maya could before. A lot of that goes hand in hand with Viewport 2.0. Although a lot of the particle and level-set draw [work] came from our team, it really is relying on the general framework of Viewport 2.0.
CGC: Will that change in future?
MN: The architecture of Bifrost [consists of] a graph analyser, a code generator and a compiler. The procedural graph that describes the simulation is analysed and code generated from it, and compiled on the fly. When you compile code, you can have multiple targets: you can target regular CPUs, but you can also target game consoles or GPU code – and if you were to do that, the whole graph would be running natively on the GPU.
That’s different to saying, ‘We have a graph and we’re going to start porting certain nodes to the GPU.’ What we’re talking about here is having the entire graph run on the GPU; and then, an instant later, you could say, ‘I want to run on the CPU,’ and recompile on the fly.
Bifrost in Maya 2015 doesn’t expose the graph … so these things are still being explored. But it’s very powerful, disconnecting your authoring model from the compute; the compute could potentially happen on many nodes.
CGC: Like the cloud?
MN: There’s no way [to do the compute] in the cloud right now, other than to launch a [general] Maya session on the cloud, but that is something we’re looking at. Obviously, being able to compute outside the Maya session is desirable so that you don’t have to consume resources specifically tied to Maya.
CGC: How large a simulation can you create with Bifrost in Maya 2015 and still get reasonable performance?
MN: Anything you could do with Naiad, you’ll be able to do with Bifrost: performance and scalability should be very similar. Despite all of Maya’s infrastructure, it doesn’t prevent Bifrost running very competitively to Naiad, and in many cases actually beating it.
The fact that you don’t have to do the whole export/import [process] any more eliminates a lot of file caching … and in Naiad, you had to use procedural graphs no matter what, whereas in Bifrost, we have a very nice point-and-click interface. It makes set-ups far quicker and easier.
One long-time Naiad user told me that he’d been testing the beta [and] that something that took him a couple of hours to do in Naiad took him a couple of minutes in Bifrost.
CGC: Some studios used to mesh Naiad simulations in other packages, like Houdini. Can you still do that?
MN: Naiad [used to export] particles and voxels as EMP files. Bifrost’s version of that is called BIF. BIF files are currently closed-source but one area of active research is an API. If you have someone who can write C++ code, they would simply be able to link to that API and use it to read particles or voxels coming out of Bifrost … or write a node in Houdini that would read native BIFs.
CGC: But one of the cool things about Bifrost is that you don’t have to mesh at all, do you?
MN: Yes, there’s a direct level-set rendering shader for mental ray.
I’ve seen people make simulations of over 40-50 million particles in Maya using Bifrost, and when you mesh that, you can end up with an enormous number of triangles – [up to] 100 million triangles – and any 3D package, not just Maya, will have a hard time with that.
So if you get into those situations where you have a big sim, and have trouble dealing with the meshes, direct level-set rendering – where you produce an image without meshing at all, right in the shader – is a great way to render those images.
CGC: Could you use RenderMan or Arnold? Is there any reason the shader has to be for mental ray?
MN: Absolutely not. Bifrost is not in any way dependent on mental ray. It was just a question of time.
We had something like eight months [to work on the first version of Bifrost]. The acquisition was a big business deal, then [we had to assemble a team]. We had to work out the minimal useful set [of features] we could target in the first release … and we knew that people would always have access to mental ray.
CGC: To what extent can you interact with Bifrost with standard Maya tools? Can you sculpt the simulation?
CGC: Or use standard Maya forces?
MN: No, not that either. But any mesh that you can animate can be used as a force – we call it an ‘influencer’. If you need to make waves on the water, and you use some kind of ocean toolkit to create a moving wave mesh, you can apply that as an influencer to push the [simulation] around. Or if you want to create an artistically driven force, so long as you can express the motion of that force as a mesh, you can use it as an influencer.
It’s a departure [from previous tools]. We’re not really trying to build a new Maya Fluids; we’re trying to build something next-generation entirely. Maya Fluids and [the Nucleus simulation framework] are good for what they do, but they’re not designed around the idea of proceduralism, which Bifrost is.
Whatever we introduce in Bifrost needs to be future-proof. We really need not to redesign those things every year. So we’re intentionally not making a lot of backwards compatibilities to things we feel may go away.
CGC. Do you have to be a TD to get good results out of Bifrost?
MN: Well, no. In Maya 2015 that was actually the whole point. It’s very much designed for generalists. Fluid TDs are obviously going to be using it because they’re the ones doing liquid simulations, but liquid simulation on its own doesn’t have to be much harder than animation.
Where Bifrost beats Naiad, other than it scales better, is ease of use. The Naiad interface was pretty cryptic, and pretty hard to use. It forced the graph upon you whether you needed it or not. With this release, generalists can point and click.
If I just want to pour water into a glass – which is actually quite a hard sim to do technically, believe it or not – from the user’s point of view, it should be as simple as modelling the glass, clicking Emit, adding gravity and setting up the water to collide [with the container]. It shouldn’t require knowing about 12 different types of node.
We’re hoping to show that you can do a lot of things with fluid sims without requiring a procedural graph and all the complexities that arise from that, and thereby scaring away a bunch of people who don’t need to be scared.
Softimage’s ICE visual programming system. With Softimage now discontinued, members of the ICE team have been moved to work on Bifrost, resulting in “a strong ICE cameraderie” behind the new simulation system.
CGC: Softimage’s ICE visual programming system did a similar job of making technical tasks accessible to non-TDs. What does Bifrost take from ICE?
MN: There are quite a few people from [the old ICE development team] working on it. In this release, you’re not going to see much ICE influence because we don’t expose the graph … but there’s a strong ICE camaraderie behind Bifrost.
CGC: How does the size of the development team compare to Naiad?
The Naiad development team was primarily me and [Exotic Matter co-founder] Robert Bridson [also now working for Autodesk], but we did have a few other people, so I guess we were five or six, give or take. [Autodesk doesn’t normally talk about team sizes] and the Bifrost team varies in size, but we’re definitely bigger than that.
CGC. What’s the benefit of using Bifrost over a third-party tool like RealFlow – aside from the fact that you don’t have to buy a separate piece of software?
MN: I think one of the biggest selling points is exactly that. If you’re a small studio where money matters, maintaining multiple [software] licences is a big deal. And for the artist, it eliminates the import-export process, which makes workflow more efficient. They can turn around more iterations of a shot in a day, which translates into better-quality work.
But the third advantage is the solver and the Bifrost technology. I felt that one of the big reasons that people loved Naiad was that they knew they could do a really massive sim and go home leaving it to run overnight, and it wouldn’t crash. You can expect that stability in Bifrost … the stability of the Naiad code, and the quality, the level of detail [of simulations]: all the things that Naiad was famous for.
CGC: Will people only be doing liquid simulations, or gaseous fluids as well?
MN: In Maya 2015, liquids are really the main thing. For gaseous stuff, you’ll still have to use Maya Fluids. We’ve researched it, and it’s there in our plans, but I can’t comment on when and in what form.
CGC: A robust fluid simulator is high on the list of user requests for 3ds Max. Will we see Bifrost in Max?
MN: My only answer is one I’ve given before: Bifrost is engineered as a standalone entity, so it’s not dependent on Maya at all. It was designed that way for the purposes of being able to take it into any environment. Whether we decide to take it into Max – that is a decision we haven’t made yet.
Tags: 3ds max, Architecture, autodesk, Bifrost, cloud, comparison, Exotic Matter, Featured Articles, fluid simulation, gaseous fluid, GPU, graph, Houdini, interview, level set, liquid simulation, Marcus Nordenstam, Maya 2015, meshing, Naiad, next generation, Q&A, RealFlow, rendering, solver, video, workflow