Új hozzászólás Aktív témák

• #88 sb veterán Jack@l #87

  Új Válasz 2015-02-03 13:57:08 #88

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  sb

  veterán

  válasz Jack@l #87 üzenetére

  Raytrace-nél nincs.
  De offline rendernél lehet, mivel az lehet offline sima raszterizálással is.

  De tök mindegy, hogy nincs draw call. Van más, sokszoros számítási igény.

• #86 sb veterán Jack@l #85

  Új Válasz 2015-02-03 11:36:17 #86

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  sb

  veterán

  válasz Jack@l #85 üzenetére

  Alma-körte.
  Most mit hasonlítasz mivel?
  Egyik raszteres, másik raytrace. Totálisan más feladatok és számítások.

  Objektumok transzformálását, textúrázást, shader kódokat. vs Fényforrás (hány darab?), pixelszám (milyen felbontás), milyen mélységű rekurzió, stb, stb...

  Raytracingnél nincs is olyan, hogy objektumot rajzolsz ki klasszikus értelemben. Geometria van és pixelek rajzolódnak ki, amikből összeáll vmi kép.

• #84 sb veterán Jack@l #83

  Új Válasz 2015-02-03 11:01:45 #84

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  sb

  veterán

  válasz Jack@l #83 üzenetére

  Akkor viszont szarul fogalmaztál.
  Az offline a realtime ellentettje jelen esetben.

  Realtime: Amit úgy renderelsz, hogy mozgásban elkészül a kép csúszás, várakozás nélkül. Vagyis olyan render ami tud mondjuk 25-30fps sebességgel képeket előállítani.
  Offline: Ami nem tud: előbb kiszámolod, utána nézhető. Pl egy 10 órát futó render, amivel készítesz egy 15 perces valamit. Ez nyilván nem lehet realtime, mert előbb ki kell számoltatni, hogy láthasd.

  A render módja meg tök irreleváns. Lehet raszteres render is mindkettő, de lehet raytracing is akármelyik.

  Ebből következik, hogy a "draw call" is független a render típusától. Rajzolási parancs. Ez is egy általános fogalom ilyen formában.
  Egy offline elindított renderben nem kell rajzolni? De. Kirajzolsz 10 ojjektumot, X idő. Ha kirajzolsz 100-at az mennyi?

  PC-s DX rendernél pedig egy sajátosság, hogy a rajzolási parancsnak a rajzoláson kívül magas teljesítményigénye van. Ha technikailag ugyanazt csinálod ott is lehet overhead.

• #77 sb veterán Jack@l #73

  Új Válasz 2015-02-02 19:09:14 #77

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  sb

  veterán

  válasz Jack@l #73 üzenetére

  Én se értem miről írsz.
  Mit értesz realtime és mit offline render alatt?

• #52 sb veterán Abu85 #47

  Új Válasz 2015-02-02 13:35:21 #52

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  sb

  veterán

  válasz Abu85 #47 üzenetére

  Az MS eddig is lesz*rta az igényeket. Általában a PC-seket. Pedig az RTS ugye pont az az egy szegmens talán amire a konzol nem megoldás.

  Bár igény sincs rá azt meg kell hagyni. De szerintem PC-n egyrészt van, másrészt meg lehetne csinálni rá igényt a "konzolos generációnál" is szvsz.

• #51 sb veterán Reggie0 #48

  Új Válasz 2015-02-02 13:25:49 #51

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  sb

  veterán

  válasz Reggie0 #48 üzenetére

  Értem én. Nincs mit ragozni rajta.
  1. Eleve nem szeretem a motion blur-t. Ez az első pont valóban, hogy felesleges is sok esetben, mert nem nyújt jobb látványt hiába "reális".
  2. Ill. ezen belül még válasszuk ketté azt az esetet amikor (sokszor) szarul használják és még csak nem is reális. Ott főleg felesleges.
  3. Eset: amikor sok az fps, erről írsz te. Eleve felesleges, mert ha kellően sok a mozgásfázis akkor a szem "mossa el" a képet, ahogy a valóságban.
  4. Eset: kizárólag erről beszéltem én:
  Amikor nincs 120fps, nincs ilyen gyors monitorod sem hozzá. És emellé van egy jó, valós hatást keltő motion blur.
  Ez az egyedüli együttállás, amikor érdemes lehet használni.
  Na ehhez volt az a véleményem, hogy annyit viszont ez az eset sem ér meg, hogy 3-4x számítással leterhelje a gpu-t. Van 1000 fontosabb dolog, amire használni lehetne/kéne előbb.

  szerk: Az idézet megvolt nekem is.

