‘Cities: Skylines 2’ की performance क्यों खराब है

 (blog.paavo.me)
2 पॉइंट द्वारा GN⁺ 2023-11-06 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Cities: Skylines 2 एक simulation-केंद्रित genre का game होने के बावजूद, ज्यादातर स्थितियों में GPU bottleneck साफ दिखता है, और benchmarks बताते हैं कि न्यूनतम settings से ऊपर 1080p 60FPS पाने के लिए करीब 1000~2000 euro स्तर का graphics card चाहिए
  • Renderdoc से capture किए गए example frame में 87.8ms, 6705 draw calls, 50 हजार से ज्यादा API calls, और लगभग 6.7GB GPU buffer·texture usage दिखता है, जो 60FPS के 16.7ms target से बहुत दूर है
  • bottleneck की मुख्य वजह कई meshes में LOD की कमी और simple culling है, जिससे screen में लगभग योगदान न देने वाली high-polygon geometry बार-बार render होती है; सिर्फ shadow pass ही 40ms और कुल draw calls का 72% लेता है
  • विवाद में आए citizens के दांत सच में render होते हैं, लेकिन वे अकेली वजह नहीं हैं; citizen models·props·decorations में कुल मिलाकर बहुत ज्यादा vertex count और inefficient rendering का जमा असर बड़ा problem है
  • Unity DOTS और HDRP का integration अपरिपक्व होने के कारण संकेत मिलते हैं कि Colossal Order ने ECS और renderer connection, culling, virtual texturing आदि खुद implement किए; इससे CPU bottleneck घटा, लेकिन graphics pipeline पर्याप्त रूप से polish नहीं हुआ लगता है

release से पहले और बाद में सामने आई performance problems

  • Cities: Skylines 2 में release से पहले ही recommended specs बढ़ाना, console version को 2024 तक delay करना, और performance से जुड़ी बातों पर सीमाएं थीं
  • release से एक हफ्ता पहले Colossal Order ने performance problems पर पहले से सफाई देने जैसा notice जारी किया, और release के बाद performance लगभग universally criticized issue बन गया
  • city-building games में high framerate निकालना मुश्किल हो सकता है, लेकिन इस game में genre में आम CPU bottleneck के बजाय GPU bottleneck ज्यादा prominent है
  • PC Games Hardware और Gamers Nexus के benchmarks के अनुसार “very low” से ऊपर settings पर 1080p 60FPS के लिए करीब 1000~2000 euro-class GPU चाहिए
  • RTX 3080, Ryzen 7 5800X, 5120×1440 monitor environment में first launch पर main menu 10FPS से कम था, और developer की recommendation के अनुसार depth of field, motion blur, volumetric effects बंद करने पर यह करीब 90FPS तक गया
  • empty map में करीब 30~40FPS मिला, और लगभग एक घंटे खेलने के बाद भी similar level और occasional stutters बने रहे

engine और rendering structure

  • Cities: Skylines 2 Unity 2022.3.7 पर आधारित है, और Unity के DOTS, ECS, Burst compiler का उपयोग करता है
  • DOTS की वजह से यह पिछले game की तुलना में कई CPU cores का काफी ज्यादा efficient उपयोग करता दिखता है
  • game logic code में लगभग 1200 systems से बना है, और practically ज्यादातर game logic ECS structure पर रखा गया लगता है
  • UI Unity UI Toolkit नहीं, बल्कि HTML, CSS, JavaScript आधारित Coherent Gameface का उपयोग करता है
    • JS bundle में React और Webpack के उपयोग के traces हैं
    • UI maintenance और modifications के लिहाज से फायदे दे सकता है, लेकिन analyzed data में यह main bottleneck नहीं है
  • graphics Direct3D 11 और Unity HDRP का उपयोग करते हैं
  • DOTS/ECS से बने game को existing Unity rendering system से जोड़ने के लिए अलग layer चाहिए, लेकिन Cities: Skylines 2 Unity Entities Graphics का उपयोग करता नहीं दिखता
    • Entities Graphics में skinning और occlusion culling experimental mark किए गए हैं
    • virtual texturing supported नहीं है
    • इसके बजाय BatchRendererGroup और low-level code का उपयोग करके custom connection layer implement की गई लगती है

