1. HUGE question, requires an essay… main take away is that a large chunk of the Vulkan implementation is multi-threaded so scales well with more cores. 2. No major change, basically comes down to GPUs & drivers that support Vulkan 1.2/1.3, which is pretty much everything mainstream for over the last 5 years. 3. Most “busy” locations are CPU limited, so Vulkan will only give minor gains there.
Hi. No, there are no visual features tied to Vulkan relating to gas clouds, so this is really a question for the creative director and marketing department.
It’s possible the videos were just recorded earlier in the development, and those assets didn’t work well in the final version. It’s relatively common for things to look good in limited scenarios, but once viewed from all distances or when they try to get them in budget things need to be scaled back. Or it could just have been a “look dev” experiment, or intended for a future patch.
But these are just guesses, I’m not involved in the day to day content setup of locations or marketing videos. Sorry I can’t be more help!
TL;DRThe scope shader shipped soon after that CitizenCon with several effects, but the slight in-scope zoom was held back and now exists in Squadron 42, coming to Star Citizen later with no predicted date.
The scope shader was added to Star Citizen very soon after Citizen Con in 2023 (can't recall exact release number). This includes various features such as:
Parallax (offset image)
Eye relief (clear image only when at ideal viewing position)
Defocus (blur at non-ideal viewing position)
Vignetting (tunnel vision)
Chromatteic abbertion
Diffraction/glare
Scope shadow
Light amplication (selected scopes)
The cool thing about the scope shader is that it isn't a fake effect that only applies to a special first person model, it's actually always present on every scope, and can be seen when examining a scope in your hands or one just sat in the environment, so long as you can find the correct viewing position (eye-relief).
However the initial release missed one key feature shown in the 3rd image above, which is the ability to zoom the image slightly. In the above image this is somewhere bewteen a 10-20% enlargment, with the majority of the zoom coming from the main camera zoom, however the slight extra soom inside the scope does a lot to help the feeling of a real scope. Unfortunately it can't be a full zoom inside the scope as this brings about a HUGE performance hit, that even the beefiest machines would struggle with, and would also require a LOT of extra complexity in the engine as we'd need to be able to support all our complex feature sets in secondary viewports (planet clouds, space/gas clouds, atmosphere, fog, rain, etc). The reason this smaller zoom wasn't shipped at the time was that it didn't support anti-aliasing or upscaling (due to a lack of also zooming the depth buffer and motion vector buffer), and so in practice it wasn't usable. However, since then the required work has been completed and S42 now has the extra zoom inside the scope, and this will be making it's way to Star Citizen once the latest engine features are integrated over (which could take a while, so I won't be able to predict exactly when).
TL;DRGenesis decides vegetation from soil, temperature, humidity and other rules, with artist-made source data and per-planet species, while rock placement combines artist-generated maps from erosion and weathering simulations; exotic worlds and ecumenopolis questions go unanswered.
Hi! Pyremius’s reply is broadly correct. Genesis models natural rules at a fine scale, such as deciding which plants will grow where, and how rocks are distributed based on large scale geologic data sets, and then allows the results to be viewed from orbit. But the actual source data is largely up to the artists to decide, and although they use many simulation and procedural tools to aid this, they can still basically draw continents wherever they please and pick the temperature at any specific location.
Vegetation uses rules based on soil quality, temperature, humidity, light availability, competition, reproductive rate, and more. Trees will dominate if the conditions are right, but lower quality soil or cool temperatures are likely factors for fewer trees. Also we pick per planet which species are available, so each planet will have a unique combination.
For rocks, the artists generate rock aggregate size maps, geology type maps, and soil depth maps. The offline simulations for these use erosion and weathering to determine how the rocks and soil are broke down and transported. The run time algorithm then combines these data sets procedurally, and then scatters the rocks based on the combined results.
Hi! The entity system team actually made it possible for game systems to read ‘hierarchical context data‘ which includes planet data, but it’s up to each game system to make use of this. So something like you suggest is plausible, but I can’t speak for the others teams and if/when this may happen.
TL;DRGenesis won't make ArcCorp a futuristic city, roads aren't planned yet and weather may take priority, farmland will be raised with the creative director, and crash-site terrain changes are wanted but need performance and network work first.
1. Honestly, no. It’s been designed to build worlds from natural rule-sets, but most of this isn’t applicable to Arcorp. However some of the foundational tech of Genesis might allow future improvements to Arcorp, because under the hood it allows for more complex rule-sets driven (but currently based on nature) and efficient spawning of objects at multiple scales on a regular grid (randomised for nature, but can be kept raw for man-made elements). So city-block generation could fit well, but would need extra work.
2. Not yet. Genesis is the only planet tech feature in development. After that it’s up to Chris, but my gut is that more varied weather may trump roads.
3. We’ve never been asked about farmlands once actually. Often we have to scour the corners of Earth for reference to get away From farming! It’s something I’ll ask the Creative Director though.
4. If nobody sees you crash then did it really happen? :wink: For a more useful answer, currently the answer is no, because ships crashing doesn’t really modify much… but what we’d love in the future is for a ‘terrain modifier’ to be spawned by the impact which would remove the trees and adjust the terrain, and this would be visible from quite far away with Genesis. such terrain modifiers already exist, but aren’t currently created dynamically as there a lots of performance and network considerations to address first.
Hi! The Nyx rocky planets will come next year. Setting them up using the previous iteration of planet tech would have added considerable (wasted) dev time, so we decided to going straight for the new tech.
The main menu uses the ancient Flash/Scaleform rendering system, which has major issues with performance due to ancient and creaking third party code. As such it has been superseded internally with a new system. The UI is going to be reworked with this new system, and I’ll make sure that widescreen support is on the requirement list.
The planet creation aspect of Genesis is progressing well, and is a major focus for myself and many others. I can’t share a timeline for its release yet, but it’ll likely start with one planet, before rolling out to others and more diverse biomes, rather than a massive full replacement. This will allow us to roll it out sooner. We hope the rate of planet production after this point to increase significantly due to the massively streamlined art process.
As for the specific tech features, most of the infrastructure is now done, but there are a few important visual features left, and then two major tech changes to achieve the desired performance, and then a bunch of smaller tasks. If I had to put a % done on it, maybe 75%… but it’s incredibly hard to be precise.
I can’t provide a specific distance for the rendering of grass meshes until we release Genesis/V5 and it’s fully optimised. However a core pillar of this tech is avoid any popping or colour changes on approach, so when the grass mesh disappears it will be replaced by textures with a similar appearance, and beyond that you’ll still see the same green patches of grass from orbit. This is not a problem most games need to solve, and has been a significant challenge.
I’m not clear what you are asking. Can you please screenshot the setting you refer to from another game?
Syncing CPU and GPU hurts performance, it literally means to force one of them wait for the other. Every game does need to sync them, but you do it very carefully and for the bare minimum time. There’s no way that doing more syncing would result in more performance, but perhaps I misunderstood the question.
S42 has been using Vulkan by default and it’s been going well, but has uncovered various stability issues that have been fixed. Our focus has been on polishing various major graphical features required for both projects, and we’re about to move onto a large and long overdue optimisation push.
Moving code between the projects, fully testing and stabilising it for public release can take many weeks, and often months if the feature set is large. This has been happening in parallel to the above polish and optimisation, but finding and fixing bugs is always unpredictable so I don’t want to get stuck giving predictions or frequent updates, but we’re hoping there will be news on this front before long (don’t ask me to define that! :stuck_out_tongue: ).
Ali Brown Director of Graphics and Procedural Tech
You may want to check this thread: https://robertsspaceindustries.com/spectrum/community/SC/forum/50259/thread/vulkan-hdr-update-4-0-x-inquiry-about-vulkan-hdr-u
TLDR: Vulkan is still BETA in the public release and hasn't recieved an update recently (see the thread above for details), but internally we've made many improvements and are testing it as the default renderer for Squadron 42, and so once it reaches the PU the intention is it should be much more stable and faster then DX11.
TL;DRMost changes can be tested in minutes or seconds, and builds take from a minute for small code changes to one or two hours for full builds, with a multi-million-line codebase and several terabytes of source assets.
Your question is quite open/vague so hard to answer concisely, but here's a high level overview: Most kinds of changes can be tested very quickly, e.g. less than 5 minutes Art/design changes can mostly be iterated upon live in the editor, but some changes require (re)starting the game (usual startup time, e.g. 2-3 mins) Balancing some game systems can be done live while playing the game Code takes a minute or so to compile small changes (sometimes possible while the game is running, sometimes requires restarting), and up to 10 minutes to build the whole project from scratch (distrubuted build system over many machines) Shader changes happen live, so usually complete in seconds Full builds of the game take between 1-2 hours, but devs just use the last build and add their latest changes to this, so only need to wait for a new build if they are not a programmer but need the latest code changes The build system caches lots of data (textures, meshes, animations, shaders), such that if we wipe the entire cache the first 'clean' build can take several hours longer I don't have up to date statistics on the size of the uncompiled game, but the code-base is millions of lines of code, and the source assets take up several terrabytes Cheers,
Ali Brown, Senior Director of Graphics & Procedural Tech
TL;DRStar Citizen has prioritised stability and quality of life over a new engine version, while Squadron 42 is road-testing Vulkan, HDR and multi-threaded rendering; no timeline for Star Citizen, though piecemeal engine updates are being considered.
The focus for Star Citizen recently on the code side has been on stability and quality of life (QoL) improvements to existing features, especially after the rollout of server meshing and the huge impact it's had on the game. As a result the Star Citizen team haven't been able to take a full new version of the engine in a while, because this would bring potentialy instability and slow down the QoL improvments for players, and also likely prevent regular/timely releases, all of of which are critical for continued engagement. But the Squadron 42 team have been road testing Vulkan (which is enabled by default for them) along with HDR, and multi-threaded rendering, so hopefully most of the kinks are ironed out by the time they reach Star Citizen, though I won't be able to predict when exactly that will be.
We are also considering changes internally that would allow the Star Citizen team to more easily take piecemeal updates to the engine into the live release to reduce the risk of instability for lower risk features/systems, as we're of course eager to get all new shiny things into your hands as soon as possible without comprimising the player experience.
Thanks,
Ali Brown Senior Director of Graphics & Procedural Tech
TL;DRNo quantified speed or quality figures can be given yet because a whole planet can't be made and supporting systems aren't done, though quality is already better in some areas and they won't mass-produce planets.
Well, quantifiable is a weird word here because we're not done. So we haven't measured how long it takes to make a planet because we can't make a whole planet yet. But the design and the whole way that we've built this tech is with speed of iteration and quality in mind. We're already getting quantifiably better quality in areas and we want to keep working until they're all of the areas of a higher quality as well. But also, we can't kind of measure how quick all this will be until it's done, until all the supporting systems are done. So just because we can pump out a planet in a day doesn't necessarily mean we can work out everything else that makes that planet an interesting and unique location. That requires content from all sorts of other things, from narrative to level design to locations to lore. There's no point pumping out a million alien worlds that are all lifeless. They've got to have meaning. And that's kind of what we've done really nicely with Pyro, I think.
Just to clarify, we're also not going to be pumping out a planet in a day or a million planets I mean, it's as long as a piece of string, isn't it? You could pump out something in a day, whether it's worthy of releasing in a day would be a very different question.
TL;DRRoads are something they want to do, and the river tech provides groundwork, but they aren't working on them yet; placement rules, tooling, assets and some graphics work remain.
I can say regarding roads is that it's definitely something we want to do. A lot of the river tech when it was made was made with kind of like and roads in mind in terms of there's a lot of similarities in terms of kind of like dynamically creating and destroying things as you approach it on or across a long spline, because if you just load a mesh for a 100 kilometer road, that's obviously not going to work. But it takes some time and some investment into the tooling and it's making the assets and getting design and so on. We want to approach it. We're not approaching it this second.
Yeah, just to add to that, we've got Will's done a lot of the groundwork for that. So on the planet side, a lot of the work has been done or wouldn't take much to take it further. You know, there's not a huge difference on the planet side between a river and a road. Where the work remains is there's a bit of graphics work to do. Obviously, a road doesn't look like a river. We need whatever stylistically we need to change there. And presumably, you know, the whatever assets would be distributed at the side of the road would be slightly different to a river. But probably the biggest difference is we assume it would come from Starchitect. Like you would have to place all these locations on the planet. And then we have to figure out what would be the logical distribution of roads. There will need to be rule sets. You know, does this planet support roads? Is there areas of the planet that will and won't have roads? You know, maybe outlaw bases don't have roads. They don't want to be signposted with a big motorway to an outlaw base. But, you know, some places will. So it's that element that is the biggest part that's missing. And then obviously there'll be a bit of once you have decided to connect two towns or locations. There's some code to figure out what is the best path to get between these two. Do I carve straight through every mountainside or should I weave around them? So there's a bit there. So on the planet side, we've kind of done it. But mostly on the tool side, we're deciding where the roads would go. And then a little bit of graphics to actually make it look like a road.
TL;DRBiomes and weather are meant to follow more physically plausible data, automatic for new planets, while older planets will need touching up so things like snow and temperature make sense.
Yeah, I think it's basically the same answer on the last question as well. It needs to be. We need to make it all more plausible and the data will be and then it'll just happen.
We kind of need for the weather, we need the data to be more physically correct so that the weather can match. We can't have it snowy in somewhere that's 20 degrees Celsius. So it comes hand in hand. The weather will be based on physically based stuff. But then Seb has to go and make sure the planets are following them physically based rules. With V5 it'll be automatic with the new planets. But when it comes to the older planets, we'll have to touch them up to make sure they do, but they are plausible. Maybe some bits get more snowy or less snowy as that happens to make sure it all makes sense physically.
TL;DRArcCorp will get weather and must eventually use the new tech, but no bespoke ArcCorp work is planned; the team hopes to adapt the new rule sets for it after other planets.
I mean, ArcCorp does use the planetech. I mean, there's a lot of special cases on ArcCorp. It shaded differently. We kind of abused the system a little bit to get the results we want on ArcCorp, to say the least. It probably will be a similar story. We're not planning on spending a year making bespoke ArcCorp tech. But there is parts of the new system that we're hoping will allow improvements on ArcCorp. Obviously, things about the amount of light that will gather underneath a tree and whether a fern can grow isn't really relevant. But there are many other parts that are relevant with the density, with the way we position things. We have a grid pattern for where we're going to put things, but then we randomize it. We could kind of just remove that randomization and get an actual grid pattern more naturally. And yeah, a lot of these rule sets, they're built for nature. But some of them, again, they're more powerful this time. So we might be able to abuse them again to get something nice out of ArcCorp. But we're not focusing on that at the moment. We're making sure that we can deliver every other planet. And we're hopeful that we will then be able to do something nice with ArcCorp at the end as a result. Because all planets must eventually use this tech. There is no option long term. They all must use it. It's just a question of how much we have to change to make it suitable for ArcCorp at the end. Which we won't fully know yet until we give it a bash.
TL;DRThey would like larger planets, but eight times is too much for resolution, memory and gameplay; a smaller increase like two or three times would be more appealing, though roads would likely rank higher.
I think we'd like that because we feel the small too, especially as we introduce more and more advanced atmosphere. It breaks our nice illusion that our planets are full scale, which I hope all of you continue to believe because I certainly do in my heart. The thing about bigger planets is it stretches the complications with precision more, which we're hoping to be able to do away with. But that's one problem. Obviously, we need high resolution textures. At the moment, if we have a global texture and it's, say, 2K, that gives us a certain number of kilometers per pixel. And obviously we have local data, too. But if we make a planet have twice the surface area, then suddenly we have half as much resolution for the same kind of budget. So we need to consider those decisions and consider how the tech can deal with that. But you also get kind of gameplay problems with that as well. If I make a real life size planet, we have fast ships, but like suddenly getting from one place to another takes 10 times as long. And it's not necessarily good for gameplay to have that. So it's a convoluted question. We appreciate the reason that people are asking that we feel the same. But also there's a certain amount of the why question, which I guess you can ask for a lot of our features, which is what we have works. What we have is great. Should we invest more time in making it bigger? Is that a good use of our time versus going and doing rivers, too, or finishing out something else sooner? So if you put up a poll that said roads versus bigger planets, I bet roads would win. So, yeah.
I'd probably add that eight times is probably, like I say, it probably pushes all of them aspects too much. Too low res, it's too much memory, it's too much of a knock on for the gameplay. A smaller increment would be more appealing, I think. You know, like a doubling or something like that. Because just being able to double the scale of our mountains would be nice. Double the scale of our global features, our mountain ranges would be nice. So something 2 or 3x, we know would be more chill. But 8x, pushing a few too many areas at the same time probably for us. Yeah. And then the other thing we talked about, we didn't mention, is content density. We have to fill it with stuff as well. We'll see with Starchitect hopefully helps fill that gap a bit. But we just don't want to, like, if the current game, we don't want to put things miles apart. As we start to see the product of Starchitect, we might be able to see, okay, yeah, things are feeling too crammed and, you know, claustrophobic. Maybe we do need a bit more space and we'll try and explore that. But yeah, probably 8x is probably pushing it, I think.