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?
TL;DRBeing downstream can complicate scheduling but isn't frustrating, as it's just the pipeline, and Leo Vansteenkiste adds that VFX sometimes drives projects itself, such as wind and atmospheric pressure, which other teams then use.
I guess it can be frustrating, but it is the way it's got to be. Audio are the most downstream, I should add, as well, because any effects that we make, then audio is going to provide the audio that matches the thing we've made. But it's just part of the process. As you say, you said downstream, and that is a phrase that everyone hears a lot in CIG. It affects the scheduling. We can't make a thruster effect until the thruster exists. So maybe from a scheduling point of view, it makes things more complicated because it's a bigger web, isn't it? There's more things that need to come into place. I don't think it's frustrating in the sense that we get frustrated with other people at all. It's just the nature of the pipeline, isn't it? It's all part of the pipeline.
That's a great point. That's a really good point. Sometimes the audio can make an effect look better. I think I might have said that in the past, but it's really true. The weapons in particular, we did a big pass on improving vehicle weapon effects throughout the latter half of last year. And without Darren, the audio director, and his team making the weapons sound better, it would have made my life more difficult. So it's a great collaboration process.
I want to add to what Mike said, but we're not always downstream either. In some cases, some projects, we're actually the driving team almost. Or we're in quite early, so that we become a driving team. For example, the weather effects or the planetary effects that we have on the planets right now, we were quite early with starting to add those things. So we were in charge of actually implementing wind. We needed the wind for our effects. And other teams have started using the same kind of wind system that we added. Because if we have it, they can use it just as well. And there are some other examples, like the fire that we're working on right now. It's, again, a system that's very VFX heavy. But it will affect quite a lot of gameplay as well. Another one is atmospheric pressure. It was something we already had. But the VFX team has implemented the support for it on planets and gas clouds, because we needed the pressure value, because it drives a lot of our effects. We just added it on planets and on gas clouds. And now a lot of gameplay systems also use that same pressure that we've been adding. So I think it's part of our company as well, because we're quite a big VFX team. I think we're in a special place where we can actually drive projects as well as be a downstream team.
TL;DRMike Snowdon says lightning in gas clouds is quite close without giving a timeframe: manually placed lightning works well, but the systemic placement driven by gas cloud data still needs to be implemented.
Well, without putting a timeframe on it, obviously, as I mentioned earlier on, I've been looking at the lightning effects options that we've got in the game. I know we've shown over the last couple of years examples of really nice looking lightning. We can do really cool stuff in our engine. What I'm doing at the moment, part of my ongoing Q1 task, is I'm looking at the tool set to see if it's user-friendly enough, to see if it can do all the things that I know we're going to need to be able to do when we have lightning in Pyro locations, like say in a gas cloud in Pyro, perhaps the art director, Ian, wants that, let's just say. I need to make sure that we're able to do that. And then the other side of it, what we can't currently do, what we haven't fully implemented yet, is the systemic placement of the lightning. So in various CitizenCons, actually thinking about it now, we've kind of shown what we want to do in the gas clouds. We can currently manually place really, really good looking lightning, but we want to, and this is where Leo again would come in and the other VFX programmers, we want to have a system where the data of the gas cloud drives those effects. So maybe design want lightning to become increasingly stronger the closer the player gets to an area that is dangerous. Or maybe it needs to just be more frequently flaring up and frequently occurring. And whichever design decision gets made there will dictate how Leo implements that lightning. So yeah, it's coming along. And I appreciate these things sometimes take longer than might be expected. But lightning is a very, very powerful thing that we've got in our game. And it's really fun to play with. It's good fun.
No, we do have a team of programmers for the VFX team as well. So we'll share the burden. But yeah, the lightning, again, it's one of those interesting projects. I think almost all the projects we do are interesting because we get to do more than just implement the lightning that you place in a location. What we want for our game, everything needs to be systemic. So the lightning needs to be dynamically spawned, let's say. And currently, we have the tech to place the lightning just in the level. But that doesn't really work at the scale that we want to develop the game. So for us, we've had a lot of discussions about this already. And it will come down to how do we drive this lightning systemically. So do you have some kind of electricity value in the gas cloud? And then different gas clouds can have different electricity values. And then if you go into the denser parts of the gas clouds, you have more lightning. And then lightning is spawned in the denser parts. And then for the programmers, it's how do we manage all those lightning things, that they are kind of like separate objects. So how do we manage them? How do we make sure that we don't spawn too many lightning objects and those kind of things? So it's quite interesting to work on these kind of projects.
If you want a visual update on how that might look, if you catch the end of the main CitizenCon 2019 presentation, when the Carrack arrives in the Pyro system, there are some of those lightning events happening in the background. That's the system that we're talking about.
TL;DRManeuvering thruster effects are limited by the thruster size on each ship design, but work is under way to make the effects match the physical wind volumes the thrusters generate, which should add punch near the ground.
I just want to make sure I'm not the only person talking, by the way. I've got a habit of just saying things first. I appreciate that a lot of the maneuvering thrusters have got that potential for looking a bit like a candle flame compared to the main thrusters. Sometimes it's just the scale of the actual thruster item itself. If the ship has a really small nozzle, then it's probably going to look even worse if I give it this ridiculously oversized, like five times longer than the ship, effect. You know what I mean? It's not always going to work. So we're definitely at the mercy of the ship design in that sense. But there's definitely things, I guess, relating to that. We're doing some work at the moment on thruster wind volumes, and what that is specifically is we want to make sure that the effects match the physical volume that these thrusters generate. Because I think it came in, did it come in in 3.12 when we got the thruster volumes? Teo, can you remember?
Yeah, so we just need to make sure that our effects properly match the physical force itself. So we're doing some work on that. Leo, I guess you've got some knowledge on that system, if it's worth us talking about that a bit.
I mean, yeah, I feel like there are different things that we could do. For example, add a separate strength value or have some kind of dynamic behavior based on if you're in the atmosphere. We already do something similar for shock diamonds on the main thrusters. So potentially, we could use that data we do have anyway to do something special with the smaller thrusters if necessary. The ground effects, as you mentioned, with the per-thruster wind volume stuff, I think they will help quite a bit as well to give more punch to the thrusters, especially if you're close to the ground.
Yeah, because that's the thing, it's not necessarily that we want to have a really hot, emissive, long thrust effect that you can clearly see hitting the floor. If you're sort of high up, and then there's enough force coming from a smaller thruster that it's displacing all that snow or that sand or whatever the surface is, I think that will help as well for sure. And that's definitely in the works.
TL;DRDifferent re-entry effects per atmosphere are considered feasible and worthwhile, but would need a pre-production investigation and a systemic setup that works across many planets, and none of this is committed.
I think it's a really nice idea. It's definitely something that I think would be worth looking into for the future, definitely. I think it's feasible. It's definitely feasible. And again, probably Leo will be able to talk a bit about the way that those effects are set up. Because again, it's a great example of a system that's driving the effects. So yeah, for me, it makes a lot of sense. It's entirely typical of our game, isn't it? It's a visually nice feature, but it's also going to give readability to the player from a gameplay point of view as well. So very important, visually and for gameplay too. But yeah, in terms of the setup, I suspect that that's perfectly feasible.
I don't know if you remember, when I was working on the atmospheric entry effects, I actually pitched different colors based off the... I actually wanted that to be in the first release, but it didn't really make sense because first of all, we needed a stable visual state for it, but also we didn't have that many different atmospheric compositions. So anyway, that idea was put on the side, but yeah, as Mike said, it's possible and would look cool.
Yeah, from a technical point of view, it's definitely possible. We do have all the data available on the ship to actually trigger those effects. It would be more a challenge to get a good setup that's easy to set up for artists and that's systemic again. We always need everything to be systemic. It's necessary because we want this to work on hundreds of planets, all with different atmospheres.
Maybe color, maybe size. But yeah, it's definitely possible, something like that. So for us, the first step we need is an investigation of what changes we would have based on the atmosphere. So does it affect color, does it affect size, is it a completely different effect because it's aesthetic or whatever? Those kind of things. And then artists at least will go and do pre-production. And I think Mike can tell more about it. But it's like artists will tell us what they want. And then we go and discuss options of how we can implement it.
Yeah, Leo just mentioned pre-production. That's a massive part of the VFX pipeline, and it's really just R&D. Before anyone does any effects, they have to have done a pre-production pass. For something really simple or something that we've done a lot of before, let's just say like a muzzle flash, the pre-production still exists, but it's probably a very small task, like identifying, yeah, there's an existing weapon in the game. It needs to look like this. So there you go. We've ticked that box. We know what it needs to look like. But for something exploratory, like what Leo's describing, it really is just going through a process of understanding what it could look like, what it needs to do from a gameplay point of view. Is it performant? Is it going to be just ridiculously complicated to implement? Is it going to be a year of a programmer's time, et cetera, et cetera? So yeah, lots of exploration in pre-production.
TL;DRThey acknowledge that quantum entry and exit effects for other ships are wanted and would be done if the underlying system provides hooks, but an earlier attempt was deprioritized and no timing is given.
Yeah, this is a topic that crops up all the time, to be honest. It's something that design will regularly remind me needs to be a thing. And it's all about the setup again. It's to do with the hooks that we've got from the underlying system, and if it provides us with the opportunity to spawn an effect, then yeah, we'll do it. Teo, you did kind of a pitch, didn't you, for quantum travel improvements just generally, so that played a part, didn't it?
Yeah, I mean, I like things to be clear what's happening. So when ships arrive in your vicinity, it would feel, sound and look so cool if there was something really punchy there, because it's an aggressive sort of action that's happening. So I would love, yeah, I mean, for me, I love all the sci-fi tropes of ships jumping in with very large flashes. And yeah, I've tried a couple of things, and I think I had a task to actually work on it and then it disappeared because other things came into priority.
Yeah, we've moved it around, I think. But yeah, when we first did quantum travel, because it's gone through some iterations, and I mean the actual underlying setup, the tech, the system itself. So when we first did quantum travel, in some ways, it was a lot more straightforward. We just had very simple timings, like the spool up happens now, then it initiates, and then it stops, and we had all those kind of things. But we were primarily concerned with the view for the player doing the QT. But yeah, hopefully I've not rambled too much there. But yeah, we acknowledge that that's going to be a thing.
TL;DRThe team highlights unnoticed work: converting CPU particles to GPU particles for performance, a minimum-pixel-distance option keeping laser projectiles readable in combat, and physically based formulas that ease artists' ship effect setup.
I would just say that the conversion work we did from CPU particles to GPU particles, I think is something that no one really noticed and nobody really talked about, but it had an incredible impact on performance. Just the other day when I switched some of the distortion impact effects, I noticeably felt a reduction in this kind of micro lag. I don't know, it wasn't a drop in performance, but it did feel better. And yeah, that's not talked about a lot. And the entire team does a lot for that work.
That's a great shout, yeah, because even though we've had the GPU particle system for a long time, just for the sheer volume of effects in our game, there are still quite a few CPU ones that we want to eventually replace with GPU. And as Teo said, doing that actually provides, not necessarily slightly intangible, but it provides a performance boost. And actually, in our game, a really small performance boost for one scenario like that, if you think about 20 ships, however many ships, all firing that weapon, the performance gains are big. And that's a huge win for the player. I guess I've got a similar sort of thing with laser projectiles. When I say we, the VFX programmers gave me a minimum pixel distance option on the projectile shader that we use. And what that means is that I can keep that projectile, as long as it's alive and it's on screen, at a minimum amount of pixels. And even though that's a really minor thing, seemingly, in the field of battle, that was absolutely invaluable because it meant that you could still see them. It's just a readability thing. It just meant in combat, it made a difference that people probably wouldn't have really thought much of.
Yeah, so as a programmer, it's a bit different. The small gains that we do are more for the artists, I would say. I mean, we do performance improvements and those kind of things. But the small things, like making the setup easier or finding a good formula. We have the wingtip vortices on ships. It's all physically based. And as long as the planets and the gas clouds are set up with pressure and temperature and humidity, it will work with different combinations. And it means less setup for artists. So as long as they make sure the effect is set up on the ship, they don't have to tweak values of we want this here, this there. It's been a long process. I think we got some good formulas, physically-based formulas, and it's quite satisfying finding those and making the future setup for ships and anything better and easier for artists.
TL;DRGas cloud interior effects were ready but held back because the room system's pressure value wasn't ready, so they're working on restoring it, plus new collision effects with rocks and metal bits hitting ships.
Yeah, so for the initial gas cloud release that went into 3.12, we did have the effects, the interior effects, and when I say interior effects, I mean all the kind of small, high velocity, high detail noise that gives you that sense of parallax. We had all that working and it was all ready to go, but unfortunately there were just some of the hooks we were dependent on. It was the pressure value, wasn't it, of the gas cloud provided by the room system. That wasn't quite ready to ship because there were some knock-ons to the actor status, I think. So the designers had to just keep the pressure set to zero. So we are working on that at the moment, getting that back in. Everyone in this call, actually, has been working on that. I mean, Jacob, yourself, you provide the method of creating the gas cloud in the first place, don't you, for the artists? You're integral to that process. So yeah, I'm losing my thread here. But yeah, we're working on it, and it's all happening. It's all going quite well. I think Teo and Leo got together and added a really nice new feature, which is, do you want to talk about that, the collision?
Yeah, sure. It's basically inside the gas clouds. Some of them are themed differently. Some of the themes are asteroid field or mining themed, and you would expect little rocks or micro asteroids flying about. And when the ships go quite fast, you'd expect those items to interact with the ship, so the rocks would interact with the ship's hull and break apart as you fly through the gas clouds. There'll also be some metal bits in some cases, but yeah, all of those will interact with your ship and it'll feel really cool. And audio actually are hopefully going to pizzazz it up and add that extra layer. But yeah, it's coming along.
Looks really cool. I'm quite excited about it. And the cool thing from my side was that it's using existing tech from the atmospheric entry. So it's using the SDF. It's using the same kind of system for dynamically placing the emitter so that it follows the direction of the ship. And it was a relatively quick thing to add on our side that I think will give a lot of extra nice environment.
TL;DRThe directional rain and snow effects should work with wind direction, so problems on some ships are likely UV or flat-plane edge cases, and players should report affected ships to the Issue Council.
It should. I think I'm allowed to say it should be working. The setup that we created for those directional effects was incredibly complex, actually, an intricate setup. And it is actually taking the wind strength and direction, isn't it, Leo?
Yeah. So we're using the movement direction, the wind direction, the gravity, I think, as well. It might be a bug where we're simulating the raindrops on a flat plane, and the plane then needs to be wrapped on the different faces of the canopy and the glass. So either there is something wrong with the UVs, which map the flat plane to the mesh, or it's one of the edge cases where, because it's simulated on a flat plane, we can't really get all the directions perfectly covered. And that might be an edge case. So we have to see the ship itself and see how it behaves and maybe send it to our team to fix up the UVs. It could be a few things.
TL;DRNo research into black holes has been done, comets have come up in conversation with gameplay possibilities and level design concerns, and wormhole jump gates might count as an anomaly eventually.
I mean, black holes, I'm not sure that we've done any research into that so far, but comets have come up in conversations for sure. I think when we started to show the atmospheric burn-up, Teo took a really nice video where there's a ship passing through the atmosphere, but it's right off in the distance, and it just looked like a burning up meteor. And you were probably in it, Jared, it was in one of the weekly updates. And immediately, Ian was talking about, oh, it'd be great to get loads of comets coming through. And then the designer's like, yeah, but then it's going to land somewhere. And then it could be like a new location, and there's all these gameplay opportunities.
TL;DRThe quantum travel effect is acknowledged as dated, with a planned update and concepting starting next week, and they'd like dynamic, damage-reactive, per-drive and tech-level effects.
Yeah, so for sure, you kind of nailed it there. I think there's a bit of visual fatigue that comes in when it's one of the earlier effects that people just see a lot. I've seen that quantum travel effect a few times myself. And yeah, we use the term rot, like some things rot over time. It's just the tech that's driving the effects might have changed. So certainly with quantum travel, there have been fundamental changes to the backend work, like what is the engine doing with that actual process of quantum traveling, which does change how the effects are behaving. So I won't say they're broken, but they definitely don't look like they used to, and the timings get changed as well. So from a design point of view, it's really important that they care about the spool-up time and they care about all those kind of hooks that we then use to drive the effects. So I guess what I'm saying is we're aware that they are due an update. That is planned and scheduled. Actually, our VFX concept artist, Rob, I think next week, in fact, I think that's his next task. He's going to be jumping onto concepting the quantum travel. We've got some really good information from people like Nate, the Squadron 42 art director, and Hannes, the cinematics director. Those guys have got a really clear idea of what they want. We're going to use that. We're going to feed that into our concepts. To address your point about the more dynamic element of it and variables and things changing, I think absolutely that's something that we always look to do with our effects. I've talked in the past about emitter strength, so particles have a strength curve, and, Leo can probably elaborate on this, but we can actually use that strength curve to map that to other variables. Let's just say the quantum drive was getting damaged. We could actually visually reflect that. We could show a much more chaotic-looking effect. There's all kinds of things that we could do with that and that we would like to do as well.
There's also some possibilities of using the SDF tech. When I was exploring the look of the atmo entry, I also tried it with what a QT effect might look like. There's a lot of possibilities and a lot of really cool dynamic things we could do with it.
From a tech point of view, it was a while ago that we implemented the QT effects. And one of the limitations we have right now is that the effects are set up on the ships. So if you change your quantum drive, the effects will remain the same. One of the things I'd like to do at some point is make it so that we don't have those limitations anymore. So with a few changes to the system in the back end, we could actually implement per-drive effects rather than per-ship effects, which I think is also one of the things that people have been mentioning.
So somebody could take the quantum drive from an alien ship, like the Scout has a very different quantum effect, and bring it over to a MISC ship or an Aegis ship and put it in there and get the change in effect?
Something we'd like to pursue, absolutely. You mentioned the different styles as well. Obviously, the most common one is the default, as we call it, the streaky blue one. But yeah, we've got different visual styles for different alien races. And we've always talked about having high- and low-tech variables as well. So maybe a cheaper drive would look different. It's a bit like putting a nasty old big exhaust pipe on your car compared to something high end. We'd like to be able to reflect that visually as well.
TL;DRMeteor showers are technically possible and look good on the VFX side, but spawning meteors believably and handling gameplay implications for players who fly to them is a hard unresolved problem.
Well, I have tested this, and on the VFX side it is obviously completely possible. It would just depend on the design requirements, perhaps story elements in Squadron, things like that. But on our side, it's possible, and it looks pretty cool.
I imagine it's one of those things that's easy to make look cool from a distance, but then you have to figure out the gameplay implications of what if somebody goes to that meteor shower and flies to it. Now it's more than just looking cool. Now there have to be gameplay implications to it, and that's a much more complicated conversation.
Yeah. In a normal game, you can use meteor showers as a backdrop. For us, how do you spawn a meteorite in the sky? Where does it come from? Will it just pop into existence?
I mean, that's a great point, Leo. That's the challenge. That thing's got to come from somewhere at some point. Where? Is it hidden behind something? Is it in a gas cloud? Is it hidden? There's always a possibility that someone could be at that place where the thing spawns. Yeah, that's quite a unique challenge to our game.
NPCs in games have monster closets. Are there such things as meteor closets where they can spawn and come from? And again, they have to be visible from every angle, because you can't control where the player is going to be when they see it.
If you want to see how it looks, just get a couple of friends to all come down at more or less the same time at the same speed on a planet. And then that's kind of how it would look.
TL;DRThe speakers name environment effects, gun-barrel smoke (tricky lighting and particle limits) and atmospheric entry (hard to time spawning realistically) as the most problematic effects.
I think for me, you probably sympathize with this, Teo, but I think for me, one of the problem effects is smoke from the barrel of a gun, which sounds like a really simple thing to do, but that's really, really tricky to get looking good. Two reasons. One is the lighting model of our particle system at the moment; it's not fully PBR, so it's not quite accurate in real-world terms. So again, with our game, you have to make sure that your effect looks right in daylight, you have to make sure it looks right at nighttime, up in space where the glare of the sun is intense. So what we end up doing is, you want a nice subtle smoke emission from the barrel, and you always get this from the artists and designers working on weapons, because you just get a little bit of smoke coming out the barrel. And the problem is that you do that and it looks great, but then you see someone firing it in space and it's super bright. It's like, oh God, it looks really bad. So now I've got to tone it right down. And then I've toned it right down, so then I get people saying, no, I can't see any smoke coming out of my gun. So it's really tricky in that sense. And also another side of that, I'm sorry, I don't know if this is boring or interesting, but another one is the fact that you can move around really quickly. Obviously we can't spawn too many particles; even with the GPU system, we can't spawn too many. So you get this problem where, if the smoke is emitting from the gun while the player's moving it around, you just get these little blobs of smoke, and that kind of breaks the immersion. That doesn't really look good. So just a really minor type of effect, I guess, in the scheme of things, but that's a really tricky one. That always causes me headaches.
The past year, I think atmospheric entry has been kind of a headache as well, just in the sense that we had some trouble figuring out when to spawn the effects. Our ships don't really fly fast enough to physically accurately spawn the effect when it should happen, like in real life. So we have to kind of fake it, because it's a really cool effect. But yeah, we've had a lot of back and forth between different teams about what we can do to change the experience or change the calculations. For me, I guess it's a bit more from a technical point of view, not really visual.
TL;DRThe hull heat glow is still planned and not off the table, but it needs graphics and ship team time, no commitment on when, and a more generic glow shader is being requested that fire propagation will also need.
Before you answer, I wasn't going to mention it, but one of the things that is difficult, based on the previous answer, is making sure the reason for the effect is understood and seen, and on the atmospheric entry effect that Leo and I worked on, that glow is a big part of that.
Well, I mean, it is still planned. That's the short answer. We did indeed do it and we showed it. We haven't taken it off the table. We're definitely planning on doing it when we can. The issue there is that, again, I'm probably just going to be repeating myself a lot, but it's the collaboration. It's not something that we as a VFX team can implement. We need to get time from the graphics team, so Ali and his team, to actually work on the shader itself. We then need to collaborate with the ship people. So you mentioned John Crew. So John's been in conversations about this. It's just getting everyone together at the same time to make sure that all priorities are aligned to actually be able to do that. So definitely still planned. I can't commit to when, but it's certainly on the table. And we're also going to be needing something similar for the fire propagation as well.
Yeah. So the reason why it didn't really work was that we have the glow on the ship itself with the damage map. So if you shoot the ship, you get the glowing. So we could use that for making the ship glow, but all the items attached, such as the landing gear, the glass, even the doors, they didn't glow with it. And basically, we need the same kind of glow tech on all those other objects. So one of the things we're requesting now from the graphics team is a more generic glow shader, so that we can use that same shader on the material for fire. So if an object is hot enough for it to glow, then we can use that same kind of system to make an object glow. So it's probably going to be a while, but it's going to be something used for different systems as well, which is nice.
TL;DRA prototype demo shows fire based on voxels with physical material properties, spreading through radiation, convection and damage, with extinguishing via heat, oxygen and fuel, while static objects are averaged per voxel for performance and visuals are all temporary.
We prepared a little demo for the fire propagation, so I can go through the demo and answer some of those. So we've got everyone's favorite ship, the 600i. Maybe not. We're going to set it on fire. So we are going to base our fire on voxels, so you can see the squares. I can put a debug on with this. I don't know if you can see the green edges, but those are all voxels with material properties. So in those voxels we are going to bake the environment, and in the environment we have material properties. So for example, plastic, the material properties... this is all prototype work, so nothing is final. A lot of tweaking and balancing and setup still needs to be done for all of this to be implemented. But for now, this for example says plastic, so in plastic we have all of these properties which will affect fire. In here we have wood dense and plastic combined. Here we have fabric as well. So all of these have these kind of properties. They're physically based. So we're going to start with a physically based propagation system and see how far we can get with that. And then we have an entity as well. What's the difference between an entity and a voxel? Basically, a lot of the environment in our game is static. It will never move, and we have a lot of those kind of static objects, and it's mainly for performance reasons. We can't keep track of the fire state in all of those objects. For example, here in this voxel, we have all of these dirty pillows. We can't set each pillow separately on fire. So we kind of average out all of these properties inside a voxel. So for example, if I turn the physics on, you'll see that the stool was falling, because it's a dynamic entity and it can move in game, while the plant pots will remain hovering over the table because they're static. They do have static physics, but they don't have any dynamic physics or anything. So we can be sure they will always be in the same place. So we can set these voxels on fire, and we have different effects as well. So if I set this voxel on fire, we'll have the generic effect that most materials will have. But for example, this one has fabric, which is a different material and a different effect as well. So we'll have more low effects compared to the high flames from the generic one.
Yeah, definitely. All the visuals you see here are temporary for the prototype. They're definitely not final. We've also got this one, that's the vegetation. I don't know if it's very well visible with the quality of the stream, but this one has ash floating up from the flames. So you can see the ash. We can also do electrical fires and whatever. And in the meantime, you see that this fire is getting out of control. It's burning around. It's spreading around. We also have a fog volume. So you see that the room is getting a bit foggy because of all the smoke being released by the fire. This is something we'll also add. This will be based on the atmosphere of your room. So if there's lots of smoke or toxic gases, your room will start fogging up to add to the visuals. How do we propagate? We've got some quite fast propagation here in this area. We have a few ways of propagating the fire. So the first one is radiation. Radiation is basically your object shooting rays of energy to nearby objects. So it will heat up by radiation. This is not the most effective way of heating up an object, but it's simulated anyway.
Yes, exactly. Good point. We also have convection. This is basically the way you heat up the air and the air starts moving around in your room. We won't do full fluid simulation for this, but we will try and add gravity in there, so that if you have low gravity, then the convection won't be as strong, while if you have high gravity, then there will be more convection. We'll also try to model in wind, so that the wind direction affects the propagation of your fire.
This is important actually for visuals, sorry to cut you off there, because the particles will follow forces like wind and gravity, so you would expect flames going up a wall, for example, to then have more of the voxels above them catch fire.
Yes. For example, if we set a voxel on fire near a wall, then there should be more propagation upwards rather than around it. And the last type of propagation is damage. So if we heat up an object, and this will be based on the material type as well, so not all material types will do this kind of behavior, it is possible for that object to have a chance to ignite when it receives damage. And this allows us to model a more random fire behavior, while the convection and the radiation are really deterministic. It's always the same. It will go up with gravity, with a certain wind direction. The radiation, based on the strength, will always just go around. So the damage gives a little bit of randomness. And then there was one more thing I wanted to show here, with the entities and voxels. So for example, if I set this voxel on fire and I move this static brush, the fire doesn't move, because everything is baked into this voxel. While if I set this dynamic entity on fire, we can move it and the fire will move with it. And what this means is that you can set fire around here just because this stool is on fire.
It's really cool to play around with, to be honest. I've got some more, if we have time. A rolling barrel. Keeping the best for last. If we ignite it and we enable physics, the barrel will start rolling. And we can keep track... So if we track this voxel, then we can track the temperature of this voxel. And if it goes above the yellow line, it will go into the smoke temperature, so it will start smoking, and that means that the voxel can also start to catch fire. So in here you see it just spiked up; that's because it went into the fire range of the temperature, and this voxel caught on fire, basically. And we have this for all these voxels around it. So the temperature will go up, they will start smoking. And when is this important? It's going to be important if we want to start extinguishing. Our extinguisher is not working very well, but we've got a debug extinguishing feature which we can use. Let's speed this up a little bit so I can speed up the propagation. And then I can start extinguishing, and hopefully you'll see the fire die down where I extinguished. So basically what you need to do is make sure that there is no more smoke anywhere. Extinguishing works in a few different ways as well. Because we go physically based, we can use the fire triangle, which is used by firefighters: fuel, heat and oxygen. So basically what we do is we take away the heat inside this debug sphere that you see here, and we also take away the oxygen, so that the fire dies down. And then by taking away the heat, we are able to make the temperature go below the smoke temperature, and that will make sure it won't be able to reignite and catch fire. We also track fuel, so if that specific voxel or object doesn't have any mass left to burn, it will die down on its own. And of course, later down the line, if we decompress a ship, then your fire will be gone as well. So yeah, I guess this is my demo, completely running out of control.
TL;DRIn zero-G fire propagation mainly differs because convection has no pushing force, but the visuals are hard because gases behave differently, and that is next on the effects artist's list to look at.
I explained a little bit how convection will play into it, which is the only way zero-G will affect fire and propagation, but Teo will explain a little bit about the visuals, I guess.
Yeah, I mean, in terms of propagation, it makes sense, right? In zero-G there's nothing pushing the fire up or sideways with wind or anything like that, so it radiates everything. The difficulty with zero-G fire is obviously the visuals, because gases behave differently in zero gravity. It's something I think about a lot. It keeps me up at night. It's next on the list for me to take a look at, along with different visual styles for surface types, for different types of fuel. That kind of plays into it almost, because it might need its own look.
TL;DRMike Snowdon says falling blossom leaves are both exciting and, half-jokingly, terrifying, since the art director wants a gentle-breeze feel in Orison, while tying leaf counts to particles was a joking idea and seasons would come at some undetermined later time.
For me, both. It's terrifying in the sense that it's more dynamic effects, but it's exciting because it's really nice having leaves falling from a tree and getting blown around by the wind. And Ian, the art director, wants Orison to have that kind of feel to it, like a gentle breeze. So yeah, I mean, it's exciting actually. I'm only really joking when I say it's terrifying. But I seem to vaguely remember, I think I half-jokingly said to Chris in one of the updates that if we knew the amount of leaves on a tree, we could directly drive the amount of leaf particles that fall from the tree. Leo's laughing already.
Yeah. All the leaves would have to grow back, otherwise we'd just end up with no leaves on the trees at some point in the game. So it's probably not the best idea I've had.
TL;DRYes, effects artists get blind to their own work, for example after an hour of tweaking fire, so they take breaks and rely on colleagues to point out what they no longer see.
Yes. For me, it's obviously not so much text or anything like that. It's more motion and intensity. A good example is when I'm working on the fire effects and tweaking values with different strengths on the actual fire effect. After about an hour, it's hard for me to distinguish between the changes I'm making. And that's just because it's like when you're sitting in the back of a car that's moving for a long time, and then you stop, and your vision continues to make you feel like you're moving. That definitely happens to me a lot. So it's important to take breaks, work on another type of effect, or even something completely different, and then come back to it. Otherwise, you just waste time making changes that don't make any sense.
I think that's where your colleagues come in useful as well. It's nice to show an effect that you've been staring at for so long. I might give Teo some feedback, or he might give me some feedback, or Leo, anyone in the team will point things out that you've just become blind to, because again, you've just been looking at it for so long.
TL;DRThe team treats performance as a top priority, making effects like fire and sandstorms run in frame and putting performance before visuals, while the shown fire effect is work in progress with the focus currently on lean tech.
Oh, that's a good one. That is a good question. Well, we've got to make it work. So the fire is probably a good example of that. Sandstorms are another example. We've got a clear brief on what it is we need to do. And it just so happens that the fire is very easily going to be a performance breaker. So we need smart people like Leo to help us out here, and Simon. We need to make sure that they are performant. I mean, this is game development. It's a core principle for everyone in every department. You've got to be able to make sure that it runs in frame. It's got to be optimal. Maybe you make some compromises for that, but you've got to make sure that the compromises aren't to the detriment of the visual quality.
I was going to say this makes a big difference to me when working on impact effects, for example. Visually, I could throw tons and tons of particles with smoke and make it look really cool when a mass driver hits snow, which I've prototyped before and worked on. But you do feel that lag come in when you have an impact or fire a weapon, and that's just a no-no for me. It drives me crazy when I'm playing any other game. It's something where I will put performance before visuals, and try to get as much visuals out of the performance as possible.
It's worth noting that in the fire demo we saw today, and in all the footage we've seen in previous ones, that is a very WIP effect for the fire itself. The work right now is on the tech and making sure the tech is lean and mean and functions the way it should. And then once all that's done, somebody will go in and start working on the actual fire effect itself.
Yeah, for sure. I mean, Simon and Leo did great things with the sandstorms, by the way. That was a huge undertaking. There's a lot of effects going on on the screen, and given what they're doing, the performance is actually really good on them. So yeah, Teo's absolutely right. We've got to make sure that the gameplay experience is top priority there.