As per usual, anything said during the show is subject to change by CIG and may not always be accurate at the time of posting. Also any mistakes you see that I may have missed, please let me know so I can correct them. Enjoy the show!
FPS Weapons Team:
Finished the second art pass on the Klauss & Werner Arclight 2, Galant, and Arrowhead.
First art pass completed on the Kastak Arms Ravager 212 and second art pass on the Devastor
Ship weapons completed all rockets and rocket pods from sizes 1-3.
First art pass on the Knight’s Bridge Arms Ballistic cannons which uses the new modular tech for upgrading and combinations
Hired a lead lighting artist who is working on integrating the lighting with the modular outposts and the challenges the procedural generation of the insides and outsides bring.
They’re also creating a visual target for the main rooms: Habitation, hydroponics, engineering, storage to push the lighting interior even further.
Level Design Team:
Working on the space station and outpost modularity system.
Going forward they’ll start with the 5 outposts versions they’ve determined.
Truckstop is the first test of the modular space station system.
Finished physics grid refactoring.
The old CryPhysics grid system worked on a fixed physics 2D array of cells in unified dimension which were huge. This worked at first, but due to scale they needed to change and as such they’ve created a fixed hierarchy of nested 3D cells of various sizes.
This change allows the scaling of objects as big as planets, to small pebbles.
Initital tests in Crusader showed efficiency up to 10 times less entities returned for small query and general queries of 1.2-2 times faster while using just slightly more memory.
Evo Herzig has been busy building the core foundation for AI movement.
His work has been about taking mocap data which is used for fixed and predictable scenarios, to unpredictable and varied interactions.
The system created is called parametric blending which seamlessly allows AI to perform a variety of animations in a natural motion.
The video played during ATV on his section shows how parametric blending works in detail.
Engine team also made improvements to object blending with the terrain which will be shown soon.
New Senior QA tester James stevens has joined the team in helping refine the loadout editor and testing the new Solar system editor, Soled.
Completed mission functionality for SQ42 and the PU.
Worked on improving the setup for scenarios involving multiple characters interacting with one another simultaneously.
Subsumption tool has had some improvements for conversations and work on conversation sub activities has begun. Sub activities are the logic for multiple characters in one view
Completed first pass on refactoring the perception for spaceships to allow AI to interface with spaceships when inside them and control the behaviors of AI on spaceships.
Work on new SQ42 scenes and polishing existing ones.
Continued work on planetary effects such as atmosphere and weather effects and more specific effects for various types of assets being used by the object scattering system.
Focused on finalizing the moons and the procedural asset distribution system has made a lot of progress with improvements being made.
Brian Chambers said: “All the pieces that make up our procedural planets and moons are truly starting to fall in place you could say and things are looking great”.
The final art stage is about the extra polish, making the ship function, feel and even explode in the right way
A favourite step is using POMs as decals to give the illusion of more geometry where none exists.
Animation is next in the steps and is described as a family affair
Function, timing, flair and then character interactions are the next foci
The process reminds Elwin of building and playing with puppets
VFX is now allowed to come in and work their magic and uses R&D, the ship's unique animation along with Drake lineage to create a first pass which is reviewed
After feedback, polishing, signing off and optimization it's considered flight ready
UI likes to be involved from the beginning, but are hands off until the very end if they share the same template systems, but still give them their own unique feel
Audio production starts on large ships first as they need the most work, but all deserve the same emotional connection with the player's
Part of a Herald's charm is that it feels like it might explode any second
Many conditional layers are used to produce a very organic feel and give a voice and realistic flexible character to each ship, even in ambient sounds
Drawing inspiration and sound from the other Drake ships is not a simple copy-paste affair
Flight ready stage is the last stage and involves building damage
Lots goes into modelling setup, and lots of different meshes have to be adjusted and worked with to get things looking right.
Once the modelling is done, they do UV setups, which prepare for the damage models. Then there’s making sure pieces break off correctly, and making everything is powered, and adding smoke / light / particle effects, etc…
Lots of work, and lots of people, have a hand in creating even just the models and effects for ships, then the ships go to finalization.
Eric Kieron Davis (EKD): Hello and welcome Around the Verse, our weekly look at the development of Star Citizen. I’m Eric Kieron Davis, Senior Producer
Steve Bender (SB): And I’m Steve Bender, Animation Director over here at CIG. So Eric I’ve heard you’ll be on a WonderCon panel this Saturday?
EKD: Yeah! I’ll be joining Narrative Designer Chris Avellone. Author Janice Davis, Screenwriter Adam G Simon, and Composer Sean Pak to discuss how to make a career as a creative professional.
SB: Very cool, and that’s for WonderCon attendees.
EKD: Yes, if you have a badge you can attend and I’d like to see anyone who can make it there on Saturday. Event details can be found online in your WonderCon program.
SB: Awesome. Well we have a great episode today. To celebrate its reveal in the 2.6.2 patch, we can finally share part two of the ship pipeline video that follows the completion of the Drake Buccaneer.
EKD: But first let’s go to Brian Chambers in Germany for the Studio Update
Brian Chambers (BC): Hi everyone. I am Brian Chambers, the Development Director here for Foundry 42 Frankfurt. We started Foundry 42 Frankfurt a little over two years ago with six employees. This past month we just signed our 70th member of the team, seven zero. We’ve come a long way in a short time from an office mostly filled with empty desks to now an almost full office working across most all disciplines.
This past month has been busy as usual. At one point we had I believe 15 visitors here from other offices working across various disciplines. We occasionally travel to the other offices to meet and discuss future plans, review progress in certain areas, kick off large tasks, etc.
So let’s jump right into it and see what the team's been working on over the past few weeks.
Starting off with the weapons team. The FPS weapon artist finished the second art pass on the Klauss & Werner Arclight 2, the Galant and the Arrowhead. These now include new venting mechanisms which add much more visual interest when you’re doign things such as a reload and so on. They also completed the first art pass on the Kastak Arms Ravager 212 and the second art pass on the Kastak Arms Devastator with an additional layer of detail.
For the ship weapons, we completed all the rockets and rocket pods ranging from size one, all the way to three as well as the first art pass on the Knight’s Bridge Arms ballistic cannons. We can now use those various sizes to test out the new modularity system and various upgrade levels and combinations to see what we can come up with.
In the office here in the Frankfurt we recently hired a lead lighting artist to work with our global lighting team. One of his first tasks was modular surface outposts and determining how we’ll integrate lighting in such a way that it will feel coherent across potentially countless permutations of the outposts layout. Every single room can have a different arrangement of props and objects which then dictates where lights would logically be placed. As well as the specific theme or mood for that room that we’re after. For example crew sleeping quarters need to have a different mood than a hydroponics lab, etc. Our first step though is to integrate simple lighting variations into the procedural system so we can discover and solve any issues that may arise such as light leaking through walls or certain lighting variations looking incorrect when placed next to each other and so on, so you can really see what conflicts.
At the same time these technical challenges, we’re also focusing on creating a visual target for our main room types. Habitation, hydroponics, engineering, storage, see how far we can push the lighting to match our concepts and goals for the interior look of our surface outposts
When these are finished we can then determine how to break the lighting down into modular components, they can then be fed all the way back into the procedural system and be applied to all the other procedural bits we have.
The tech art team in Frankfurt worked on multiple skinning tasks this month including clothing for both the PU and Squadron 42 to widen the range of character customization and a skinning pass on the final Vanduul mesh so the animators can work across on their animations. They worked on a tool for the animators to redirect their walking animations to turn animations. It’s a fairly simple turn, but it ultimately will reduce the time the animators need to spend on creating those specific animations. In the sense it allows us to reuse and recycle. They also created a tool to allow the teram to quickly update the exact brick placements of individual weapons. Artists can now you a reference mesh to create an offset, export and immediately see the changes live in engine. This makes things much more efficient, allows them to iterate much quicker than before.
The level design team here in Frankfurt is busy working on the modularity of space stations and surface outposts as seen in a recent ATV episode. As an initial proof of concept, we have five versions of the outpost that we’re moving forward with. In the future we’ll be able to create a large number of outposts with different layouts and purpose, but as initial step we focus on just the few to ensure that the systems, props, placement of planets, blah, blah, blah, is all working together as we intend.
The truckstop is our first test of modularity in space stations. We’ve been working on customisable hubs to be able to create variation using add ons and procedural placement to add flavour to various rooms. The modularity of space stations also extends to how the rooms connect to one another following premade flowcharts. We're currently working with engineers to get it functioning in game and get it all going the way we actually intend it to be.
The system design team has been continuing their work on the useable system as we’ve also recently discussed. They’ve also been working with the cinematics team in helping to establish the final look and feel that we’ll have for the conversation system and the progress is going good.
For the engine team we generally discuss what they’ve been doing for the procedural tech and they continue to make great progress there, but I thought I’d dig a little deeper into a couple areas this month. So, yeah, here it goes.
We finally finished the physics grid refactoring which is used to store each individual physical object in the world and to allow for fast neighbour queries such as give me all the objects within 10 meters, and it has all the bells and whistles now active.
The old legacy CryPhysics grid system worked by projecting the entire world onto a fixed physics 2D array of cells of unified dimension. For memory reason the old system was configured to huge cell sizes to allow for our massive worlds which led to severe performance problems when dealing with lots of small objects as well as lots of entities returned due to the fact that the grid would wrap around every few thousand kilometers.
To address these issues the new grid system was designed to have a sparse and fixed hierarchy of nested 3D grid cells of various sizes. For objects would get inserted into different levels of the fixed Hierarchy depending on their size. We can therefore efficiently handle objects of the size of a planet several thousand kilometers in radius, down to small pebbles just a few centimeters across.
Initial performance tests once it was in, in the Crusader have proven the new grid to be vastly more efficient. 10 times less entities returned for small queries and queries in general in the faster magnitude of 1.2-2 times while using slightly more memory than our legacy system.
On the animation front, our Lead Animator Engineer, Evo Herzig has been busy for quite some time. He’s been building the core foundation for our AI movement. I want to give you some insight into his progress and give you some examples of what he’s been working on. Most of our animations were motion captured which is a perfect solution for cutscenes and linear animations where things are fixed and predictable, but you can’t use mocap data directly for animations that need to be truly interactive like we’ll have from both the player and the AI.
To use the mocap data in interactive situations, we must break down the longer motion clips into short clips and generate multiple variations of the same motion style. As an example, for a simple walk cycle we need walking at different speeds, walking in circles, walking on slopes and walking in different directions such as strafing etc. A typical AI character in Squadron might have about a 1000 of these small motion clips. It’s impossible to create unique animation clips for every given situation. That’s why we developed a blending technique that we call parametric blending which enables all these clips to be controlled at runtime. Parametric blending takes the concept of simple animation blending and moves it to the next level. The goal is to make the outcome of the transitions or an interpolation, predictable for an undefined number of assets. Each motion clip contains a combination of physical and stylistic properties. We call those the natural motion parameters because they’re inherently a part of the motion itself.
To control a character in a game we want to pass these natural motion parameters to the animation system and let it generate the motion we need itself. Once we have enough animation clips we put them into what we call a blend space, the most important aspect of a blend space is that each animation clip represents a point in a coordinate system and all points are connected by an index list. In a blendspace we treat blending as a geometric program. The geometric relationship between the animation clips is extremely important for the blending to work correctly and the placement of these assets into the blendspace is setup so it’s fully automatic due to how the animators set up their locators before they export their animations.In a single blendspace we can have more than a hundred unique animation clips and we can control all of them like a single animation.
What you see here is an example of a 2D blendspace. In this case, we put the travel speed on the X and the turn speed on the Y. We can move the red cursor over the plane and for each coordinate we get a blending motion with the correct parameter. This means we can generate all motions between a slow walk, and a fast walk while maintaining the correct turn speeds. In this test area we can move the cursor in any place or direction and always get the correct blending motions back.
Here’s an example of parametric starts and stop that lead in and out of the walk cycle. You can see how a character starts to walk in the direction we select and then he walks at different speeds with different turn angles and stops to the left, right, right foot, left foot, etc. Blend spaces are not only limited to simple motion cycles. They can be used for most AI motions in our vast universe, enabling our AI characters to move fluidly and realistically throughout the entire world. It’s great to see both progress and it’s definitely going to have a strong impact on how our AI navigate around the world.
The engine team also did improvements to the objects blending with terrain. The underlying terrain and object shapes are now taken into account to blend procedural distributed objects more naturally with the planetary generated environments and hope to show you those improvements soon.
The QA team here in Frankfurt grew by one member this past month. James Stevens, our new Senior QA tester. He immediately stepped up and took charge of pioneering the testing of the loadout editor. The loadout editor is heavily used by our devs across all four locations. So it only made sense to increase the depth of testing we do for it on a daily basis. Melissa Estrada also spent some time testing the first version of the solar system editor also known as Soled. The engineers went over Soled’s functionality and we gathered initial feedback from the team. QA was there, they documented all the feedback and now they’ll work closely with the engineers to find the best way to address each item and how to test it and work with them in the future to get all those resolved. They also supported the engine team with testing of a few separate things such as updated planet physics grid and refactoring of the texture streaming logic.
The AI team this month completed some mission related functionality for both the PU and Squadron 42 designers. They also worked on improving the setup for complex conversation scenarios where multiple characters need to interact with one another. The first step to achieve this was to allow the subsumption logic to run on top of the players. This allows us to execute some logic on the players on predefined story scenes, but also make sure that the AI system can fully communicate with the player and interact with them.
The subsumption tool which you’ve heard a lot about has also had some improvements on the conversation setup and kicked off work on what we call the conversation sub activities. The sub activities describe the logic for multiple characters in one view to make it easier for designers to synchronize interactions between the characters and the environments. Under the hood, these conversations will still result in unique sub activities that will run on different characters so that we can still guarantee that each individual entity can still handle further event and situations on their own. They also completed the first pass on refactoring of the perception for spaceships.
We currently have a general perception component on characters that can handle several types of senses. Normal human will obviously have things such as vision and hearing, but once sitting down inside a spaceship, they’ll also be able to interface with that spaceships radar and the group information about the different senses into its perception component. This now allows us to progress easily towards more character controlled behaviors on spaceships since we’re removing strict dependencies between the game code and specific behaviors running on the vehicles themselves.
Cinematics team as always is making steady progress across multiple chapters this month. Some implementing brand new scenes, some are polishing existing ones. As I previously mentioned I unfortunately can’t show anything specific at the moment without spoiling anything and they’ll all yell at me. In the coming months we’re hoping to show you a few bits to really give you an idea on the quality bar we’ve set. We’ve set the bar high for ourselves and it would be good to show that on the work that we’re proud of.
The VFX team here in the Frankfurt has continued working on planetary effects. The systems for implementation have been progressing nicely thanks to the close collaboration between the VFX artists and our engineers here. They started implementing some of the new effects on the planets including various atmosphere and weather effects as well as more specific effects for various types of assets that will be distributed with the object scattering system.
The Frankfurt environment team has been primarily focused on finalizing the moons. The procedural asset distribution system has seen a lot of progress and is still improving. All the separate pieces that make up our procedural planets and moons are truly starting to fall in place you could say and things are looking great.
So that’s wraps this up from Frankfurt. Thank you for all the support everyone gives us on a daily basis. The team honestly truly really appreciates it and I’ll see you again soon.
SB: That look at parametric blending really shows how creating something like walking animation which sounds really very simple, is actually difficult to do in an interactive universe.
EKD: Yes there is a lot of iteration involved in developing new gaming tools, but it’s worth it especially when you want to create a detailed a realistic final product.
SB: As you may have heard, the 2.6.2 update was released to the PTU. We’ve been receiving helpful feedback from players which the team is using to fix as many bugs as possible before it goes live.
EKD: And as you probably saw on the forums, the latest patch includes an addition to the Drake Interplanetary lineup, the Buccaneer. We decided not to announce the inclusion of the Buccaneer before the Evocati release because we weren’t sure how the untested ship would fly. Fortunately the Buccaneer surpassed our expectations. To celebrate, we’re having a Drake sale. For the next 10 days you can get the Buccaneer, Dragonfly, Caterpillar, and more.
SB: Speaking of the Buccaneer, awhile back Sandi Gardiner and Forrest Stephan premiered part one of the ship pipeline featurette. In it the team followed the ship through the first half of its production pipeline to showcase the process each of our ships takes to become flight ready.
EKD: Yeah and if you haven't seen it I highly recommend going back and watching that featurette to see how the Buccaneer went from concept art to basic whitebox model, and then back to the ship artists for the greybox phase.
SB: Well with the ship flight ready, we can now share the second part of the ship pipeline featurette. We’re picking up right where we left off with the greyboxing of the Buccaneer completed, take a look.
Elwin Bachiller Jr. (EB): Last time we spoke about the white box stage and the gray box stage. Since then we've moved on to doing the final art stage and what we call flight ready stage.
Matt Sherman (MS): And that's really where it's just putting the extra polish into the ship, making sure not just that it flies, but that it flies how we want it to, not just that you can blow it up and that it takes damage, but that it looks fantastic when you do that. It has the right amount of health. Its shields are working and soaking the amount of damage that we're intending them to, and really just putting all the final touches on the ship.
EB: What we essentially do is we finish off the surface of the ship, so we decide what materials any of the geometry is going to be, so if we're going to go with a raw metal or painted metal we'll make sure we create all the textures necessary for each material. So, you know. We have wire textures. We'll go ahead and use POMs, which is parallax occlusion mapping textures, basically a decal which makes the surface look like it has a lot more detail geometry wise than it actually does. And we'll use that in order to add rivets to the surface, cut lines onto the wings as an example where no actual geometry exists, so it looks far more detailed geometry wise than it actually is, which makes it more efficient to run in engine. It uses less resources, but it looks great. It ends up looking like there's tons of detail on the ship, and it's actually one of our favorite parts to start working on. Once we get to that stage it really is about detailing it and sort of bringing the ship to life in terms of the way it looks, because we have a lot of freedom as to how we make these cut lines, you know, start dancing across a ship without actually having to affect the geometry in any significant way. We'll make sure during that stage also to finalize all the animations, so we'll bring in Jay Brushwood in Texas in order to finalize all that, change the timing on the animations if we need to.
Jay Brushwood (JB): Finally get to get my hands in it and get nitty gritty in terms of setting up pivots, the hierarchy structure of the ship, and for those of you that don't know the hierarchy is basically a parent-child relationship. For instance it's like your hand being a child of your forearm. Your forearm being the child of your upper arm. Same thing … deal on the ship. We've got all sorts of hierarchy structures where things can branch out and do their own thing. For instance with the landing gear the foot of the landing gear's going to be attached to the ankle of the landing gear and then we might have pistons that go in and out of each other and that allow the landing gear to fully retract in. And so anyway after setting up all that, I get the opportunity to go ahead and work on the timing of the animations and this is where you actually add the bit of flair with overlapping action and a lot of other principles of animation of how things deploy and the various parts of the ship that we end up setting up animations for are things like the landing gear, the ladder entry, the canopy opening and closing. All sorts of this stuff needs to be worked out, and then we export that all to game, and once that's exported to game the next thing we do is we set up the character interactions. And this would be the character climbing in and out of a cockpit, opening up a drawer, opening up a hatch, all the various things.
EB: For me the whole process is building a puppet that I then get to play with and the animation part is where it comes to life and that's where the illusion sort of comes together. This is also the stage where we allow the VFX team to come in and start doing all of their effects for thrusters as an example.
Mike Snowdon (MS): So the difference between the effects that you'll see on the Buccaneer compared to other Drake ships would be pretty much driven by what that ship looks like and what the function of that ship is compared to the other ships. I suppose the best example is the thrusters, so the color scheme and the style of the thruster effects for the Buccaneer they're going to be sharing similarities with the other Drake ships; however, the thrusters are a specific shape on that ship, and the thrusters actually animate in a specific way to that ship, so that's going to drive what our effects look like compared to the other ones. So the VFX pipeline itself we will have … we will go to from the R&D to the block out we then have the first pass, which is the artist's first attempt to get an effect that's kind of good as he can get it, and then that will get reviewed. We will provide feedback from that review, and then it goes into the polish pass. So the polish pass is … once that's done, and once that's signed off, and it's been optimized as well, because that's a big part of the getting the effects finished in the game then that's it then. The effects are done for that ship, and we consider it flight ready.
Treavor Wernisch (TW): UI likes to be involved with kind of all milestones of the pipeline from the gray box to the white box. Overall a lot of the ships use the same UI style. There's definitely quite a few that will require unique screen shapes and sizes. We have a lot of great upcoming ships that have very unique bespoke designs on them. So the earlier we know about those designs, the quicker we can start working on the visual side of things, but as for the Buccaneer and a lot of other ships they … quite a lot them use the same template systems, so UI can be hands off until the very end. When it came to doing the Buccaneer thankful we had a very clean and smooth pipeline introduced already so plugging the new screens in was instantaneous basically after the 3D modelers came in. There is very few customization that needs to be done. Eventually we want to have the Drake ships have their own look and feel, the Anvil ships, everything kind of while they might all have the same screen sizes and screen ratios, we want them to have their own unique colors and feel and different shape language.
Darren Lambourne (DL): Our audio production, Nichola Grelk, takes care of communication between our discipline and other disciplines. We can see that the sort of large ships coming down the pipeline. We can allocate time to work on those. Smaller ships are going to be … going to require less time so the smaller ships tend to wait until more towards the end before we start working on them. But they all need to have the same amount of emotional connection with the player. So for example with the Drake craft we're looking at the lineage, the Herald, the Caterpillar, these are the ships. What they sounded like and what they felt like to fly. It's quite different from the Buccaneer. The Buccaneer is far more kind of finesse than say the Herald. The Herald is like a can with a rocket strapped to it. I mean it's like it's going to explode any second, and that's part of its charm, you know. It's sort of agricultural, and this is the feeling we get from it. But we can only really tell that when the ship's got all it's decals and detail and … and stuff. In situ we can decide what mat that should sound like.
Here's the Herald thrusters for a quick comparison. [Thruster Noise] So you can hear that engine, its roar. You're strapped to a rocket. And here's our Buccaneer. [Finer Thruster Noise] That's the Drake sound. Yeah ... The thrusters are made up of lots and lots of layers. Here's one of them that gives it a very distinctive tone as we traverse the thrust range here moving up towards maximum thrust. [Isolated Thruster Component Modulating] Hear the sound morphing and changing in character right up to the top and then back down again. That's kind of a synth layer in the background giving it some character. So this synth element is just one element of many that make up the compound thruster sound that … look how many real time parameters are bound to this single synth sound. All of these here are going to react to the player's input to the ship controls, and they all change the pitch and the filtering and the volume of the various elements which gives it a very organic feel. You know as one element rises in tone with a strain on the ship, another electronic buzz might fall in tone in a sympathetic way and in turn that provides a very natural interaction within the sounds. And that's exactly how we give the ships more of a voice, a realistic flexible character, and this extends to even the ambient sounds in the ship as well. They all have these real time parameters assigned to them.
Taking the lineage from the other Drake ships and bringing it across to the new ship is what we're trying to do, but also create something unique in the new ship. It's not like a kit bash. It's not the sort of copy paste from an old ship to a new ship. It's about taking ideas from those other Drake ships and bringing them across into the new sound design sessions for the Buccaneer, but creating something unique in the process as well.
EB: Then the last stage in the process from the art side is the flight ready stage, and during this stage we are not really focusing on what the ship looks like anymore. We've already finalized that, but we are filling in some of the gaps that are necessary for game-play to be fully fledged on the ship. So what that means is that we need to build damage.
Matthew Intrieri (MI): I am involved in every ship in the pipeline. I jump in about white-box stage, after concept’s done, the modelling gets laid out, design has put some features in, I’ll go in and I’ll look at what the design is, what’s been done so far, and start to think about destruction. Very early on we start to think about how the ship will break apart. So we’ll talk about how the meshes get divided very early, and in the case of the buccaneer, Pat handled the damage and the lighting, and I handled some of the optimization work. And what we did for optimization was we do a process called skinning, and it’s like rigging a character, where you make several meshes a single mesh, which reduces draw calls, which improves performance, and that also needs to be hooked up through our mannequin animation platform, and driven through say the thrust of the engine, needs to dilate the nozzle of the engine, so I’d hook that up, and the landing gear of the ship needs to deploy and allow you to rest on a platform, and have proper collision and materials.
And so I handle all that.
Patrick Salerno (PS): When I get the ship from the artists the first thing I do or start to set it up for detachability. What that usually entails is going to MAX and the XML, setting up the variety of components, like the wings detaching, and normally in this stage we’re getting this done so design can start to iron out health values and how parts break off and how it affects the flyability of the ship.
So before I even get into doing shaders and effects and making it look pretty, just got to get it to work.
After I do all the detachments, I set off how the pieces fly off the ship, and those are called vectors. So when you blow off a piece of geo, it’s going to spin around, right? And that’s based on its pivot point. And then that’s going to rotate and then it’s just going to go flying off into space, so I set up how that works. After that I also go into the XML and set up pieces that will detach with other pieces. So say for example you blow off a big huge engine on the buccaneer, but there’s a wing attached to that. There's also a thruster, and maybe there’s a little wing flap behind it. You ask yourself, if the explosion’s big enough, would it take off these other pieces surrounding it? So shoot that and then you can have extra pieces fly off with actual probability, so it’s kind of random, whether pieces fly off.
That’s actually just the sort of damage set up phase. I want to get into making sure everything starts to look appropriate when it breaks off. That involves getting ready for shader damage that we’ve added, we’ve talked about that, where we have procedural damage shader which melts across the surface. For that we needed to do what’s called UV2 setup, and now, if you know, UV’s are how your texture gets mapped onto the surface of an object. So, in our game, we have two sets of UV’s. We have one set of UV’s for the basic texture on the surface of your ship, and we have another set of UV’s for your damage map to melt and wear across. You’re creating like a mesh that closely resembles the shape of the actual ship, and from there it’s kind of trial and error actually, there’s really no tried and true methodology for it. We’re kind of working it out as we go. Quality keeps getting better as we go through, but that’s a basic setup.
So now what I’m doing is once I get in the editor I start shooting shit, I’m testing it. I’m making sure there's two types of damage happening, there’s a decal happening when you shoot, so a bullet hole will leave a burn or a bullet ding. But there’s also the shader damage which can happen around it. Now, the shader damage works for different weapon types, so a laser will leave a melty wear and a bullet will leave an actual indent that has metal. As you keep shooting shooting shooting, you can tear a hole. As you tear a hole, the modellers have prepped it so that there’s internal damage.
KT: Before tech art can implement any of the damage, we have to build it. So we need to actually generate the content that gets revealed in the damage process, the actual setup of it. So we’ll do internal damage structure, so this is like I”ve mentioned before, this is where we build the internal structure for the wings and the body so that there’s something there to show, and we will also do an initial pass on what we call the UV2’s, essentially it’s just the second UV channel which we use to generate procedurally, on the fly, an alpha map which then tells the engine where to reveal the damage on the ship.
PS: After I”ve done the UV2’s and I’ve tweaked in and it looks good and there’s lots of melting metal and all sorts of fun stuff going on, I move on to the V effects. Now, there’s multiple people working on V effects. I’m doing more preparatory V effects. Since I do the shader damage, there’s two parts to it. There’s what’s called squibs, which are little kind of explosive charges which create shader damage in a radius, I set the radius min max, and then there’s actual particles, like fire, electricity, smoke, explosions, you name it. Now, I don’t actually build the particles, but what I do is I go into a library where all the particles are held and I start to set up all the pieces and I pick effects, and I put them where I think things are exploding. Are there tubes here? Maybe there should be gas, something like that.
After I set all that up and it looks great and there’s parts flying around and fire and smoke and stuff, then I send it to the actual particle guys who then do an optimization pass, make sure I’m using the correct libraries, and the very last final bit is actually making sure that everything detaches correctly. So, when a piece blows off, does the gun go flying off with it?
Artists will generally do the lights on their ships, so they’ll do that as part of the art pass, and then we’ll have the components so, if a wing flies off and there’s lights on the wing, the lights should fly off with the wing. That’s part of the setup. It’s common sense, but… usually there’s a bit more setup to it than that.
So, with lighting there’s two things. We have what’s called prefabs for multi-light, which means when a player gets in a cockpit seat it then powers on all the lights around him. Then we have what are called object container lights, which are slightly different; object container is a new tech, someone else will talk about, but basically when we have lights in an object container they’re always on. So we use these mainly for more interior, sometimes aesthetic lights that always just need to maybe be on. Anything needs power, fits in a multi light. I do all that in the ship setup level, so that’s kind of post-phase, but that’s the final phase, and from there it’s polish. You just shoot it, make sure everything looks good, there’s no bad UV’s, no parts hanging on, etc.. etc…
But for the most part, that’s the tech art pass, and then it goes off to all of the departments for finalization.
MS: One of the interesting challenges that always pops up is that for finishing off the ship are sort of the random things. It’s like, oh crap, I can’t believe I forgot that, or, just chasing down why something doesn’t work for no reason. One of the more notorious aspects of that is usually our collision. So we’re actually just getting the landing gear in, it all functions and looks proper now, but occasionally it doesn’t want to act like it’s turned on, so the ship can fall through the ground and just blow itself up for no reason.
PS: Right now i’m chasing up several loose ends. We’ve got some shader issues, we’ve got some texture issues, so I’m also chasing up issues with the thruster not delivering parameterized values to our nozzle correctly, and the glow on the material that’s inside the engine. These things will all be solved before the public finally sees it.
MS: And it’s just getting those little parts lined up where it's like, okay, do we have to adjust this, or help that get cleaned up, or do we have to adjust the landing gear itself, and start chasing down almost which discipline it’s like, okay, this is going to be the cleanest fix for our problem. This is going to be the best fix in the long term for making sure that, if we have to do something similar again, it’s like oh, we can refer to this ship because we fixed that really clean there this way, and we can apply that to whatever other ship you want to.
Andrew Nicholson (AN): So I’m probably the last step, the last person to get hands-on with the ship, and that’s kind of an overlapping stage, where test and myself have a little back and forth when the ship comes to us. And it’s about tweaking and taking what’s already been designed for, making sure that that’s the way it is in-game.
The process of balancing it is kind of, you need to be able to see how, it’s kind of like ranking it in with all the other ships, really. So, being able to see how all the other ships compare to each other. That’s kind of my job, to make sure that nothing comes in, with flight tuning in particular, this ship does not out-perform where it should be, it’s not too fast, it’s not too maneuverable. Where it should sit right where it should sit. It’s a difficult thing to get right, and it’s often a lot of back and forth, even now, with testers, internally and externally, where they point out mistakes or imperfections in the flight model of the ship, the flight tuning of the ship.
It’s, when it comes to weapons, it’s kind of the same. We need to make sure that the ship loadout isn’t too powerful, when it comes to dogfighting against each other.
When it comes to finding problems with imbalance, like with weapon loadout for instance, it’s up to me to point that out to the designer in charge of the ship, see if there’s any leeway. The buccaneer being another example of that, of having a very large loadout of weapons, it hits really hard, it packs a punch. I was concerned about that. That it may be overstepping its bounds a little bit, in terms of the wider balance.
So that conversation we had, it’s all about the tradeoffs. So if we can ensure that that ship is weak but still hits hard, that’s fine. That’s balanced.
MS: I’m really not sure I’m supposed to be talking yet about this stuff… we’re not really going into all the details of the company right now
SB: There’s something shady happening at Drake Enterprises that you won’t want to miss. And that’s it for this episode of AtV. We want to thank all the subscribers out there who make this show possible. For the month of April, subscribers can test-fly the Gladius Valiant. The Valiant is the first ship to defeat the Vanduul in combat.
EKD: Sounds like an awesome dogfighter. We’re also giving active subscribers a Big Benny’s vending machine flair, on April 17th. So, if you’ve been thinking about becoming a subscriber, join before April 17th to qualify for this deal. Click on the link in the description below for more information.
SB: Of course, Star Citizen exists because of our backers, so thank you again for all of your support. Tomorrow, kick off your weekend with Star Citizen: Happy Hour, at 12 pacific. Ben Lesnick and Jared Huckaby will be playing one of Chris’ classic games, Wing Commander Privateer. Ben will also share some little-known history about the game’s development.
EKD: Thanks for watching, and we’ll see you
Both: Around the ‘Verse