The VFX team covers planned polish for the EMP and quantum travel effects, tractor beam redesign, engine and thruster visibility, and fire progress. They also discuss water interaction, gas cloud lightning and SDF trails, particle budgets and Pyro work.
TL;DRMike Snowdon agrees the EMP effect is a prime candidate for improvement and says it's on the list to be redone from scratch through the VFX concept pipeline, with no look or timing given.
Yes, absolutely. Thank you for saying they've aged gracefully. They are quite old. I would agree that they are definitely a prime candidate for an improvement, and especially because we have a lot of better options now with the toolset that we've got. We've massively expanded our GPU particle system since we did the EMP effect, and lots of effects actually as well. So yeah, absolutely, it is on the list to be updated.
Well, we'd have to go through the pipeline, wouldn't we, Jared? So we'd have to go through the VFX concepting process, work out what we can and can't do, work out if there's any kind of things that the designers need from it that the current version doesn't offer. And that's how we kind of define the look, really, just taking all that into consideration and concepting.
No, no. Starting again, really. To be honest, we didn't even have VFX concept back then when we did the EMP effects. So we would definitely go through that pipeline now.
So our position on that is that it's not a purely VFX overhaul or rework, it's actually the whole feature itself, including all the teams that that entails, so the game code, I guess the ship designers. So we know what we want to do. We've got some ideas about how we want to improve the visuals. Again, similar or the same answer to the EMP question: we've got a lot more cool tools now that we can use to make those effects a lot better. So once that's in the schedule, once everyone's aligned on that in the company, then that's when we'll jump ahead. Again, we'll concept that as well.
TL;DRLightning is generally more expensive overall than dust particles because of CPU costs for gameplay positioning, though screen-close sprite dust can cost more in overdraw, and the two are built very differently.
That's an interesting question. Do math? I can't. That's why I have VFX programmers. I just look at pictures. Definitely the lightning would on its own be more expensive than dust particles, but it depends on what cost we're looking at. If we're talking about dust motes, let's just say dust motes for argument's sake, the dust motes might be more expensive if we, for example, had a dust mote that's essentially a sprite. So it's a sprite-based particle that's right up to the screen that might actually incur more of an overdraw cost than the lightning bolt would. But really, the lightning bolt's always going to have a lot more cost associated with it. There's going to be CPU costs because we actually need to know the positioning of the lightning bolt for gameplay reasons, to be able to damage or interact with players and vehicles and things like that. So that would definitely be the most expensive overall. What was the other part of the question?
Yes, they are built very differently. Lightning effects are a kind of subset of the particle system. So without sharing my screen and showing the fundamental differences, it's probably a little bit difficult for me to describe it. But dust motes would be built in a much more simplistic way to the lightning, lightning regions we call them actually. So yeah, very different.
TL;DRMike Snowdon has no tractor beam video but says he isn't a fan of its current look and is working on the side on a better, refraction-based effect, which he pledges will look a lot better.
Do you know what? I'll maybe show the concept. Well, basically, the tractor beam itself, even the FPS one, we're going to be improving, because I'm going to give full disclosure, I'm not really a fan of the tractor beam as it looks. I think I'm allowed to say that, I hope I am, because I just have. I'm not a huge fan of it. We went through a few iterations with it, and just to be completely honest, it just didn't quite end up... it serves a purpose, and it's a really fun item, it's a fun actual game mechanic, but we know we can do better with the visuals. We've got some ideas on how we want to improve it. One thing that myself and Rob do, so Rob is my senior VFX concept artist, we work really closely together. There's lots of back and forth. We talk about ideas. He's a great guy for adding logic to ideas, so it's never purely visual. We're always trying to think of how and why it would work, and obviously within the parameters of making it fun and being in a sci-fi universe. But we looked at things like sonic waves and things like that for the tractor beam. And we've got a new GPU particle refraction option now, which we didn't have before. That's relatively new in our toolkit. So I'd been playing around with using a fully refractive beam effect, as it were. Sound patterns, sound waves, things like that. So it's a work in progress. It's something that I'm actually doing on the side, really. But it's going to look a lot better. That's my promise. That's my pledge.
SCL isn't the show where we normally show things. I put Mike on the spot there with the question. But if we don't get it today, I've got a Sprint Report in two weeks. I'll see if I can't fit it in there.
Well, we do plan to because we have done. So the size 10 bomb that we released a patch ago, two patches ago, that is physicalized. There were so many cool backer videos when we released that thing.
Ah, yes, we actually do. My bad. I can't really give hard details on that whole thing, but there's an expectation from Chris that water interaction is realistic and physical forces will actually displace the water. So that is definitely on the to-do list.
TL;DRYes, the team plans ship trailing in gas and planetary clouds, using signed distance fields and per-cloud-type effect templates that put mist or matter streaming across the hull.
Yes, there are. So ship trailing like in quantum, so all of the effect that we've got where it looks like the ship is displacing matter and causing a trail. Yeah, absolutely. That was one of the things that we... we've talked about signed distance fields probably a million times, and we use it a lot, or we plan to use it a lot more. And that's the kind of thing that the signed distance fields would allow us to do. When we're in gas clouds, when we're in planetary clouds as well, we have template effects that are spawned from the cloud data. I know that we said don't talk about clouds, that's another team. The actual creation of the clouds is being done by the art team and, on the code side, Karsten, as I think Ali might have mentioned actually in his Inside Star Citizen. But the VFX team work on the interior effects for gas clouds and clouds. So as part of that, we think of it like templates. Different types of clouds have a different set of effects, like a different template for the VFX inside it. And one of those categories of effects is mist or matter, depending on which kind of cloud you're in, going across the hull of the ship and creating trails for that reason. So yes, we plan to do that.
TL;DRThe bright, far-visible Gladius engines come from a still-in-testing minimum-pixel-size setting meant to aid readability; it isn't applied to all ships and may change depending on how design feels about it.
This is an interesting one. So the Gladius, I did some tests for... design were asking to be able to see them further away in the distance. As with anything in the game, we have to have LODs with our particle effects. And I think what was happening was the actual thruster items themselves were getting LODed out and the particles were getting LODed out. But from a point of view of readability for the player, that was problematic. So I did a test on the Gladius using min pixel distance. So I can force a particle to be a minimum amount of pixels on the screen, and that can force it to draw further away than it otherwise would do. It would otherwise be culled. So it's still in testing phase, I guess. It's not been propagated across all ships. It might need to be changed depending on how design feel about it longer term. So that's one of those examples where some of the ships have got this test applied to them, but not all the ships, because that wouldn't be practical to do. So hopefully that answers the question.
It's one of those things where, because we are operating a live environment in the middle of our development, we have the opportunity to do that kind of A/B testing and see how it works in a practical environment and see what the majority of folks say.
TL;DRSmall maneuvering thrusters limit how big their effects can look, since effects follow the physical item, but the VFX team can ask the ship makers to enlarge thrusters to allow a more powerful-looking effect.
I can give a bit more about that question because I've seen a few questions on this. I know it's a talking point and has been discussed before, but some of the maneuvering thrusters are quite physically small, so the actual effects themselves probably don't convey the amount of power that that maneuvering thruster is putting out to keep the ship afloat when they're on places with gravity. One of the problems we've got is that we take our cues from the physical [item]. So if the item itself is quite small, it's difficult for us to... if we oversize the actual effect, that's going to look weird. That's probably not the intention of the people who created the look of the ship in the first place. So we have to find that balance, and there's a bit of back and forth. We do have the ability to discuss that with the people making the ship. So if we look at the ship and go, you know what, this would probably be better if we could make the maneuvering thrusters just that little bit bigger, that would give us a bit more scope to create a more powerful-looking effect, then that conversation does happen.
TL;DRFire work has continued the whole time, mostly code and back-end integration with room, player, AI, pressure and warning systems, and the team says it is quite far along with that.
I've got some notes written down for fire, because obviously there were a lot of questions about fire, and understandably. It's quite a big feature and it's quite exciting and there will be big gameplay implications. So we haven't stopped working on it at all. We've continued to work on it. Since the last time we spoke about it, we've been actively working on fire the whole time. But when I say we, it's been mostly code. So it's been Leo, our principal VFX programmer, who I always ask to do these things, by the way, but he was away today. He was on PTO. So even before I got a chance to ask, he was like, "Before you ask, I'm on PTO." But he very kindly wrote some notes down for me. A lot of the work that Leo is doing now, and has been doing in that timeframe where you've not really seen much on Inside Star Citizen, is just because it's the less glamorous side of it. So it's more in the back end. He's written here: "We're still working on getting fire integrated with different systems. We're quite far along with that work." And what he means by that is making sure it works correctly with the room system, making sure it's going to work correctly with the player, with characters, with the AI and things like that. So making sure it's robust and actually triggers all the things that it should trigger: room pressure, warning systems, all that kind of thing. And much more complex stuff that I probably don't even understand as well.
Yeah, absolutely. It goes back to what we were talking about with bombs, actually displacing the water. We see it all as the same thing. We basically need to be able to have water bodies, water volumes that can be interacted with, that can be displaced. And the ship wakes or the vehicle wakes is probably one of the easier parts of that. But that's absolutely the plan.
TL;DRDust settling on helmet visors is definitely planned, tied to the existing visor-layer work, but it is complex and needs coordination with other teams, such as character artists.
Yeah, we are. I was going to say, we are planning to do that. Have we got some of that in? We definitely plan on doing that. That all ties into the work that we did, I guess, in 2019 now, with getting the frost and slush and rain onto the visor. It's all the same type of work, where it's tied in with how we get all the visual layers onto that visor and how we get them to play together. So it's definitely planned, but there are quite a lot of complexities with it. One thing, I don't know if this is relevant, but when we brought out the tank, I think... did we show this? We like the idea of a physicalized shockwave being able to displace dust from the surface of characters and vehicles. But conversely, we like the idea of being able to put dust on players from nearby impacts and things like that. So all of that is definitely planned and very doable. We just need to coordinate with the other teams again. It's a similar kind of thing where we need to just work out where the roles are; we don't want to put the character artists under pressure to have extra UV maps and stuff on the visors. But I love that kind of thing. They're the kind of effects that I really enjoy, that very interactive, immersive type of effect, dynamic.
We have, and we are. We're actually working on them right now. Caleb, our principal VFX artist, just yesterday in fact, I was on a call with him where he showed me, because he's in Frankfurt. He started doing a new simulation in FumeFX to have more interesting waterfall visuals. So we're actively working on that, and it's looking pretty nice.
Because we've got a great team, and we've also got great leadership who push us to and allow us to really go above and beyond to create high-quality effects. And for that, I am very grateful.
Yeah. This is something that I was actually talking to my leads about the other day, and something I talk to Ali, Ali Brown, about often. Min/max settings, dynamic scalability to the particles, things like that. That's something that usually comes in once you've got the toolset locked down more, so there's no more feature requests for the particle system itself. That's when we then start to look at making that toolkit, or that particle system, more dynamically scalable, more robust. You need to look at where we claw back that FPS, or where we're actually using up that FPS, and we start to look at it. We've got some really nice profiling tools actually with the particle system. But absolutely, we want to do that. We don't just want to fry people's graphics cards, which we don't do, by the way.
Definitely the outfits and the characters need to have that wetness. So that, again, will be something that I'd be talking to Ali Brown about, and we'd be working with all the people working on characters as well. Would they drip? I don't know if we've got as far as actually dripping. If I had my arm up, would it drip off me?
So I'm being a little bit cheeky by answering this one, because it's technically not something that my team will be in charge of in terms of how that looks. But I do know that we're basically planning on it to not look pristine. So say there was a logo or decal on your wing and you were repairing that wing, that decal wouldn't come back again. I don't know exactly, but it definitely would not look pristine, because that wouldn't really make sense, would it? How does that painted logo come back on? But that's just me as a VFX artist saying what I think I know.
TL;DRParticle budgets do shift, for example when moving from CPU to GPU particles, and because the number of ships nearby is unbounded, the engine needs some dynamic scaling rather than fixed budgets set at authoring time.
The budgets do change. The weird thing when working on this game is people get better quality graphics cards. So it's very much tied to the hardware that you've got. But budgets do shift around. I'll try and give a more specific example. An example of the budget changing would be if we were using CPU particles, like the old particle system that we had, we would not be able to use as many individual particles. So we'd have a low count limitation compared to using the GPU particles. So absolutely, once upon a time when we only had CPU particles, the budget was a lot, lot lower. And once we moved towards GPU, the budget was higher, because it wasn't that we were taking a portion of the budget, but the count limit was much less limited for us. So the budget does shift around. It's weird when you're making a game as big as ours as well. It's really hard. It's not finite. You can't just be given a budget from Ali Brown; he can't just go, "You can only use this portion of the budget on this very specific thing," because you've got no limitation on how many ships could be in the vicinity as well. So you might work towards a budget for an individual effect, say the Gladius maneuvering thruster. But if there's 10, 20 Gladiuses, then that budget has shifted drastically. And actually this ties in with the question about having dynamic scalability to the particle system. That's the kind of thing where we need it to be dynamic. We can't really make those decisions when we're authoring the effects. There's got to be some kind of dynamic element to the engine itself, how it's deciding what to draw and what not to draw, without killing what it looks like to the player.
For those who maybe haven't been watching the programs for as long as we've been making them, almost a decade now: when we talk about cost and budget and stuff like this, this is a resource allocation thing in the computer. Everything you ask your computer to do slows it down, just a little tick. So we always have to balance where we spend those resources. It's not a money thing.
TL;DRThe team optimizes as it goes, keeping rough budgets in mind so effects don't look worse later, and then does a final, fuller optimization pass near the end.
Basically, I guess they're asking, do you work on optimizations as you go, or is this something that you wait for at the end? Some things you have to wait for at the end. Some things you can optimize as you go. Some things, if you try to optimize as you go, you're just repeating work over and over again and it's not very effective. What's your case?
That's actually a really good question. So we optimize as we go. We have to do that to an extent, and I'll give you a reason why. Say I was working on the tractor beam and I was using a count of a million particles for a relatively short effect. It might look great. People might look at it and go, yeah, that looks fantastic. Show Chris, show the designers, et cetera. And they're like, yeah, that's definitely what we're looking for, we're really happy with that, thank you, that's great. And then I actually optimize it to the point where I couldn't really use a million particles, I could only use a thousand, and it doesn't look like it did anymore for that reason. Then that's a bad thing. You have to factor in rough budgets while you're making the thing, all the way through the lifetime of working on it. Otherwise, you're just setting unrealistic expectations. So it's somewhere in the middle. You've always got it in your mind. You're always being sensible. But you do still need to have the freedom to get the effect looking as good as you know it needs to be, or you know it can be. And then once you have done that, that's when you will typically do, in a more linear fashion through a pipeline, a more full and final optimization pass. There's all kinds of things, like can you make the particles deterministic instead of non-deterministic, which will be an incremental saving, things like that. So you're somewhere in the middle. You're always thinking of the budget while you're working on the effect, and you will do a final optimization pass towards the end.
TL;DRMike Snowdon says Star Citizen doesn't want players gaining a competitive advantage by lowering graphics settings, and he dislikes forcing effects off, though he understands why competitive players do it.
I think we don't want to give players competitive advantages by reducing graphics options. I don't think that's the ethos of Star Citizen. From my point of view as a VFX artist, I hate the idea that the competitive gamers just won't ever have the effects on the screen. So we need to find the balance. We obviously don't want to be crushing people's performance, but I wouldn't like the idea that we're forcing people to hide the effects. I just think that's not really in the spirit of the game we're making.
We used to do stuff like that back in the old Battlefield 1942 and Tribes 2 days. You used to be able to reduce the graphics to the point where you were basically playing on LOD 5, and so the player characters really stood out from the background.
Don't get me wrong, I'm all for giving yourself a competitive advantage where you can take it. I used to play Counter-Strike 1.6 and I had drawn a dot in the middle of my screen. Not that it did me much good; I was never that good at it. I understand where people are coming from with that.
TL;DRSalvage hazards like hitting a fuel line are a design decision that he can't confirm, but he says it's under discussion and VFX could spawn effects from such situations, though marking up hull pipes would be tricky.
So this is ultimately a design decision, so I'm just going to speculate. And this is really just me thinking about this from a point of view of: if that was a requirement, how would we deal with it from the VFX point of view? I know it's been discussed. I know I've heard people talking about this in various conversations we've had not too long ago. It's how do you mark it up, I think, is the thing there. It's how complex does it need to be? I know that there's certain ships with the damage shader where, once you've stripped away the top layer of the hull... and you can do that just when you shoot the ships with the damage shader as it is, but that's similar to what salvaging might be... there are lots of pipes just in the art itself, so in the shader. That would be quite tricky to mark up, I think, from a point of view of having that pipe have gameplay implications. Personally, I think that it would make sense to go that detailed with it. But I think with the risk-versus-reward element of salvage gameplay, there's probably going to be things like that. Again, I can't clarify too much because it's a design question, but I know that that's in the mix. I know that's in the discussion. And if that needs to be done, there's ways that we can have our effects spawn from those situations.
TL;DRHeat haze existed in the old planet effects but refraction is expensive; a new, potentially cheaper GPU refraction will be needed for fire's heat haze, so it could spread to wider uses once solved there.
You know, the funny thing is we actually used to have that. We had a heat haze with the old planet effects, and I'm sure there'll be people who remember, and I think this has been called out by some backers as not being in the new effects. But again, we've got a new GPU... refraction is really expensive, that's what I should say. That's a really expensive overdraw; transparency, sorting, they're real big thorny issues when you're working on VFX, just in game engines in general, to be fair. So that could quickly become very expensive, but we do have a better, potentially cheaper GPU refraction now. And let's be honest, we're going to need to have that hazy heat effect for fire anyway. So I think it's feasible that once we've solved it for that, we can start to look at it propagating in more general circumstances.
TL;DRNo underwater effects are scheduled yet; Mike Snowdon says the aim is realistic, dynamic effects like displaced silt and misty water, using gas-cloud-style templates, but he isn't committing to anything immediate.
Obviously, rivers are very exciting for the backers and for the people at CIG. There's loads of potential once we get them propagating across all these locations. When we get to do the effects side of it, because obviously, as you know, the first iteration doesn't have effects in it, we're probably going to want all of that, aren't we? Basically, my stance whenever people ask me about these kinds of things, what will you be trying to do, it's always: well, we'll try and make it as realistic as we can, we'll try and make it as dynamic as we can. That's the expectation from Chris at the top. So we'll need to deal with that when we get it scheduled in. I think fogging underwater would probably be more on the graphics side of things, or the programmers working on rivers and water bodies in general. But then we're probably going to have to look at surface types for the soil, that layer at the bottom of the rivers, and you're probably going to want that to displace when the player displaces the surface. And maybe that needs to lead to a more misty look to it. Maybe we need to use space loop particles. We'd probably approach it in a similar way that we do with gas cloud interiors. We might have template effects depending on the type of water. There's going to be more swampy water potentially. Again, I'm just thinking future iterations, by the way. I'm not committing to immediate things here. But I guess all of that: players interacting with all the small little bits of particulate matter. We can do all that with our screen space collision, so why would we not?
I think this is a good opportunity to just talk about greater Star Citizen philosophy here for a bit. Our goal is always, and we've said this a lot, take it to the point of realism, bring it back to the point of fun. But there's also another underlying consideration: there are games that specialize in one particular aspect. People were bringing up Hardspace: Shipbreaker, a game whose sole focus is salvage, or a game like Subnautica whose sole focus is underwater. We are a sandbox game, so our focus is a bit broader than that. So we always want to take these things as far as we can. That will always be our intention. That will always be our desire. The question is only ever how far is that, before it begins to affect other aspects of our sandbox that are just as important, either in time and resources in the physical world, or resources in the virtual world. It's always just a question of how it fits in with everything else. That will always determine how far we take a thing. Our desire will always be to the absolute end. And I think we've proven, over what is now our 10th year here, that we will always push things as far as we think they can go, and continue to push, continue to refine, continue to develop. So it's a harder question to answer than it seems. We're going to do everything that we can within the sandbox universe that we are creating. It's just always important to remember, when managing your expectations, that there are dedicated games for that kind of stuff. We are not that. We are the sandbox. We are dedicated to a life in the persistent universe. So all those considerations have to be taken equally.
Fire's a good example of that, Jared, because we've already been clear that the first iteration of that is interiors, specifically vehicle interiors. If we just tried to do full-on fire propagation for Star Citizen, you're looking at burning forests.
If our game was "burn the universe", then obviously at some point you would expect everything in the universe to be able to catch fire. But because it is one aspect of our entire sandbox, it will be limited. But it will be limited after we push it as far as we can.
TL;DRLightning in gas clouds is being done and already works networked, striking players and vehicles, with design controlling its effects and spawn behavior and surface conductivity adjustable.
Yeah, absolutely, we will. We obviously showed a video that we did where we got lightning going on. That's absolutely what we are doing. I was going to say we're going to be doing, but that's what we are doing. Can I say anything about Squadron 42?
We showcased the Coil back in our Squadron 42 vertical slice a couple of years ago. If you can track that down on YouTube, if you haven't seen it, you can see the process of navigating an enormous gas cloud that has lightning and stuff that actually damages and affects the ship as it goes through.
Lightning's similar to the process of working on the fire. We got to a point with the lightning where lots and lots of code work was done, lots of visual work was done, but then you get to a point where a lot of the work that has to be done to get this properly working in-game is, again, less glamorous. It's more in the back end, it's more just making this thing work with systems and work with networking and stuff. So we do have the ability... the lightning regions: if you drop a lightning region in a level and the surface types are set up correctly in a level, then it will strike. It will strike a player, it will strike a vehicle. It's all networked as well. It will work. Design have got full control over what the lightning actually does. We had it killing people if it hits them, which you'd probably expect. But there's a conductivity setting in the surface type settings, so you can make a surface more conductive or less conductive, and then there's lots of interesting gameplay requirements for that. In terms of the actual spawning of the lightning within a gas cloud, that's the interesting thing. I've probably said this already way back, but we create SDFs, signed distance fields, from the gas cloud VDBs, so we know that we can use that to spawn the lightning. Where it becomes a design conversation is: do design want the lightning to spawn more regularly to prevent players going to certain areas of the gas cloud, i.e. the thicker the gas cloud becomes, do you want the lightning spawning more regularly? Or, rather than it spawning more regularly, would a designer maybe want just one much more powerful lightning bolt to strike the player? So all of these kinds of things we can do. We take our instruction from design. I've said this before, but the effects team, we kind of serve two masters, if that makes sense. We want to make it look as good as we can per the art direction, but we also need to make sure we're hitting the gameplay requirements from the design teams. So hopefully that answers the question.
I don't like that term, by the way. I'm not a fan, even though I use it myself. I prefer support team. Downstream makes sense in as much as we typically can't do our work until the process has cascaded down. So that's where downstream comes from. But for me, downstream conjures images of, I don't know, the muddy bog at the end of the pretty stream, with a discarded shopping trolley. So I don't like to think of myself as... But yes, we are. Along with audio, the lovely audio.
TL;DRSome Pyro work is done, including preparation for planetary effects, and more is scheduled, including lightning in gas clouds, but as a downstream support team VFX isn't as polished yet as other teams.
It's made it to me via Ian with lots of requests. "Hey, Mike, hey, Mike." We have actually done some work, or quite a lot of work, for Pyro. I've been in tons and tons of meetings where we've signed up to do more work. There's a lot that comes with Pyro. There's the actual gas clouds themselves. So, hey, guess what? Lightning is going to be needed in Pyro gas clouds, as we've already shown. But then it's just all the different locations that are in Pyro. There's all the planets. There's going to be different visual themes. We've done some preparation for the different planetary effects for the Pyro locations. Then there's the actual rest stops and locations and things like that. So some of the work's done, lots of it is ready to be done and part of the schedule, but because we are a support team, or downstream, we won't be as polished at the moment as some of the other teams are. I've seen lots of cool Pyro stuff.
TL;DRFire is fully dynamic, modeled on real fire needing fuel, oxygen and heat, but designers have requested, and the system can provide, fires with infinite fuel so they can block areas.
I am prepped for this question, thanks to Leo again. So Leo's lovely answer here is that the full systemic fire in the PU is modeled on real-world fire behavior, so it does need fuel, oxygen and heat. It will react accordingly if fuel or oxygen is missing. To give an example, if there is no fuel left, obviously the fire will stop burning. If there's no oxygen in a room, so if the safety systems shut a room down, then the fire will stop burning, and it won't just switch off; we'll have it visually looking correct for that, and the player will be able to see what's going on through the visuals. Having said that, we can add infinite resources for the fire, and that's actually been requested by designers. So the system itself is fully dynamic, but the designers do and have requested the ability to have a fire that's constantly spawning. And an example there: it wouldn't make sense if it was a pile of logs or something that should burn forever, but we can have a pipe, say there's a fuel pipe. That's a good way that we could allow design to build in some kind of barriers or blockers or reasons not to go somewhere, by just keeping that fuel burning constantly. So yes and no, I guess.
TL;DRParticles have no built-in collision with walls or ceilings, but effects can be made to react using signed distance fields, vis areas or screen-space collision, and smoke crawling along ceilings for fire is an aspiration, not a commitment.
This is interesting because the particles on their own, there's no real concept of that. If I just place a big smoke effect in a room, nothing's going to stop that particle as it is from just going outside the room, and certainly it's not going to react to the ceiling and crawl along it. Having said that, if we're clever about it... and again, for fire, we are going to be wanting to do this. Try not to commit overly to some of these things. But for fire, we want smoke crawling along ceilings eventually. That's something that we aspire to be able to do. That's just how you mark it up. So maybe, again, we use signed distance fields a lot; maybe we have a similar kind of setup there. I know we've actually played around with that in some of our fire work so far. Vis areas, actual screen space collision on certain effects. It depends on what the effect is, I guess. But again, it depends what the game needs and what design are asking for, what art are asking for. We can absolutely make it do that, but it might be more complicated to get it to look visually right.
Chris wants that. Everybody wants that. But it is a good example of how we can use SDFs. It's a little bit tricky because the gas clouds themselves, or the volumetric planetary clouds themselves, they're not going to react. So it's not like we're going to morph the volumetric form itself. But if we do it with particles, which we'll try and do, we need to just make it look like it's connected to the cloud. So it's quite a tricky one to do. We've already actually done some experiments with it. Trying not to give away spoilers. But it's something that we've definitely worked on visually. And as I say, Chris wants that. I understand why, because it's a great idea. So that's another one where I'm saying yes, we're definitely going to plan to do it.