• #46 sb veterán Reggie0 #43

  Új Válasz 2015-02-02 12:39:04 #46

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  sb

  veterán

  válasz Reggie0 #43 üzenetére

  Nem teljesen értem ez hogy jön ide.
  Épp azért kenik el renderből, hogy el legyen kenve. Tök mindegy hányszor frissít a monitorod, ha egy elmosott "paca" képet frissít.

  Erről volt szó. Csak ráadásul az elkenés nem postprocess, hanem erőforrás-zabáló módon, többszöri renderrel akarják elérni. Kár belé a Gflops/CO2, ahogy te is írtad.

• #45 sb veterán Abu85 #41

  Új Válasz 2015-02-02 12:36:43 #45

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  sb

  veterán

  válasz Abu85 #41 üzenetére

  Akkor ők miből élnek? Az MS fizet, ha 3-4 évenként új API kéréssel állsz elő? Inkább csak s*ggbe rúgással, nem?

  szerk: Amúgy meg nyugodtan lehetne a heterogén feldolgozás felé kutatgatni ehelyett. Most az új low level API-kból is elég sok minden kihozható majd valószínűleg látványügyileg, de a játékok 90%-ban nem ezen véreznek el. Sokkal nagyobbat lehetne előre lépni AI-ben, de főleg aktív, játékmenet befolyásoló fizikában.

  Egyébként ha ránézek a StarSwarm-ra akkor - látva és értve/megértve, hogy hány kismillió cuccot rajzol ki valóban - akkor sem vág oda a látvány. És akkor finom voltam.
  Nyilván lesz más jellegű motor, amiben sokkal többet lehet kihozni majd belőle, de szvsz a látvány továbbra is egy irány marad a sok közül.

• #36 sb veterán Abu85 #32

  Új Válasz 2015-02-02 12:00:31 #36

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  sb

  veterán

  válasz Abu85 #32 üzenetére

  Akkor most kicsit pihenhetnek.
  Értem, hogy tovább dolgoznának, de hova?
  1. Nincs több API.
  2. Még senki nem használj a a mostanit sem. Ők nem abból élnek, hogy pénzt hoz az engine?

  Gondolkodni lehet és dicséretes, de abból megélni nem.
  Ellenben ha kijönne mondjuk pár igazán ütős, új RTS, ami az utóbbi 10 évre enyhén szólva nem volt jellemző akkor azzal lehetne valamit kezdeni.

• #25 sb veterán Reggie0 #8

  Új Válasz 2015-02-02 11:28:54 #25

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  sb

  veterán

  válasz Reggie0 #8 üzenetére

  Én is örülnék, ha minden ojjektumot kirajzolna 20x, csak hogy be*szrjon a gép és szarul nézzen ki.
  Egyetértek az első poszttal.

  @Abu:
  Arról van szó, hogy hiába írod, hogy ott a low level API és innentől minden más a program(fejlesztő) dolga. Épp arról szól az írás, hogy milyen olyan megoldásokat szeretnének (és majd fognak?) alkalmazni, ami nem fekszik ennek a hw/sw környezetnek sem.

  Remélem azon is gondolkodnak már, hogy mi lenne, ha az x86 Win-t a gpu-n futtatnák a rendert meg a 12 szálas (x86) cpu-n. Mert úgy lenne még igazán szuboptimális.
  Én mindig a fejlődést pártolom, de most egy kicsit előbb írjanak már bár 50k rajzolásos ÉS jóval szebb, jobb játékot. Aztán jöhet a gondolkodás a további irányokban...

  Egyelőre itt se tartunk még.
  És ha kijönnek tömegével a low level játékok akkor még mindig ott a mondat második része. Kíváncsi leszek jobban néznek-e majd ki.

  Anno a T&L-nél a retinámba égett erősen a váltás. Jöttek az első progik amik el sem indultak T&L nélkül. De hányás módon néztek ki az ezeréves "régi" cuccok mellett.

  Most kaptak új API-t, ideje bizonyítani. Aztán ha ügyesek lesznek kaphatnak újabbat.

Új hozzászólás Aktív témák