As is with any information on our transcripts and summaries, everything posted is subject to change by CIG and in some cases may not always be 100% accurate at the time. While we strive for accuracy, mistakes do happen so please let us know if you find something amiss that we didn’t catch. Enjoy the show!
Sandi Gardiner (SG): Hey everybody, welcome to another episode of Around the Verse where we take a look at Star Citizen’s development. I’m Sandi Gardiner.
Forrest Stephan (FS): And I’m Forrest Stephan.
SG: To start things off, just wanted to welcome all of newcomers to the game and if you’re thinking of joining, now’s the time. This is the last week for the Super Hornet free fly, and if you haven’t tried one yet for yourself just click on the link at the top of RSI to get further details on how to start flying.
And behind the PU alpha and Arena Commander content available to play right now, we have a lot of other stuff in the pipe. You want to update everybody on what’s happening?
FS: Oh I’d love to. So we have Alpha 2.6 has been making some great progress with new things dropping in every single day. The Evocati have been hammering away with the new flight balancing so watch out, design has been wrapping up a few new missions for Crusader. The music logic system is pretty much done. The ship team have two new ships that are feature complete and ready for release.
SG: Yeah! Those two ships are the Herald and the Vanguard Hoplite, they’re two pretty different ships and they’re pretty cool and they’ll be awesome additions to the game.
FS: Totally agree. On the Arena Commander, art had been polishing up some new item pickup system and the pirates have been starting to really swarm about, so be careful. New cameras are in showing off new sweet camera angles. There’s just so much stuff.
SG: Cool. We’ve also been doing a lot of internal playtests on Star Marine with the whole team and been getting great feedback. The fronted network refactor and network improvement are also expected to be wrapping up soon.
FS: Yeah and Mark as we know the “Bugsmasher” found a pretty funny bug this week where we could actually teleport through space, I think it could be a feature but you know.
SG: Super cool. You can check that out on our Star Citizen YouTube channel. So now let’s head over to our Frankfurt office for a studio update to look past 2.6 into 3.0.
FS: That’s correct.
Brian Chambers (BC): Thanks guys. I’m Brian Chambers, Development Directory from Foundry 42 Frankfurt.
The road leading up to CitizenCon: it was incredibly busy. It’s always cool to show off our progress and get that out in front of you guys. And the support’s been overwhelming for myself and the team. Team’s back at it – across all disciplines – everybody’s busy working.
For this week’s update let’s start with QA where Melissa will give you some insight into how the QA department functions here in Frankfurt.
Melissa Estrada (ME): The Frankfurt QA team is currently made up of three testers with two dedicated to testing the engine, and one dedicated to testing Squadron 42 and FPS. We work closely with the development team whether we’re testing new code changes or investigating an existing issue.
There are an array of different types of testing we do on a daily basis but test requests are high up on our list or our tasks that we do pretty regularly. So a test request is essentially a request submitted by a developer who would like to submit code changes that could potentially break the build. In order to prevent this the code will go through thorough testing where sometimes the entire game, or only certain parts of the game, will need to be tested.
In this particular test one of our engineers has made shadow and object optimisation code changes. He provided us with a custom Bin64 which contained his changes and during our testing we discovered a one of crash and excessive shadow flickering throughout Homestead. We then compared our finding to the vanilla code version of the client and reported our final results to the developer.
This process prevents new issues being introduced into a build. However the challenge we sometimes face is if there were any recent code changes to the same system the test request is meant to to address, and then these changes were then picked up when the developers synced to the latest code in Perforce to compile the Bin64, it then becomes difficult to tell which code is causing the issues.
Regardless all issues are reported, further investigated, and fixed prior to submission. And the final result is a build that contains improved shadows, no flickering, and no crashes.
And this is what I like about being QA here in the Frankfurt office. Being able to track down these issues and contribute to the process of fixing them as well together with the development team. It’s a really rewarding experience and I consider myself lucky to be on this team and contribute to the development process.
BC: Thanks Melissa. QA is always a huge part of development especially with her and the team working with the Engine team here. I don’t always envy their job but they do help us dig in and sort out any bugs that accidently creep in.
For the next part of the update let’s check in with our Senior VFX Artist Caleb. He’ll break down some of the VFX work they did for Homestead.
Caleb Essex (CE): Today I’m going to give you a more comprehensive breakdown of the large sandstorm effect that was featured in the Homestead demo. This effect required a lot of collaboration with the Audio and even the Cinematics department to make it function properly within the engine.
So here we are inside the editor with the Homestead level opened up. The sandstorm effect itself is actually fairly simple: it’s only made up of three different sprites. There’s a thinner sand texture at the top of the effect, a thicker one down below and the lighting texture. The two sand textures also include normal maps as well as the optical flow maps for the frame blending. These optical flow maps give us a virtually unlimited frame rate for our textures. Because of this we can slow down or speed up the effect without the animation looking choppy. Something we actually do as the sandstorm approaches the player to increase the sense of foreboding and scale.
The forward motion of the effect is actually controlled by Track View. The blue line is the path that it follows. As it approaches the player there’s also a fog volume entity that moves up from the ground. This fog volume is to help with the transition as the sandstorm hits the player. However it is also used as an optimisation technique. When the player is inside the storm we can disable the effect and enable a localised effect of sand whipping past the camera. By disabling the effect while it is hidden in the fog we can sidestep some of the overdraw issues that can arise when the whole screen is filled with particles.
As we move forward all of these systems will be unified and controlled by our Planetary Weather system.
Here we have the final effect running inside the engine.
BC: Thanks Caleb. It always surprises me how much particles and effects help in bringing the world alive. It’s cool to see the progress.
The rest of the team – incredibly busy as I mentioned – making great progress from cutscenes for Squadron 42, to weapons, to design and so on. Another quick update is that the office expansion that we’ve had: we’re now actively in it – we’re now actively here and working and functioning – and so I hope to show that off soon.
So that wraps it up from Frankfurt. Short and sweet. Thanks for watching and we’ll see you next time.
SG: Wow, that sandstorm looks pretty epic. It’s like something out of Fury Road.
FS: Aw yeah. Mad Max. Awesome. Yeah I mean really now that all this art and tech is coming online we are able to develop some really interesting planetside gameplay environments. Right? And even the environment wind can become as much of a threat as possibly another player.
SG: There we go. Speaking of other players, let’s now go to this week’s Community Update with Tyler.
Tyler Witkin (TW): Hey everyone. Tyler Witkin, Community Manager in the Austin, Texas studio, here to bring you this week’s Community Update. Now as previously mentioned, and just as a reminder, this is the final week for the Fall Free Fly. So if you wanted a chance to fly the Anvil Super Hornet, you can click the link at the top of our website to find out more information. Now speaking of free flies, racers get ready. The Origin M50 will be made available to all subscribers throughout the month of November.
Last weekend the Star Citizen community in Germany came together to put on their own community organized CitizenCon. This event had almost 500 people in attendance. You don’t believe me? Check this out.
Presenter: Greetings from Frankfurt.
Crowd of Community: Star Citizen!
Presenter[Speaks in German] Clean! Now we are going to start. Thank you very much.
TW: That’s a whole lot of citizens and if you didn’t have the opportunity to watch it live you can find out all the details of how the event went over at citizencon.de And if you are interested in these types of events just a reminder to head over to BarCitizen.sc Check out the interactive map, because it’s very likely there’s an event in your area.
And now it’s time for this week’s MVPs. Yes plural, because this time we don’t have one, but seven MVPs. So I want to give a huge congratulations to Sereth, Avalean, Valkyrie, FyreMaster, SnowCrash, Cantrip and Michiel81 for their exemplary efforts on the RSI HELPDESK. Now for those of you who are not familiar with what that is, this is a RSI chat channel on our website where players can come together to ask or answer questions about the game. So congratulations again to all of you. You’re this week’s MVPs.
Lastly the week would not be complete without Reverse the Verse, so make sure to tune in tomorrow at 7:00 AM Pacific Daylight Time where we’re going to talk about everything you saw on today’s episode. Thanks again everyone for all your support, and we’ll see you in the verse.
Sandi Gardiner (SG): Moving back to our Frankfurt office, getting procedural planets working is a massive undertaking. One that we can’t possibly show in a single episode, so next up is the first of several segments we’ll be doing to focus on procedural planet tech being developed in Frankfurt.
Forrest Stephan (FS): So on that note let’s take a look now on the ecosystem painting, the zone system, and some other cool features that Frankfurt has been working on for 3.0 and …
FS & SG: … beyond.
Hannes Appell(HA): So today we want to give you the first out of probably many deep dives into the core of what makes our planets tick and about the planet creation and this is tech developed here mainly in Frankfurt by Marco, Sasha, Carson of course. Basically with the Homestead demo for Citizen Con, practical test case of what we call the V2 planet tech which is… we are already basically at V3 now so we kind of needed to say at one point, that is it for the demo.
So we have a couple more features in progress and the Homestead of course was not just made because of our love of giant space worms but also to have engineers and artists work on something that is basically a substantial test case so we can mature our tools, our planet editor or what we call it the plan ed. To basically arrive at something where the useability has grown into a mature tool set but also the feature set of course with the massive object distribution, vegetation, ecosystem, painting and terrain height map.
Sasha: Working with our environment artist, Pascal on the ecosystems themselves which in the case of Homestead were actually only five distinct ones.
HA: My job on Homestead was as visual director and for that I basically initialized the lighting and mood and overall feel of this and also worked with our environment artist Pascal on the ecosystems themselves and I basically also every day a couple of hours spent with Marco, Sasha and Carson on the tool set itself.
Marco Corbetta(MC): Hello, we are going to talk about planets today. Thanks to everyone on the Star Citizen subreddit and the CIG community forums for your positive feedback, we really appreciate it. Initially we were not planning to have seamless transition from space to planets into Star Citizen. Around September we started rewriting from scratch the CryEngine terrain system, here you can see my first experiment of a procedural planet without any atmosphere at the end of October 2015.
Then this is our first test with atmosphere in November. Carson Wentzel has been working on the atmospherics and clouds as well as a number of other engine features. Here is our first public update at the end of 2015 showing the first Delamar planet version, it was more simple procedurally based but was already integrated into the editor so you could place landing zones on top of the planet. In February 2016, we had the first man working on planet, at this stage we still did not have ground details and we still had many precision issues as you can see in the video.
So during March and April, we made a lot of progress, you can see more details when zooming into the planet and this is the video of the first buggy driving on the planet surface. At this stage the planets were mostly procedural and even though we were getting good results it was becoming difficult to really customize the planets.
Pascal Muller(PM): There was no diversity in the planets, it was either a big, rocky planet or a jungle planet or a desert planet but there was no variation in the ecosystems on this planet and with V2, this changed. We introduced something new, which we called ecosystems, so when we talk about ecosystems what we mean is basically you can think of it as kind of a level of it’s own. It’s a piece of terrain and it covers about four or eight square kilometers, you could say and each ecosystem contains many, many different kinds of assets which are created by the artists.
Part of it is the terrain itself, like the information that defines how the terrain looks, is it mountains or do we have dunes or do we have plateaus or canyons and all this type of stuff. Then additionally to that of course you need all the ground textures that make up the surface of the terrain, do you have like rocky ground or grassy ground and this type of stuff and then on top of that of course you also need assets… all kinds of assets that need to be scattered in a procedural way. It’s going to be done by hand if you think on a global scale, so all of these things come into the ecosystem and for this Sasha Hoba developed own editor for the engine and within this editor we basically all this information is accumulated and tweaked.
We tweak the height of the mountains, where which texture belongs and which assets belong together on which surface and all this type of stuff comes together in the planet editor in the engine. Once all these ecosystems are done, you can basically take your planets which is more or less grey at the moment and just pick some of these ecosystems and paint them over the planet and this is basically how the terrain is generated in the end. Of course, when this is generated you want to make sense of it, you know, you want to have ridgeline of mountains and behind you want to have some hills and that goes into grassy lands or desert or whatever.
MC: So, at CitizenCon 2016 we were supporting spherical terrain, seamless transition, run time generation of 60 frames per second without any preprocessing, unrestricted view distance on a planetary scale plus different ecosystems and the first version of procedural vegetation as well as hardware tessellation and per pixel displacement. Going back in time a bit before Gamescom, here is a test showing how Pascal had quickly put together a Mars looking planet. Using a few ecosystems and changing some parameters like atmosphere, colours and so on. So with a just few ecosystems and painting them on the planet through the planet editor we can create many different types of environments and planets.
Here I’m showing a bit of our work-in-progress features. One of the next steps for us is improving the procedural vegetation placement and object distribution.
In this video clip you can see trees and grass being rendered through the zone system which Chris Bolte is going to talk about in a bit.
Here you can see in this last video another work-in-progress feature: a rotating planet. The planet is actually rotating extremely fast but at this scale looks like it’s not moving. If you get very close on top of this static control tower which is not moving, you can see the planet rotating very fast.
Another interesting thing to note is the ocean which was worked on by Anis, one of our new hires in Frankfurt.
The ocean is reusing the planetary patches with different displacement. This way, we’re getting adaptive subdivision computations for free and we don’t even need any extra geometry memory usage for the ocean.
PM: The original ocean was also just a flat terrain piece more or less and of course for the planet we also needed this to be a spherical object and this feature made it in. You can see that we have proper waves, there is vertex animation, it’s nicely tesselated, the shading is working. Anis has really put a lot of work into it.
The next feature would be the clouds. The clouds are still in a very early stage. Carson Wentzel is putting a lot of work into it, doing a lot of research, but you can already see some realistic behaviour. You can see they are casting shadows, there are different thicknesses to them in certain areas so there is less light penetrating.
Speaking of light, one thing that also changed quite a bit is the sun. Because this is a spherical object, you have different kinds of lighting all over the planet. So you cannot simply say, “Okay for this planet I want to have daylight. I want whatever is happening on the planet to take place in sunset,” because, depending on where you are on the planet you have different lighting situations. All of this is now implemented. Depending where you are, the atmospherics generate different effects. At the sunset, obviously, everything turns red and during daylight you have blue bounce light from the sky and all this type of stuff.
Chris Bolte: Hello everyone, I would like to talk to you about the changes related to our core technology which allowed us to implement the planets as you have seen them during CitizenCon.
One of the first components we changed was the jobs system. This system was responsible to distribute work which must be done to compute a frame in a video game over multiple CPUs. This work is called jobs in our engine.
The old approach was applicable for perhaps 3000 to 5000 jobs per frame. With the new one we can handle a very large amount. This was realized mainly by utilizing the inherent parallelism of games which is basically the smart way of saying that we have always more than one object to update. Furthermore, we changed the jobs system to better communicate with the operating system to allow for better usage of available resources.
We then built the zone system which is a better object management system. Such is a system is responsible to allow for an efficient way to query objects based on spatial properties, for example finding objects visible inside the camera or overlapping with a box. This system replaced the octree-based scanning approach and is now used to store all kinds of objects’ world space position.
This system had two important characteristics.
Being efficient – the system should scale well. We already have over 200,000 renderable objects present in Crusader. This is realized by ensuring that we use efficient data structures and use a processing layout which is spread to multiple cores with the help of the job system. Then, the system should cope very efficiently with large clusters of simultaneous moving objects. Here we use a novel approach of using multiple reference frames.
The regular approach used in games is to store objects in a single coordinate system, the so-called world space. This world space position is then sent to the GPU as 32-bit coordinates and projected to the screen with a projection matrix. For Star Citizen, we cannot use this approach due to two reasons. The GPU can only process 32-bit floating point positions efficiently but we need 64-bit positions for the large game world. We want to move kilometer-long spaceships and planets through space. In the old approach this would mean updating the positions of all objects on said ships or planets which is not possible in realtime.
So we did something else. At the highest level, we organized our world in a 64-bit position universe coordinate system. To render the objects stored in that, we compute a camera-relative position before we then send the data to the GPU. This allows us to keep the world as one coordinate system by using the more efficient 32-bit position on GPU. To move objects around, we use multiple zones. A zone is it’s own coordinate system with all objects which move together like a spaceship or a planet. With this system we can move an arbitrarily large number objects by just moving around the pivot of the coordinate system. Calling in such a system is implemented by converting the tested against objects into the zone space.
This sums up the technologies we had to advance for our goal of a living universe. Thank you.
SG: That’ll about do it for this week’s episode. Remember to tune in for Reverse the Verse tomorrow at 7AM Pacific or 3PM GMT. We’ll be back with the team in Germany to discuss Procedural planets and more.
FS: Awesome and we’d also like to thank subscribers. We wouldn’t be able to show you this cool stuff like the procedural tech and produce all these awesome shows without your continued support so it’s so much appreciated.
SG: it is and until next week, we will see you..
[Both] Around the Verse.