Calix Reneau

It's tough to give hard updates. I can tell you where it's at, because physical damage is a big undertaking. It's not just about ships. This is about everything in the game. And generally, the top-level intent that Chris has had for this system is broad. And the reason I say that is every material in the game should be a real material, has tensile strength and all the things you would expect of a real material. So it's not a very gamified implementation where there's just some penetration value or whatnot. He wants to go through and have every one of those materials, whether it's a box, whether it's a character, whether it's a ship, whether it's a space station, all be respected. That's mass, everything that comes with it. You can imagine how many teams that affects. And then on top of that, because the way our surface types work with physics and where they're actually stored is very art-centric. So our physics type and what the impact of that given surface will do is defined actually by an artist when they do the physical proxy. So it's also stored in the material. So anything that we do within here is not only going to affect all the gameplay balance of the ships. Again, it's not just health anymore or not just parts, but it's actual density and thickness and those kind of things that will affect. But it's also going to affect the art setup itself, because all of that stuff comes into play, because obviously we don't want to have, well, maybe that's a bad example, but let's say aluminum on a ship. We don't want to have that aluminum act differently or read differently on a box, on a character, and do something different. So anyways, long story short, affects a lot of teams. I think everybody understands that. Where things are currently at is on the core gameplay pillar, Rich Tyrer and the physics guys have been doing a ton of work just going back and forth with narrative, because again, we have some real materials, like a titanium or whatever, but we also have things that are created from in-game lore that are lore materials, let's say. It's a real material that exists, just not in the real world, so we have to come up with all those values, and they have to coincide with the reality of a value. It's even just getting the details of all of that. Then beyond that, it's talking about what's the kinetic reaction of it, the radiant reaction. I've got a list here. Thermal, electrical, chemical, cold, heat, rarity. There's so many layers of it. So really right now, it's a big Excel sheet of here's all the surfaces that we're going to need. Here's all the reactions that those surfaces do. Where can we get that onto the content teams? And then once we do get that on the content teams, it's going to have to go to all the different experience teams. So vehicle experience team will have to tweak everything, because imagine what's going to happen with the ships. We have some balance in on the ships. We know that ship A will beat ship B in most cases because health is here, damage output is higher. Once it goes to a physically based setup, that changes the ballgame, because now all of a sudden the art of that ship informs what the armor is, how strong it is. And this to balance is just going to take some doing, I can imagine. In terms of if that's coming soon, I don't want to say anything in terms of timing, but it is an ongoing discussion and constant design that is being done and a lot of back and forth with Chris. And again, Rich Tyrer is really driving hard on it on the physics and the core gameplay side. So I expect more to be talked about in the future, but just do appreciate the complexity of the task, and it would be less complex if we didn't have any assets, but again, here we are a couple years running, so we've got a lot of assets already in place that need to be updated and converted to such a system.

On the implementation side as well, we've talked about the physically based damage over the years because we've done explorations and experimentations of what would it take to set this up to get the kinds of behaviors that we want in a closed system. And those have been informative, but like Sean says, we can't move forward until we find the version of that that addresses all those considerations at the same time. So a lot of that has been explorations to determine what it was we needed to be able to hit, what it was we needed to be able to accomplish, and then with that information starting to chart out the full scope of what this entails, which carries into all the stuff that Sean just said.

Another change might be that this also affects mass and also center of mass. Our flight model will have to get updated to accommodate the more realistic physics that will get informed by the art that's generated by the artists.

There's even some more fun with it. Our vehicles are one of the most destructible and interesting ways of blowing up an entity. You could break off wings, you could break off panels, you could break ships into different pieces, and all that is kind of customized into this XML packet. And if we want to be able to utilize the same breakable technology across entities across the board, we can't just use what vehicles are doing. And so there's been other discussions and even pipeline tools of changes where we could change the asset itself to define how and why things could break based off material properties. So it's no longer we have an asset of a ship with XML. You have the asset and it behaves correctly. So there's a lot of cool things coming along with this tech.

Yeah, just there's tons. Because I don't know, we made it sound pretty negative because it's work, right? And we're just going over, oh my God, it's all this work. But the stuff that it gives us is pretty incredible. Because now all of a sudden, it's not a gamified physical damage thing. It is a force damage. It's a kinetic damage. And they all have different reactions and all have different byproducts of them, whether it's an effect that is different or whatever. But it also just really embeds the materials and the art into the actual gameplay of the world, because we don't just color it because it looks cool. We make it aluminum because it needs to be aluminum in that part of the ship. And what I hope is that it informs the design even further as we make new stuff. It just would make sense.

Like the cascading damage effects that can be reinforced or negated by whatever particular circumstances are happening. Yeah, it makes it a much more reactive and specific behavior.

And procedural. Chris always talks about it, but he'd prefer, right now we have a very specific thing. If you damage a part at whatever it is, 75 to 100%, then you have a chance of detaching it. And then we have to apply a proper impulse. We do it very specifically. So it's like, oh, okay, we know that ship has gone to 90% of wing damage, so the wing has to punt off. Where Chris would like this to be much more, there's a technology called BMNG or something, way more physically based, where it's like there's a constraint. There's a constraint and after so much of an impact, let's say you hit it with a size nine railgun, it doesn't destroy the wing, but that's going to rip it off, because it just physically makes sense that that would happen. Anyways, stuff like that absolutely comes out of it.

Hopefully we can find a solution to prevent players being able to exit seats into other ships too at the same time. That'd be nice to get rid of that.

So that's almost fully on vehicle experience team for obvious reasons, the cockpit experience, vehicle experience. These guys on the VTT side are absolutely supporting it, though, in terms of the MFD setups, the UI setups, the UI updates. A big part of what's coming, not a lot to do with the MFDs, but a big part of what's coming is the UI updates for the given ships and things like canvas slicing, scanning and radar, and that's what these guys are working on very specifically. So a lot of the UI is being updated, and we're really hoping to roll that out soon with the connection of scanning as well as potentially missile operator modes and these other things in the nearest future. I want to avoid dates.

Calix prepared a lot of the physical button actions on that dashboard. You want to talk about that for a second?

