Game Discussions Star Citizen Discussion Thread v12

Viajero

Volunteer Moderator

September 2nd, 2020

Attention Recruits,

What you are about to read is the latest information on the continuing development of Squadron 42 (SCI des: SQ42).

As a result of our latest intel reports, we've learned about work towards creating the Xi'an race, responsive music to dynamic situations, and further work on the Vanduul combat AI and animation.
The information contained in this communication is extremely sensitive and it is of paramount importance that it does not fall into the wrong hands. Purge all records after reading.
UEE Naval High Command
b88fe478-70ab-417f-ba1c-5f6eb06f9cf3.png
AI (Combat)
Though a significant portion of the AI Team’s work is relevant for both SQ42 and the PU, some ongoing tasks are exclusive to the single-player campaign. This includes continued iterations on Vanduul melee behavior, which now automatically evaluates the suitability of specific special actions (dodging, jump attacks, melee attacks, etc.).
Regarding melee attacks, damage is now triggered by collision with the weapon’s blade to enable timing and assets to be tweaked and adjusted. The Vanduul lance has several states that can be utilized by the behavior, including extending it when preparing for melee attacks or keeping it collapsed when firing or aiming. These weapon state modifications are triggered by the behavior based on general context. Vanduul health was also further developed to reflect the different skeleton and activate the correct damage when it receives hits to different areas.
AI (Social)
For social AI, the recently devised bridge crew behavior now uses operator seat functionalities. The team are currently using this scenario to extend the seated actor state to support some usable functionalities. For example, they have extended the idle/fidget system on top of operator seats to allow the animators more freedom to bring life to seated scenarios.

SQ42-specific behaviors and functionalities were set up for vendor characters as well. Work also started on usables for the mess hall that will allow NPCs to collect and consume food systemically. When complete, NPCs will be able to collect cutlery and plates, serve themselves food, and then occupy seats to eat and drink.
Animation
Animation spent the month working on object and grenade throwing, knockdowns and knockbacks, and several new weapons. They further developed the weapons master, capital ship seat interaction, the bartender, and AI ship inspections. They also made great inroads into the NPC ammo retrieval mentioned last month, Vanduul combat, and female player faces and emotes. Interrupts were added to several chapters as part of ongoing scene work too.
Art (Characters)
The Character Team revisited a few key heads, cleaning up skin textures, refining hair, and are currently working with tech animation and cinematics to address facial animations. Some of these revisions may impact other departments, so all changes are modular and easy to roll back. This work will inform the process of reviewing other SQ42 characters and updates in the future.

Aliens-wise, the character artists finished modeling and texturing the Vanduul armor and passed it to the tech artists for rigging.
“So far work on the Vanduul looks fantastic and we are very excited about it.” - The Character Team
They also began coordinating with Tech Animation on the Xi’an race, ironing out major anatomy and animation issues.
Art (Weapons)
Weapon Art’s SQ42 focus throughout August was on the Vanduul lance, which consisted of looking at the weapon’s materials. A new concept for a medical device used in some of the larger ships was completed too.
Audio
August saw a refactor to the footsteps system to improve the audio on different surfaces, making it more responsive to player movement. They're also improving the granularity and structure of the music system to improve transitions between music content based on what's happening in a gameplay context.

Time was dedicated to the Lombard effect; a newly developed system detects louder volumes and large amounts of noise in-game and makes dialogue louder automatically so that players don’t need to do it manually. Audio also supported the VFX Team on triggering sounds when particles are generated on the GPU. Currently, if a particle is generated on the GPU, audio cannot efficiently play or sync. This ongoing work will remedy that.
Cinematics
August saw work continue on the character lighting rig used by scenes that don’t require a full manual pass, with more rules defined and edge cases identified. They also began investigating how the automatic depth-of-field focus system chooses which character is of interest during conversations. For filmic scenes (where the cinematic designer directs the camera), focus is selected and controlled manually. However, conversational scenes (where the player can freely roam around) can move out of focus if the player looks past them. Careful consideration is taken to ensure this doesn't happen due to another character being classed as a ‘higher priority.’
Several scenes moved past the ‘implementation complete’ phase and into production. Once production is complete, scenes are fully playable and deemed almost shippable, though a final pass is required to tweak and finalize lighting, VFX, UI, and animation.
Attention was also given to sequences that play out if the player reaches a ‘game over’ condition due to behavior not befitting a UEE naval officer.
Engineering
In August, the Engineering Team added support for SDF-based local physics grids and SDF sets, interior grid markup for SDFs in the resource compiler, and g-force calculation for all actor entities. They also added a separate g-force collision calculation to the actor entity, new visualization modes to help development, and ‘inspect’ and ‘modify’ properties of static and rigid entities. The option to export bit-voxel geometry via the mesh setup and save it inside CGF was added too.

