It's a lot about trying to teach people how things affect each other. Basically sharing the knowledge, that's the best way to tackle these kinds of problems. And another part is then offering tools. One of the things that we need to do is take care of the budget, but if people can't see how they affect the budgets, they can't do anything about it. On our side, how do we handle that? We provide tools for artists to actually check themselves. What does your effect actually do? What effect does it have on the performance? So it's those tools, together with actually telling people what it means when this tool shows this or that, that helps artists to better understand and to better optimize for the game.
TL;DRThe overdraw previewer is a toggleable heat map showing how stacked, transparent particles hurt performance, so artists can spot hidden wasted effects and dial back; a graphics programmer's side project that the VFX team now maintains.
Basically, with particles there's a high transparency cost to them, because there's opacity or there's lack of opacity, and that incurs a cost. That's the transparency cost, but there's also the overdraw aspect of it, and Leo will explain it in a more concise way, but for me it's basically: we can quickly blow the budget, we can really hit the frames per second with our transparency costs if we get too carried away with adding particle after particle. So it's how they all stack up over each other. And the overdraw preview basically just shows a heat map. It's a toggle and it just draws the screen as a heat map. And it's got a guide showing you basically if it gets to this color, it's too high, so the overdraw cost is too high. You're wasting particles that can't be seen because there's something else in front of it. It's great. You just toggle it on and off. You can see, 'Oh, wow, great. I can't really see many effects on the screen right now. There's maybe some subtle dust scrolling,' but you stick it into the overdraw preview mode and it's fully white, and that's just too expensive and we need to dial that back.
Exactly. And like Leo says, the great skill that Leo and his guys have got is that they make our lives easier. They do as many things as they can to make our job easier, to help us stay within the limits of, again, the budget.
We try to. But for the overdraw visualizer, shout out to Alejandro. He's one of the graphics programmers; he did a side project and he basically gave it to us. We've taken it over and we'll maintain it. This is a nice collaboration again with the graphics guys.
Well, there's a massive crossover with graphics and VFX programming anyway. Don't want to sound too cheesy, but it's almost like the same family, isn't it? And you're a niche part of that department. So shout out to them.
Yeah, for sure. Well, it changes the way you create systems. Everything has to be systemic. It's a buzzword, but for Star Citizen, everything we do needs to be possible on all scales. If it's big enough, you can look at it from very far out, but then you also go inside, like you're inside a gas cloud or whatever. And then the whole scale, the travel from outside to inside, everything has to work, and it has to work from all angles. And it gives an interesting problem to solve for us. So we try to make as much as possible systemic, but then the Squadron guys come in and they ask, 'How do we control this?' That's the other side of your question. We need to provide some control over the systemic nature of the game.
TL;DRMike Snowdon and Leo Vansteenkiste thank the VFX team, saying who works on Star Citizen or Squadron 42 and some current tasks, while withholding most details as spoilers and a quantum travel item as not shareable yet.
I'll start with our producers. Without our producers, we couldn't get anything done. So Mark White, Colin Whiteley, this is for you guys. Thank you very much for producing us. And then we've got our senior VFX concept artist. And by the way, I know everyone. It's just hard to remember them all on live TV. So we've got Rob Lujan, who's our senior VFX concept artist. So Rob, you're awesome, so keep being awesome.
Okay, so that's that. And Rob's also doing loads of weapon stuff as well, so he's doing great work. Then we've got the senior VFX artists. I'm just going to go with first names. We've got Rory, we've got Karthik, we've got Ali, we've got Guillaume. These are all our senior group. Rory, Karthik and Guillaume are all working on Squadron 42. You're doing a fantastic job on that. You know you are. Ali's working on Star Citizen, because we've basically got half the artists on Star Citizen, half the artists on Squadron. I can't really go into much about what they're doing because it's all spoilers, but they're doing lots of locations, lots of destruction sequences, et cetera. And then we've got VFX Artist 3s, Ryad and Diego. Ryad's working on Star Citizen, doing some Lorville skyline improvements at the moment. And we've got Diego, who is Mr. Houdini, so Diego's doing loads of amazing stuff with destruction for Squadron 42. Again, can't go into too much detail. Then at VFX Artist 2, we've got Joyce. Joyce is actually on maternity leave. Joyce works on Star Citizen and does everything: ships, locations, feature work, weapons, all sorts of stuff. And then at VFX Artist 1 level, we've got Will Wallace, who's just come back from a career break travelling the world, and Will is on Star Citizen, doing great work at the moment with the MISC Hull C. And then we've got Enrico and Nicolás, and they're both on Squadron 42. So I can't really go into too much detail about what they're doing, but there's lots of cool location stuff. And then we've got Ricardo, who has just joined us this week and is working on Star Citizen. So he's just onboarding. We do an onboarding process that lasts a couple of weeks. It culminates with doing a weapon effect. So welcome to the team, Ricardo. It's great to have you. And we've actually got four interns. All the way from Sweden, we've got David, Kevin, Axel and Nazir. Two of them, Kevin and Axel, are working on Squadron 42, and David and Nazir are working on Star Citizen. Nazir's doing GPU conversions, David's working on the MISC Fury. And then we've got Jake, who is embedded QA. Jake just keeps us all right. Anything that's not working, he highlights it. He helps us debug problems. So Jake, you're doing great. And then I'm going to hand over to you for the programmers, Leo.
So we have Kiran and Francesco, VFX programmers, and Alexander Meyer, also one of the interns from Sweden. Kiran has been working on the quantum travel effects. Then Francesco has been working on fire hazard visuals. And then Alexander has been working on particle tools, so he's more of a tools programmer. External Ref, it's called, the project, but it's something to organize our particle libraries a little bit better. But I appreciate you guys as well.
We support the VFX team in features, tools, anything that we want to achieve, the nice visuals that VFX artists want to implement. There is quite a bit of bug fixing in there, but also feature developments. The features range from fire hazard to, currently we're also working on damage maps, which is a big project for the salvage feature. But there are quite a lot of features in the pipeline that are being planned out as well. And then in terms of tools, it's like the particle editor that Mike will be showing. We have quite an extensive particle system. And if there's anything new in there that artists want to achieve, then we kind of talk to them and try and implement their requests, I guess.
Yeah, and so it's basically the particles will follow the shape of the room. So the vector field has been created from the geometry in the room. And so anything that's in the room will kind of give a little bit of a sense of wind inside the room so that it doesn't just drop on everything. It will kind of flow away a little bit, which is a good use for this.
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;DRRain can only come after clouds are in, and it also needs a weather system using cloud density, pressure, temperature and humidity, plus wet-looking surfaces, so quite a few things remain before rain appears.
This kind of follows on from what I just said, I guess. So once we're in a position where the clouds are in and those hurdles have been overcome, then absolutely rain is going to be a consideration. Rain is going to come from clouds, so you can't do rain until you've got the clouds. Again, Leo, that's something we've chatted about recently, isn't it? Clouds that have rain, there's going to be other considerations other than just the markup of the actual cloud. But I remember you mentioning, we're going to need to understand that you're underneath the cloud for the markup for the rain, aren't you, as well?
Yeah. So for the clouds, we'll basically need to get access to the density of a cloud. From there, we'll have to write systems that are like, where are you compared to the clouds? Are you underneath clouds? Is it a rainy cloud? Not all clouds have rain. So we'll have to make a weather system as well that takes into consideration the pressure, temperature, the humidity. We have some basics already for that. But with clouds, it will get a lot more complex. And that's one of the things that we'll need for rain to appear. But another thing that we'll need is, rain isn't just raindrops falling. Everything needs to look wet as well. So our surfaces need to look wet. We do have the visor and the canopy shaders where raindrops appear on your visor. And that will help a lot with the feeling of rain. But there are still quite a few things that will need to be done before rain actually gets in.
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;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;DRYes, there are plans to bring the Daymar heat haze back, hooked up systemically to planetary data like temperature and possibly humidity; the effect is simple but needs reconnecting after planet tech changes.
Yes, there are. I want to make a bad joke about it being hot, not cool. But yeah, I think the actual effect itself is a fairly simple one, but I think as part of various amazing improvements to the planet tech itself, it kind of just got lost along the way, if I'm being completely honest. But yeah, the creation of the effect is dead straightforward. We just need to figure out the appropriate way to hook it back up again. And actually, it will be systemic, to use that word again, because it will be hooked up to the actual planetary data, the temperature itself, and probably the humidity, I guess, Leo. Does that play a part?
That's what I like about Leo. I ask for something and Leo goes and researches the actual real world criteria for something occurring. So then we get it all in the game.
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;DRFire is the feature they're most excited to work on, for its gameplay opportunities and cross-department impact, and it's currently being integrated with the rest of the game, which is surfacing situations and problems to solve.
Definitely fire for me. Fire, because it's terrifying, but it's also really exciting because of, not really even to do with the visuals, but just the gameplay opportunities that it brings and the sheer game-changing nature of it and how all departments at CIG need to come together to really take advantage of it. I'm pretty sure we've shown some videos from our updates showing the potential, showing the possibilities. Leo, obviously, you and Py in particular, but the VFX programmers are just creating some amazing setups. Do you want to talk about that?
Yeah, well, of course. It's the big project I'm currently working on, so it's the same answer for me. But yeah, it's quite nice. We've shown a demo and some videos on ISC, I think. But currently we're working on getting it working with the rest of the game. So before, we had a separate kind of prototype. And now that we're implementing it and integrating it with the rest of the game, there are some nice situations that already pop up, and problems to solve.
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.