Yeah, so one of the things that we started with was just figuring out the technical side of how do we get an arbitrary feature, an arbitrary interaction on a ship, any ship, regardless of how we've connected to it, to be able to connect that to the physical state of a piece of geometry and being able to point at that specifically and update that, being able to animate that procedurally without having to export specific animations for every single button, being able to do that in fewer draw calls by having it still be part of the same mesh. And then once we had a basic pipeline for how this thing can connect to that thing to tell the other thing to do something, if you can even do that, which it needs to be able to affirm before it allows you to do things, because if you don't actually have control, the thing shouldn't respond. And if you don't have power, it shouldn't tell you that it's responded. And if it doesn't actually do the thing, it shouldn't. There's a lot of things going on in this one channel. But once we have that, then we need to go back through and decide, okay, well, what are the buttons that we have? Because there's a lot of things that the ships can do. Some ships have cargo, some ships have torpedoes, some ships don't even have real landing gear. So how do we set all this stuff up in a way that we can address each of those very different concerns? And made a template and a design sheet for how you figure out what buttons a ship has, how you figure out where they should be placed so that they get grouped up in a sensible way. And there's still some getting to know your ship, to know exactly where things are. But when you step into a new ship, it shouldn't just be madness. There should be some logic to it of, oh, all of my systems ended up over here. And maybe on this other ship, they're over here. But that's because everything is flowing in this direction. So systems, and then you've got your parameters, and then you've got the specific call and response type events or the comms type things. Having a format for determining that and then making it so that all of that was packaged in a way that artists can use it. And artists don't want to hear about any of the things I just said. So that's its own task of making all that make sense in just a purely aesthetic way: what does a button need to look like? How do the labels need to be? What are the sizes that that needs to be? What kind of distances do you need? Yeah, it's been a lot. It's been passed over to the vehicle content team to begin working on. We did the Gladius as the first implementation. There are improvements to be made to the system. But the foundational work is in a pretty solid place, and we have a lot of the general information that we need to move forward with it.

Yeah, Chris really wanted to make the player immersion experience when you're within a ship cockpit to be realistic and intuitive. So it should be like you're getting into the driver's seat of your car. All the buttons should be intuitive. They should read out the proper statuses of all the ship systems. When you press a button, it should physically move. There should be a light indicator that actually shows you not only what the status of that system is, but does light up you, the environment, the dashboard itself, and then making that a system that our developers can use in an easy way and also to not tax the system. These need to be optimized systems because we have hundreds of buttons that are going to be within the cockpit, is the challenge we have.

Mark set up the light linking tech, which we use for those, which is really, really strong because it lets us use a texture to create the emissive light effect, which lets us be a lot more specific and have text that lights up or doesn't or changes. It's much better than my early attempts with just putting a light there or making it glow brightly. That was a big improvement.

With those things, here's another fun thing when you're building out tech for other people. First part of it is, as Calix and Kirk mentioned, how do we go about making this? How can we make something optimal? We have hundreds of states. We don't want to bog down the network. We don't want to bog down rendering. We don't want to add tons of setup issues. So once we figured out how we could do this and get all the states that we want to show replicated to buttons and we had a working example, we have that kind of as our tier zero technology where we hook up a ship like a Gladius and we say, proof of concept, it works, it's great. The next phase of that for our team is how do we expand this to the rest of the ships? And that's where you start building tooling or improved workflows and getting engagement from how the community is reacting to those type of changes. So we have done the first part, which is here's the tech. Let's add some more. Now, how do we make it easier for someone else to just go in and plop it in and add it in?

Well, to hark back to the physical damage question, that's really what breaching should be. It's a matter of the surface that's on that given door taking the damage that it needs to take. So there's no specific door breaching per se, because that's how it's set up right now, right? Right now, a door is in there, you can do some damage to it. Sometimes, I think in some cases they'll open slightly, they'll animate to open or they'll switch to a damage model. Yeah, they'll unlock, switch to a damage model. It's all very specific and bespoke. What we want to do is make sure that that's actually part of the overall physical damage and it just has to be. You can definitely argue, wouldn't you then armor the doors of your ship pretty heavily if that would be breached? But then again, it brings gameplay up if you want to punch holes elsewhere. That makes a lot of sense. But again, it really relies a little bit on that physical damage. But breaching as it is right now, I don't know that the design necessarily would change dramatically. It's just the way you get there would be different.

The problem with locks is that they're made to be opened.

I just want to mention that the one other system that we rely on is we need to finalize our room and atmosphere system, because part of the result of the breaching is that you're actually rending a hole in the side of the ship. We want atmosphere to vent out, and conversely, we want to be able to have airlocks that can seal off and then you want to re-pressurize the evacuated area. There's just some underlying systems that we need to do some work on first.

And to expand on this as well, fundamentally, the thing that makes all of this work is kind of the room system. This is something Chad McKinney worked on a long time ago where you have two volumes and they could hold atmosphere, and he uses the ideal gas pressure laws to indicate how and why certain gases transfer. So if you have two rooms and you add a connection, they'll transfer gas. So what a breach essentially is, is you connecting the inside room to the outside room and it just suddenly ventilates out. So if you know the connections, you could create a force. If you know when a door opens, you could establish a connection. When you know a turret is blown off, you could establish a connection to the outside. Right now our ships have immutable rooms, which basically don't allow the transfer to go through. We have worked on a life support system which allows us to turn that off, and when powered on, it would increase the oxygen and the gases in the room so that you could breathe. And if you were to turn it off, if you stayed in that room for a long time, it would all turn to carbon dioxide and you'd probably die. That's not fun unless you have systems in place that inform the player what's going on. A lot of times I see these things, you have worked on the system, what's the next step? That is the next step. How do we hook this up in a way that's player facing so you know what's going on? That's basically the next step. Then suffocation is fun.

And then we want this too. Nothing would be more fun than blowing up the top turret of a Cutlass, right? And then, sorry for the guy that happened to be in it at the time, but if it vents the atmosphere out from the hole that results from blowing it away, we want to have a door system that will shut that off so that you don't compromise the rest of the hull when you're in the Cutlass. But we need that atmosphere system to be functional in a way that we can implement this gameplay in there first.