Optimization-wise, they worked on multi-threaded RC bit-voxel baking, which saves a few hundred bytes on every CPhysicalEntity instance and improves cache locality by reordering members. They also saved four bytes per physical-placeholder instance, disabled debug validation in the final release, moved large geometry into a dedicated bucket during grid population, improved bit-voxel tree-box calculation by using blocks instead of individual voxels, and optimized tree traversals in grid checks
The Systems Team added an API to the crash handler that allows the dumping of cigprofile data. This will help them analyze what the system was doing shortly before running into a deadlock and watch dog time out and log memory usage at the time of the crash.
Deep analysis was done to resolve the disparity between tracked and system-reported memory use. Several improvements were made on both Windows and Linux to correctly track data moving forward, including low level allocator reserved pages and third-party allocations. They continued looking into the SIMD and memory layout code for zone partitions, implemented faster execution for scoped FPE enable and disable by eliminating linear search through all registered threads, and fixed several issues with ISPC integration. They also reduced the memory use of P4K system and changed the MemoryAddressRange to use CIG API instead of native OS API for memory tracking.
Work on the Gen12 renderer continued, with the team adding support for instancing and a ‘keep alive’ list so that GPUDevice objects are kept active until the end of a frame. Several refactors and optimizations were made too.
Cleanup in the shader system and renderer for thread safety continued, as did G12 brush rendering. They also started to look into DX11.1 API support (Windows 8.1 and up) for binding CBs using offsets for intermediate performance improvements until Vulkan ships. They also added support for custom texture views when using pass resources.
Volumetric fog to PassResource was ported to prevent the shader parser from stripping global symbols. Some severe Alpha 3.10 GPU memory leaks were fixed too.
For planet atmosphere unified raymarching, the team established a general atmosphere context to avoid accessing resources globally. This make it easier and safer to reuse shared code. All related shader code was refactored too. For temporal reprojection, they implemented options for: neighborhood clipping, refining color bbox using neighborhood variance, compression (based on scene luminance), and color space conversion of color data for tighter bbox to reduce errors introduce by clipping and clamping. The depth dilation code was futher developed too.
R&D into volumetric clouds continued and detailed plans for experiments and next steps were drafted. The initial set up for the volumetric cloud render environment was completed, code was restructured to allow it to be shared between planet atmosphere and volumetric cloud shaders, and the initial pass and injection of cloud raymarch results into the unified atmosphere raymarcher was implemented. The team made performance improvements to the terrain displacement mapping and optimized the shader parser to improve turnaround times when editing shader code.
Finally, Engineering implemented fast bicubic b-spline and Catmull Rom spline interpolation variants for two-to-four channel texture data, further bi-cubic spline evaluation optimizations, made a planet terrain shadow pass, and fixed time precision issue in cloud animation.
Gameplay Story
Gameplay Story continued to work thorough the key introduction of a ship early in the game, and two days of mo-cap was completed in the Derby studio.
“It was a little more challenging to work in a COVID-safe environment, but it was great to get back into the studio after such a long hiatus.” - The Gameplay Story Team
This has enabled the team to complete some long-standing tasks that could not be addressed through hand-keying alone.
Graphics
The Graphics Team predominantly focused on the Gen12 renderer last month, with time dedicated spcifically to the conversion process so that the old renderer code can be deprecated as quickly as possible. Various systems are currently being converted, including gas cloud rendering, shadow masking, and run-time environment probes. Improvements were also made to the rendering API to allow simpler and more robust client code that's less prone to human error. Work on the Vulkan backend made good progress too. The shaders were cleaned up to remove all unnecessary reliance on CPU uploaded data; modern GPU performance means it’s more important to save the CPU work in the renderer and driver than a few tiny instructions on the GPU.
Work on the organic shader continued too, bringing tighter integration with the planets to enable the artists to use assets in a variety of biomes and have them automatically integrate into their surroundings.
Level Design
The Social Design Team continued to work on scenes, usables, and NPC behaviors. They moved ten scenes to the ‘gold standard’ level, where everything plays out as expected in the final game. These scenes vary in complexity to give the team an accurate representation of how long it will take to complete their tasks for the rest of the game.
The Level Design Team continued to polish the ground-based levels while maintaining a strong focus on AI behaviors and multiple traversal routes.
The development of important dogfight locations continued. This involved working closely with the Flight AI and Art teams for support on use cases and space-scaping respectively.
Narrative
Throughout August, the Narrative Team continued with the review sessions detailed last month. As more locations progress in development, the team generated additional environmental storytelling documents to give intrepid players more insight into the story, history, and character of the environments.
As part of these playthroughs, they started to call out potential moments that could benefit from additional content, such as filling in potential lulls or calling out gameplay mechanics. After scripting, the hope is to record placeholder versions of the audio to block into the game and see how it plays. This approach will allow them to field-test new lines in situ and iterate on them long before official capture. They also worked alongside the Audio Team to develop the Vanduul language, which involved a deeper dive into the alien race’s culture.
QA
QA continued to support Cinematics with recordings of each level to ensure scenes are working as intended and are of the intended quality. They also created test levels for different effects to enable them to be tested more quickly and efficiently.
User Interface (UI)
Most visual teams have embedded UI artists, all of who have been working on a variety of upcoming features. For the Actor Feature Team, the artists polished the Personal Inner Though system and external inventory, both of which will be used in the PU and SQ42. They also began looking at the various fonts used throughout the game with the goal of unifying and updating them.
The UI Tech Team worked on ‘canvas-slicing’ tech, which will give other teams more freedom to add 2D UI to 3D spaces (via Building Blocks). They also began looking into refactoring the color system. The aim is to aid developers by making it easier to adjust colors across various UIs using a stylesheet rather than adjusting RGB values in each element. It will also allow vector gradients to be used in UI.
VFX
Working closely with the Design and Art teams, VFX Tech Art continued to support gas clouds, which is predominately now in the bug-fixing phase. They also continued to improve the texture sequence creation process, creating a faster, more streamlined workflow than the current one (which involves several different software packages). This is important to allow the artists to be more incremental with fluid sims (and exporting them as baked texture sequences), which will ultimately lead to higher-quality explosions, smokes, and fire effects.


