Developers demonstrate how the volumetric gas cloud tech is built in Houdini (node-based, Pyro, VDBs, Cloud Detail) and used for nebulae and space dressing, not Crusader's atmosphere. They also cover performance and lighting cost, GPU particles, and density-driven asteroid spawning.
TL;DRHoudini is node-based and non-destructive, so artists can go back to any point in the network and sample data, such as feature sizes before and after an action, which helps with complex things like the Coil.
Houdini is a node-based program, unlike 3ds Max and Maya, where you apply a function to it. So it's like your polygons and then you do an extrude to create a cube, for example. Houdini works in a similar sense, but instead of keeping things in a function and just having code in the background, say you want to perform this action, Houdini actually has all of these in nodes, so it's totally non-destructive. So if Ollie went all the way to the top of his network, you'll be able to see the original grid that he created from. So it's just totally non-destructive and it's actually one of the big benefits of Houdini.
Yeah, because then you can start sampling data at different points of the network, which is actually what we need to do, and actually it's the only way we can overcome some of the technical hurdles when we start dealing with things as complex as the Coil. We need to know and extract data from our models at different points of its creation. So we need to know maybe the size of a feature before and after you've performed an action on it, so we can make corrections if need be.
As we've stated, this isn't what's going to be used for something like Crusader or even for atmospheric clouds. This can be used to make the space around a star system much more interesting and much more dynamic. This is about making space more than just black empty space.
Yeah, things like celestial bodies, not planets. You've got maybe asteroid fields and then you have a gas cloud covering it to just make it a bit more, or a derelict ship in the middle of a nebula, or maybe spilled oil around the gas and it forms around the ship.
Not gas cloud tech for Crusader. It's a different tech is what we're saying. It's different. They're not the same. So this not being the thing that we're using for Crusader does not mean that Crusader is 2D. It's that it's a different tech that's being used for that.
We did try it. But for what it is, it's not the right thing. And that's sometimes what happens. And that's also just the great learning experience, really, of what we're doing.
TL;DRHow gas clouds can exist is left to designers and backstory, but the clouds drive pressure values that affect particle effects and other systems, and which gameplay effects apply is up to system designers.
I'm going to say that's a question for the designers. We have to work that out, come up with the back story. That's one of those things that luckily artists don't have to worry about.
What is quite interesting about the gas cloud itself is that it does drive gameplay parameters. For instance, the pressure: we have atmosphere systems within the gas cloud entity. Whenever you go inside the volume of one, it will drive a pressure value in the atmosphere, and that drives other systems. What we can do is that we actually drive the particle effects in there, so you see more different types of particle effects, and the intensity increases when you go deeper in and the pressure gets bigger. It's quite interesting how these different systems end up being tied together. That's something that happens quite a lot across Star Citizen, where we tie a lot of these parameters together.
Folks who saw the vertical slice for Squadron 42 saw how the Coil had some adverse effects on the ship systems, with the communications being garbled and stuff like that. There are certainly gameplay elements to this work, but again, which gameplay elements come into play when, where, and how are the realm of the system designers as opposed to the VFX artists.
TL;DRJacob Beckley prefers Houdini's Pyro for its fully exposed, tweakable solver, while acknowledging FumeFX is faster and easier, and the team lets artists use whichever tools suit them, often combining both.
We were talking about this earlier. I'm biased towards Houdini's Pyro because I'm more of a Houdini kind of person. I've used the Pyro solver and the whole Pyro tech a bit more robustly, and it is capable of really powerful things. One of the perks of Houdini being node-based is that even the solver, the calculation that happens to calculate how a smoke sim should operate, is all totally exposed. So I'm able to go into essentially the code, not quite code, but the node that builds up this entire solver. I can manually tweak the parameters. In Fume, I can't quite, but it is kind of like you pick your tools for it. I know Fume does produce results a lot faster and a lot easier than Pyro. Pyro can be a bit, you've got to work at it, it's a bit like clay. But I mean, Fume is perfectly valid. I think Jake Ganey, our assistant creative director, I think his title is...
Yeah, when I talked earlier about different artists bringing different methods, we learn every time that we do this. Jake Ganey is one of these people who's done that. He takes sims from FumeFX, brings them into Houdini, and then has them as separate node chains. So at the moment, we're just going down one linear path. But he would have quite a few different aspects in and then build up and layer up the simulation and the VDB grids. It's a really versatile method. That's why Fume is great, but Fume with Houdini is really super powerful and it does everything that we need it to do.
Yeah, that's one of the neat things. We see this quite often through different departments in CIG. It's a push towards using the tools that our artists are most effective with. If you're more effective with this, then use that. If you're more effective with that, then use that. And we have an entire tools team that works to build all of the connectors and the translators that are necessary to allow that to happen.
Yeah, and they all give good results, but different results as well. So if you want more of this kind of look, we're going to have to use a Fume simulation. If we want another particular look, we have to use a particle simulation, and then we have to start maybe thinking about tools that would help aid the process. So if an artist who uses Fume can't quite get the result that he wants with what the particle workflow produces, we've started this where, again, Ollie and I start to come in: what tools do they need to make this easier, so any artist can come and use this so it's not exclusive to this one artist?
TL;DRPerformance is a constant concern because 3D volumetrics and their lighting are costly, which is why lights are mostly static and the gas cloud isn't animated, since VDB is a static format.
Implementation has been something we have to keep an eye on, because rendering 3D volumetrics in games, not many people do it. And the reason why people don't do it is because it honks your graphics card. So this is something which we're just always looking at. And this is partly with the rendering and how many voxels we see on screen, as well as the lighting. The lighting cost is a huge thing. That's why a lot of our lights are quite static in here. At the moment, we have this little animated light that we can see, but calculating that all the time or calculating a full light with shadows is very hard. We have to make sure that we're doing the performance analysis on it all the time. When we're building it, we're building it in very logical ways instead of things which are going to be just really bad for the user, for your playing experience.
That's why the gas cloud is actually static and not an animated gas cloud. Because every time you load a gas cloud, it's got to start calculating the lights, it's got to process the VDB file itself, and it can take some time to do. So why it's not animated is because the VDB file format is actually a static format. Otherwise, you need to render X amount of files to play over each individual frame.
A bit of both, actually. I think they are starting to go towards the GPU because it's just better. Before, we were primarily CPU, but now we've got a lot of stuff on the GPU, so we're taking a bit of stress off the CPU. It just means we can add more particles.
TL;DRVDBs can be used beyond gas, since their density data can spawn asteroids in thick areas and fewer in thin ones, and an asteroid gas cloud entity already does this.
I think we're looking at, I mean, it's as much as you can think of what other things could use a nebula for. But the data in itself that the VDB offers, such as density, can be used to help populate a level. So instead of having an artist hand-placing asteroids in a vast area as large as the parent is, they could use the VDB's density value to start spawning asteroids in a massive, vast area. And you could have asteroids only in very thick areas. So you'd have asteroids in the more dense parts and then not so many, maybe a couple, in the low-density areas.
We have the asteroid gas cloud entity, which does that. I didn't want to show it today because a lot of the defaults are Squadron stuff, but we saw an image of it yesterday and it was really phenomenal. And I did play around with it. I just popped in a VDB square and put some rocks in the other day and just flew through it. It was really fun, just dodging around all these asteroids.
It could be really good when it ties into gameplay. So if we did have things like EM distortion on your ship and you're mining, or the asteroids are in the dense parts, but the dense parts are really dangerous, you could actually lose a ship or just get hurt mining by getting too close, being too adventurous.
Just to answer one of the questions I saw someone say: with simulation time, it's close to real time, but in Houdini speaking, because we're not looking for Pyro solvers or simulation to actually give us the detail, we just want it to give us the density for us to work with. We actually add the detail after simulation. So with Fume, when an artist does a simulation in Fume, they will take it to Houdini, and then Houdini can start processing with that Cloud Detail node to add the detail that the solver wouldn't be able to ever give.
Yeah, and it's like we mentioned earlier, it's tools in your arsenal, right? All these things, and every different artist has come at it and approached it from a different angle, and every time they do that, we learn this new thing. It's really fun. It's really exciting.