Yeah, for the actual process of breaching the door, we've updated the doors to be able to derive their lock state from other items. I had a deadbolt item that I made as an example. But anything that would be specifically in charge of keeping this door shut mechanically, it would be able to get that information from there instead, which would allow us to make specific breach points within a door, that maybe this part needs to be the thing that takes damage. Or if the whole thing takes damage, does the entire thing come off? That affects what will happen when you lose atmosphere. And then also having it so that you have the ability to, like you were saying, counteract the loss of pressure, being able to inject the room with atmosphere again. We have this compressor, which has been a way of taking the airlock behaviors that we had and taking it from being this hyper-bespoke setup that we had, where this room is just an airlock because we've made a room that is an airlock and wherever you place it is an airlock, to here's how you make a room into an airlock: you give it a compressor, which takes the atmosphere that's in the room and puts it into its tank and takes what was in its tank and puts it into the room. So if there was atmosphere in the room and nothing in the tank, it swaps to be atmosphere in the tank and nothing in the room; you are now depressurized to go outside the ship. If outside the ship was a toxic environment, when the doors open, it will flood full of the toxic environment, and the breathable environment in the canister will switch with the non-breathable environment in the room, and now you're back to a breathable environment to safely enter your ship. So that is the go-between from the life support system that we made, which very, very slowly regenerates and filters the atmosphere in the entire ship, to being able to intentionally use the systems to give yourself an edge or find yourself at a disadvantage because someone else has filled your airlock with toxic gas. Why'd they do that?

That was a fun thing when I remember you were experimenting with it. It's like, wait, we can't just pump oxygen into the room. We have to take out the bad gas and then replace it with the good gas. And then we started debating, all right, if you have that canister that takes the good gas and then changes the atmosphere, what happens if someone swaps it on the ship for fun? Like, hey, Sean, can I come aboard your ship? Swap his air tanks with toxic gas. All right, I'll see you later. And then Sean goes flying away. He passes out. I steal his ship. Standard pirate run.

Sure, I'll start off. So as has been clear, scanning has been the greatest experience in the world. So what we're doing is we're trying to make it so that, A, it's easier to find entities in the vastness of space in the CIG universe. And once you do identify them and get up to them, you can scan them and get worthwhile information that you want from the entities. It's not, unfortunately, as simple as just putting in what information you need from it. Each entity type needs to be set up so that we receive information that's useful to the player when you do scan. It's two experiences but one system. So we have FPS scanning. So you're scanning when you're on foot. And it's going to be mainly focused on other AI or other living entities. Then we have ship scanning. So when you're in the pilot seat or the scanning seat of a ship, what information do you glean back from doing the scan? So in the past, I think we got the ship class, the pilot or the owner, and the health of the ship. We wanted to expand that to more useful things, like what's the weaponry of the ship? Armor of the ship? Does it have cargo? Is it going to be worth raiding and emptying out the cargo bay of that ship? And then we can layer on gameplay later on. We actually have smuggling gameplay, like the Star Runner could maybe, in the lower cargo area, that can be shielded from a scan. Again, to a previous point, why would you make the whole ship out of that? But it's part of the gameplay. We'll figure out some lore to make it so that you can obfuscate the scan results there. And then figuring out all the info and then expanding it to other entities. We want to be able to scan Port Olisar or other space stations or any ground-based stations. Doing ships within ships is a thing that's coming sometime soon, and we want to be able to get that info as well from the scan. But before that, we need to find the ships. Now we need to just find all entities. And so expanding pinging and getting better results from the blob that we had. So we did some work previously to allow you to find mineables. That took some time. But it's still, I think, an experience that we need to improve upon. But at least you were able to do pings, find mineables on planets or in the asteroid sections, and then be able to kind of pinpoint where those mineables were so you could take your mining ship over and then mine the rocks. We want to make that experience the same across all entity types. So if you're looking for a particular mission goal or another ship or another player, combining all those systems together to make it so that doing the pings and doing the scans is a worthwhile experience and intuitive. Some of the systems that we've been doing that with is we've been modifying the detection of entities. So right now we're using signatures. We do have EM, IR, CS as far as our signatures are currently implemented. We're going to be expanding it. We do have dB, decibels, that we don't fully utilize. We want to expand it, make sure that those signatures are working so that you can, say, hide behind a wall, or you can, as a ship, if you're a small ship that's generating really low signatures, you can sit next to an Idris that's generating incredibly high signatures and then hide within the space of that Idris so that from the perspective of someone else's radar, they only see the Idris. And all of a sudden, oh, there's like five escorts on there that I didn't get to see because they're being hidden by the Idris itself.

Helps give a reason to fly in formation, because when you're flying very closely together and your signatures can bleed a little bit, it gives you a bit of an advantage for hiding your numbers.

To go back to what Kirk was talking about, it really comes down to those signatures. That's what scanning is all about. Scanning is the electronic gameplay, electronic warfare gameplay that goes on. And it will result in better or worse situational awareness for the player. That's what it comes down to. And each of those signatures have differences, right? How they work together. In a gas cloud, the EM and IR is going to be hard to pick up. There's just a ton of noise. There's other things happening within that gas cloud that are going to make that hard to pick up. But again, if the cross section, CS, is so large, then it might make up for that. And that's where you're going to go. Now, some of the stuff that's been added on top of it has been info of the given ship. For example, how many people are in the ship? What are they? Who are they? How deep can that scan go? And all that kind of stuff is actually coming back. What's really nice about this feature overall is that we've been driving it from a pillar standpoint. And I mentioned it before that we have this core gameplay and then the vehicle pillar. This is all being attacked together. So FPS scanning and ship scanning are all generally using the same systems. They just really rely heavily on different signatures. So to go back to one of them, Kirk mentioned dB, decibels. Doesn't make a ton of sense that a ship in space is going to be making a whole bunch of noise, but it makes tons of sense that a character or even an item is going to make a lot of noise. So what's interesting is if you have a generator in a room that's emitting a ton of dB, you can actually stomp around that generator and nobody's going to pick you up in the dB sort of thing, because you kind of get that, I call it thief gameplay, where you're in the shadows or whatever you're being. [garbled passage] But there's no really absolute value within them. And that's what has been getting worked out, especially on ambient signatures, CS and whatnot. So again, all of those signatures, they all have different sort of rule sets that you can include with or do things to, to benefit or detract from being able to be scanned or not. Just one last example, maybe. For example, when we go active missiles, if you're going to this active sort of combat mode with missiles or whatnot, it's very Hunt for Red October kind of moments, like an active ping, right? As soon as you go active, you are super hot on that radar. So you're going to be able to be locked on. But you also know that that guy's turned on his missiles and everything. So he's about to shoot me, whether or not you're going to do something. So again, it is about the signatures informing the situational awareness for the player. That's the general intention.

