VFX developers discuss the new shield effects built on signed distance fields, fire propagation using voxels (demoed on the 600i), gas clouds, weather, re-entry heat glow, missile and thruster effects, and quantum travel visual fatigue. They also cover Vulkan, space dust, and performance.
TL;DRShield VFX is going well and pre-production is nearly finished, so they are about to move into production, where the effects actually get made and put into the game.
It's been progressing steadily, really. It's going well, I would say. We've recently, I guess, come to the end of what we call the pre-production side of it. We've recently started to invest more time in concepting these kind of effects where there's not really any real-world reference. So we've got a guy on our team who does the concepts for the effects, and it's fantastic to have that. So that side of it's done. We've had Simon, our lead VFX programmer, working closely with Caleb, our principal VFX artist, on the pre-production, so actual in-engine, code side of things, shaders, looking at the graphics options we've got. Kind of slightly wackier ideas as well, stuff that's not necessarily in the concepts, the kind of ideas that come when you see this kind of thing. So I would say we're pretty much close to wrapping up the pre-production, which means that we're going straight into the production phase, which is what people care about, because that's where we actually start to make the effects a reality and put them into the game. So, going well.
TL;DRYes, largely: the effects were always meant to be driven by signed distance fields, which depended on upstream vehicle and physics work, though that wasn't really the reason for any delay.
Yeah, very much so. So we knew from quite an early stage, really. I know that the backers have been aware of this for a long time, that the SDF, the signed distance field, we knew that we were going to be using them to generate these effects and to have the effects kind of driven by the SDFs. So we knew there was a lot of work that was upstream. We sort of use the terms upstream and downstream. We're one of those teams that are downstream from other teams. So we knew there was a lot of work that was going on with the vehicle teams and the physics teams that was necessary in order for these SDFs to become a reality. So yeah, that was a large part of it. That was not really why anything was delayed, but that was what we needed to be able to have in for us to do our thing as well.
TL;DRNo, creating the clouds belongs to core engineering; VFX comes in afterward for things like rain, lightning, and the player's interaction with the cloud, collaborating with that team.
No. Well, the actual creation of the clouds is not our domain. The work that we do, similar to what I've just said, the work that we do will come in when those clouds are... they're kind of the domain of the core engineering team, really. Once that side of things is there, then that's where we come in and we'll start to care about the rain that comes from the clouds, the lightning and all them kind of things, and probably the interaction of the player within that cloud as well. That will probably be something that certainly Leo would be involved with, I think. But the actual creation, the physical creation of that cloud, is not our domain, no.
So it's like props on a set dressing. Another team will create the tech, and then you guys will come in and dress it up and make it look the way it should.
Yeah. I mean, we're involved in the process. We collaborate with the people who are actually implementing the tech. So I've got good visibility on what it is that we're doing for it. But yeah, we don't actually make the thing.
TL;DRWeather VFX depends on the clouds arriving, then they expect rain and want localized weather like storms, tornadoes, dust devils, lightning and snow, with visuals matching gameplay effects.
Well, yeah, so it kind of does depend on what we've just spoken about with the clouds themselves. Anything that you imagine would be happening is going to happen, so we're going to have rain. We need to have that. One thing that I'm more interested in or more excited by is more localized types of weather. So storms, tornadoes, whirlwinds, little dust devils, those kind of things. That's the kind of VFX that I look forward to, because it's the whole collaboration of the whole team. So again, it's the VFX programmers, and it's the gameplay implications, and it's the visuals that we have to provide to show those gameplay implications, so the player can see that if they go towards a tornado, which you probably shouldn't do, but I'm sure that people would enjoy doing that in a game, to see that the visuals match what is going to happen to the actual ship, or the player if they're not in the ship. But yeah, lightning storms as well, snow. Just anything you can think of, like weather. If you can think of it as weather, then it's a pretty good guess that we're going to be wanting to implement it in the game when we get the clouds.
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;DRVulkan shouldn't fundamentally change how the VFX artists work, though programmers will need significant time for it, and the expected performance gains could allow more particles and better features.
Well, for me, I mean, again, Leo, you can probably provide a more technical answer to this. But for me, in theory, aside from the fact that there's time out of the schedule for the programmers to do their work, it won't really make a huge difference to the likes of me and Teo. We'll get big performance benefits in the game from it. So I guess we can throw more particles at things, which is always a good thing for me. But yeah, it's not going to make a fundamental change to how we work or anything like that.
Yeah, for me personally at least, I think it won't make much of a big difference, because it's not really the code I work in that much. It's more Simon, our lead, who will be doing most of the work there. But yeah, it will be quite a big chunk of time to get it all working and tested. And yeah, it's quite exciting, because I think it will allow for some more particles and better features.
TL;DRGas clouds are going well and the tech is in a solid state, with testing now focused on breaking it in crowded dogfights and on tying up loose ends like designer-controlled variants before they feel confident putting it in.
They're coming along well. I mean, I guess it's similar to the shields topic. It's long been talked about and shown, and our very patient backers will have seen lots and lots of updates on the gas clouds. We still have weekly syncs with all the people that are involved in it. I would say it's going well. Earlier on with the gas cloud work, we were more focused on Squadron in particular, but more recently, at least this year, we've been discussing options with the PU team as well. There's lots of nice-looking gas clouds for Lagrange points. The actual tech itself, again, that's more of a graphics thing, and the tech itself, the gas clouds, that's pretty much all in a good state and looking pretty solid. We've started to do a lot more thorough testing in terms of: let's get a gas cloud in an area, let's get loads of ships in there, let's have dogfights, let's get bigger ships in there, and let's really try and break this thing. There's lots of work that comes from that, just more boring stuff, like bug fixes and lots of things that we didn't really anticipate previously. From our point of view, things like the different space loop effects. We want to have themes to the gas cloud. So we want a designer to be able to take a gas cloud that the artist has made, and if you placed that same gas cloud five times in a row, be able to change all the properties so that it actually looks and behaves in a different way, and the experience inside is different in each of those variants of that same thing. So all those kind of loose ends that we're trying to tie up, I guess. We want to make sure design is as far ahead as they are, so the whole thing syncs, and then that's when we're going to feel confident about putting it in there and letting people see it for themselves.
TL;DRYes, explosions should knock players sideways and make them stumble, this is planned with much of the work far ahead, and force reactions should be shown in an upcoming update depending on when the visuals are ready.
100% yes. Yeah, absolutely. Again, I guess the physics team and, I forget the name of the team, but Rich Tyrer, everyone will be familiar with Rich Tyrer.
Yep. So there's a lot of work that those guys have been doing, and I'm sure we've been showing it and updating the backers about it, regarding physical reactions, impulses. So yeah, an explosion should... say someone fires a grenade from a grenade launcher, I'm looking at Teo, and that explosion happens over there. Absolutely, it should knock the player sideways and make them stumble, and that's all planned, and a lot of that work is very far ahead as well.
They'll actually see that on ISC in about two or three weeks, depending on B-roll availability. You're talking about force reactions and the ability of transferring those physics from the things that create them onto the players. And yes, coming later this month, maybe at the beginning of next month. It all depends on when the visuals are ready.
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 is not happy with the missile effects and intends to improve them, has already made tweaks, and is waiting on particle system improvements, alongside a wider missile overhaul by another team.
I'm not happy. No, I'm not happy with them. And I intend to improve them. I'm actually working on them myself at the moment. I guess in between official duties, I'm tweaking the effects. And I think I've shown in a couple of the update meetings that I've already got some improvements to them. Just things like making them last longer, so increasing the life, and that helps readability. Just making the flares more visible from a distance, pushing out the actual thrust effects themselves. Just minor tweaks, again, similar to the quantum travel conversation. The missile trails are a much older effect. Possibly some of the first I worked on back in the day. But yeah, long story short, definitely planning on improving them, and I've already done some work on it. We're also holding out for some VFX particle system improvements as well, like ribbons on the GPU system, for example, which will allow us to get a bit more efficient with the trails as well. So yeah, going to improve them, definitely.
And those will go along with other improvements to missiles in general being worked on by the Vehicle Experience team, because missiles in general are due for an overhaul. And you'll of course be hearing more about that as it continues on.
TL;DRMike Snowdon says falling leaves are both exciting and a bit terrifying, since the art director wants a gentle breeze feel in Orison, and seasons are only a joking future idea.
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;DRThruster effects are driven by ship data and keep improving, with the 100i thrusters just finished internally, and Mike Snowdon is now working on the Gladius thrusters, including visibility of maneuvering thrusters, though many older effects still need work.
Same kind of question, I guess. I mean, the answer's the same. Thruster effects were the thing I was most passionate about for a while when I joined CIG. The thing about VFX is, in the old days of being a VFX artist, there was this conception, and it was the case in earlier games, that the VFX artist just made a pretty-looking effect, like a flame, and they just placed it in the level or it came from a weapon. As you just saw with Leo's demonstration of fire propagation, there's a hell of a lot of data that drives the effects these days. I really liked thrusters because it was a similar kind of thing. It was fairly simple. The thrust input, so the actual value from the ship, was driving the strength curve of the particle. So you could do some really nice things with it. It's progressed over time. So as well as thrust input, and Leo was very much involved in the functionality side of this, we've got overheating, we've got damage, we've got misfires, we've got boost, we've got shock diamonds when you're in atmosphere, and you don't see them when you're not in atmosphere. There's a lot of ships in our game as well, so there's a lot of thrusters that need to get made. We're constantly improving the GPU particle system, so naturally some of the older effects don't look as good as other ones. We've actually just finished work on the 100i thrusters. We just showed that in a PU update.
Yeah, sorry, an internal team update. Chris loved them, and Ian commented as well. He thought they were the best ones we've done. I was really happy for Jacob, the artist who made them. So yeah, it's just one of them things where you've got so many moving parts. We can't really press the pause button on the machine, the beast that is Star Citizen. So we've just got to try and keep up, and we just need to find a bit of time to look at all of the effects collectively and work on improvements that we can do across the board. I have been doing that, again similar to the missiles. I've been working on the Gladius thruster effects. It's my favorite ship. Obviously, it's important for Squadron 42. So I've been looking at what I need to do to make the Gladius effects tick all the boxes. Chris has got really, really clear ideas on how they need to be improved, like general visibility, maneuvering thrusters in particular. I know that's a common thing that comes up, that maneuvering thrusters are a bit too small, you can't see them, maybe we're being a bit too aggressive with the LODing of them. So lots of work is being done on that. I'm personally involved. So yeah, make them better. We'll try.
Yes. We used to have them, exactly, Jared. We used to have them on the CPU particle system. Again, we've moved all of our planet effects to the GPU, but we didn't have refraction there. So a refraction particle getting that heatwave look wasn't available to us. So once we get that on the GPU, then we can put the shimmer back in.
TL;DRThere are no plans to add an option to remove space dust, since it physically exists and gives a sense of motion, though it is being tweaked to be less intrusive and an AR version has been discussed.
Yeah, I see that a lot, and I understand that it's not to everyone's taste. We're not planning on removing it, just because it physically exists in our space, in our game. It's physically there. It's not an AR thing, because I know there's been conversations about, hang on, what is the purpose of the space dust? I know that it's primarily to make it feel like you can see that you're moving, basically. It gives you that parallax. You take the space dust out, you've got no sense that you're moving. And I know that there'll be some people who want the more realistic side of it, who don't care that they can't see any kind of visual cue. There's been talk of putting it onto an AR, so it's a deliberately artificial space dust kind of thing that helps with that. We did some tests quite a while ago on that sort of thing. Chris is quite keen on keeping the space dust in. One thing I will say is, again, something that I've been doing personally, I've been tweaking the values. It's not the most glamorous of effects, but I've just been looking at maybe not making the streaks quite as big, maybe reducing the amount or increasing the amount, depending on the location. So really just chipping away at that and trying to make them not too intrusive, but so that you still get the benefit of getting that motion.
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.