I must admit I am slightly disappointed by this kind of weak sauce PR. CIG can usually do so much better at manipulating the narrative. I presume Chris Roberts is reserving their real spinning firepower for the day of reckoning when he (hopefully) will need to explain why or why not the SQ42 beta comes in Q3 (ends in September).

The easiest way to buy themselves a few more months I would imagine would probably be to announce that the beta is closed and internal to CIG, and that it would "soon" be open to some select few :p
 
Last edited:
I must admit I am slightly disappointed by this kind of weak sauce PR. CIG can usually do so much better at manipulating the narrative. I presume Chris Roberts is reserving their real spinning firepower for the day of reckoning when he (hopefully) will need to explain why or why not the SQ42 beta comes in Q3 (ends in September).

The easiest way to buy themselves a few more months I would imagine would probably be to announce that the beta is closed and internal to CIG, and that it would "soon" be open to some select few :p
They have many more lesser cards in their sleeves that they don't need to play this one yet.

"COVID ate my homework", "not up to CR's standards", "CR got this new awesome idea so we reboot, dev hasn't started yet", "what's à SQ42 anyway?"...
 
Hey @LittleAnt - what's your hot take on this?

They also started to look into DX11.1 API support (Windows 8.1 and up) for binding CBs using offsets for intermediate performance improvements until Vulkan ships.

Didn't you just recently declare their Vulkan work to be complete or almost complete?

Why would they be starting to look into DX11.1 support if Vulkan is almost ready?

Hah, 11.1 came out in 2012, same year SC was kickstarted. So... they didn't use the most available tech back then? They were using 11? Already released 3 years previously?

My hot take, Vulkan support is nowhere near ready. They've hit some blockers or.... hey, Ben Parry recently left. Maybe its a resource issue. Was he their Vulkan guru?
 
Citizen's Mind from Reddit...

One thing is sure reading those reports. SQ42 is nowhere near beta. You don't go into "full production" on anything near beta release.

Or maybe CIG is again using own definition of therms. You see alpha in computer programming means all tech features are in and you are going full production.

Star Citizen is not alpha by that standards but pre-alpha aka phase where you research technology to develop game before production.

So SQ42 "beta" in CIG therms would be just alpha. All tech is ready for what they want to do and they will start working.

That being said considering the amount of work they did on some stuff it is hard to call clear alpha/pre-alpha.
 
It is some feat to write such a wall of text and still leave you without a clue as to what the thing is like at the moment. Confused why for some reason this doesn't fit as roadmap entries/cards/whatever. Some bits tell their own story, mind, for example:

continued iterations on Vanduul melee behavior, which now automatically evaluates the suitability of specific special actions (dodging, jump attacks, melee attacks, etc.)

It now automatically evaluates the suitability of specific special actions such as dodging or attacking in melee... One would be forgiven to assume that therefore, as of last month, Vanduul NPCs would just stand (T-posed on a seat?) and randomly attack/dodge the player.

I for one will be looking forward to Vanduul Bartenders.
 
No, I said the tech they add now is the final one and tailored for the future MMO part of SC, not the actual 50 players limitation.
And it's 6 years of development for me with development priorities on SQ42, not SC.
Oh, dear sir, I forgot again that you do call server meshing an one server, despite I've explained to you that this is incorrect.
And it may be 6 years of development for you, dear sir, but it's 9 years for Chris Roberts. I beleive he is the producer, not you?