Yeah, we're implementing the actual signature tech and detection. And then we'll take a pass afterward. Well, our particular team won't, but we'll have one of our teams do a balance pass so that all the ships are generating signatures that are within the ranges that they should be. And then same thing for players, same thing for anything that would be generating signature and interacting with other signatures around it to change the gameplay. And then in Sean's example, we put a sun somewhere in the galaxy and it's generating a ton of EM and IR, and directionally. So you can do the thing where if you position yourself between the detector and the entity that's generating all the signature, you can effectively hide right in front of the player in plain sight, because you are within the array of the giant signature that's emitting from behind you.

The other big fun thing is with all these changes, there's no point unless you have some good player feedback. So a major revision to all this is also adjusting our UI so that we could show this information in something that's more meaningful. Our scan UI, I think in the current release, kind of just has like a list of information. Now we're trying to organize it into more meaningful ways, like a general area saying, here's information on the ship or the player, the name, the wanted level. And then there's like an interior area that tells you, here's some of the cargo contents we found, some of the weapons that we found. Then there's like an exterior. And group the information in a way that the player could scroll around. And the other big change to this thing is making it more data and design driven. So design now has the ability to make a scanner that finds things for medical. A scanner that's made to find things that's more for like pirate cargo. Design can now make upgrade paths to specific tiers of scanning. That won't be in the initial tier. This framework just allows this gateway to open up for design. So there's a lot of fundamental changes on the core gameplay and what design can do with it thereafter.

Yeah, to Mark's point, players have been asking for the one system that I think works right now the best with our signature system, which is mining, to be able to filter out for particular mineables. If you're using one of the smaller ships, you don't want to find the big rocks. Conversely, you don't want to find the FPS rocks if you're in a big ship. If you're not in the ship, maybe you don't want to find rocks at all. So we're implementing that system. And then we'll have a way for the players to be able to filter out the signatures that they're particularly looking for by some dashboard control.

Again, that is up to the particular ship whether or not they want that or the format that they want it in. But the tech and the implementation pipeline for achieving that is there now. So I expect that probably we'll begin to use that and other similar kinds of features moving forward. I don't know anything about retroactively going back through the ships to update those unless they specifically have an update scheduled.

Calix, you want to talk about how you worked on getting the system states to be more controllable by the player, so that design and art can go and do things like we can change light states? We can do things like actually control multiple doors. We can have the door control panels actually react to the state of the door that it's controlling rather than it being a one-way communication path.

I think Kirk just did. Well, the issue is we've been able to do this for a long time, with very few exceptions of maybe you couldn't specifically get the UI panel to show up quite so easily. But the engine has been capable of doing this for a long time, but it's been incredibly difficult to actually set something up to achieve it. And so the thing that I started all this working on was trying to make it so that it was less of a chore to set up a door with its control panel, setting it up so that you can either put it in the object container with the ship and link it or you put it on the loadout and have it link automatically. And the reason that we weren't able to have this behavior is that the only way that you would get it is by having someone who knew absolutely everything about the door, how it worked, where it was getting the sensor information from, how the lights were set up in the light states of the room, and knew all that stuff at every step of the process, and then do it at every step of the process, which is not really how we make things. We have people who are dedicated to making our environments and dedicated to making the ships and dedicated to making the tech. And it's not really feasible to have these shamans to just walk through and bless everything. So it's much more important to be able to make it so that you can use these things without needing deep arcane understanding of the under-the-hood things that it's doing in order to set it up to behave that way. So the actual fix isn't so much making it that the doors can be locked or unlocked or even that the proximity sensor can be turned on or off or that the lights can be on. Those were already behaviors that those things had for the most part. There are some additional ones that we're adding, with the sensor being able to tell you that someone is there. We're expanding from here, but the real problem was making it so that you could place down a control panel, you could place down a door, and then it could have a proximity sensor or not, and it could have a light in the room or not. And then you could link those things and be done. And being able to do that is what lets our environment team and our designers on the ship side be able to actually use these to create the content that is useful and player facing. Because otherwise, it ends up being such a dark path to follow that you never get out.

By the way, there was also a bug fixed quite some time ago. The bug was that multiple control panels set up in different ways didn't properly handle the door states. So I know for a long time, the rear Connie door, if you open it from the inside, only the inside control panel would know about the state, the external enter, exit [garbled]. So, I hope we don't, but if we do have issues with that, please inform the Issue Council.

Yeah, the Cutlass and the Caterpillar, because the ships will support these things in different ways. The Cutlass and the Caterpillar both have control panels which have buttons that light up to reflect the state of the doors, whereas obviously the Star Runner has the screen, and we want to expand even from there. The other thing is that adding in the light controls for the rooms is much more limited at the moment than where we want it to be. And that's because the rooms that we have in our ships and the lighting states that we use with those is actually very deeply hard-coded into the ships, the emergency states and the power states. Those are fundamental aspects of ships at the moment. And so, except for the small slice that we're branching in the Star Runner, it's not really set up in a way that lets us manipulate those states outside of the scope of the ship from the player perspective, as an example. So there's work to be done there to make it so that that's feasible.

I do like the direction that we went, though, with the Star Runner. Touchpad-like devices that you actually interact with to change the door states, and they can have as many buttons as you want. Very, I don't know if this was mentioned, but very LCARS-ish UI to be able to manipulate the states of all the things you can with the control panel. And it's much more useful as far as giving player feedback as far as what the state of the room is and what they can and can't do. I'm pretty sure we're going to be using that particular design language moving forward.

Personally, I want screens all over ships. I love it. But not every ship should have that, I guess.

The attachment problem. So the attachment problem, it's super interesting to talk about. And it's not the first thing you'd think about within this. And maybe we'll talk some body customization questions later because that's what the big challenge is within there, is the attachments. So morphing a face and doing all these things is complex enough. But then when you tack on attachments to it, so now you've got hair, now you've got scalps, now you've got glasses, now you've got helmets, now you've got monocles, now you've got top hats, now you've got all these kind of things, you have to make sure that those still fit every single face that you can have. And like we showed in ATV, there's a huge range of human anatomy. And generally, that's why they have multiple sizes of hats. That's why they have multiple sizes of helmets. But guess what? We can't make that. I can't go to Josh and say, cool, you've got this awesome idea for a helmet. Great. Give me 30 of those with just slight adjustments to every single one. So we needed a much more dynamic system.

We could put those in our shops. We could have a size one helmet and a size two helmet. But you could only get the one that's for you. You would have a hat shop.

