Citace Původně odeslal Petrik Zobrazit příspěvek
No jasne ze to s fyzikou nema nic spolecneho tohle je pouze rendering sceny. To byla reakce na to, jak Eagle tvrdil, ze krome fyziky nema cenu nic jineho paralelizovat. Kdyby to skutecne nemelo cenu, tak by se s tim ve Valve asi nedelali, ze. O tom, jakym zpusobem je delana fyzika jsem nikde nic nenasel, ale predpokladam, ze u ni aplikovali fine grained therading, predevsim asi proto, ze u pokrocilych fyzikalnich enginu jako je treba havok, by to nemel byt problem. A jsem rad, ze tu alespon nekdo z odborniku potvrdil, ze to, co jim uz realne funguje, je skutecne mozne udelat, coz Eagle porad odmita prijmout jako fakt.
Popravdě ohledně toho vykreslování to neni problém ani ohledně implementace. Předpokládám v podstatě, že každý engine, co se začne v tuhle chvíli vyvíjet, to tak nějak bude dělat. Nestojí to nějak moc času navíc a neni v tom riziko větší nestability programu. Otázka je, kolik výkonu navíc to přinese. Já jsem přesvědčen, že v dohledné době to až zas tak moc nebude. Samozřejmě se ale nemůžeme bavít o výkonu této konkrétní "smyčky", kde to samozřejmě bude znát, ale spíš jde o to, jak se to projeví na celkové rychlosti hry, kde jsem přesvědčen, že se to ještě pár let moc neprojeví. Stěžejní tak zůstává fyzika.
V podstatě to rozdělení grafickýho enginu na víc CPU nějak moc nemění tu základní filozofii, takže by se dalo říct, že program děláme jako ST, ale pouze jednotlivé kroky se snažíme urychlit MT. Celkově však program pořád zůstává vyvíjen jako ST na té hlavní vrstvě. Pokud si přidáme další krok na začátek a to spočítat fyziku, tak i ta se dá tímto způsobem celkem jednoduše urychlit bez nějakých komplikací. Dalo by se rozdělit na určité fyzikální zóny a ty by se daly zpracovávat samostatně. Otázka je, kolik by to pak reálně přineslo nějakého urychlení (rozhodně to však nezabere moc času na implementaci). Pokud by ve hře třeba na silnici padala lavina kamenů, tak tam jelikož se navzájem všechny šutry ovlivňují, tak by se to počítalo v jednom threadu a nárust výkonu by nebyl žádný, ale v případě, že by padaly dvě laviny za sebou, tak se obě mohou počítat už samostatně, protože je každá v jiné "zóně" a pak by bylo urychlení samozřejmě velké (v celkové hře by se to ale projevilo jen pokud by byla fyzika výpočtově hodně náročná). Samozřejmě pokud pak budu mít scénu, kde se děje několik na sobě nezávislých fyzikálních výpočtů (listí padající ze stromu do jezírka, vodopád, nějaký kravinky s počasím jako mraky, prohybající se trává pod nohama postavičky,...), tak by se všechny daly rozdělit do samostatných zón.

Netušim, jak se to dělá dneska (do příštích enginů), ale kdybych se já snažil tohle řešit, aby mě to stálo co nejmíň námahy, tak jdu na to asi takhle, protože postupy jsou v podstatě stejné, jako když se dělá single-thread aplikace. Samozřejmě někde ten nárust může být velký, někde malý, to už záleží vážně na konkrétní hře. Btw abych se přiznal, tak kdykoli jsem spolupracoval na nějakém komerčním nebo free (herním) projektu, tak tohle řešili vždycky jiní lidé, ale něco už jsem za ty roky taky pochytil (btw zajímavost je, že v tom free vývoji většinou ti programátoři jsou těm novým postupům víc nakloněni, ale je to dáno asi tim, že to dělají pro své vlastní potěšení a tak nemusí řešit, jestli se ten čas navíc vyplatí).