-
Posts
305 -
Joined
-
Last visited
-
Days Won
5
Content Type
Profiles
Forums
Store
Articles
A20 Bugs
A21 Bugs
Events
Posts posted by Naz
-
-
20 hours ago, Evil_Geoff said:
Last used in A19, I'm pretty sure you saw the YT video where we used it as a "Rivet City" in TomGirlGamer's 7 Days to Fallout run.
Once Teragon is usable, and I can do a DC heightmap, you know I'm going to put that rascal in there! This is an amazing POI from the radar mast to the keel. ❣️ 💥Yeah i remember watching that, was great seeing how other players like to go through it. This concept art from fallout 3 is what i had in my head at the beginning. However the real ingame version of the fallout 3 carrier was actually really small and kind of square looking and i wanted it to be more "real life" looking. So it's almost a 1:1 scale version of the real ford class carrier.
Fallout 3 Concept Art
Fallout 3 Ingame CarrierGot a couple of tidbits to show. First is the new F35 jets. old ones looked more like Russian migs 😂 Also i've re-done the flight decks stripes to use the new trim blocks and also done a ton of optimising swapping out of the concrete painted metal blocks for unpainted concrete etc and also working on a more efficient way to give stability to the more on the edge areas.
I also re-done the rib boats and revamped the rib boat storage area.
BeforeAfter
4 -
I'd also check your cpu & gpu temperatures, it's also worth checking task manager to see if something isn't running crazy in the background.
1 -
I was replying to the op's topic so i didn't read yours sorry. However yes adding both options would be a nice to have for everyone. To be clear i'm not against it being added i just think it's more likely the op accidently ejected not because of no auto run, but because the exit key is right next to the thrust key which the addition of auto run would do nothing to fix. Might be better off seeing if binding the default use key from E to T or G or something like that which would reduce the chance of an accidental eject but not 100% sure if it would change the exit on vehicles tho.
0 -
Many keyboards have software to make a auto run hot key, I believe there is also software that will do the same for any keyboard if your particular keyboard doesn't offer it.
I wouldn't be apposed to a vanilla key being added, just as long as if it was to be added it doesn't replace the current sprint controls with no way to disable. Auto run is fine for long flights or runs but I personally hate it for regular gameplay. With auto run the only way to tell if its toggled is to sprint, so if you want to stop sprinting you have to press the key > check by sprinting that it's off > if not press again > check again to verify. VS just letting go of the sprint key.
Also auto hot run could easily get you killed just as easily. For example you accidentally run into a feral horde and get killed fumbling with the toggle xd then there will be form posts asking for push to sprint haha
1 -
Yeah I've heard of the windows optimiziation, that should be in a good place to help the cities situation. Also some time ago I think I heard they've hired some help to do tree's more efficiently, not sure how that's coming along lately tho. I think for a20 they said something about working directly with unity but don't think that materialised for this alpha, no idea for a21 obviously.
Yeah dynamic meshes would be tricky to compare apples to apples. Why I always benchmark in nav since it's usually "mostly the same" in terms of the map. I would test cites but there would be no way of running the tests on the same map since it would have to be a new seed for a new alpha and that would affect the comparison too much.
0 -
I haven't been keeping up on the last several updates since there was nothing in the patch notes to indicate anything would be significantly different performance wise. There was a couple items that may make a difference so i've ran some benchmarks to determine where performance is currently with A20.5. Noticed a20.6 came out in experimental yesterday, figures an update would come while i was almost finished xd however it's mostly all bug fixes so probably won't have any significant difference.
My Other 7DTD Benchmarks
SpoilerBenchmark Notes & Disclaimers
Spoiler1. These figures should be taken as ball park figures and not absolute values.
7DTD is a very difficult game to benchmark accurately. It's in alpha and sometimes does weird things. Also some things are difficult to account for such as the AI, they will behave differently and spawn differently every run, which leads to #2.
2. What's controlled for and what's not
I haven't controlled for driver versions & windows versions. My goal was just to get "close enough" results instead of 100% accurate as possible. That said i have controlled for memory leaks, restarting the game after every run. Time of day is reset from the console after every run. When changing resolution i changed ingame before shutting down then validated with the unity screen selector on next launch. No zombies/animals where killed so areas weren't "cleared" until x amount of days, to insure that on following runs they would respawn (Although i can't do much if zombies kill animals or vise versa etc). I only did 1 pass on each test, however any result that didn't look right or didn't make sense was discarded and retested.3. 1 system isn't enough to draw definitive conclusions for every configuration. The conclusions found here may or may not apply to your own systems, these results are only really comparable if you have similar hardware. But they will however give an idea of where the current performance is at with the hardware that was tested.
4. It's Alpha
Any update could change any conclusions drawn from these tests. Also as a work in progress things are always improving and getting worse, by the time 7DTD goes gold these results with be obsolete and invalid. Things are always changing in alpha.
5. Tests on different resolutions were done on monitors native aspect ratio
16:9 Resolutions were tested on an Asus PB287Q 4K 3840x2160 60HZ Monitor
21:9 Resolution was tested on an LG 38GL950G 3840x1600 175Hz Monitor6. The benchmark Run
I've been using the same run since A14 for all tests, you can find more details on the exact run in my a15 benchmarks i did ages ago Here
7. These results are without applies affinity and increased view distance.Original benchmark excel and results files
System Tested
Trident
CPU AMD R9 5950x Motherboard Gigabyte X570 Aorus Xtreme Ram G.SKILL Trident Z Neo 64GB (4 x 16GB) DDR4 3600Mhz CL16-19-19-39 Storage 1 Save Data 1TB Sabrent Rocket NVMe PCIe 4 M.2 SSDStorage 2 Game Data 2TB Sabrent Rocket NVMe PCIe 4 M.2 SSD GPU MSI Suprim X RTX 3090 24GB System Overclock Notes
CPU: PBO2 OC
EDC:230 TDC:130 PPT:1300
Curve voltage offset
Best Cores: -15 (4 cores) Other 12 cores -30Boost Override: +125Mhz
Ram: Stock: Default JEDEC(2133Mhz) , Overclock: XMP Enabled (3600Mhz)
GPU Core:+160 Mem:+550
GPU Bios Flashed with a 500 Watt Power TargetTested With 2 Video Settings
*Settings 1 & 2 were both the same for Ultra and Lower Settings
"Ultra Settings" "Settings 1" "Settings 2" "Lower Settings"
Trident Benchmarks
I've retested a20.0 without applied affinity and increased view distance to get more "real world" results.
SpoilerA20.5 VS A20.0 Ultra Settings
A20.5 VS A20.0 Lower Settings
Conclusions
Pretty much no meaningfully difference in performance, it may be slightly worse if anything. That's unfortunate however i totally understand why that is the case, a20 has probably been shoved onto the stage before it was truly ready and tfp have been trying to fix the issues after the fact. This unfortunately would ,mean they probably haven't had time to work on any meaningful optimisations as presumably all their time has been spend bug fixing. This is of course speculation based on my observations so take it for what you will.
Hopefully we can see some more substantial gains being made in a21 (assuming another steam sale event doesn't catch tfp's eye before it's ready😄 )1 -
1 hour ago, a_jp said:
? Ahh wait nm haha, you're welcome glad you enjoyed it.
1 -
15 hours ago, faatal said:
It already does that. Block models are Unity prefabs. Most have LODGroup components in them which determines the render height at which each LOD is shown and when it is culled. Getting them consistent with each other is a challenge as there are many heights and differing amounts of LODs. You also want more trivial models to disappear sooner.
The Video>Quality>Object Quality setting determines how quickly distance causes it to step through those LODs, but it gets expensive using the higher settings. Is actually one of the more expensive graphics settings.
definitely object quality is one of the only expensive options i try to keep as high as possible to stop blocks getting culled as often in sight. That's great news to hear it already does it, if i'm understanding correctly the object setting controls how far away objects will go through their lods before getting culled? and after a certain distance the object the object will stop switching out lods and get completely culled? i assume then it's too expensive to maintain the lowest quality lod at the same distance as a players view distance?
0 -
On 7/19/2022 at 10:39 PM, Laz Man said:
Certainly, immersion levels will be at an all time high with all of these new props. 😎
As a player and preffaber i really appreciate these. They can really bring a vision to life and add a massive amount of authenticity to a build. However high detail block models have 2 achilles heels one of which i have a suggestion that could solve it. The first issue is performance, as a preffaber it's heart retching to know i can't use these amazingly detailed blocks because in larger builds the amount i would need would render the prefab unplayable. I can work around this issue by instead using simple shapes to "approximate" what ever is needed, bunk beds for example, ideally i would just stack beds but i can create them using simple shapes that look acceptable.
My solution however is for the 2nd issue related to performance. I noticed for example the conduit blocks got updated with more detailed 3d models. Instead of being basically 2d. However presumably when all these new block models were introduced they massively increased draw calls and performance. So to deal with that high detail block models are now completely culled when not near the player. This is great for performance but has the issue of degrading the players experience when these blocks poof in and out of existence and other blocks appear to float in mid air at a distance because the block under it is culled.
You can see this in these screenshots bellow of house_modern_05 the plants are in those bird bath blocks (i forget what their actual name is) however at a distance (33 blocks) they don't render and the plants appear to float.
SpoilerMy suggestion to solve this is, would it not be possible to use the same system that's already ingame to dynamically swap the zombies models for low Polly versions? maybe more a @faatal question we can sometimes catch a glimpse of how that works which can be both fascinating and hilarious at the same time😄
Could this system not also be used to swap block models for lower polly versions the same way it currently does for zombies? obviously not rendering at all is better for performance than rendering something so i have no idea if even if it could be done, could it be done with an acceptable performance trade off. Likely it would take too long to implement for a21 but i wonder if it's not a solution worth exploring for the future?
0 -
Pretty, like tower looks like you found the perfect spot for it😀
I ran 7DTD at 8K once (7680 x 4320), wouldn't recommend it.. ran at sub 30 fps😂
i can't upload the full quality screenshot unfortunately it's 77.4MB rofl but the compressed version looks like this:
0 -
1 hour ago, RAGE PVE said:
very spectacular Naz well done!
thank you appreciate it👍
1 -
I've gotten the dry docked version to a bare minimum playable state. So i've decided to release it as a work in progress version for people to try since the snow version is getting a bit long in the tooth and the dry docked version still has a ton of work that needs done on it. Details are at the bottom of the main post.
2 -
If you're in a town or city thats normal behaviour atm, i have a 5950x and 3090 in city's it dips to sub 30fps. Double check to make sure you have xmp enabled in your bios, tune down or completely disable anything reflection related (especially screen space reflection) tune down shadows and object detail, disable dynamic meshes/imposters. You can also check to make sure there are no background process running sucking up resources. However even after all that maintaining 60fps isn't possible with any hardware with decent looking video settings. So unfortunately if none of that does the trick and it's still bothering you just keep lowering everything until it runs acceptably.
0 -
7DTD is largely a cpu bound game. However that doesn't mean it will use as many cores as you throw at it, generally it won't use any more than 6 and of the 6 in use 1 or 2 cores will be 100% utilised. This is where most bottlenecks for this game come from. So while you won't see any benefit from more cores if you already have a 4-6 core cpu already, you will see an improvement from moving to a newer cpu with stronger single core performance. If you're gpu bound it might not get you any improvements in avg fps however, but it will give you higher 1% & .1% low numbers. So 4-6 cores is where core count stops proving performance improvements with the cpu.
The limit for gpus depends on which gpu you have and what monitor resolution and frame rate you're running. Example a 1080ti more than 4 years old at this point will start to become bottlenecked at 1440p. For the current generation anything more than a 3060 or 3070 won't do anything for you at 1440p. Video options in the game can also determine the limits. 3090's will still be cpu bound at 4k amazingly and won't become gpu bound until you run 6-8k resolution.2 -
Good tip, yeah it seems to sometimes not carry over the rotations too and needs manual fixing.
0 -
Depending on the exact block you should be able to find the shape in the new a20 shape menu. You can then simply paint it with the brick texture and you will have 1200+ brick shape possibilities.
0 -
@faatal I noticed in my a20.0 tests that the 4 core affinity trick no longer has the same huge gain seen in previous alphas and that without it applied the results are where i'd expect with it applied. I also took a look at the list threads command and see the game now only spawns up to 6 threads instead of all cpu threads available. This is a god send for users with many core cpu's that don't want to mess around with applying affinity themselves. I had a couple questions regarding it out of curiosity.
1.Why 6 threads instead of 4? my initial tests using a extremely high vert and tris prefab to stress the cpu as much as possible showed a huge loss bellow 4 and every new thread above 4 showed a small but constant loss in performance, that got worse the more threads were available. The difference in performance between 4 and 6 threads is very insignificant so it doesn't really matter in the grand scheme of things but i'm curious if there was a specific reason to go with 6.2. Will any of those threads be run on a virtual core or does it somehow only utilise physical cores? I've found that hyperthreading/amd's smt doesn't help and pretty much always results in a loss in performance when used by the game. I know as an example Cyperpunk 2077 scans your hardware to determine how to handle it and if you have 12 or more physical cores it won't use virtual cores at all, but will use them on cpu's with fewer. Cyberpunk may always be considered a bit of a train wreck but i was very impressed with how well the game scales in performance in cpu's it will happily use all 16 cores on my cpu and performance does scale. Obviously i'm not expecting the same feat from 7dtd they're 2 completely different kind of games and developers with very different resources.
Appling 4 core affinity in a20.0 does yield some gain, but it's worth noting that i've targeted those 4 physical cores to the fastest cores on the cpu which will be the majority of the gain.
Spoiler
0 -
Yeah performance in downtown has returned to where it is in a20.0
Here is s an example, it's pretty rough
3 -
open the file "players.xml" found in
C:\Users\USERNAME\AppData\Roaming\7DaysToDie\Saves\SAVENAME\SAVENAME(On a rented service the file path will be different)
Find the players name and copy the userid. Open the folder "Players" in the same location and CTRL + F , paste the user id in and delete the 3 files.
That should nuke it, if it needs more nuking you can remove the <player platform="EOS" userid="" playername="" lastlogin="2022-01-19 18:19:28" /> from players.xml0 -
5 minutes ago, Blake_ said:
While I didn't have the time to be that thorough, I did see a ~10% increase in fps in 20.1 vs 20 b238. Occluder off doesn't initially affect performance on landscape but for it to show you need to go straight to downtown next to a bunch of high rise buildings and look for stutters, not paper fps, even though they also suffer. There, I notice microstutters and some "graphical lagging", but when off, GPU suffers a bit more but fps go up due to the CPU being relieved. Testing fps is better in stress tests, so I suggest these tests, they needen't be extremely detailed:
Test 1: spawn 100zds while inside a high rise building in downtown with occluder on. VS Occluder off and check the results from 20 to 20.1 while they hit blocks coming towards you.
Test 2: plant 100 grown up trees in landscape in front of you, as that reflects a very common situation, similar to downtown or mountain areas with a wide variety of fps "droppers". Then, spawn 100 zds in the very same place. The opposing test should be a20 b238 with the same situation.
100 zds is good for testing, as 64 entities is too well tunned and fps vary too much, but if you go beyond the limit, you can truly see the faults even at first sight, without too many conflicting ranges.
Your tests are amazing btw. What really affects the game are those thrilling moments that suffer from stuttering and fps drops though. Every other situation is kind of a filler performance-wise, really.
Yes that's been my experience with it also. Out in the wilderness it doesn't get much of a chance to occlude anything since most things are within the players view, Inside heavy prefabs is where it shines. I used my custom aircraft carrier prefab as it's a perfect stress test for this kind of thing. Performance with it enabled there improved by 40-80%.
Thank you, i keep benchmark data on my systems because i usually sell them after i upgrade and it's nice to be able to have a record of what the performance was. Agreed i've missed jumps, shots, swings because it decided to drop to 12fps in that split second, can be frustrating😄
Just finished the a20.1 results here same general improvements but 0.1% lows are much the same and no real improvement in gpu bound scenario's like 4k. Still a nice improvement nevertheless.1 -
Saw GPU jobs was added to a20.1 and with much excitement these are the results.
My Other 7DTD Benchmarks
SpoilerBenchmark Notes & Disclaimers
Spoiler1. These figures should be taken as ball park figures and not absolute values.
7DTD is a very difficult game to benchmark accurately. It's in alpha and sometimes does weird things. Also some things are difficult to account for such as the AI, they will behave differently and spawn differently every run, which leads to #2.
2. What's controlled for and what's not
I haven't controlled for driver versions & windows versions. My goal was just to get "close enough" results instead of 100% accurate as possible. That said i have controlled for memory leaks, restarting the game after every run. Time of day is reset from the console after every run. When changing resolution i changed ingame before shutting down then validated with the unity screen selector on next launch. No zombies/animals where killed so areas weren't "cleared" until x amount of days, to insure that on following runs they would respawn (Although i can't do much if zombies kill animals or vise versa etc). I only did 1 pass on each test, however any result that didn't look right or didn't make sense was discarded and retested.3. 1 system isn't enough to draw definitive conclusions for every configuration. The conclusions found here may or may not apply to your own systems, these results are only really comparable if you have similar hardware. But they will however give an idea of where the current performance is at with the hardware that was tested.
4. It's Alpha
Any update could change any conclusions drawn from these tests. Also as a work in progress things are always improving and getting worse, by the time 7DTD goes gold these results with be obsolete and invalid. Things are always changing in alpha.
5. Tests on different resolutions were done on monitors native aspect ratio
16:9 Resolutions were tested on an Asus PB287Q 4K 3840x2160 60HZ Monitor
21:9 Resolution was tested on an LG 38GL950G 3840x1600 175Hz Monitor6. The benchmark Run
I've been using the same run since A14 for all tests, you can find more details on the exact run in my a15 benchmarks i did ages ago Here
7. These results are without applies affinity and increased view distance.Original benchmark excel and results files
System Tested
Trident
CPU AMD R9 5950x Motherboard Gigabyte X570 Aorus Xtreme Ram G.SKILL Trident Z Neo 64GB (4 x 16GB) DDR4 3600Mhz CL16-19-19-39 Storage 1 Save Data 1TB Sabrent Rocket NVMe PCIe 4 M.2 SSDStorage 2 Game Data 2TB Sabrent Rocket NVMe PCIe 4 M.2 SSD GPU MSI Suprim X RTX 3090 24GB System Overclock Notes
CPU: PBO2 OC
EDC:230 TDC:130 PPT:1300
Curve voltage offset
Best Cores: -15 (4 cores) Other 12 cores -30Boost Override: +125Mhz
Ram: Stock: Default JEDEC(2133Mhz) , Overclock: XMP Enabled (3600Mhz)
GPU Core:+160 Mem:+550
GPU Bios Flashed with a 500 Watt Power TargetTested With 2 Video Settings
*Settings 1 & 2 were both the same for Ultra and Lower Settings
"Ultra Settings" "Settings 1" "Settings 2" "Lower Settings"
Trident Benchmarks
I've retested a20.0 without applied affinity and increased view distance to get more "real world" results.
SpoilerA20.1 VS A20.0 Ultra Settings
A20.1 VS A20.0 Lower Settings
Conclusions
Overall The difference is much improved not necessarily game changing, but the results are still pretty damm impressive nevertheless. GPU Jobs seems to work it's magic best in CPU Bound scenario's, you can see from the 4k results there was little to no improvement. Given 7DTD is a predominantly CPU bound game this change will benefit most people. If we look at 1440p gpu utilization for both tests it's getting very close to becoming gpu bound which is really good. Nvidia deems the 3090 an 8k capable card, so the fact 7DTD is now able to make nearly full use of it is amazing news for those with high refresh rate 1440p displays. Even 1080p sees 60% usage so if you had a 3060 or 3070 on paper i would guess you would now get full utilisation at 1080p.
The issues with stuttering still remain however and 0.1% lows are either unchanged, slight worse, or slight better. 0.1% lows have a really high margin of error test to test even a swing of+/-15% is pretty common from my experience. Unfortunately there have been reports of crashes and GPU Jobs will likely be disabled again in the next exp update based on what the devs have said. So enjoy it while you can and keep in mind if you have crashes file a bug report and if you haven't experienced any you can always enable this feature easily as long as you don't play on an EAC server as the change isn't compatible with it.
2 -
7 hours ago, Blake_ said:
Alright.... while it did improve, GPU load at 1080p is not really a problem in b238 (you could go 4gig VRAM-dedicated GPU with high graphic settings no problem if it weren't for the CPU).
CPU is the bottleneck, really. Unless you are doing 1440p and 4k, which eat a lot of video memory.
Turn off Vsync and dynamic meshes, tune down shadows if just a tiny bit and behold. The boost, the crazyness, the unoptimized mess of an engine that can't granulate heavy loads away from the main thread.
Occluder-OFF can give false feedback on your tests, though. If you turn it on, the GPU load will be relieved at the cost of CPU, but if your GPU can really handle top settings with slack, then you are better off with Occluder off, by a WIDE margin.
What is your testing rig?
1080p was just an example of the improvement of a20.1. Full test will have 1080p,1440p,4k and a 21:9 resolution. Vsync was off for all tests. Tests were done on a new World so there shouldn't be any dynamic meshes. Ocluder was on for all tests, previous tests indicate performance was better with it enabled on my 2 systems. I'd be interested to see your data on this as I haven't retested it in a20. The details for that testing rig for that test can be found in my a20.0 Benchmarks here it's the system "trident"
1 -
14 hours ago, faatal said:
It is probably Unity graphics jobs. I enabled them a few weeks ago, since that is now the default for Unity projects and they are supposed to improve performance. Two testers started having random crashes and they have reports of others crashing. I disabled it today, which will be in next exp. When we get our new consultant from Unity, that will be one of his initial tasks of why Unity is doing that. We will give it another shot once we switch a21 to 2021 LTS.
Probably something you've already verified, but just in case. Is it certain gpu jobs is the root of the problem and the crashes aren't symptoms of the performance increase gpu jobs provides? GPU jobs increases performance and thus more heavily loads the gpu. Prior to a20.1 low gpu utilization is fairly common and underlying issues with the hardware won't present themselves as often under lights loads. With a20.1 enabled gpu jobs increasing load on users gpus could create conditions that expose underlying hardware problems like, old thermal paste, defective thermal paste, gpu fan faults, unstable OC Settings, Dust clogged fin stacks, inadequate airflow ect. All those issues could result in the game crashing in a20.1 and not a20.0.
I've been doing some benchmarking on a20.1 and enabled gpu jobs makes a substantial difference in general performance. It doesn't help all that much in 0.1% lows, so doesn't treat the root performance issues of a20, but it does a good job of ban aiding it until the bottlenecks can be looked into and optimised.
I've not finished compiling all the data but here's an excerpt of a20.0 vs a20.1 1080p ultra settings
SpoilerIt was great gpu jobs was now being included as stock. It's seems like it would be a step backwards in performance to disable it, especially now since a20.0 in the city's is already borderline unplayable with the frequent and unrelenting stutters. Don't get me wrong if it is actually the cause of the crashes obviously it's better to play with reduced performance over having random crashes. But personally i wouldn't disable a performance feature like this without verifying the crashes weren't caused by something simpler first.
I'm very aware 1 system and 1 users experience doesn't reflect every possibility, but for what it's worth i haven't had a single unexplained crash playing and testing a20.1🤞
3 -
Assuming power consumption of 350 Watts of load 7dtd would pull from the wall. 20,000 hours works out to an electricity cost here of about £1015.00. what a waste, glad I don't have 20k hours spend doing nothing to pay for🤣
0
FPS capped at 60fps?
in General Support
Posted
Double check your monitor is actually running at 360hz, vsync caps the fps at the monitors maximum refresh rate and 60 is usually the default windows like to set high refreshrate monitors for what ever reason.
https://support.microsoft.com/en-us/windows/change-your-display-refresh-rate-in-windows-c8ea729e-0678-015c-c415-f806f04aae5a