You would have a helmet shop. You would have all these things. So we needed to make sure that we could implement a system that could adapt the shape of the attachments to fit, basically. So that's what we did. When Andreas Rohr came on last year, who did part of the demonstration there at CitizenCon, he was the one that kind of cracked the case on this, which was using some concepts, to be fair, from the film side that he had done most of the work within, but then applying them to a runtime implementation. So these were all these new deformers that we've created that are runtime deformers. We call one elastic, one is non-uniform scaling. And deformers are a method of moving verts around or deforming them, obviously, at runtime, based on some sort of input, and the input is the face. Now, what gets weird about it is there's different deformer types for different types of attachments, and Ivo and Andreas went through this really well in their presentation. The elastic type, basically this is one that follows per vert the offsets for every single vert against every other vert in the attachment. It wouldn't work on a helmet because the whole thing would contort into such a weird shape that you wouldn't be able to recognize that helmet anymore. So it was really important to bring those deformers online so that we could actually roll the system out, and that's why there was a big, big delay within it. We were still using the system behind the scenes; we couldn't apply it or give it to the players without solving the attachment problem.

Yes, but first we have to, okay, so hair. Let's talk hair. Okay, hair is hard. Hair is really hard. And not just hard for me. It's hard in real-time rendering. Hair is very difficult. And to be fair, nobody's really solved it in a new or unique way for the last, let's say, 10 years. It all uses alpha cards, and whether you use alpha test or alpha blend, there's pluses or minuses to the whole thing. So the difference between alpha blend and alpha test: you have a card, you have an alpha channel that's basically saying this is transparent here, not transparent here. Alpha test only does a singular test of that. And it says, basically, is this vertex going to render or not? Is this pixel here or not? And it does one check, and it goes through, or it doesn't go through. Alpha blend does multiple. It actually blends it rather than doing just a test against the singular pixel. When you do alpha blend on a bunch of the hair cards, the softness of the hair can look amazing. The problem is performance changes depending on the distance that you are, so how much of the screen space alpha blend actually takes up. So it's a bit of a rendering thing. So we showed at CitizenCon pretty much an update to not only the hair shader, but the method that we make the hair. So this has not at all been applied to the current character creator. So that's step one, is take those hairstyles that are there now and make sure that they're using the updated shader and the updated pipeline so that they're all going to look a lot better.

We also had to update it to unify them so that we could have them on all of our different head shapes and all of our different characters.

And make the attachment system work for that. So they use that elastic sort of technique. The trick is getting it simulating on top of that. So once we've got the visuals where we want it, then we'll get into the simulation side of it. And that has to do with the complexity of these attachments. So now think of how this works. We have this hair, and we have an adaptable face, and we have this runtime deformer that contorts the hair to fit. And it's not just a uniform scale thing. We can move the scalps. We can move all of the areas of the head, so the hair has to move up and down. And now add joint chains into that, because generally you're going to want to simulate these things with either joint chains or some sort of cloth vertex simulation. Or you go crazy and you go TressFX, NVIDIA hair. But all those systems use some form of vertex simulation to some degree piped down onto the GPU. So whether we want to implement that, that's probably a bit further than we'll go. But on the joint chain technique, we need to be able to update the offsets of those joint chains so that the simulation happens from the right place all the time, depending on the attachment changing. And the constraints.

Actually, I have a question for you. The blending that we're doing on these attachments that hair is a part of, are we able to do that in multiple steps, or is it just the one step? Like, my head is this shape so my hair has to attach to that, but if I put on a beanie or whatever, are we able to then also clamp it on the secondary step, or is that problematic?

That's a bit problematic, and I know what you're saying. So what we do instead, we do subgeometries. So that's basically different forms of that geometry depending on what the attachment is. A great example of this is the current Snoopy cap. And we finally fixed this thing. Well, kind of. It's coming back. So everybody's seen it, I'm sure. You've got Mohawks sticking through helmets. Now that we have long hair, it's more like the rule than it was before. It used to just be the exception. The one hair, the Mohawk, would always go through the helmet. We had set up a bunch of logic, but there was a code bug within here that the tag wasn't being respected. So basically what we do with this Snoopy cap: if your hair is so long that it would clip through the helmet, we instead put a Snoopy cap on the hair, but that's all adapted based on what hair you have. So when the helmet comes on, just to go to your point of putting on a beanie and changing it, we do this with the Snoopy cap. So when the helmet goes on, if the hair is so long that it would clip, we put the Snoopy cap on you.

But because of the way we do that with the subgeo change, we don't necessarily have to pick the same Snoopy cap for every hair. We can have that hair sticking out the bottom of it or whatever else.

And that's all just asset work. And generally, with the character team, I talk to Corey a lot about what he calls hat hair. So it's basically, when you put a helmet on, what's your hair look like? When you put a hat on, what's your hair look like? And it's just how many of those they actually want to make. For every single hairstyle, if you now have to make a hat hair version, a helmet hair version, that's already multiplied it by two, or three anyways, the three different forms of each hairstyle. And you just don't want to make so much complexity for them.

What I'm imagining is Pacheco's hair, but then you put a hat on top of it, but the dreads are still low.

Yeah, but again, what's that look like in a helmet? Because if you've got dreads, okay, cool, you put on a helmet and you've got dreads hanging down here. What's that look like in a helmet? Actually, what would that look like? It'd be really weird. You'd have this bunched up stuff in your helmet. So I realize I'm hand-waving, and put the Snoopy cap on and that volume of hair just kind of goes away. I don't know if you could fit that into a Snoopy cap. So, yeah, I guess short answer is yes.

Yeah. We actually just started talking about that the other day when planning improvements for this next quarter. And conceptually having undo history and stuff like that is definitely on the radar. I think it depends on which level of undo we want to do. I think we were talking about having an undo stack. So what we do is just save off all the DNA values, which is actually a really small set of data. It's like 200 bytes. It's a really short string of characters.

So much of the complexity comes from the fact that we have all these different types of modifications. We have changing the DNA deformer as well as changing the actual items that are attached. And that's when it starts to get a little bit more complicated in terms of how we're going to manage that history.

Yeah, because actually all the eidonomy stuff that we have right now for hair, eyes, soon-to-be beard and stuff is actually totally separate from DNA. This is actually an item being attached to you. So we need to have this history of your changes be sort of agnostic to the data that you changed. Like, okay, if you changed DNA, we need to say, here's the value, refer to that value of the DNA matrix. If you had an attachment, it's like, okay, well, what item port and what was there?