Renderdoc analysis environment और limitations

  • rendering analysis के लिए Renderdoc का उपयोग किया गया
  • Game Pass version में sandboxing या file permission issues की वजह से Renderdoc और NVidia Nsight Graphics executable तक access नहीं कर पाए
  • Steam version में भी Paradox Launcher और Steam authentication flow के कारण normal तरीके से Renderdoc connect करना मुश्किल था, और आखिरकार Renderdoc के Global Process Hook से capture सफल हुआ
  • NVidia Nsight Graphics ने Steam को Nsight में खोलकर उसके अंदर game launch करने के तरीके से काम किया, लेकिन D3D11 में कई profiling features supported नहीं थे, इसलिए Renderdoc से ज्यादा जानकारी नहीं मिली
  • analyzed frame करीब 1000 population वाले city में capture किया गया
    • game version 1.0.11f1 था
    • latest patch 1.0.12f1 में कुछ improvements शामिल थीं, लेकिन उसने सभी problems solve नहीं कीं
    • Renderdoc measured frame time 87.8ms था, जो करीब 11.4FPS के बराबर है
    • actual gameplay में average 30~40FPS था, इसलिए Renderdoc overhead या उस frame के outlier होने की संभावना है

example frame के rendering metrics

  • Renderdoc द्वारा report किए गए example frame stats इस प्रकार हैं
    • Draw calls: 6705
    • Dispatch calls: 191
    • API calls: 53361
    • Index/vertex bind calls: 8724
    • Constant bind calls: 25006
    • Resource update calls: 1679
    • Textures: 342, लगभग 3926MB
    • Render targets: 180, लगभग 2328MB
    • Buffers: 4144, लगभग 447MB
    • GPU buffer और texture कुल: लगभग 6.7GB
  • 6.7GB VRAM usage एक अपेक्षाकृत simple scene के हिसाब से ज्यादा है, और 8GB VRAM वाले current-generation mid-range GPUs अब भी मौजूद हैं
  • FAQ के additional analysis के अनुसार उस frame rendering में 121 million input vertices और लगभग 36 million rasterized triangles शामिल हैं
    • यह screen पर सच में दिखने वाले total polygon count नहीं, बल्कि सभी render passes में process हुई geometry की मात्रा है
    • Reddit पर बड़े cities में hundreds of millions vertices, और कुछ specific situations में per-frame अधिकतम 1 billion vertices तक पहुंचने की reports भी हैं

DOTS instancing और GPU data updates

  • लगभग सभी draw calls instancing का उपयोग करते हैं
  • game सभी objects को render करने के लिए जरूरी instance data को एक बड़े buffer में रखता है
  • सामान्य game objects प्रति instance करीब 50 floats use करते हैं, और roads इससे ज्यादा data use करते दिखते हैं
  • visible सभी objects का instance data हर frame buffer में update होकर GPU पर upload होता है
  • buffer करीब 60MB से शुरू होता है, और जरूरत होने पर बड़े size में reallocate होता है
  • यह buffer लगभग सभी draw calls में use होता है, और Renderdoc के हिसाब से vertex shader और pixel shader से accessible state में है
  • हर vertex पर buffer lookup cost लग सकती है, इसलिए यह high-polygon mesh problem के साथ combine हो सकता है

simulation और virtual texturing

  • GPU compute shader का उपयोग water, snow, particles, skeletal animation जैसी graphics-related simulations में होता है
  • ये tasks कुल मिलाकर लगभग 1.5ms लेते हैं, जो total frame time के 2% से कम है
  • game की actual simulation को GPU पर large-scale offload करने की शुरुआती speculation decompiled code और GPU calls के आधार पर सही नहीं है
  • Cities: Skylines 2 ने अपना virtual texturing/texture streaming system implement किया लगता है
    • Unity का built-in Streaming Virtual Texturing experimental·unsupported state में ही है
    • game terrain को छोड़कर अधिकांश static 3D objects पर virtual texturing use करता दिखता है
  • virtual texturing सिर्फ जरूरी texture tiles load करके memory बचा सकता है, लेकिन current implementation में nearby surfaces पर भी high-resolution textures load न होने की problem है
  • anisotropic texture filtering support न होना भी virtual texturing usage से जुड़ा हो सकता है
  • यह pass लगभग 0.5ms लेता है

