PROGRAMMING (Engine, API, Hardware, etc)

  • BParry_CIG

    Developer

    Posted:
    Posted:
    [hide]

    [hide]

    Please do not discuss dev replies or other user's posts in this thread. If you would like to talk about VR or it's implementation or the future of that tech in Star Citizen, please continue that discussion here where we've moved those replies to https://forums.robertsspaceindustries.com/discussion/370122/vr-discussion, or start a new thread in a different more appropriate subforum. Follow-up questions for devs are perfectly fine here though.

    Thanks.

    Ben, I suspect this might have gotten lost in the discussion - can you point us towards whomever would be the right person to ask about headtracking? (NOT VR! separate issue! :) )
    Sorry, @Krel, I'm not too sure about whom to contact - partly because I'm bad at inter-team communication, but also partly because I don't know which devs really like being contacted directly (or even have forum accounts). It's best to go through community management.
    I try to poke people into coming in here but it mostly doesn't work.
    Programmer - Graphics Team
  • sniper2333

    Posts: 501

    Posted:
    Edited: by sniper2333
    Posted:
    Edited:
    will it be possible to pass that legendary door in our hangar with 3.0, if this happen, will we have permission to cry ?
    bbf78a4694903b997b023e66126f2fc0.gif
    The game (Star Citizen) will speak for itself - Christopher Roberts
    Welcome to Roberts Salt Industries, enjoy the salt
  • Kalrati

    Posts: 13

    Posted:
    Posted:
    Hey Ben! First time posting in the developers' section. It's more on the networking side.
    I've been doing some reading about network optimization and this journal came up (below). In terms of network coding to support a player count of say (an exaggerated amount) 500,000 players, is it that currently, there exists a huge trade off (correlation) between high continuous data rates from a server to client and the noise tolerance reduction that may occur? I do understand the netcoding side of it and how it affects the ping based on distance, but in terms of player count support and stability, does this article have any relevance? I'm curious because I was thinking that while unifying even dedicated servers may help, we'd still be scratching our heads to bending the current underlying technology to meet a very very high player count. It'll be amazing and enjoyable still if we can eventually player with 100 players or a bit more but just thought I'd include this bit also. I REALLY hope we get to see an AtV segment of the networking steps that would have been made for 3.0 when that time comes!

    Networking sure is difficult! But it sounds really intriguing!

    https://www.researchgate.net/profile/Antonio_Napoli/publication/271470858_FEC_Overhead_and_Fiber_Nonlinearity_Mitigation_Performance_and_Power_Consumption_Tradeoffs/links/5632bb8b08ae911fcd491718.pdf
  • BParry_CIG

    Developer

    Posted:
    Posted:
    [hide]

    [hide]

    [hide]

    Some of us who are VR users have been using every work around we can find to play the current iteration(s) of Star Citizen with our VR headsets right now. For those that don't tend to have VR sickness issues, Star Citizen even in it's current unoptimized, buggy, laggy state is still a wonderful thing to behold. For me, even the jerky seat entrance animations aren't a deal breaker.

    Over time we have lost things like the stereoscopic console commands that make VR much easier to implement. Having to rely on frame shifting to get stereoscopic 3D is at best pretty crappy, but I still prefer to play that way when I can, then to play on a monitor.

    Is there any way that some of the console commands can be switched back on for users like us? At least the stereoscopic ones? I understand not wanting people to have a bad experience in VR, and I can see where not making it plug and play right now is for the best, but for those that are already willing to do whatever legwork is necessary to get a less than optimal experience in the game right now, isn't there something that can be done to make things better?

    @lmac, I'll double check about the stereoscopic console commands tomorrow. I think it's likely that they're broken right now, the rendering pipeline was in a very fragile state when we got it, so getting it working again would probably require someone to spend some dedicated time working out a clean solution for it. I don't know that though, they might just not be on the whitelist.
    @BParry_CIG

    Hi Ben, I was just wondering if you had a chance to check into this and what the outcome was.

    Thanks for your time.
    Hi @lmac,
    I gave those CVars a try today and it looks like there's some shader issue that needs looking at rather than just a whitelist problem. I'll make sure the team's aware of it and we'll try to schedule a fix.

    Programmer - Graphics Team
  • ABrown_CIG

    Staff

    Posted:
    Posted:
    [hide]

    Hey Ben! First time posting in the developers' section. It's more on the networking side.
    I've been doing some reading about network optimization and this journal came up (below). In terms of network coding to support a player count of say (an exaggerated amount) 500,000 players, is it that currently, there exists a huge trade off (correlation) between high continuous data rates from a server to client and the noise tolerance reduction that may occur? I do understand the netcoding side of it and how it affects the ping based on distance, but in terms of player count support and stability, does this article have any relevance? I'm curious because I was thinking that while unifying even dedicated servers may help, we'd still be scratching our heads to bending the current underlying technology to meet a very very high player count. It'll be amazing and enjoyable still if we can eventually player with 100 players or a bit more but just thought I'd include this bit also. I REALLY hope we get to see an AtV segment of the networking steps that would have been made for 3.0 when that time comes!

    Networking sure is difficult! But it sounds really intriguing!

    https://www.researchgate.net/profile/Antonio_Napoli/publication/271470858_FEC_Overhead_and_Fiber_Nonlinearity_Mitigation_Performance_and_Power_Consumption_Tradeoffs/links/5632bb8b08ae911fcd491718.pdf

    Hi Kalrati,

    Unfortunately Ben nor myself work on the networking team so don't have any insight into the problems or solutions in this area. I'll nudge the network lead to see if any of their team have the time to take a look at the network related questions here.

    Cheers,

    Ali Brown - Director of Graphics Engineering
  • ABrown_CIG

    Staff

    Posted:
    Edited: by ABrown_CIG
    Posted:
    Edited:
    [hide]

    Did they manage to get to the bottom of the lighting bug in the PU that keeps changing colour tone randomly?

    Hi Azaral,

    This will most likely be a setup issue with the trigger volumes and logic that the art & design teams use to control color grading across the level (e.g. if you manage to escape a space station but don't pass through specific trigger volumes then the color grade might not be updated). If there is a known set of steps to reliably reproduce the issue I'd recommend raising it in the issue council.

    This setup however is intended to be replaced with a more reliable and systemic system to control color grading where every room is tagged with the desired color grade / mood (either by art or procedurally by code). This system will be updated every frame and doesn't rely on hand placed trigger volumes so will never get into an incorrect state, even if you somehow teleport from one location to another. This will likely have a dependency on the 'room system' being developed in LA so it's something we intend to address later in the year, and is a required feature for both 3.0 and Squadron 42.

    PS. Apologies for my earlier post which was from my personal account rather than my staff account.

    Cheers,

    Ali Brown - Director of Graphics Engineering
  • BParry_CIG

    Developer

    Posted:
    Posted:
    [hide]

    Hey!
    Any idea what Cvars can control the particle tessellation values? The old ones seem to not work any longer in the new particle lightings system?

    Since I have a powerful NV card, and not an AMD card which struggles with the tessellation, I would love to be able to tweak the values to avoid large pixelation like so (check out the shadows on the smoke billboard near the middle piping):
    starcitizen_2017_01_157kc3.png
    starcitizen_2017_01_175kdk.png

    Hi @Dictator,
    There's definitely some work to be done on the particle shadows - you might have noticed that the quality's actually higher for local lights (not perfect, but better) than it is for the sun. This was basically just a legacy issue, better shadows needed to take several taps of the shadow texture, but the way the sun cascades were set up, those extra taps would have been duplicated in each cascade and the cost was prohibitive. We've been making a lot of changes to how the sun works though (it now shares memory with the main shadow pool), and a side benefit of that is that the duplication goes away.
    The performance problem wasn't really about the amount of tessellation though, it was about the amount of work we do for each vertex after the tessellation, so it's unlikely nVidia would fare better than AMD for this.
    [hide]

    I wish to ask: does Star Citizen make use of tonemapping for processing the shaders/materials in any way?

    And I have sort of a following question maybe relevant to tonemapping:

    Re. graphics and anti-aliasing: Being very far from being an expert on the subject, still, I can't help but wonder, if maybe controlling highlights on detailed spaceship models might be a good idea, when having models viewed at some medium, and close range where LOD models are closer to LOD0 (most detailed), and where brightly lit pixels would demand the most of anti-aliasing efforts, such that maybe toning down the highlight somehow with tonemapping, could maybe make the anti-aliasing look a little better that way.

    Presumably, one wouldn't want an entire broadside of a ship that has been brightly lit, to be tonemapped down to some weird looking level, as if artificially darkening an entire surface (a large area of pixels), and maybe only reduce the highlight on really thin geometry, like railings and bevels. I guess I imagine tonemapping here to be some kind of intelligent clamping of the most bright pixels closer to white, to be more effective the more thin, say, a railing or beveled surface might be, and more relaxed when a highlight has more pixel area to blend with the rest of the colors.

    I am sort of assuming that overly bright pixels, might come about due to a material being very reflective, or being lit by a light source, or when the geometry is relatively thin, like a hand railing or any other beveled surface, which I imagine might pose a difficulty for anti-aliasing efforts. Although I suspect smoothly beveled surfaces fare better with anti-aliasing than hard edged bevels, "thin" bevels probably make highlights difficult to smooth out with anti-aliasing.

    I guess tonemapping is normally associated with High Dymamic Range pixel data (more than 8bit RGB colors), though I couldn't help but wonder if 256 levels of brightness could still be enough fidelity as a useful tweak to how bright a pixel is, when a pixel turns towards pure white.

    Hi @realspacehobo!
    First off - yes, we do use tonemapping. All our scenes are lit in 16-bit floating point colours (this is standard throughout the industry), then at the end of the pipeline it passes through an exposure scale to get it into a reasonable range (this is equivalent to a real world camera's shutter speed or aperture size), a filmic tonemap (equivalent to camera film), and a colour correction lookup table (for artistic tweaks).
    When it comes to standalone bright pixels, there's three things to help with them:
    1) Firefly reduction: The new optics code from a couple of months ago has a "firefly reduction" step, which basically just throws away any really bright outliers it finds in the image. This helps deal with sub-pixel details that are flickering in and out.
    2) Conventional antialiasing: High quality temporal antialiasing has been turned off for a long time now, as it introduces a lot of artefacts for transparent objects. We've been working to move that step to an earlier point in the pipeline where it won't be able to cause those issues, and obviously the more antialiasing, the less isolated bright pixels.
    3) Specular antialiasing: A lot of glitter comes from sharp, high-gloss edges. It's actually pretty reasonable to assume that if two adjacent pixels are pointing in drastically different directions, the space between the pixel centres must have a gradient between the two, and you can approximate that variance by increasing the roughness (we already do this inside textures, as an object's normal map blurs out in the distance, the roughness increases to compensate).
    This is an approximation, though. Roughness is omnidirectional but often the spread of normals should all be aligned perpendicular to the edge, also, we don't know whether that spread should happen across the whole distance, or if it actually happens in a tenth of the range, or whatever.
    Because the approximation can add an odd cartoonish highlight on some objects, even as it improves others, we've left it turned off for now. If you're interested in trying it out, though, I'm adding it to the whitelisted CVars in the next 2.6 build. r_DeferredShadingFilterGBuffer = 1Add that to your User.cfg and see what you think.
    Programmer - Graphics Team
  • Krel

    Posts: 6300

    Posted:
    Posted:
    Not sure where else to ask this, but this section is the only one that gets any interaction so... ;)

    Any idea if a mobile app for Spectrum is actively in development yet? I know it's in the plans at some point, just wondering if it's being currently worked on.
  • Fushko

    Posts: 257

    Posted:
    Edited: by Fushko
    Posted:
    Edited:
    Why did the following cvars: "cl_fov" and "r_drawnearfov" get locked/removed in 2.6?

    I assume there is a good reason for this change. As of now, I literally (and I mean literally) cannot play the game for more than 10 minutes without getting a massive headache, given that the default FOV is extremely narrow for my 900p screen. It's caused me to stop playing 2.6 entirely because an headache is basically guaranteed. I wish I was joking.

    Wild guess: is it because increasing the FOV also stretched the 1st person helmet model in an ugly way? If that is the case, didn't r_drawnearfov take care of that already?


    On a probably related note: as of 2.6, the helmet model and its HUD don't seem to scale at all between different resolutions. The helmet blocks a fixed amount of view regardless of screen res. How do you guys plan to tackle this issue?
    5788x1080-outlaw.png
    (That's not my screen heh, but you get the idea)

    Sorry about barrage of questions, but the FOV situation is a concern shared by a lot of citizens lately, and a clear answer on what are the plans & issues you are tackling with FOV would be hugely appreciated.
  • Kalider

    Posts: 11

    Posted:
    Posted:
    Hi, Two questions ?
    1)
    Will planet modelling be available for outside 3D Artists and Developers?
    I mean can I load a spherical terrain like the one show in CitizenCon 2016, where CIG Artists are creating a scene with cryengine ?
    We can create terrains in cryengine (Lumberyard now) but with flat terrain surface as basis. Can we have, say a blank planet template to "create a world". CIG could for instance make a contest like "The Next Spaceship". Artists could contribute with new worlds. just an idea.

    2)
    When can we have an API to communicate with the Game and to retrieve, for instance the position of our ship in the universe, to create external MFD, for example in android Tablets, etc.

    Thanks
    - UEE SAR -
    So others may live
  • ABrown_CIG

    Staff

    Posted:
    Edited: by ABrown_CIG
    Posted:
    Edited:
    [hide]

    Is there plans to add sharpening at some point? I was getting some really good results using reshader to add a sharpening filter. It brings out a lot more definition particularly when you look at the player armor for example.

    There is a sharpening filter built into Lumberyard, and while we hadn't planned on exposing this it's certainly something we can consider if it's of interest to the backers. We'd need to ensure any user defined settings didn't interfere with the intentions of the artists (e.g. if art/design were to enable sharpening when you're hit, and if you have it forced on all the time this may lessen the impact), but I can't see this being a big issue. However for more exotic image filters you'll always get more flexibility with external apps like SweetFX as these allow to completely change the visual direction of the game whereas our focus is to deliver the vision of the art directors..
    [hide]

    Any word on an HDR video output ? I hope Star Citizen won't stay an 8 bit per chanel game..

    HDR output is something the graphics team are very interested in, and would be a nice self-contained mini-project for one of the team. For now our first step is to get hold of some hardware, and then we just need to start experimenting to see what works for Star Citizen and how much work is involved. Our game uses a very wide range of exposures and colors are kept at 16bit so enabling HDR output wouldn't be difficult, however our tone-mapping and lens effects (bloom/flares) are balanced for a low-dynamic-range display so would need to be tweaked before we'd get the desired visuals. I'll see where we're at on the hardware-front and post back once I know more.
    [hide]

    Hey @ABrown_CIG your comments here have led to some worry and speculation within my org, more questions than answers it seems.

    Apologies if my comment was vague, let me clarify the situation with the color-processing. It's actually a very simple piece of tech from our perspective, but has a few dependencies on currently-in-progress work from other departments which makes assessing precisely when it'll be 100% complete a bit tricky without me firing off a bunch of e-mails, but it certainly wouldn't block any particular release. Therefore "later in the year" is clearly a poor choice of words as it can be misinterpreted as something in the later half of the year where I literally meant "at some point later than today".

    But yeah this isn't the right place to discuss release dates, and I'd recommend against inferring any dates from comments on here. It's always best to check the official updates from production or Chris for this type of info.

    Cheers,

    Ali Brown - Director of Graphics Engineering
  • BParry_CIG

    Developer

    Posted:
    Posted:
    [hide]

    [hide]

    [hide]

    Hey!
    Any idea what Cvars can control the particle tessellation values? The old ones seem to not work any longer in the new particle lightings system?

    Since I have a powerful NV card, and not an AMD card which struggles with the tessellation, I would love to be able to tweak the values to avoid large pixelation like so (check out the shadows on the smoke billboard near the middle piping):
    starcitizen_2017_01_157kc3.png
    starcitizen_2017_01_175kdk.png

    Hi @Dictator,
    There's definitely some work to be done on the particle shadows - you might have noticed that the quality's actually higher for local lights (not perfect, but better) than it is for the sun. This was basically just a legacy issue, better shadows needed to take several taps of the shadow texture, but the way the sun cascades were set up, those extra taps would have been duplicated in each cascade and the cost was prohibitive. We've been making a lot of changes to how the sun works though (it now shares memory with the main shadow pool), and a side benefit of that is that the duplication goes away.
    The performance problem wasn't really about the amount of tessellation though, it was about the amount of work we do for each vertex after the tessellation, so it's unlikely nVidia would fare better than AMD for this.
    Thanks for the reply Ben!

    Interesting to note that that was actually a legacy issue that is getting cleaned up! Does that mean both sun and spotlight particle shadows will see bumps in quality? Or just a matching of quality for the sun shadows?
    Hi @Dictator,
    The changes I mentioned, with the sun cascades, are primarily about bringing the sun shadows up to the quality of the others, though one other benefit of these changes is that when the sun isn't active, the memory should be available for other shadows to increase resolution.
    Ali's spoken about other tweaks that would add quality across the board, but those would be independent changes.
    [hide]


    I saw these interesting tidbits in the monthly report:

    Considering how so much of our concept art makes heavy use of rectangular lights, we’ve started work on area lights. While this may sound simple, area lights are actually an active area of research for many game studios and are incredibly difficult to get right (both in terms of looks and performance). Lastly, we’re in the early stages of planning for a new and vastly more efficient particle system that eventually will replace the current one.

    What kind of stuff is being done to the rectangular area lights? They seem to, for the most part as I can see, work properly in terms of specular shape atm. Perhaps getting them to shadow? Or something else?

    Also, what kind of awesome stuff are you guys cooking up for the particle system?

    Best,
    Since I'm working on the planar lights right now, I conveniently have a comparison screenshot to hand. While this isn't final, and some further tests have shown our approximation is quite a bit brighter than it should be, it does show the issues with the old model and the limitations of the new (the reference model at the bottom is a 10x50 grid of disc lights covering the same area)
    Specularitah.png

    Programmer - Graphics Team
  • Foodoo

    Posts: 79

    Posted:
    Posted:
    i read on the last monthly update you were going to write the back end code in some of your own propriety language. What advantages / disadvantages does this give you? Im guessing more stable against hackers and backed vulnerabilities or is there more to it?
  • JuanBrOLO

    Posts: 8

    Posted:
    Posted:
    Hey guys I am not sure if this is where to post but i was wondering if you guys knew a way to make the cutlass flash fire turret specialty mount work?. i know nobody has been able to make it work yet so i was just wondering as this would make a huge difference in the ship. anyhow keep up the awesome work i love this game and the entire idea of it. cant wait to see whats planned next.
    Whoever appeals to the law against his fellow man is either a fool or a coward. Whoever cannot take care of himself without that law is both. For a wounded man shall say to his assailant, "if I die, You are forgiven. If I live, I will kill you." ..HONOR..
  • Guerreiro_Anfibio

    Posts: 3

    Posted:
    Posted:
    Hi, this is my first question here, hope it gets answered.

    I've seen in a previous episode of ATV that CIG plans to use some kind of distributed peer-to-peer server clusters for handling instancing in an elastic way for the gameplay simulation. If I understood it right, the workload for a high populated area will be shared between multiple servers communicating between themselves, thus allowing hundreds of players flying/walking in the same area of network visibility.

    I've never seen this architecture for gameplay servers, but there are some examples of distributed p2p database servers like Apache Cassandra (which is used by Netflix), Elasticsearch, Google BigData. The requirements of a database are different than gameplay servers, but I think that this can be done.

    So, my question is: What kind of database is CIG using for data persistency in the game? Is it the same old relational databases (which I think is a terrible choice for the scale of the game), or something in a distributed p2p fashion like Apache Cassandra or Elasticsearch (which are more suited for giant datasets)?

    Guerreiro Anfíbio
  • ShadowSpear

    Posts: 12

    Posted:
    Posted:
    I don't really post on forums much, i think this is like my 3rd post in 3 years for this game. I watched the latest around the verse dealing with multi-region servers. I'm a lower level network engineer for my company so by no means do I claim to know everything at all. I have one simple question that I don't understand after looking at your model.

    Why are you guys using TCP over UDP?
  • ABrown_CIG

    Staff

    Posted:
    Posted:
    [hide]


    I think many people would find a resolution scale slider useful. Often the GPU is not fast enough to maintain stable framerates at UHD. Options like 85% of UHD would be valuable to get the maximum picture quality out of the hardware while enjoying stable framerates.

    You should be able to use "r_width=1920" and "r_height=1080" in your user.cfg file (if you don't have one then create one in the root folder of the game's install path) and specify any resolution you wish. If you use a non-standard resolution for your monitor you will however get quality issues as the image will just be naively stretched/up-scaled onto the monitors pixels. Algorithms do exist to improve such up-scaling, but this isn't something we currently support or are focusing on in the near future.
    [hide]


    It would also be nice to have a dynamic resolution scaling which is based on the performance like in Gears of War 4 but I assume it costs more time to implement something like that. The same applies to lower-resolution edge areas in the image. As is the case with some VR games.

    Dynamic resolution scaling isn't on our road-map at present, but we do have time scheduled for a major GPU optimization pass. This process will involve running the game on various levels of hardware and identifying where the bottlenecks are for our game on each GPU, and then putting in place controls to alleviate these where possible. Dynamic resolution scaling is only really relevant if your game is fill-rate limited (too much work per-pixel) and only in specific situations or for a limited time (e.g. during explosions), whereas if you're constantly fill-rate limited then we'd instead need to look at reducing the overall work per pixel (e.g. lower quality lighting/shadows). However there are many other potential bottlenecks such as too many vertices, too many draw calls, expensive compute shader, or fill-rate limited off-screen effects. So we'll determine what performance controls we need to add based on the results of these hardware tests.
    [hide]


    Sharpening is a major graphical improvement imho a must have. If there is a filter there that we could use with a slider or value adjustments it would be very appreciated.

    You can add "r_sharpening=0.5" to your user.cfg to enable sharpening (can also be changed via console). You can set this to any number you wish, but personally I find anything over 0.5 just increases the aliasing.
    [hide]


    But I think a good temporal anti-aliasing algorithm is even more important because of the much lower performance impact. A combination of both would be awesome though!
    Alexander

    I started on a major update to our anti-aliasing last year, but this was paused during the build up to 2.6 and will be picked up again in the future. We started by taking the Lumberyard temporal AA, however we found this had major issues in our game due as it doesn't deal with transparency correctly and results in a visible 'juddering' behind anything transparent. Given we spend most of the time in our game looking through a glass visor, glass cockpit or transparent UIs/holograms this made it pretty much unusable (you can enable it via r_antialiasingmode=3 in your user.cfg, and it looks noticeably better on opaque geometry but suffers badly on the UI and glass). Our work-in-progress technique applies the AA earlier in the rendering pipeline to avoid some of these issues and attempts to better identify matching pixels from the previous frame to allow sampling over multiple frames for a cleaner image without ghosting or juddering.

    Cheers,

    Ali Brown - Director of Graphics Engineering

  • aesu

    Posts: 54

    Posted:
    Posted:
    I am playing from Hong Kong and China and the latency on the game is really bad for me... any chance on getting up a server close by so I can enjoy Star Citizen?
    Everything I do is my signature.
  • ABrown_CIG

    Staff

    Posted:
    Posted:
    [hide]

    @ABrown_CIG I still connot play Star Marine on my 21:9 monitor because the loadout customization screen has the enable button on the bottom cut off.
    Any chance this can be addressed soon?
    R

    I forwarded your message to our UI Director, and he says they're aware of the issue and this is their top priority and will be fixed in the next patch. As a workaround you should be able to create a user.cfg text file in your install folder and add the following.

    r_width=1920
    r_height=1080

    Once you're in game you can use the open the console using the tilde key (below ESC) and use the same commands to set the resolution back to your native monitor resolution. Obviously this isn't great, but hopefully it'll allow you to play the game until the fix is in.
    [hide]

    Hi,
    i have seen gameplay in ADRIFT.
    The space station structure has a really nice white color.
    The structure of the stations in SC are a little bit gray compared to the ADRIFT station.
    Has ADRIFT another lighting for the level (Unreal Engine 4) or use the artists in SC another color for the station structure?

    The Adrift scene is lit by white sun but there's a very strong blue bounced light reflection from the earth, and the variation between the blue and white light is what makes this look so nice.

    Olisar is lit by a much more red/yellow sun, and there's no significant bounced light as Crusader is much darker and further away than earth in Adrift. This results in a flatter and more red hue which I personally agree isn't as visually appealing (very subjective though!).

    So partly this is an artistic decision and partly unfortunate positioning of Olisar. But we are working on real time cubemap/env-probe tech which will help improve the quality of the bounced light, and with future updates we're adding more space stations in more varied locations so I'm sure we'll see some more interesting lighting situations.
    [hide]

    Ali or Ben,
    Do you happen to know what the status is as far as looking at the issues with surround resolutions? 5760x1080, 7680x1440, 5.3:1 scale, that range. Specifically, three things:

    1. Menu and UI elements scaling with the full surround width so rather than the scale correctly for the center monitor they are way too big. I posted a couple examples of this earlier in the thread, I can easily repost if it would help.

    2. Locked field of view - obviously adding a FOV slider would be a future task but the cl_fov entry in user.cfg has been locked out now so we can't change it at all. Can you look into whether it would be possible to make that accessible again?

    3. Effects overlays - it looks like there is an effects layer that's 4096 pixels wide (give or take.) You can see it in arena commander very easily, if it would help I can get some video.

    1. I've let the UI Director know of the wide-screen / multi-monitor UI issue you posted previously and it's a known issue which they're looking into.

    2. There's an on-going discussion about this at the moment and we're looking into potential solutions. Unfortunately due to the way we attach some of our UI to a physical helmet model, and also the complexity of our ship UIs we need to take great care in how we deal with FOV (not as simple as just changing it and shuffling around a simple 2D UI). However I'm confident your concerns will be addressed, so watch this space!

    3. Can you post an example of this? We're not aware of any limit in width of any of the effects in game, but we can certainly investigate.
    [hide]


    SC could definitely benefit from improvements to its transparent objects/glass materials, though I do vaguely remember one of the engineers a ways back saying there was some work being done there/with things like order independent transparency, to improve transparency rendering?

    We do plan improve our glass effects to add several cool features (condensation, blood, cracking, spider-webbing, translucency), but as these are mostly just a graphical niceties they've been trumped by more fundamental rendering features thus far. But it won't be too long before we're seeing much prettier glass in the PU.
    [hide]


    Also, I haven't dug into what you guys are you using fully currently in-game. Does SC currently use any form of specular occlusion?

    We use Screen Space Directional Occlusion (SSDO) to individually occlude our diffuse, ambient & specular lights. This is much better than typical ambient occlusion (AO) effects as these don't take light angle into account and therefore are poor at occluding specular. The SSDO effect is however on our near-term roadmap to improve as we have some ideas how we could get better results for specular, but this also ties into the area light work we're currently doing because traditional shadow mapping doesn't really work for soft area lights but an improved SSDO effect is much better suited.

    Cheers,

    Ali Brown - Director of Graphics Engineering
  • ArchMarine

    Posts: 41

    Posted:
    Edited: by ArchMarine
    Posted:
    Edited:
    When can we start seeing other peoples flash lights and lighting on the ships worknig properly? Is their a problem with the engine or something in preventing the ability to see other people generating lighting? Personally I see it as a major issue when your exploring a dark area with friends (or enemies) and can't see their flash lights. Takes away from the immersion aspect completely.

    Never mind, looks like you guys already fixed this issue! Thanks CIG!
    2449039.jpg
  • Primalabandon

    Posts: 1294

    Posted:
    Edited: by Primalabandon
    Posted:
    Edited:
    Will you guys be integrating Speedtree 8 into your lumberyard build seeing as thats the engine getting it first?

    the screenshots from it look really good, the new flora you guys have shown off that is newly created is not very impressive tbh BUT is it viable to have that level of detail of trees and stuff on a planetary scale and has the flora recently been created been designed with a limit to how detailed it can be so the game doesnt cripple under the graphical load??
    bvcsorF.pngaBIG3k3.png
    >
  • ABrown_CIG

    Staff

    Posted:
    Posted:
    [hide]

    How about an actual fix or some kind of answer to trouble call tickets?

    Hi DumpiTruck,

    This thread is for Q&A with the programming devs and not for dealing with support tickets. However I thought I'd try to help, but given you haven't provided a support ticket I looked through your other posts and responded in one of those threads. It sounds like your issue is that it's still using the lesser powered GPU in your machine, but I've let you know how to verify whether this is the case, and if this isn't the case and this is a different issue then you really need to create a separate support ticket to differentiate your issue from the other issues in that thread (which do have solutions).

    Cheers,

    Ali Brown - Director of Graphics Engineering
  • ABrown_CIG

    Staff

    Posted:
    Posted:
    [hide]

    Hey there,
    I have a question.
    In the future, would Star Citizen have Linux support or is Star Citizen "Windows Mafia" only?

    Hi Profit_Hsssssss,

    Linux support is a stretch goal and is on the long term road-map. We already run our servers on Linux so the core game code already works fine, but to get the client working we first we need to move the renderer over to the Vulkan API rather than Microsoft's DirectX. We've been taking steps towards for some time, but there's still plenty to do. That covers the visuals & game-code, so would just leave Audio, Input and general per-platform work such as as installers, none of which I'm familiar with but will all likely need some amount of work.
    [hide]

    I have a question about the game engine performance. Do you have a feeling or even data that suggests the engine will do better with more cpu cores (8c16t) or if it relies more on higher clock speeds on a 4c8t setup?

    Would you consider doing a small benchmark of two processors to find out?

    Hi NightshadeXL,

    Historically games & game-engines have focused on 1-4 core performance, inline with the hardware of the time, but over the last 5+ years the focus has shifted to spreading the work over as many cores as possible. We've been making huge strides in this area but there are a few systems that are still able to bottleneck a single CPU. The two biggest are the game-code and the renderer, which each primarily run on their own threads/CPUs but are often able to saturate those threads/CPUs and if they do then the frame-rate becomes limited by the clock speed of your CPU. However this situation is improving every week thanks to improved distributed code systems, and so while a high clock speed may be a benefit today, the trend will be for more cores to be of greater benefit in the future. So unfortunately there is no simple answer to your question, it depends which CPUs you're comparing, which level/gameplay-scenario you're playing, and whether you're looking for a system for today's build or a future build.
    [hide]

    Many reviews of the AMD Ryzen R7 CPU's have said that while they excel at the benchmarks they fall short on gaming performance. AMD's response was that since this is such a new and different product that it'll take some time for developers to learn how best to optimize for their CPUs. Is this something that you guys are planning on doing?

    Hi Thevanin,

    We are hoping to get our hands on some of these CPUs in the near future to see if there's anything particular we should optimize for them. It's possible there are differences in the way it handles multi-threading that we need to cater for, however it could also just be that it favors fully multi-threaded work as opposed to single-core bottlenecks as discussed above. If that was indeed the case then it's performance with Star Citizen would improve over time as we spread the workload over more cores.
    [hide]


    r_width/r_height are locked like cl_fov btw

    Hi apoketo,

    Ah yes you're right, easy to forget what's inaccessible in public builds! I guess you'd have to go through the menu's instead, but I'd need to test whether this is a solution for the original reported problem.

    Cheers,
  • THEMIKEBERG

    Posts: 541

    Posted:
    Posted:
    Hey Ali/Ben

    I don't think this is either of your areas but I'm just wondering if you might have any insight towards rendering of capital ships?

    IIRC last we heard they don't "fit on memory" or rather are too large to render all at once? Was said that there are some unique rendering challenges involved with Capital and larger ships.

    If you know what kind of progress has been made there I'd love to hear about it!
    M50 Adventures!
  • ABrown_CIG

    Staff

    Posted:
    Posted:
    [hide]

    Hello Ben,

    Any idea if we will see Track IR support implemented into the game anytime soon?

    There is a work around using free pie, so surely CIG could do it?

    Thanks.

    Hi Orion1632,

    There's two parts to this question, when will TrackIR hardware support be re-enable/fixed, and when will the game code implement the necessary camera controls for a solid user experience. The answer to the first question is that we've already done it and it'll work again in 2.6.2 (i.e. extremely soon). Unfortunately I can't answer the second question as it relates to game-code rather than engine-code. There appears to be just one major bug with TrackIR at present which is that when in a ship the camera moves fine, but the helmet and body doesn't move which means your view can end up being blocked by your own helmet. Hopefully this isn't too difficult to fix and I'll try and prod the right people, but can't promise a fix for any particular release.

    Cheers,

    Ali Brown - Director of Graphics Engineering
  • ABrown_CIG

    Staff

    Posted:
    Posted:
    [hide]

    Long question here! @ABrown_CIG @BParry_CIG !

    ......

    The question could then based on this from me is: is there going to be a system inherited from later versions of CE / Lumberyard to remedy some of the oddities of the the first 3 types of participating media? A system which perhaps unify the way they are rendered so that they reflect more physical properties / do not clash?

    As an example: the voxel based fog used in later versions of CE (not sure if the Lumberyard branch was late enough to have it at all) seems to be a step in a more unified direction... although it may make assumptions in its rendering which are incompatible how "scaled" SC is (large areas which would typically be cube shaped maps are actually on 3D planets! Ships could have fog volumes in them which are rapidly moving through space!). Much like the voxel fog done in other engines (like Anvil Next in Assassins Creed, Dunia in Far Cry 4+, or all Frostbite titles since NFS) it can accept colour from point lights moving through it, the local patches of fog (artist placed volumes) likewise can be shadowed and coloured by pointlights, and the "spot light casters" merely just project through the voxel grid which aligns with the player camera.

    Hi Dictator,

    Are you sure you don't actually work here? This summary is pretty comprehensive, even highlighting the major assumptions & flaws in each piece of tech :-)

    So yeah, you're pretty much spot on with everything you've said above. We do want to try and unify some of these, and the Lumberyard volumetric fog tech has lots of great features so we'll certainly be looking into this, however our needs are far more complex than Lumberyard's. The example you mentioned of a moving ship is one of my key concerns, as is the required scale because the LY tech is based on a screen-aligned voxel grid which becomes exponentially less detailed at greater distances so can't represent detailed clouds even remotely far away. We're actually planning the next stage of this work later this week, so I don't have any concrete answers for which precise direction we'll go today, but our intention is to unify the LY volume fog with our gas-cloud tech such that we ray-trace the screen-aligned LY voxels first then the world space gas-cloud voxels. The big problem here is that we need to unify two feature sets that were written by two different teams with different limitations, but fundamentally they're trying to solve aspects of the same problem so I'm hopeful!

    By the way, I'm avoiding the word 'nebula' when discussing space volumetrics as that suggests a ridiculous scale that is pointless trying to represent as a volume as even at light speed you wouldn't see any parallax.

    Cheers,

    Ali Brown - Director of Graphics Engineering

  • sailor67

    Posts: 12291

    Posted:
    Edited: by sailor67
    Posted:
    Edited:
    [hide]

    [hide]

    Hello Ben,

    Any idea if we will see Track IR support implemented into the game anytime soon?

    There is a work around using free pie, so surely CIG could do it?

    Thanks.

    Hi Orion1632,

    There's two parts to this question, when will TrackIR hardware support be re-enable/fixed, and when will the game code implement the necessary camera controls for a solid user experience. The answer to the first question is that we've already done it and it'll work again in 2.6.2 (i.e. extremely soon). Unfortunately I can't answer the second question as it relates to game-code rather than engine-code. There appears to be just one major bug with TrackIR at present which is that when in a ship the camera moves fine, but the helmet and body doesn't move which means your view can end up being blocked by your own helmet. Hopefully this isn't too difficult to fix and I'll try and prod the right people, but can't promise a fix for any particular release.

    Cheers,

    Ali Brown - Director of Graphics Engineering
    Thank you!! That helps a bunch.

    Can you guys give any insight into where huds are going?

    MFD'S are problematic in combat and many are pretty broken for anyone using a stick. Track helps a lot but taking my hands of the stick controls to hit z, control z, three mouse clicks to get an ammo count doesn't work very well in combat or heck while you moving anywhere that is crowed, then I still have problems reading it using a 50 inch TV as a monitor.

    I really really miss the 1.x huds everything worked including trigger groups. 2.x wasn't bad, but getting the trigger groups right was it's own mini game :). 2.4 was the best overall. Every ship had a good hud..
    html>
  • ReinhardO

    Posts: 48

    Posted:
    Posted:
    [hide]

    [hide]

    Hello Ben,

    Any idea if we will see Track IR support implemented into the game anytime soon?

    There is a work around using free pie, so surely CIG could do it?

    Thanks.

    Hi Orion1632,

    There's two parts to this question, when will TrackIR hardware support be re-enable/fixed, and when will the game code implement the necessary camera controls for a solid user experience. The answer to the first question is that we've already done it and it'll work again in 2.6.2 (i.e. extremely soon). Unfortunately I can't answer the second question as it relates to game-code rather than engine-code. There appears to be just one major bug with TrackIR at present which is that when in a ship the camera moves fine, but the helmet and body doesn't move which means your view can end up being blocked by your own helmet. Hopefully this isn't too difficult to fix and I'll try and prod the right people, but can't promise a fix for any particular release.

    Cheers,

    Ali Brown - Director of Graphics Engineering
    Addon question from my side:
    Is "full" support for TrackIR (and eventually VR) planned (be)for the official SQ42 release?
    It would really be nice to have it in SQ42.

    p.s. I know ist a "when question", but since it's only a "before or after" to something that has no official release date, I thought I could ask it.
  • Hartsblade

    Posts: 1302

    Posted:
    Posted:
    @ABrown_CIG

    Hi, I have a quick question about control customization. Are there plans to allow us to bind a function to more than one key/axis at a time? For example binding "Strafe Right/Left" to the X axis of a joystick and to a thumb stick on a throttle.

    Here is the Rise of Flight Options Menu as an example:
    rofkeybind.png
  • Thomas_Jegust

    Posts: 82

    Posted:
    Posted:
    [hide]

    @ABrown_CIG

    Hi, I have a quick question about control customization. Are there plans to allow us to bind a function to more than one key/axis at a time? For example binding "Strafe Right/Left" to the X axis of a joystick and to a thumb stick on a throttle.

    Here is the Rise of Flight Options Menu as an example:
    rofkeybind.png


    Hi there, i think this is a great question and i would like to ask if in addition to bind 1 function to many keys (1-N) it will also possible to bind more than 1 function to just 1 key (N-1)? ... resulting in something more like a (N-N) relationship...

    In the Controller Options Menu of "House of the dying Sun" for example i bound one joystick axis to 2 different functions (roll and yaw), thus resulting in a flight behaviour much more like WW2 or StarWars as a single yaw-movement of one joystick axis did add a bit of rolling.

    hotds_mapping.jpg




Sign In or Register to comment.