And the smarter the system can be about that, the better we can have it update. If we don't have any idea what the change was and we just say, okay, here's the last state it was in, we have to reinitialize the entire character. He's going to pop off screen for a second and then come back on. It's just a way worse experience, and you don't get to see the actual change happen so you can judge it. So you have to just hold more of it in your head at a given time. So making it smarter is worth doing because that'll make it a lot more usable.

Yeah, I think so too. That main point is there's a couple of data sets in here. The main one is kind of the anatomy, the shape, the geo.

Yeah, and how the colors are being attached, how all the materials are being attached. That's totally separate from the matrix.

So I know I made the joke in the ATV where it was like, oh, I see blonde, I see brunette. Actually, that data's not in there. It's just a joke.

So we have the DNA matrix for the anatomy, and now we need a string for the eidonomy.

Basically, we need some sort of data to represent what hairstyle, what color, what skin tone.

In addition to it being useful, I think that there's just something that's really beautiful about any time we expose the data in our game, because for once we don't have to fake it. We have so much going on in this game that we can just say, here's the actual values of it, and have that represented on screen in any number of ways. And I think that it's very easy to end up with something that's kind of beautiful and engaging just on the data side of it. In so many things, you'll have the doctors manipulating all these aspects of it, and it's all just hand-wavy. It looks nice, but it doesn't mean anything. And here, it's actually tied to something that's real. And sometimes that thing that's real is still abstracted away, like the way that we do our blending. Even just having my manipulation of the world result in actual changes to it, I always find that compelling.

Especially as a programmer, when the data is written in hex, it doesn't take too much of a leap to say, oh, I can actually look at this and see what it means. This head has this much weight in the face. It doesn't take too much explaining to say, oh, okay, this is what it means. I really see what this code is doing here.

I do think it's cool. And that's why I make that matrix joke, because it really is. You're looking at it, and you're like, oh, that's head ID 9. It's blended at 20%.

And so I would have totally wanted to have a copy-to-clipboard function. So you could just paste it and be like, this is my dude. You want to tweak it? You think I have too big ears? Here's the guy. Make your own ears on it.

And especially since we reset them every major release right now, I think that's a nice way to bring it back. But one big point about it is, what we're doing right now, you'll see it on the next roadmap publish, but we have a V2 planned. We've got lots of iteration to the actual UI, the actual interface. We've been talking about it a lot this week anyways, taking in the feedback from people and everything. So I don't want to go too deep into it, because I'm sure we'll do an ATV or something like that about the next iteration of it. But the whole mentality around that is simplify some of the interface a little bit, make it a little easier to get to what you want, take up a little more screen space, try to make things a little more clear. But the point being is that we're going to change some of the content that is in there. So one of the things about being able to output that string would be, between releases, if we change that content, that string is going to mean something very different all of a sudden, because our indices are going to change, the amount of heads are going to change, the hairstyles are going to change. So unless we're very additive in the way that we add the indexes, we're always going to basically clobber that data. So once we're in a state that we're actually pretty solid on our data, that would be a better time to do it.

We can also have an internal mapping, too, where we try our best to future-proof it and say, if we're going to change the order of stuff, it won't break it.

Exactly. So for the next release, it knows, okay, well, if they are importing data, that ID 1 is actually ID 4 or whatever we want to do with that.

Okay, so hybrids. So what's super interesting about the hybrids, and what do I mean by hybrid? A hybrid is a resulting head that we can reuse as a source head again. So where it kind of started was what we found when using it, and this was over the course of the last years anyways. What I found when using it is that there's a lot of redundancy within faces, within heads. And you probably even notice it right now that we've got nine male, nine female within the system right now. But of those, for example, on the female side, there's probably four of them that are mostly the same. They're very close to the same, let's say, archetype. So there is some redundancy within there. And what's interesting to see about it is it makes the average head that people end up creating look a little heavier on the sort of Asian, Eastern European kind of side right now.

Okay, I wasn't imagining that. I thought that was me.

No, that's what you noticed. A lot of people kind of look like that. And a lot of that has to do with just the source heads themselves. So what we did in this early iteration, because we didn't want to make this thing wait until halfway through this year. We wanted to get this in front of players. The main reason was we wanted to get that feedback, because we use it all the time.

Yeah, and interacting with it is so key to the actual feature that just seeing the results isn't sufficient.

So the heads within there have some redundancy. So what we want to do instead is make each piece of data that you are sourcing be meaningful in its own way so that there's no redundancy in there. So what we're going to be doing over this next V2 thing is, what we've done is cross all the Squadron heads and everybody. And there's so many benefits to doing it this way. We've archetyped all the heads. So there's a huge mosaic that basically has every single face that we've got. And what we've done is kind of align all the people into their own archetype. So to use an example, I'm almost scared to use it a little bit, but Sandi and Rhona Mitra have a very similar archetype of a face. But then between the two, there might be unique features of each. So what we're going to do within the data sets is, instead of just the nine male and nine female that you've had since the first character creator, it will replace all of those with our hybrids of meaningful data sets. So we'll take the unique ear of that guy, the unique nose of that guy, the unique brow of that guy, all within the same archetype group, and make that a single head.

Yeah, we're distilling it to the extremes so that you can pick between those extremes.

Yeah, exactly. Meaningful data so we don't have redundancy across it. So what it does is it makes it a lot easier to use, because each of the data sources are unique in their own way, and you don't have a lot of redundancy to sort between. And this doesn't mean that we're only going to have four or five heads. Even within that archetype and hybrid approach, the reason we can do this is that I can take very specific features of maybe an actor that we can't use the full likeness of and create that into a hybrid. And that's actually not an issue at all. We're making people that aren't actual people, but are combinations of people. So basically, we're using our own system to source our system, which makes some sense. The other cool part about that is, because we're going to have this ability, it does make a pipeline for us making guys like mission givers or new heads a little bit easier. But what's really cool about it, I think, is an interesting design idea that we're trying to flesh out between myself and Todd and CR. I call it the loopback or the feedback pipeline or the sins of the father kind of idea. Legacy, or heirlooming or something like this. If you create a character within Death of a Spaceman, after you've died a certain amount of times or whatever, you can't respawn and you have to create a new character. But I would love to be able to then source back my original character as a source head within the pool. And this is totally possible because, again, it exists as a combination of those hex values. We feed it back in as a source and then we blend against it. You can only do that so many times, because eventually you will just end up back at the average if you just keep blending, blending, blending. You'll just end up back at the average over time. But I like the option for characters to do that. So I like this concept of, if you were playing the game as a criminal or something like this and you've got a certain amount of reputation, that when you roll your next character, if he's kind of, quote, unquote, the son or your child, some of that reputation comes with you. Because if your dad's a horrible criminal, maybe you start life with a little bit of that, and you have to work against it, or if you just want to make something anew. But I love the idea of being able to source back the player head.