मुख्य rendering passes की cost

  • Skybox generation

    • Unity HDRP के physically based sky system का उपयोग करके हर frame cubemap generate किया जाता है
    • इसमें लगभग 0.65ms लगता है, जो 60FPS के लिहाज से frame budget का लगभग 4% है

  • Pre-pass

    • deferred rendering के first stage के रूप में depth, normal, smoothness estimation information अलग texture में record होती है
    • इसमें लगभग 8.2ms लगता है, इसलिए यह बहुत भारी है

  • Motion vectors

    • anti-aliasing और motion blur में इस्तेमाल होने वाले per-pixel motion vector को अलग pass में render किया जाता है
    • इसमें लगभग 0.6ms लगता है
    • motion vector कुछ broken लगते हैं, और इसी वजह से लेख लिखे जाने के समय DLSS या FSR2 support नहीं है

  • Roads and decals

    • roads, grass, terrain surface के साथ चलने वाले elements render करता है
    • इसमें लगभग 1ms लगता है

  • Main pass

    • deferred rendering का core pass है, जो अब तक के buffers और virtual texture cache का उपयोग करके albedo, normal, PBR properties, depth आदि generate करता है
    • virtual texture visibility information भी यहीं generate होती है
    • यह horizontal resolution के आधे पर render होता दिखता है, जबकि terrain virtual texturing use नहीं करता और full resolution पर render होता है
    • इसमें लगभग 16.7ms लगता है, जो 60FPS पर पूरे frame के लिए allowed time के बराबर है

  • Ambient occlusion

    • shader debug name के आधार पर GTAO use करता दिखता है
    • इसमें लगभग 1.6ms लगता है

  • SSR + SSGI

    • Unity HDRP के screen space reflections और screen space global illumination का उपयोग करता है
    • दोनों effects मिलाकर लगभग 3ms लेते हैं

  • Deferred lighting

    • पहले generate किए गए intermediate buffers को combine करके लगभग final image जैसा result बनाता है
    • इसमें लगभग 2.1ms लगता है

  • Water rendering

    • compute shader preprocessing और reduced·blurred image input का उपयोग करके water surface render करता है
    • इसमें लगभग 1ms लगता है

  • Post-processing

    • temporal AA, bloom, tonemapping, और enable होने पर DOF और motion blur का उपयोग करता है
    • कुल मिलाकर लगभग 1~2ms लगता है

  • UI

    • Gameface-based UI और world में text render करता है
    • road names 2D signed distance fields से render होते हैं, और depth buffer का उपयोग करके buildings के पीछे होने पर scene के साथ blend होते हैं
    • final UI pass time negligible है

दांत विवाद और character models

  • citizen characters के पास सच में complete teeth model है, और game के normal view में यह दिखाई नहीं देता
  • Reddit user Hexcoder0 के NVidia Nsight Graphics analysis के बाद यह बात सामने आई कि teeth हमेशा maximum quality पर render होते हैं
  • ज्यादा important problem यह है कि character-related meshes में overall LOD variant नहीं है
  • Colossal Order ने इस problem को publicly acknowledge किया, और broader LOD handling issue का भी जिक्र किया
  • citizen models Didimo Popul8 के आधार पर generate होते हैं, और game में teeth/mouth model 6108 vertices का है, जो Didimo default mesh के 1060 vertices से ज्यादा है
  • hair, clothing, accessories को छोड़कर single character ही लगभग 56,000 vertices तक पहुंचता है
    • औसत low-density residential building yard props और detailed elements हटाकर 10,000 vertices से कम है
  • example frame में teeth के 13 sets render होते हैं, लेकिन final image में एक pixel पर भी असर नहीं डालते
  • teeth performance drop की अकेली वजह नहीं, बल्कि broadly मौजूद unnecessary high-polygon geometry का evidence ज्यादा हैं

high-polygon props और culling problem

  • game final image में बहुत कम या बिल्कुल contribute न करने वाले objects को बहुत ज्यादा संख्या में और बहुत high polygon count के साथ render करता है
  • मुख्य वजहें दो हैं
    • कुछ models में LOD variant नहीं है
    • custom culling system simple है, और सिर्फ frustum culling implement है; occlusion culling के traces नहीं हैं
  • distance-based culling मौजूद है, लेकिन aggressive नहीं है, जिससे pop-in तो कम होता है लेकिन performance के लिए नुकसानदेह है
  • examples में मिले high-polygon props इस प्रकार हैं
    • gas cylinder pallet: 17,000 vertices से ज्यादा
    • clothesline prop: प्रति item 25,000 vertices, ज्यादा dense variant 30,000 vertices से ज्यादा
    • parking booth: 40,000 vertices से ज्यादा, LOD नहीं, monitor और keyboard connecting cable तक अलग model किया गया है
    • log pile: 100,000 vertices से ज्यादा
  • buildings और indoor props को एक mesh में combine करने से draw calls घटते हैं, लेकिन internal props को individually cull नहीं किया जा सकता
  • city-building game में वही inefficient model एक frame में सैकड़ों बार render हो सकता है, इसलिए छोटी waste भी accumulate होती है
  • high-resolution models अपने आप में problem नहीं हैं; current problem यह है कि game high detail को handle नहीं कर पा रहा और polygon usage inefficient·inconsistent है