How can you count 9 years for something that was only decided later ?
It's easy, dear sir - I subtract the date that Chris Roberts declared as the start of current project development from the current date.
How many years is it OK to take pledges for an MMO without getting two servers to share session state?
9 years and counting. Stay tuned!

Weasels are cute animals.
While they are cute animals, they are not very cute people.

The fact is they have started to test iCache with Pico on the actual 3.10.2.
CIG have just finished the iCache service which is the main brick.
Dear sir, testing phase is actually a part of development, not something that is done when development is finished.

For the backend structure yes. They integrate it in the alpha now.
Excuse me, dear sir, haven't you said
You need all services to work before trying to establish a real contact between 2 serveurs.
That would mean that iCache isn't working in SC.

And when the developer had to throw away the vast majority of what have been done because the whole design had changed, it's called a reboot.
No, dear sir, that is called a failure.
 
Last edited:
It takes some feat to write such a wall of text and still leave you without a clue as to what the thing is like at the moment.
Sounds to me like they sent a mail around the teams asking for status updates and just pasted them in a list - hence you get the very vague 'we did some mo-cap' and the very detailed 'we saved 4 bytes of data' - depending how the team lead was feeling.

None of it has the feel of 'we're nearly done' though, does it?
 
It is some feat to write such a wall of text and still leave you without a clue as to what the thing is like at the moment.
The more words, the more faithful can think there's progress. It's the litteral representation of Chris handwave. I could bet one day we'll get a "lorem ipsum" update report.
 
No, dear sir, that is called a failure.
When you start to build a small house, and you are given the budget to build a skyscraper, having to destroy your not finished small house to build your skyscraper is not what I call a failure.

Why would they be starting to look into DX11.1 support if Vulkan is almost ready?
Yes indeed it's not a good news. Delay again expected...
 
Last edited:
Sounds to me like they sent a mail around the teams asking for status updates and just pasted them in a list - hence you get the very vague 'we did some mo-cap' and the very detailed 'we saved 4 bytes of data' - depending how the team lead was feeling.

None of it has the feel of 'we're nearly done' though, does it?
We get them every month via email...they invariably read exactly the same. A lot of meaningless words written in lines that say nothing at all. Attempting to read through them is like sitting in the doctors or dentist waiting room leafing through 'Country life'.
 
Sounds to me like they sent a mail around the teams asking for status updates and just pasted them in a list - hence you get the very vague 'we did some mo-cap' and the very detailed 'we saved 4 bytes of data' - depending how the team lead was feeling.

None of it has the feel of 'we're nearly done' though, does it?
No. Did they rework the roadmap again to this? It does have some benefit, a wall of text is not so popular to read and might deter some critics.
 
When you start to build a small house, and you are given the budget to build a skycrapper, having to destroy your not finished small house to build your skycrapper is not what I call a failure.


...
You may want to change it to "skyscraper" - a skycrapper is something different. But anyway: If I'm given a budget for a skyscraper - why would I start tearing down the house I've been building for eight years? Is rhetoric question. The real question of course is: Why would someone build a small house for eight years in the first place with a skyscaper budget?
 
You may want to change it to "skyscraper" - a skycrapper is something different. But anyway: If I'm given a budget for a skyscraper - why would I start tearing down the house I've been building for eight years? Is rhetoric question. The real question of course is: Why would someone build a small house for eight years in the first place with a skyscaper budget?
And I'd first find another terrain as the one for the tiny house is probably not suitable for a skyscraper. And if it is, it's obvious the foundations for the house (if I had them done of course) aren't suitable.
 
If I'm given a budget for a skyscraper - why would I start tearing down the house I've been building for eight years? Is rhetoric question. The real question of course is: Why would someone build a small house for eight years in the first place with a skyscaper budget?
CIG was building a small house till 2014/2015. Then the budget skyrocketed and CIG decided to build a skyscraper since then.
And you have to destroy your small house because its foundations will never hold up with a skyscraper.
 
And I'd first find another terrain as the one for the tiny house is probably not suitable for a skyscraper. And if it is, it's obvious the foundations for the house (if I had them done of course) aren't suitable.
Exactly. Like hiring hundred of persons to build the new fundations, switching to 64 bits positions, create new tools, etc
 
CIG was building a small house till 2014/2015. Then the budget skyrocketed and CIG decided to build a skyscraper since then.
And you have to destroy your small house because its foundations will never hold up with a skyscraper.
They wanted to build two games from the start. SQ42 (house budget is good enough I guess, he must have blown it with celebrity mocap in one go I guess) and SC - a MMO in living universe (requires skyscraper budget)
 
Back
Top Bottom