Would we do anything where we could source from different people, from other players? Your head ends up in my pool because of a certain reason.

That kind of goes to the copy-paste of the data. We could absolutely do that, because if you could share the data between players, you could feed that back into your pool. But, and by the way, a lot of this is theorycrafting still. I don't have a plan for that. Hybrids are in. That's happening this quarter. The sins of the father kind of thing is a little bit different.

Yeah, we're exploring all the potential consequences and ways we can really leverage it.

So we've talked about possibly having the gene pool or the head pool basically controlled via the org. So for example, the org could expose all the heads, all the characters that they have within their org as sourcing. It's a dangerous road to tread, though. If they just want everybody looking a certain way or looking a certain type or something like that, they can absolutely do that.

You'd be able to deviate from it, but there's also an element of family or whatever you have to it. Just things to think about. People spending time together.

Yeah, I like the idea of dominant traits sticking around. What if I have a player that has this massive crooked nose and I just never die, and eventually this guy's like 100? Traits stick around in the gene pool.

But that is an idea that has been expressed, that orgs could share individually within there.

It's about having different colored eyes. As far as the asset side of it, I don't see a reason we couldn't support it. I don't think that we do, and I haven't heard of any plans to do so. How do you feel about this, Sean?

I love the word. Again, I'm just like, different eye colors.

It's a pretty rare condition in the world.

It's way more common in animals like dogs and stuff. We already support asymmetry, so it would just be like locking one eye and then...

Yeah, I mean, actually, the helmet thing was a big part of that asymmetry decision, because we supported manipulating your face directly asymmetrically. And that was problematic, because even if you end up with a non-homunculus character, when the helmet morphs to match your face, the asymmetry in the helmet becomes really apparent and problematic.

That's a really polite way to put it. It looks awful. You have a Slaver helmet that looks like a face, and then you have half of it looking like it was melted.

On the material side, which is what supporting heterochromia would need, I don't know if we have anything coming down the pipe for being able to do any manipulations of material at that scale. That would be very similar to how you would handle alterations to eyebrows, makeup, flesh tones.

So we did build this into the character system from the get-go as an option, because I thought eventually we would want this. And actually what I thought eventually we would want would be holographic upgrades and things like that that you would put on one eye, or a contact lens on one eye or something like that. That's your AR lens or robot eye or something. But within the item ports of the character, it's actually split up into left and right eye. We use one of them right now. That's all. And it has the two eyes in it. So the easiest way to do it is actually just to add another set of eyes, and then we zone cull one or the other. So there's actually four eyes, but we're zone culling the opposite ones. And that totally works right now. We can do it. So I think depending on how much people want it, yeah, sure. It's not a nightmarish add, but it's not planned for this quarter.

I want to be able to make Cable from X-Force.

Right. No, that's exactly it. Things like scarification and having any sort of post-manipulation, things like having augmentations or prosthetics, those would all be handled on the asset side at this point. Same as adding a hair, which is a weird way to do it, I'll admit. If you're adding the extra eye in or you're adding a scar or something, it doesn't initially make sense that you would attach that to a person, but that would probably be how.

And then the color is somehow attached to the person, which is fun, too.

That's the sort of abstraction you have to get your head around in order to manipulate it correctly.

It's going to be the same tech as doing different kinds of eyebrows, right?

Yeah, somewhat. And people have probably noticed this anyway, some of the skin tones for the females have makeup built into them. There was this character art pass where they did a makeup pass, basically, against all the heads, so they added some eyeliner, eyeshadow kind of things. But whether that's a separable thing, it's completely up to character art on that front. It's, again, not a huge nightmare to do. We have a great feature within the skin shader to deal with it, but I'm not sure that it's going to be perfect, because the thing we have in the skin shader is really good for tattoos, for decals, for dirt or mud, for face paint, basically.

It doesn't do the blending nearly as well.

Exactly. And it doesn't adapt the specular. So the biggest thing that happens when you put on makeup is you're changing the light reaction on your face. A good example is you put powder on so that you're not as greasy-looking. We don't really have that control. So if we put makeup in, it would look like face paint and not like makeup, because makeup changes the specular reaction of that skin. So we'd have to support that. That's all. So right now, to have a really good makeup, it has to be pretty much painted into the texture itself and not a layer on top. So we would need something like that. So if we do progress on the tattoo front or the face paint front, we'll have to do something in that way. But right now, we wouldn't just put the makeup in, because it would just look like face paint, and it would look like a bunch of game developers thought, what would makeup look like? And we have Joyce Platten here, who is a beauty specialist, let's say. She has podcasts and everything. So we had her come over a couple of times, and we talked through this quite a few times, and we even showed her the decal stuff. She's like, mm-mm. That's not at all what it should look like. Please don't do this. So, yeah. Face paint, yes. Makeup, not really. It's kind of built into the shader, and I know some of the skin tones already have it within there.

Yeah, the eyebrows are baked in.

Same texture and same problem. Around your eyebrows, you do get a different specular reaction. And we actually have to paint out the gloss around the eyebrows, because it ends up looking really fake when light rolls. Oh man, faces have so much subtle stuff in them that if it's not there, it completely breaks down. But within the eyebrows, we paint out the gloss in that area. So basically, we make it less glossy around the eyebrows. The reason we do that is it looks a lot less fake. They're part of the texture right now. What I've talked to Corey about, it's the same problem as scalps. We have to make sure we remove all the base hair out of some of our texture scans. So when the guys were scanned for textures, they had little beanie caps on with their hair sticking out and stuff. We've got to remove all of that, because now we have a generic scalp that we can apply, and we need a scalp because it has directionality on it for when the specular rolls around. And then you put the hair on top of that, but you can't have other hair underneath, because your hairline then doesn't line up to what the scalp is, and it can look really weird. So basically what I'm saying is we're going to treat eyebrows the same as hair.

True, and it introduces errors every time you do that. There's no clear solution on that right now, but I quite honestly haven't had it be a massive problem yet. And at the point that it does become one, then sure, we'll do something about it. But right now, I just don't see it as a huge issue, especially because, again, we're going to randomize the weights and everything within there. You could eventually get to that state, but I haven't seen it happen.