shadow pass सबसे बड़ा bottleneck है

  • Cities: Skylines 2 cascaded shadow mapping का उपयोग करता है
  • shadows में artifacts और flickering काफी हैं, खासकर sun या leaves move होने पर
  • game 4 cascades use करता है, और हर cascade की resolution 2048×2048 है
  • advanced graphics settings में directional shadow map resolution item है, लेकिन लेख लिखे जाने के समय code से connected नहीं है
    • individual settings या overall shadow quality settings shadow map resolution नहीं बदलतीं
    • medium और high shadow preset practically same हैं
    • low preset terrain से cast होने वाली shadows बंद कर देता है
  • quality low होने के बावजूद shadow mapping लगभग 40ms के साथ सबसे slow rendering pass है
  • example frame के 6705 draw calls में से 4828, यानी 72%, shadow mapping में use होते हैं
  • game सभी 3D objects को size या distance की परवाह किए बिना सभी quality settings में potential shadow caster मानता दिखता है
  • Renderdoc performance counters में कई draw calls shadow map के सिर्फ 0~100 pixels से कम हिस्से को affect करते हैं, और teeth भी shadow pass में फिर दिखाई देते हैं
  • LOD और culling improvements shadow mapping performance पर भी बड़ा असर डाल सकते हैं
  • एक सकारात्मक detail यह है कि game city की current date·time·coordinates का उपयोग करके sun और moon की position calculate करता है

main menu performance problem

  • main menu static background image और buttons जैसा दिखता है, लेकिन actually 3D scene हमेशा मौजूद रहता है
  • menu के पीछे terrain, water, skybox वाला scene render होता है, और बाद में UI उसे पूरी तरह cover कर देता है
  • invisible scene पर भी full rendering pipeline use होती है, इसलिए graphics settings main menu performance को तुरंत affect करती हैं
  • launch के समय ज्यादातर settings default रूप से maximum के करीब थीं, और developer ने जिन heavy effects को disable करने की सलाह दी थी वे भी शामिल थे
  • हालांकि first launch पर 7FPS तक गिरने की वजह पूरी तरह clear नहीं हुई
    • उसी स्तर का performance drop बाद में reproduce नहीं हुआ
    • first launch पर virtual texture cache processing task चलती है, लेकिन GPU usage confirmed नहीं है
  • पूरे main menu scene में लगभग 400 draw calls, 563,000 input vertices, 745,000 rasterized triangles शामिल हैं

FAQ में जोड़ी गई interpretation

  • यह कहना मुश्किल है कि इसे Unreal Engine 5 में ही बनाना चाहिए था या नहीं
    • UE5 में Nanite, Lumen, Virtual Shadow Maps हैं, जो C:S2 की कुछ problems से निपट सकते हैं
    • दूसरी ओर Unity ECS के equivalent large-scale game logic·simulation के लिए production-level features कम हैं, और C++-centric structure modding flexibility और accessibility में disadvantage दे सकता है
  • game में LOD बिल्कुल नहीं है, ऐसा नहीं है
    • कई buildings में proper LOD लगता है
    • pipes, yard props, decorations जैसे elements में LOD न होना या select न होना अक्सर दिखता है
  • InstaLOD game की asset pipeline में, खासकर mod tool में new asset import करते समय, use होता लगता है; runtime rendering में use होता नहीं दिखता
  • JavaScript-based UI analyzed data के हिसाब से main bottleneck नहीं है
    • Gameface Electron जैसे full browser engine पर आधारित नहीं, बल्कि game UI use-case के लिए custom framework है
    • इसका explanation है कि Chromium/Blink या WebKit-based approach से memory usage और performance में बेहतर होना चाहिए
  • Renderdoc एक precise benchmark tool के रूप में सीमित है, लेकिन “game क्या कर रहा है जिससे slow है” समझने के लिए पर्याप्त evidence देता है

