VFX Technical Artist
Well, no, we don't actually.
But how are we seeing that fast?
It just updates really well, which is really, really convenient.
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've kind of ruled out... We explored VDBs and kind of said, not quite the tech that we should be using.
Different technologies, different solutions for different problems.
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...
Is that his new title? He was assistant art director the last time I talked to him.
Oh, I think that was it, yeah. He uses Fume quite a bit. He doesn't really use Pyro. And some of the stuff that he produces just with Fume is crazy.
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.
But yeah, we've got another artist, Jake Dunlop. He uses particle sims as his base. So we all have different methods.
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.
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.