With regard to character customization, it's a matter of introducing more extreme options, more meaningful choices to make. And with regard to the legacy system, it would be about managing it so that it does introduce elements of error within that blend. You wouldn't ever end up beyond that blend, but because we blend between four different heads, you don't necessarily have just the weight between these two people.

Yeah, so that's one of the things that we're trying to do for the V2, to make those decisions less segregated. We want to make it so that you're able to jump back and forth between all the elements that really impact your choices much, much more easily. So we want to bring the skin selection into the same screen as where you're doing a lot of the head selection stuff. That's some of the stuff that we're exploring right now. And yeah, that'll definitely help that process. Because right now, if you want to see what this feature would look like and you start going towards something, like, oh, the skin tone doesn't really feel right anymore, I want to go towards something lighter or darker or different, then you need to navigate away from the thing you were just doing. It's definitely a UX problem.

Yeah, it's like context switching. You totally lost the perfect framed shot of what you thought that person would look like with a different tone.

I mean, V1 of this character customizer with blending is all about how do we communicate how this novel system works to new players. One of the things that was really important is it is not a sculpting system. So we don't want to use any tools that operate similarly to what you might use in ZBrush or Max or anything: I'm going to take this thing and move it over here. That's not how the data works. It's not something that's going to be able to actually get you towards the result that you're expecting from that. And the moment you try to do something and it reacts incorrectly, you immediately have a break of that mental model and you immediately have a bad experience. So step one, not sculpting, we need to communicate that. And then step two was trying to communicate that when you're blending these things, you have the full breadth of choices at every step. So one of the initial things is, we keep showing you the heads, they come in and out and they do all that stuff. Because we felt that it was important to try to get across that when you go to edit the nose, you don't need to be using the same pool of four heads to manipulate that nose that you used for the brows. You can have a unique head selection on every single one of these features and blend them independently. That is a level of control and minutiae that, the feedback has proven, is a little bit beyond what is helpful. So we've sort of keyed in on the thing that worked, the thing that was nice about the way that we set it up, which is trying to make the coarsest, broadest choices early and refine from there. So each choice is how do I get closer to what I'm looking for, instead of how do I identify which thing I need to change. So it's focusing in more on the next step: I want to look more like this guy. I want to look more like this. I want this skin instead. So bringing that into the same panel, making it so that you don't have to go to a different step, is absolutely part of that process of how do I give you the clearest, broadest choice such that you can refine from there.

So for the V2 stuff, what we've talked about a lot is, currently, with the UX and the way that people end up making their characters, we're not feeling like they're actually getting the result that they necessarily want or expect. And a lot of this is experimentation, but rather than being beholden to what your result is, because I think a lot of people play with it, and they'll get to a result that they're kind of happy with, but it kind of takes you there rather than you taking it there, if that makes any sense. In the V2 version of it, that whole mentality is kind of switching, where we'd rather you have very precise, as Calix talked about, ever-increasing complexity controls within it, but get the result that you want out of it a little more directly.

Yeah, if you go into the system with an idea of what you want, we want you to be able to get it. Currently, that's a bit more difficult because you have to sort of comb through the system for the tools that you need. And that was in service of trying to explain this novel system, but it muddied up those choices. And so we're trying to clarify those choices so that they can be a little bit more useful and available when players want to use them.

This is actually something we talked about. And then I was like, all right, that's great. We made a task and it was at the bottom of like 20.

And then Spence goes, Sean, do you want emote animations, or do you want the heads to blend when you press X so it actually goes away? And it's like, we've got to make a call. And I'm like, yeah, I want them to blend. And actually, we tried to get the different animation at the end in time. I don't think we made it.

Oh, that got in. It is in. It kind of cuts to the new animation.

Oh, really? We've got to maybe update the Mannequin blend time. I didn't know it got in, because we did get some animation at the end. Nobody liked the pose that we had at the end, because it was super slouchy. The female looks very slouchy, and with the angle of it, at that FOV and with that perspective, it makes her head look tiny on the body. It does to the male, too, to be fair. It's just more obvious on the female. So short answer is, yeah, we want to get that, but it'll become a priority call once we get closer to the end of the quarter, I'm sure.

Yeah, we wanted to expand the review step with a lot of those sorts of things: checking out your emotes, checking out different loadouts, checking out different lighting situations.

That's right. And I don't know if we've talked about it much, but the example I keep using, and hopefully people recognize it, is the XCOM photo mode, or XCOM 2. When you were making your soldiers, you had this great little photo mode that you could go into, where you could see different attachments on them, put different backgrounds, things like that. That was kind of the mentality around review. We'd also like for V2, and I'm not sure if we put this in the estimate yet, to have the different loadouts. So we'd like to be able to show you guys at the end of that, similar to how other character creators in MMOs generally work, where they like to show you the really, really awesome armor, like endgame, perfect, you've got everything. So I can imagine just having three loadouts within it would be nice. So basically, no clothes, civilian clothes, and awesome armor. So you can just see how your character is going to look with each one of them. I think it would be a nice thing.

Yeah, and conceptually, right? And Andreas is very keen to do this. And he's pretty confident that he can get there. Keen and confident. That's why I adore him for that, because I have my own reservations about it. I'm not sure. It's a technical and a bit of a visual thing, too. We have about 1,500 character items right now. When we did the facial attachments, there were like 50. Not a big deal to go over the facial attachments and put in the markup for the facial customization and the runtime deformers needed. A little different story on 1,500 to 2,000 assets. And that's what's getting harder and harder, by the way, about doing systems within Star Citizen and for the game: the sheer breadth of content that you sometimes have to update makes a very real impact on the feature. Like, are we going to do it this way? Because, holy, that's a lot of updates that we've got to make across it.

It's easy to balloon from there. You're just talking about character assets for what they're wearing. You're not even talking about what has to change about their animations, what has to change about anything regarding the seats and the ladders.

That's true. So I don't expect we'll do anything with the heights, but absolutely the body shapes, we do want this. It's just there is a technical challenge within it, and there are different ones than the face brought, but I have lots of confidence in Andreas and Ivo and those guys over in Frankfurt. And they are absolutely looking at it, but we can't promise it at all, because we don't have it working yet. But we'd like to. And if we get there, it'll use a very similar system with the runtime deformers. It'll be quite interesting, I think, once we get there.