निष्कर्ष: CPU bottleneck घटा, लेकिन GPU pipeline लगभग अधूरी है

  • Cities: Skylines 2 के GPU पर जरूरत से ज्यादा भारी होने की direct वजह यह है कि graphics card को unnecessary geometry बहुत ज्यादा भेजी जा रही है
  • यह geometry waste कई meshes में LOD की कमी और simple, कम tuned culling implementation से आती है
  • custom culling और rendering connection layer implement करने का कारण यह लगता है कि Unity DOTS और HDRP का integration अभी work in progress है, और real game में इस्तेमाल के लिए इसमें बड़ी limitations थीं
  • Unity की virtual texturing भी experimental state में है, इसलिए Colossal Order ने custom solution implement किया, और इस system में भी अभी कुछ हिस्सों में polish की कमी है
  • अनुमानित flow यह है कि Colossal Order ने Unity की नई technology DOTS पर bet लगाया और CPU bottleneck तथा simulation scale के मामले में gains हासिल किए, लेकिन graphics side पर culling, animation, texture streaming जैसे systems खुद implement करने पड़े
  • developer का यह दावा कि game शुरू से 30FPS target करता था, भरोसेमंद नहीं माना गया है; pure PC game और graphics quality को देखते हुए इसे performance target के रूप में justify करना मुश्किल है
  • सबसे ज्यादा solve होने वाले areas LOD जोड़ना, culling improve करना, shadow caster selection optimize करना, और prop-level asset cleanup हैं; कई assets को individually fix करना पड़ सकता है, इसलिए समय लगेगा

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-11-06
Hacker News की राय

  • यह रोचक लेख है, इसलिए चाहूंगा कि चर्चा का केंद्र ठीक-ठीक क्या रोचक है इस पर रहे
    ऐसे threads आसानी से $THING खुद—यहां पूरे game—या $RELATED—यहां framework—या मिलती-जुलती चीजों के बारे में सामान्य बातें बन जाते हैं
    सिद्धांत रूप में यह बुरा नहीं है, लेकिन जैसे-जैसे चर्चा generalities की तरफ एक-एक कदम बढ़ती है, वह उथली और कम दिलचस्प होती जाती है। इसलिए site guidelines में भी “general tangential discussion से बचें” शामिल है - https://news.ycombinator.com/newsguidelines.html

  • “Colossal Order ने Unity की built-in culling का इस्तेमाल न करके अपनी implementation इसलिए रखी, क्योंकि DOTS और HDRP का Unity integration अभी भी जोर-शोर से चल रहा है और अधिकांश real games के लिए अनुपयुक्त माना जा सकता है, इसलिए graphics side का काफी हिस्सा खुद implement करना पड़ा” वाला हिस्सा मेरे Unity tools अनुभव से दुखद रूप से मेल खाता है
    DOTS release हो चुका है, लेकिन Unity द्वारा acquire किए गए दूसरे tools की तरह इसकी implementation भी उपेक्षित लगती है। कंपनी का संचालन गंभीर रूप से गड़बड़ है, और कुछ हफ्ते पहले publicly फूटे pricing policy वाले मामले को देखें तो वे engine सुधारने के बजाय users से और पैसा निकालने के तरीकों पर ज्यादा ध्यान दे रहे लगते हैं
    Bevy का ECS implementation सच में अच्छा है, और Godex के साथ मैं चाहता हूं कि यह क्षेत्र में सफल हो

    • Unity हर साल लगभग 1 अरब डॉलर revenue जला रहा लगता है, फिर भी engine अब भी आधा-पका अधूरा product जैसा महसूस होता है—यह समझ नहीं आता। वह सारा पैसा जाता कहां है?
    • Godex आखिरकार सुअर पर lipstick लगाने जैसा है। performance थोड़ी बेहतर हो सकती है, लेकिन ECS कोई जादुई optimization नहीं है जिसे plugin की तरह चिपका दिया जाए
      gameplay layer की cache coherence engine-level bottlenecks ठीक नहीं कर सकती
    • सच कहूं तो performant games बनाने के कई तरीके हैं, और ECS न तो जरूरी है, न ही अनिवार्य रूप से modern तरीका। यह game को structure करने के कई architecture patterns में से एक है, और इसके कई फायदे-नुकसान हैं
      उदाहरण के लिए Godot ECS-केंद्रित नहीं है; यह “servers” के concept पर केंद्रित है—rendering, physics जैसे specialized domains को ज्यादातर स्वतंत्र रूप से handle करने वाले autonomous game subsystems—और ये सामान्य game logic से loosely coupled होते हैं
      ECS architecture PS2/PS3 के दौर से निकला था, जब CPUs खराब थे। छोटे cache, branch prediction miss की बड़ी cost, धीमी memory, fragmented memory space, और random-access storage की कमी के कारण developers को predictable memory access patterns के हिसाब से games बनाने पड़ते थे, और नतीजे में game data को छोटे chunks में stream करके process करने वाली structure आम हो गई
      यह तरीका आज भी आम तौर पर good practice है, लेकिन बेहद तेज CPUs, शानदार speculative execution, अच्छे branch predictors, और दर्जनों MB cache आने के बाद यह अब strict requirement नहीं रहा। खासकर यह देखते हुए कि modern games ने screen पर हो रही चीजों के scale को 10–20 साल पहले की तुलना में इतना ज्यादा नहीं बढ़ाया है। action games में भी player का एक साथ दर्जन भर से ज्यादा enemies से लड़ना अभी भी rare है
      जिन games में screen पर हजारों elements एक साथ आते हैं, उनमें आम तौर पर अलग specialized logic और processing की जरूरत होती है
    • क्या DOTS Unity के अंदर ही नहीं बनाया गया था?

  • इस game को try करने वालों के लिए tip: resolution scaling को dynamic से fixed पर बदल दें
    3080 पर main menu “unplayable 10fps” level से बदलकर, medium-high options पर game के अंदर “बिना समस्या ठीक चल रहा है” level तक आ गया

    • इसे पूरी तरह off भी कर सकते हैं। मेरे 3080 पर यह काफी rendering artifacts बनाता लगता है
    • वह solution नहीं है। motion blur और depth of field बंद करें। खासकर depth of field menu performance को मार देता है

  • संदर्भ के लिए, मुझे याद है कि Crysis के एक frame में, benchmark scene के आधार पर, करीब 3 लाख vertices या triangles थे। तो आपकी memory किस तरफ गलत है, और हर model का vertex/triangle ratio कितना खराब है—इस पर निर्भर करते हुए यह 3–10 log piles के बराबर है

    • मैं लेखक हूं: RenderDoc में per-frame total vertex count गिनने का आसान तरीका नहीं मिला, इसलिए खुद नहीं गिना। लेकिन Reddit पर किसी ने ReShade से total vertex count measure किया था, और कहा कि बड़े शहर के close-up scenes में यह सैकड़ों millions से लेकर 1 अरब vertices तक जा सकता है
      edit: RenderDoc से vertex और polygon count check किया। लेख के example scene में 12.1 करोड़ vertices और 4 करोड़ से ज्यादा triangles process होते हैं
    • सही लगता है। मुझे performance HUD में “1M Triangles” देखकर यह सोचने की याद है कि दस लाख triangles तो पागलपन है। edge splitting, billboards आदि को देखते हुए shared vertices भी लगभग न होने की संभावना है

  • writing style सच में बहुत अच्छी लगी:
    “यह pass लगभग 8.2 milliseconds, यानी मोटे तौर पर बेहूदा हद तक लंबा समय लेता है, इसलिए हैरान करने जितना भारी है…” जैसे वाक्य

    • काश थोड़े serious लेखों में भी ज्यादा लोग इस तरह छोटा humor मिलाकर लिखें

  • “यह log pile mesh भी सिर्फ shadow rendering pass में इस्तेमाल होता है, फिर भी इसमें 1 लाख से ज्यादा vertices हैं”… लेकिन क्यों?

    • क्योंकि game development में ध्यान रखने वाली करीब 10 लाख चीजें होती हैं। संभव है किसी व्यक्ति या किसी software ने LOD setting में गलती की हो। या dynamic LOD code LOD0 mesh को ठीक से cull नहीं कर पाया हो, या वह code समय पर पूरा न हुआ हो, या कोई बिल्कुल अलग वजह हो
      AAA games में कुछ incomplete और unoptimized elements होना पूरी तरह normal है। budget हमेशा सीमित होता है और development time कम। ऊपर से यह hit-driven industry है जहां सफलता guaranteed नहीं होती। game की सफलता की संभावना बढ़ाने के कुछ तरीके हैं, लेकिन वे आम तौर पर development से ज्यादा management side के होते हैं, और expected pre-order revenue सही-सही नहीं बैठता। इसलिए risk घटाने के लिए compromises करने पड़ते हैं, जहां संभव हो cost कम करनी पड़ती है, और सबसे महंगी development priorities को नीचे करना पड़ता है। ये compromises किसी एक mesh के optimize न होने से कहीं बड़े होते हैं। एक mesh कुछ भी नहीं है
      यह रोचक बात है कि यह mesh LOD0 है और teeth mesh भी LOD0 है। लेकिन सिर्फ उससे game performance नहीं टूटती, और actual performance fixes की जगह इसे ठीक करने की संभावना भी कम लगती है। इस thread में ऐसे meshes पर obsession थोड़ा ज्यादा है
      बहुत से comments भावनात्मक रूप से गरम हैं, इसलिए मैं उसमें और जोड़ना नहीं चाहता; बस और context देना चाहता हूं
    • इसे करीब 100 vertices और smart normal map से handle किया जा सकता था, यह तो बस पागलपन है
    • इस game को बनाने वाले studio में लगभग 30 developers हैं

  • क्या यह सारांश सही है कि गेम बेहद detailed models इस्तेमाल करता है, लेकिन उन चीज़ों को समझदारी से abstract करने या culling करने का तरीका नहीं रखता जो असल pixels के रूप में दिखाई ही नहीं देंगी?
    और अगर ऐसा है, तो क्या इसे आसानी से ठीक किया जा सकता है, या यह इतना core structure है कि समाधान के लिए design से ही फिर शुरू करना पड़ेगा?

    • सुधार की कठिनाई का सिर्फ़ अंदाज़ा ही लगाया जा सकता है। मैं expert नहीं हूं, लेकिन culling और LOD को engine के बड़े स्तंभों में से मानता हूं। existing implementation का इस्तेमाल न कर पाना वाकई बहुत खराब स्थिति है
      “तरकीबें” अपने-आप में अच्छी तरह जानी-पहचानी होंगी, लेकिन मुझे नहीं लगता कि implementation आसान होगा

  • DOTS Mike Action के idea से निकला था। उनकी 2014 की CppCon presentation “Data-Oriented Design and C++” देख सकते हैं [1]. हालांकि Twitter के मुताबिक Mike ने Unity छोड़ दिया है
    [1] https://www.youtube.com/watch?v=rX0ItVEVjHc

    • मूल पोस्ट में DOTS की rough edges की बात ज़रूर है, लेकिन लेख में मुझे ऐसा कुछ नहीं दिखा जिसे देखकर लगे कि वाकई DOTS ही कारण है। अगर DOTS समस्या होता तो वह CPU overhead बनाता, लेकिन यहां मामला बहुत ज़्यादा excessively detailed geometry ढेरों में इस्तेमाल करने और LOD system implement न करने जैसा दिखता है
      UE5 का Nanite होता तो शायद किसी तरह संभल जाता, लेकिन उस स्तर की excessive geometry बाकी सब कुछ गिरा देती
    • क्या उसी Mike Action की बात हो रही है जिसने sports games वगैरह को छोड़कर बेहद संदिग्ध dataset के आधार पर कहा था कि 30fps games, 60fps games से ज़्यादा बिकते हैं?

  • Proton Experimental में 1080p पर खाली map से भी कुछ fps से ज़्यादा निकालने की कोशिश में 40 मिनट लगाए, लेकिन हार मानकर refund कर दिया। अगर वे भयानक performance ठीक कर देंगे तो फिर से कोशिश करूंगा
    पहला भाग मैंने सच में बहुत enjoy किया था, इसलिए इस बार वाला खेल न पाना बहुत अफ़सोस की बात है

    • समाधान एक tweet में समा जाता है -> https://twitter.com/ColossalOrder/status/1716883884724322795
      “अगर performance issues हैं, तो performance को प्रभावित करने वाली समस्याएं हल करते समय हम screen resolution को 1080p तक घटाने, depth of field और volumetrics बंद करने, और global illumination को कम करने की सलाह देते हैं”
      AMD Radeon RX 5700 XT पर smooth performance पाने के लिए मैंने बस यही किया था
    • GeForce Now पर यह काफ़ी playable है। फिर भी थोड़ा stutter करता है, लेकिन मैं कई घंटों तक बिना बड़ी समस्या के खेल पाया। कभी-कभी परेशान करने वाली रुकावट आती है, पर सहने लायक स्तर की है