TL;DRSimulated magnetic fields could potentially drive an aurora effect, though particles alone can also do it, and similar tech might be needed for sun flares in Pyro, but how detailed to go depends on how close players can get.
Potentially. It does create that aurora borealis kind of... It's partly due to positive ions hitting the atmosphere, which is a magnetic field, and you get that movement because of the magnetic field. So you inherently get that movement from it. So yes, it can be used to generate the vector field required for it, but I know Mike has also done tests way back in the past to show off the whole particle system creating aurora borealis just from particles alone, so we've got many different ways to do it.
The Pyro system actually might require that sort of stuff, sun flares mostly. There was talk about it back when we did CitizenCon. So more tests probably will be made towards that.
Yeah, we've had discussions with other teams actually regarding solar flares. One question that I would straight away ask with something like that is, how close can the player actually get to that thing? Because Jake could make an absolutely phenomenally accurate looking sun-like creation with potential for really nice solar flares, but if design decided that actually you couldn't get that close because there's no tech in the game, and this is just purely speculating, by the way, but if you can't get close enough to it, then why invest all that time and resources into making it look so detailed?
So yeah, we did a quick experiment, mostly regarding my work with gas clouds, where we needed to start simulating magnetic fields to try to create a bit more organic kind of feel. Give a bit more detail and life into things. And we can actually use that tech, and did try using it, to create the details and vector fields to help move particles to try and simulate the movements with the sun. So you could get the surface movement as well as some of the corona flares coming out. It was a good initial test. It was good highlighting where we might need to improve in the future and where we could definitely add. It does have a lot of potential to just look absolutely awesome.
TL;DRUnique per-manufacturer shield patterns are described as feasible and discussed, but the first release has a single style and the priority is making the tech and visuals solid first.
It's entirely feasible, and it's definitely something we talked about. So I think the main thing for me is that I want to get to a point where the tech that we've got and the visuals are rock solid initially. Like this initial release, it's just the one style. It does what the designers needed it to do. It looks good. It's efficient, et cetera, et cetera. But yeah, for sure. With all our VFX, we like to theme them. We like to be able to make the effects different per manufacturer. We've done that with thrusters for however many years I've been here, nearly seven. So yeah, I think it's perfectly feasible. I'm going to ask Jake a question. I'm going to put him on the spot. So 3D textures, we've talked about using 3D textures to define the shape, to give some pattern. And I guess that's the kind of thing where I might go to you and say, hey, how can we use Houdini to quickly generate some nice variety of 3D textures? Just to be clear, I'm not asking you to do that as a task. It's just a theoretical question.
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;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.