sunsmountain schreef op maandag 2 november 2020 @ 14:45:
[...]
Klopt, maar tegen dat inkakken van de framerates is geen CPU / GPU tegen opgewassen en ligt op netwerk niveau. Multiple cores lijken daarbij (boven een minimum) minder uit te maken dan hogere CPU clock speed en kwaliteit van de netwerk controller / dubbele netwerk controllers.
In een singleplayer offline game met dezelfde workload gaat het even hard inkakken, dat heeft echt niks met het netwerk te maken. Dan zou ik ook geen CPU-limiet in de FPS-counter zien. Er is geen enkele multiplayer-game die ook maar in de buurt komt van het noemenswaardig belasten van een gigabit-interface. De enige reden dat ik dat zei is omdat die game voor de serverload al een afweging maakt wat je uberhaupt naar je computer gestuurd krijgt. Voor een client (game) is dat peanuts, ook al zou je alle data van alle spelers krijgen, maar voor de server (met duizenden connected clients) zie je elke byte besparing meer dan duizendmaal terug.
roy-t schreef op maandag 2 november 2020 @ 14:51:
[...]
Mijn punt was dat het bezig zijn met of dingen wel of niet getekend worden, of op welke LOD ze getekend worden maar een hele kleine invloed heeft op de CPU. Omdat het puur gaat om draw calls, er wordt nauwelijks extra data heen en weer gestuurd.
Physics is dan weer iets interessants omdat je deze ook buiten je gezichtsveld moet simuleren. Stel je een brokstuk voor dat rond vliegt door een explosie. Op frame N is deze misschien nog niet zichtbaar, maar op frame N+100 wel, de enige manier dat je dit op frame N+100 weet is door dat de simulatie de physics simulatie de afgelopen 100 frames ook objecten die niet zichtbaar waren uiterekende.
Ik had het dan ook alleen maar over de draw distance, niet de LOD. In mijn specifieke voorbeeld zijn physics zoals jij het beschrijft niet van belang, aangezien de wereld niet destructible is en er verder niet heel veel spannends gebeurt wat long-lived impact heeft. Physics is alleen van toepassing op players, vehicles en short-lived particles (kogels) en dus eigenlijk alleen maar binnen je draw distance. Alles erbuiten wordt door die game gewoon niet gerenderd, en physics die plaatsvinden buiten beeld boeien vaak ook niet zoveel aangezien de volgende server-update bepaalde objecten weer kan "resetten" naar een positie+houding. Dus al zou je spelers buiten je draw range binnenkrijgen over het netwerk kan je kiezen er geen berekeningen op te doen totdat ze volgens de server binnen je gezichtsveld zijn. Ook hebben een heleboel objecten wel een soort periodieke beweging die je voor elk frame zou moeten berekenen, maar die door de periodieke aard gewoon door een functie te beschrijven zijn waardoor het niet uitmaakt of je die berekening een aantal frames overslaat als het object off-screen is, en dat bespaart wel weer CPU-power als je dat én niet hoeft uit te rekenen én er geen draw calls voor hoeft te sturen.
Desalniettemin is er altijd 1 ding als eerste de bottleneck, blijkbaar zit jouw CPU op het randje en kan deze dit kleine beetje extra werk niet aan.
Voor deze game is het dus voor mij in deze situatie niet interessant om mijn videokaart te upgraden naar een 6900XT ofzo, aangezien het hele zaakje nu al op 3440x1440 en Ultra-settings draait. Ik kan dan alleen nog in framerate omhoog maar die wordt gelimiteerd door mijn CPU. Als ik de draw distance omlaag schroef, gaat de framerate in dat scenario wel iets omhoog omdat een aantal objecten gewoon genegeerd wordt. Dus voor mij heeft het eerder zin te upgraden naar een Ryzen 5xxx, waarschijnlijk wordt dat de 5950

Dan kan ik daarna kijken of de 6900XT in beeld komt

MMOs zijn wat dat betreft een hele interessante use case. [..] Maar dat staat over het algemeen niet in verhouding tot het extra rekenwerk dat de GPU hiervoor zal moeten doen.
Die MMO was een voorbeeld, ik noemde ook GTAV (singleplayer) en ook andere open-world games met grote maps. Daar wordt ook niet in elke scene de hele wereld gerenderd om de GPU daarna een selectie te laten doen op basis van draw distance. Dan is de CPU namelijk veel langer bezig om elk objectje naar de kaart te sturen dan de kaart bezig is om alles in het gezichtsveld te renderen. De GPU kan bij het krijgen van de draw-call al zeggen van "leuk maar die is niet te zien dus daar doen we niks mee. Next!". Een manier om dat in de praktijk te zien is als je in GTAV een auto achtervolgt en die even uit het oog verloren bent, deze niet meer te vinden is omdat hij is gedespawned. Hij was namelijk buiten de render range gekomen en daarom niet boeiend meer.
Ik vind het moeilijk in te schatten hoe scherp je precies "Ik mag hopen dat je als hobbyist game developer ook nadenkt over..." bedoelt. Maar volgens mij zijn we het niet oneens. Maar ging mijn nuance over de relatieve grote van het werk.
Je stelling kwam op mij over alsof je vond dat draw distance een GPU-only dingetje was en dat dat helemaal niks met de CPU te maken had. @
Sp3ci3s8472 zei dat o.a. draw distance een grote impact op CPU-load kon hebben en jij lijkt dat tegen te spreken. Relatief is het renderen van de scene voor de GPU doorgaans inderdaad het meeste werk maar dat wil niet zeggen dat je aan de CPU-kant nergens rekening mee hoeft te houden. Ik heb zelf wel ooit wat gedaan met 3D programming maar jij hebt er ongetwijfeld meer ervaring mee dan ik. Ik kan me in ieder geval goed voorstellen dat de engine die je gebruikt sowieso geen drawcalls zal sturen voor objecten die buiten de range vallen en dat je daar als dev nog verder op kan optimaliseren door überhaupt geen bewerkingen op die objecten te doen.
Dus: helemaal afhankelijk van wat voor game je hebt kan de CPU een behoorlijk grote invloed zijn op je framerate. Als je een game hebt waar veel bewegende objecten in zijn kan de GPU al gauw van ondergeschikt belang zijn. Het reduceren van de draw distance zorgt ervoor dat je in ieder geval minder objecten naar de GPU hoeft te sturen en in een gunstig geval ook die verre objecten in de CPU niet constant hoeft te tracken/berekenen. Ik denk/hoop dat we het uiteindelijk niet oneens zijn inderdaad