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!
Sandi Gardiner (SG): Hello and welcome to another episode of Around the ‘Verse, our weekly look at Star Citizen’s ongoing development. I am Sandi Gardiner.
Chris Roberts (CR): and I’m Chris Roberts.
SG: On today’s show we’ll be visiting various moons and planets to show you how our procedure planet tech works.
CR: Yes, but before we go exploring let’s head to our UK office for their latest studio update.
Phil Meller, Lead Designer (PM)
Hi everyone and welcome back to the UK for our Wilmslow and Derby studio update.
Our focus over the last month has been on getting 3.0 to everyone as soon as possible as well as continuing our ongoing work for S42.
For 3.0 we have been closing down the remaining features and much of the team is moving on to bug fixing, polish, and optimization tasks. So, let’s start with what’s been happening on our technical sprints this month.
On the programming side, we’ve been helping the cockpit experience sprint with a goal of making the feeling of sitting in your ship much more dynamic. Some of this is incorporating psychological effects such as black out and red out into the actor status system. So, it’s all controlled by one system which can influence things such as player’s breathing and stamina. This sprint is also improving the G-force animations, player hit reactions, when the ship gets a dynamic input.
Close combat is coming along very nicely. We have been working on some great knife-based takedowns and unarmed takedowns as well as working with design and animation to make it all look and feel extremely satisfying.
One of the less visible but fundamental underlying pieces of technology is the new actor status system or actor 2.0 and we’ve nearly completed converting all of the old player and actor code over to the new system. Whereas as previous setup just inferred actor states from other variables, we now have a much cleaner interface for serializing between the server and all of the clients. All told, it makes writing new player features much more straightforward and makes the code much more reliable.
We’ve also been working on incorporating the brand new patching system into our internal copy build 3 tool that was developed over in Frankfurt and Austin. Now that it has passed QA’s approval, we have started doing a limited rollout to the dev team to carry on fleshing out any issues with it. So far it’s looking pretty good and the people using it are really appreciating the reduced time it now takes to grab the latest build.
Moving on to the graphics team, the new render to texture system has been a key focus this month. One major issue of this tech has been the hologram system which will be used for mission briefings, comm calls, mobiGlas, and many other situations. The render to texture system will be used for all of our new user interfaces and we’re also aiming to use this for live rendering of video comm calls from other players. Our exposure control system had an upgrade to deal with the enormous contrast of lighting in space. The system now takes light from your peripheral vision into account and so should no longer overly brighten the screen when looking into space when you’re near bright objects. The graphics team have also added a host of new features to the GPU particle system such as lighting, turbulence, and anti-aliasing that will be used as cool new effects in 3.0.
The concept team has firstly been focusing on ship weapons. We have worked on the Amon and Reese laser cannons S1 to S6 and the Klaus and Werner laser repeater S1 to S6 along with some associated VFX. On a smaller scale but just as important, we’ve taken the Gemini manufacturer and created a slick-looking heavy machine gun with the iconic cooling system as seen on other Gemini guns. This month we took on a sixth member of the concept team who is looking at areas of the Stanton system and more specifically Horizon while also supporting additional needs on Squadron 42 locations. As ever, we continue to search this universe far and wide for more talented artists.
The environment art team has been building some exciting prototypes for procedural cities. This will allow us to create vast cities and landing zones on planet surfaces for the Stanton system and beyond. Work continues to flesh out texture of space and to provide a greater palette to make space travel interesting and at times support the narrative in both the persistent universe and Squadron 42. One specific element is our new space dust shader, allowing us to add large volumes of space dust to the Stanton system for the 3.0 release. Yela’s asteroid belt has also been improved which once again makes use of the new shader tech.
All of the major outpost archetypes have been finished. This includes dressing for different corporate and independent companies for various functions such as mining, hydroponics, habitation, and storage. We’ve also included some additional unique varieties such as emergency shelters, abandoned outposts, and gang ground outposts too. All outpost doors and airlocks have been switched to the door 2.0 system meaning that they can interact with different rooms, power systems, oxygen, overrides, and gasses. Outpost clusters and additional exterior elements have been finalized. This includes outposts, landing pads, paths, power modules, water collectors, weather stations, relay stations, and exterior lighting. The branding prototype has been completed and so now outposts are represented by several different corporate companies as well as independents and gangs. Planet surface integration is ongoing. Sand, dust, and frost materials have been finalized to help blend the outposts into the moons. Decals have been used to add an extra layer of dirt buildup and have also helped to blend in the exterior landing pads and props.
The team have finished all pre-polish and optimization work on the exterior truck stop pieces and have moved on to finish the interior. The main hub is currently being worked on based off concepts from art direction and additional pieces have been made to add more of a truck stop character. Props and lighting are currently placeholder. The side shops and corridors have had a first pass on them. The Platinum Bay shop is having its own building set made for it so it looks more distinctive and an admin office has been created so players drop off packages relating to missions. Finally, an observation room has been blocked out facing the landing pads, so players can watch the comings and goings of other players ships from the interior of the station.
Also, admin offices have been added to other Stanton locations such as Port Olisar and Grim Hex. All of the 3.0 locations have been updated with a new door and airlock system and two new shops have been added to Grim Hex - one is an independent ship parts trader and another, Technotik,is an old electronics store that may house a mysterious character.
On the UI front, work has been cracking along on the new mobiGlas UI and all of the other various new apps that will become available for 3.0. Last month we successfully integrated the mobiGlas and kiosk UIs using the new render to texture tech and the visual result has been promising in further achieving the look that the team is after. In addition, we’ve been working with the VFX team to couple the particle effects and lighting to help ground the UI projection within the game world environment. As part of this, we’ve been working to drive the second multidisciplinary sprint for the Starmap app, the goals of which are to implement the remaining functional requirements for the 3.0 release as well as improve upon the general visual fidelity and user experience from previous iterations. This involves focused collaboration between art, VFX, audio, and engineering teams to help bring together a refined experience. We’ve also wrapped up work on implementing the basic functional requirements for the new mission manager app, allowing players to view information on available missions as well as allow players the ability to accept, track, and abandon missions which have been accepted as well as view a log of the previous missions which have been completed or attempted.
Along with the work on item 2.0 ship conversion, we have started to implement the new pilot multifunctional displays which refines the UI of previous iterations and adds new information as well as capabilities in managing your ship’s systems. We’ve also been helping with the recent doors and airlocks sprint where we helped to design and implement new status displays for the various airlocks throughout the system which also utilizes the new render to texture tech.
The audio team has been involved in lots of different sprints and pipelines as usual this month. Weapon audio completed work on weapons such as the railgun and having made steady progress on derelict ship audio and the interior ship audio for the Javelin. The team is also helping to finish up the actor status system so that the breathing from the player works alongside dialogue more intelligently. A new outlaw music logic set was completed which will be reflective of the player’s reputation system. Also, various locations for the 3.0 release have been revised and improved in terms of environmental and ambient sound with members of the audio team even attending a character-based sound recording at Shepperton Studios.
The animation team has been working closely with gameplay programming to continue development of the takedown/kill mechanics. Weapon improvements and tweaking continues across the board for the upcoming 3.0 release. The jump mechanic is receiving some love to get a more flexible system to cope with various environments and gravity states. mobiGlas has been moved from a look pose to an aim pose to allow increased functionality. We’ve also added in some extra animation to the enter and exit states to make it feel more connected to the player. AI combat assets continue to be exported and tested where possible in engine. We’ve also been continuing the export of cinematic scenes for design to implement in-engine.
The Derby studio has been busy on 3.0 mission givers. Both are coming along very nicely and it’s exciting to see life being added to the PU. Facial animation is still being produced by the team for S42 and future PU releases. The mocap guys set up the system for a quick shoot in the new office space. It was great to see such a quick turnaround of the data from shoot to in-game in a matter of days. There was another quick audio headcam shoot earlier in the week for some last minute pickups for 3.0. The facial data is already edited and in production.
As always, the ship team has been up to a lot this past month. Work on the derelicts is coming to a close for this phase. We have the Starfarer, Caterpillar, Constellation, and Freelancer ready to be used in various gameplay missions both in space and planetary locations. The underlying tools to allow placement correctly on planets so that the ship components and wreckage all conform nicely has now also been implements. This will allow for some well-crafted artist-driven derelict sites while maintaining the ability to use those sites in various types of terrain. Coinciding with concluding of the derelicts is a bug fixing pass sorting out any issues such as collision or minor art tweaks.
On the Hull C the team has finalized geometry on the folding section of blocked in materials. We are currently in the process of finishing the mechanical rig and making sure it all operates smoothly without any collisions. The front end interiors now have an initial lighting pass and is being continually tweaked to help areas gel together. The rear of the interior has been blocked out and is now getting a modelling pass on a room-by-room basis.
Work on the Eclipse is well underway with focus currently on the cockpit. Extensive work is being done on the dashboard, collaborating with other departments to make sure that the layout is appealing and the monitors are legible. With the new item 2.0 push, it is important to place buttons and switches within the player’s arms reach to create further interactivity and immersion. The landing gears have been fleshed out and work on the wings has begun, starting from the outside and working towards the center of the ship.
Work on the Reclaimer is almost complete with only three rooms left to go through final art. This month we’ve wrapped up final art on the cargo room as well as the main lift. In both cases, we tried to maximize the space to allow for easier transportation of cargo. A huge amount of effort is going into making the cockpit functional in a tight area. We’ve implemented retractable screens which fold around the player when seated. We were hugely excited to see the tractor beam seats transition from concept to final art and we’re really looking forward to seeing people using them in the ‘Verse. The team has also been busy working on the bridge area and the bridge lift which provides access to the lower deck.
Well, that’s our update for the month. I hope you’ve all enjoyed seeing what the team in the UK as well as the rest of the world has been up to. As always, thanks for all of your support in allowing us to make this great universe. And of course, thanks to all of our subscribers who provide for us to be able to do these updates from the community. Take care and I’ll see you all in the ‘Verse!
SG: All the UI is looking pretty cool and coming along nicely. Searching the Starmap from your mobi will not only be helpful, but also is a great way to show the vast size of these systems.
CR: Yup no they’re pretty huge as you can see from the little Starmap demo as well as mobiGlas refractor is coming along really nicely, there’s going to be a whole bunch of functionality and apps that you’ll get in 3.0 that you didn’t have before so that’s cool as well as the various finishing touches we’re putting in on the environments like the outposts and derelicts which are also looking awesome as you can see from the episode. So actually looking forward to the point where all you guys can adventure around in that so it’ll be pretty cool.
SG: Another thing to get excited about with 3.0 is the introduction of our planet tech. Designing this system came with numerous challenges of its own including how to procedurally place objects like rocks and flora in a way that looks natural.
CR: Yeah so to learn how the team handled these obstacles and many more we put together an in depth look at our procedural planet technology. So let's check it out!
Marco Corbetta (MC): Hello, I'm Marco Corbetta. I'm senior technical director at Foundry 42, Frankurt. We're going to talk about planets today. So, what we're going to look at here today is the planet tech and some of the features we're going to include into our first 3.0 release. The planet tech is exactly the same type which we have been using for moons, planets, Delamar, the Delamar planetoid, Levski and so on. Each planet is unique. It has its own gravity, ecosystems, objects, weather and atmosphere.
If you look at the footage here the progress we've made since we started working on this, you can see the planet from space, and you can smoothly fly from planet to space without any cut scenes or interruptions. The major challenge here is that you can land anywhere seamlessly on the planet, and basically the only way to do this is to generate the planet surface as you are approaching it. The terrain's getting generated recursively subdivided. Objects are procedurally scattered on the surface as they're becoming visible as well as particles, grown betas and so on. When you are on the surface you are able to see objects like space stations, moons and so on orbiting around the planet in space.
Michel Kooper (MK): For our entering the atmosphere and getting closer to a planet in order to make sure that it looks good on all levels from high up to the ground, we have different artist driven input on each level. So on a global scale we have our colour map that defines the colours of the planet, then when we get closer we have our ecosystems that is defining our features. These all fade into each other and become one thing. The closer you get the more it fades towards the final result on the ground.
MC: We can also transition from a solar system down to a planet surface. Here we're showing the scale we're dealing with. You can see the different level of zooming from a solar system down to the different moons and planets. It's very challenging to deal with generating all these different type of environments at all of these different scale.
We have a fixed pool of geometry share for our planet and a fixed pool of memory used for texture streaming. Since you can land anywhere as mentioned before, the only solution was to procedurally generate on demand the planet's surface. The geometry is generated on the fly, and textures are procedurally combined at run time blending many layers. These allow seamless transition from space to planet. The source data use for generation is very small. For example, on these moons we are using only about five unique ecosystems for each planet. Each ecosystem has different properties, and they're all combined with other layers in nice combinations to generate a large amount of variations all over the planet surface. Another interesting thing is that we are only using 1K resolution full of textures created by our environment artist. These textures are used for planets generation. So, we have developed an efficient generation and blending to combine all these textures' layers together and still getting good results when you are close to the surface.
Pascal Muller (PM): The biggest challenge I think was what we've been working on lately is the scattering of all of these objects on the terrain. From the last update that we made we have done a lot of progress on the terrain and the textures. Here we could render these big mountains and oceans and all this type of stuff, but in the end the planets are still empty. There was no content. There were no objects, no rocks, no trees and all that. We had a very basic system, but that didn't really work for what we wanted to achieve. So most of the R&D time that we had in the last couple of months went into this object scattering system. The difficulty with the object scattering is to get a natural look. When you traditionally make a level for a game, and you have … you can place your rocks anywhere you like or your trees, and you can compose the scene where the player comes in and it looks … you have this nice vista and this background assets and all this type of stuff. Or we can't really do this on the procedural level. We cannot really place all the assets by hand, so we need a way that kind of automates this for us, and of course you don't want to ... you want this to look as natural as possible. So you want to have a little bit of control, but also want to have most of the work you want to be taken care of by … by an algorithm.
We developed the system that where you can kind of define what assets you have that you want to do a forest. You need some trees. You need some leaves. You probably want some grass on the ground and then you can define certain object groups, and say, “Okay, I want to have a tree in there.”, and then you can define a certain logic that around the tree you have leaves. You can define particle effects so that the leaves fall down. You also can add audio in there, so you have wind blowing through the tree.
Basically these object groups or object presets are like packages, which then are assigned onto the terrain on specific areas where you want these trees to grow basically, and then the scattering is done in an automatic way, but it follows a certain logic. So, you kind of have … you still have the … you can define like a natural harmony, so that it's not completely random or in a grid pattern that would be very noticeable to the human eye. You get to define how the assets are arranged. That you have a huge rock, you want some smaller rocks around them and then some very tiny rocks around those again. You kind of create a kind of aesthetic, so it's not just ... okay I have this big rock and this small rock and the tiny rock and then it just scatters it over kilometers of terrain. We had this in the beginning, and then we've … we added more and more and parameters to change, the visuals and of course you have values to tweak random scaling, random rotation, alignment to terrain and all this type of stuff.
MK: As an art team we produce all the content that forms our final planet. That contains like the ecosystems that define our terrain shapes. It includes the materials that define the look of the ground when you are walking around in first person. We built the rocks and the assets and the shrubs and the plans that we basically build all of these components, and it's remixing our procedural planet tech.
Besides we're using and remixing our textures and materials. We also built … built them in a smart way. When we build a material for our rocks for example we also … we use the same material in our ground textures to define how the small rocks on the ground look. In order to do this we use Substance Designer which really allows us to break down all of our texturing components into separate modules in which we can then plug in and remix and change the settings on the fly. This really allows us to speed up our texture creation process, and allows us to quickly knock out different variations of different colors of sand, different amount of rocks on the ground. We have a lot of ground to cover on our planet so we try to cover a lot of space, multiple planets. So, we need to make sure that whatever … however we work you do it in a smart way.
Whenever we try to define a material palette for one of our plans for locations what we actually do is we build our set materials and we apply them it in an asset set where we can toggle the time of day, have a view of like ... what does it look like at a steep sun angle? What does it look like at a 12 o'clock sun? That way when we combine all of these elements we know that at least at the baseline everything looks good. When feeding these materials into our planets there is various elements that influence how the final material looks on the planet. Procedurally these different materials will be mixed. Other elements will come in. It will sample colours from the global definition of how colours look on the planet. So, wherever you go on the planet it … the result, the ground, is never the same.
What we try to do when we build a massive library for the procedural system is to not for example to define the final surface material. So, what we try to do is make sure that it's reusable as well. We can take the same rock type or rate same rock shape and then reapply a different material on there and then use it in a neighboring moon or system. This is making sure that we can put more in our memory, 'cause we are using the same base elements, but it also makes like covering this large area faster.
PM: Another big challenge that we had with the object scattering or how we built our frames in the game make these environments look very good was that we don't really have any background assets. So, in traditional games you always have your foreground and your mid-ground and then you also have your background assets that are basically making up the scenery, where you normally you never go there. For example, you're in your jungle and in the back there's a big volcano, but you can never really go there. It looks really epic, but it's mostly just a background asset. In Star Citizen there is no such thing as a background. Everything that you see on the screen you can go to, and this also then goes into our workflow, how we make the assets.
Sometimes the things in other games that you see in the background is just a painting, always looks the same, and if you go up close you just see there's a wall in front of your face, which never happens, because the player's space is restricted, but in Star Citizen there is no restriction for the player's space. For like smaller rocks this is fine, because you only see them when you come really close to them, but if you have large cliffs in the back, you want to see them from far away you obviously you see them when you're close up, and you want to have them nice and detailed, and you want to have the nice transition when you come from outer space, and these large objects are coming up. Every asset has to be made that it works first person and it works from a little distance, that it works far out the background, and it should also work from outer space.
MC: Another major challenge is dealing with online games and procedural generation, because the generation is to be deterministic on all machines. So, we need to do a bunch of operations on CPU side to make sure it all works on the dedicated server as well. Usually a dedicated server don't have a graphics card. So, currently all terrain generation is done on CPU and most of the visual textures blending is done on the GPU on the client. Generational results are cached in the fixed geometry pool mesh from before, and the generation is distributed over all available mesh in cores. So, the generation is very efficient, and this scaling with the number of available cores ... the generational results are exactly the same on client and server, so there is no need to transmit any information to replicate the environment.
Here we are watching a video recorded by our QA of four players playing together and landing on a planet. You can see the seamless transition of all of them landing on the same planet surface.
MK: What makes working with our planet tech so different is the scale. When you would work on an FPS level for example. You would … even if it's a very large map, you would cover like four kilometers. You don't have to worry about what happens outside of the playable boundaries. What we do … try to do in Star Citizen is basically cover all those elements. So, you come in from a very far distance. Fly close to the surface. You step out of your ship, and you walk around and look at the rocks and the ground and the details. You have to make sure you cover all these different ranges, which takes some getting used to. It's an interesting system to work with for sure, and you use on the one hand you lose the opportunity to handcraft every single meter around you. At the same time you're generating a large scale environment, and the procedural system allows us to set up these rules where the way the stuff that's placed you get these situations were like wow, I couldn't have made this if I tried to.
PM: You never really know what's going to happen and how the objects are arranged, so every now and again you come to a corner of the moon which you have never seen before. I mean on one hand you don't have the hand-placed control, but you don't really want this, 'cause you could spend years on this one planet, but yeah … the nice thing is that every now and then you come to a certain corner of the planet or the moon, and you're just surprised by how the objects are arranged, and it just works out beautifully. Also with the sunlight you never know how the sunlight is, because the planets … you don't … you never know what time it is or you can't just say, “Okay, I want this in a sunset”, so every now and again you have these moments where everything comes together and it just works out beautifully, and you have this nice, scenic, huge environment right in front of you.
MK: We define the rules. We define our shapes that we would like to see, but it isn't until everything comes together, and you actually fly around and just land and just look around and just ... wow. All these elements that our team built … right now it's all put together. This is just the world that we've made.
MC: To end this presentation we're going to show you a procedural planet visual effects breakdown showing how the different elements are combined to compose the final image. Thanks for watching.
[Procedural Visual Effects Breakdown Demo]
SG: as Pascal said: In Star Citizen there’s no such thing as a background asset. If you see it, you can go to it.
CR: Yeah and what makes the game so challenging to build, every asset must be crafted so it looks good not only to the distance, but also from right in front of yours eyes and there aren’t many games that have those demands and I think it’s one of the things that makes Star Citizen so special.
SG: Yes it is and that’s it for today’s episode. We’d like to thank all of our subscribers whose support make shows like ATV, Bugsmashers, Loremakers, Citizen of the Stars, and Happy Hour possible.
CR: Yeah and thanks to our backers, we couldn’t be building this incredible game without it.
SG: We could not and until next week we will see you…
Both: Around the Verse.