4. schnelle GPU "hash" Funktion (gesucht)

schnelle GPU "hash" Funktion (gesucht)


  • Die Hardware ist schon neuer - das älteste auf was das laufen muss ist ne Radeon HD 4650, aktuell ne Trinity APU.
    Ich verwende bloss die D3D9 API, bin also vom Shader-Code auf das eingeschränkt was D3D9 kann.

    Aber ich kann ja trotzdem mal probieren wie die Performance aussieht wenn ich schneidere.

    Was verwenden denn die grossen Jungs für prozedurale Texturen etc.? Auch einfach die fract(sin(x) * SomeMagicNumber) Funktion?

    0
  • ?

    hustbaer schrieb:

    Was verwenden denn die grossen Jungs für prozedurale Texturen etc.? Auch einfach die fract(sin(x) * SomeMagicNumber) Funktion?

    Die grossen Jungs verwenden keine prozedurale Texturen.

    0
  • R
    Mod

    kleinerJung schrieb:

    hustbaer schrieb:

    Was verwenden denn die grossen Jungs für prozedurale Texturen etc.? Auch einfach die fract(sin(x) * SomeMagicNumber) Funktion?

    Die grossen Jungs verwenden keine prozedurale Texturen.

    mir ist auch nicht bekannt dass jemand grosses es nutzen wuerde, schon garnicht im shader.

    0

  • D.h. keiner verwendet in aktuellen Spielen berechnete Noise-Texturen?
    Kommt mir irgendwie sehr komisch vor.
    Ich hätte mir erwartet dass das Verhältnis GPU-Leistung <-> Speicherbandbreite schon lange so stark in Richtung GPU-Leistung "verschoben" ist, dass sich prozedurale Texturen auszahlen.
    Und bei Noise-Texturen geht es halt auch relativ schön, da auch berechnete Noise-Texturen ganz gut aussehen.
    Bei anderen Texturen gehe ich davon aus dass keiner berechnete Texturen verwendet, weil man prozedurale Texturen einfach nicht gleich schön hinbekommt wie "klassisch" erzeugte.

    (snip)

    OK. Egal.

    Neue Frage:
    Warum verwendet man in grossen Spiele-Titeln keine prozeduralen Texturen?

    0
  • R
    Mod

    hustbaer schrieb:

    D.h. keiner verwendet in aktuellen Spielen berechnete Noise-Texturen?

    ich kenne kein spiel dass sowas per shader rausrendert. es gibt ein paar wenige noise texturen (diese jedoch eher fuer noise wie z.b. dithering->color grading, etc. nicht fuer prozedurales), aber ehrlich, wozu dafuer extra was programmieren wenn du es in photoshop abspeichern kannst? dann haben artist auch noch ein wenig einfluss und koennen den look bestimmen, das ist bei prozeduralen dingen sehr problematisch (und code art moechte niemand).

    Kommt mir irgendwie sehr komisch vor.
    Ich hätte mir erwartet dass das Verhältnis GPU-Leistung <-> Speicherbandbreite schon lange so stark in Richtung GPU-Leistung "verschoben" ist, dass sich prozedurale Texturen auszahlen.

    ja, dem ist auch so, vielleicht 1:4 bis 1:10 wuerde ich sagen. ich vermute deine 'noise' funktion alleine hat 10cycles und du sagst du brauchst die 40 mal und dazu 7lerp? das sind also ca 414 cycles.
    du muestest einen extrem textur limitierten shader haben damit sich das ausbalanziert.

    Und bei Noise-Texturen geht es halt auch relativ schön, da auch berechnete Noise-Texturen ganz gut aussehen.

    wie gesagt, noise fuer wirklich noise, aber nicht fuer prozedurale texturen.
    ein paar effekte koennen 'prozedural' sein z.b. wellenbewegungen, aber da wird das einmal auf cpu seite ausgerechnet und dann auf die gpu hochgeschoben.

    Neue Frage:
    Warum verwendet man in grossen Spiele-Titeln keine prozeduralen Texturen?

    -weil art von artist gemacht wird und die mit einem pinselstrich etwas erzeugen koennen was sie sich wuenschen, aber mit randomizern erhaellst du 'irgendwas' und darfst dann rumprobieren. das ziel ist synthetisierung von ideen, nicht schnell 'irgendwas' machen. (jedenfalls aus sicht der kreativen).
    -ein spiel 'poliert' man auch, dass es mit der zeit immer besser ausschaut, aber das kannst du bei prozeduralen dingen kaum, du kannst immer wieder neue sachen erstellen, aber sie nicht progressiv schoener gestalten. Mag sein dass du ein 'kickstart' hast und 'wow ein terrain in nur 2tagen coden' erstellst, aber dann musst du 200details besser machen und jedesmal wenn du eine sache aenderst, aendert sich woanders wieder was, was dir nicht gefaellt. (bzw deinen artist). Als coder lernt man, dass man denen lieber ein manuelles tool gibt wo sie gegen ihr eigenes zeitmanagement arbeiten, als ein 'automatisches' tool zu machen wo sie jeden tag an deinem schreibtisch stehen und dir erzaehlen welche 3 winzigen wuensche sie noch haben. Am ende ist der coder genervt und die artist unzufrieden, da ist es besser wenn sie die verantwortung und moeglichkeiten bei sich auf dem schreibtisch haben.
    -prozedurale dinge kann man schlecht zeitlich einschaetzen, wie lange wird es dauern bis du 10 oder 1000 xyz prozedural in guter qualitaet generierst? bei artist kann man sagen dass z.b. ein artist ca 1woche pro objekt braucht, man hat 2jahre zeit und 10 artist also muss man mit ca 1000objekten hinkommen fuers spiel und dann arbeitet man los.

    manche dinge generiert man z.b. bei minecraft die level, ich glaube bei gothic die map, aber das ist nur mal ein kickstart, bei gothic haben die, afaik, dann alles ueberarbeitet wo der player sein kann. stellen die sie nicht angefast haben sehen halt nicht komplett oede aus, aber es ist keine prozedurale content creation wie du es vermutlich im sinne hast.

    was viel mehr im kommen ist, ist real world scanning (und auch da haben die artist viel dagegen z.b. weil dinge vorbeleuchtet sind und texturen dann von z.b. schatten befreit werden muessen und das UV-set automatisch generiert ist und suboptimal ist was dann doppelt arbeit macht etc. etc. etc.). also wenn es um zeitersparnis gehen soll, prozedural eher weniger.
    wenn du etwas erstellen wuerdest was super schnell ist und beeindruckend ausschaut, dann hast du vielleicht ein keil in der tuer.

    0

  • Vielleicht war die Formulierung "prozedurale textur" unglücklich gewählt.
    Ich meine damit nicht unbedingt etwas was als Textur auf ein Objekt draufgeklebt wird, sondern einfach alles wo man im Shader "Zufallswerte" braucht. Also die Wahl hat eine Noise-Textur zu sampeln oder eben das selbe über eine rein berechnete Noise-Funktion zu machen.

    Vielleicht hab' ich auch überschätzt wie oft man sowas in Shadern wirklich braucht. Trotzdem wundert es mich dass die Grafikkarten keine fertigen Zufalls- oder Noise-Funktionen anbieten. Da ich nach wie vor glaube dass es viel schneller als die von dir geschätzten 400 Zyklen gehen müsste wenn die Grafikkarte es mehr oder weniger "direkt" unterstützt.

    ps: Einige Vorteile stehen auch in dem von dir verlinkten Beitrag unter Punkt "26.2 Storage vs. Computation".
    Weiters kommt u.U. noch dazu dass Texture-Lookups speziell langsam werden wenn die Texturkoordinaten zu wild "rumspringen", und der Textur-Cache daher schlecht bis gar nicht genutzt wird. Einer berechneten Noise-Funktion ist das dagegen egal, die wird deswegen nicht langsamer.

    0
  • R
    Mod

    hustbaer schrieb:

    Vielleicht hab' ich auch überschätzt wie oft man sowas in Shadern wirklich braucht. Trotzdem wundert es mich dass die Grafikkarten keine fertigen Zufalls- oder Noise-Funktionen anbieten. Da ich nach wie vor glaube dass es viel schneller als die von dir geschätzten 400 Zyklen gehen müsste wenn die Grafikkarte es mehr oder weniger "direkt" unterstützt.

    eine extra instruction die, wenn ueberhaupt, extrem selten verwendet wird? der trend geht eigentlich in die gegenrichtung, weniger spezialhardware und die gesparte silizium flaeche fuer general purpose oder fuer taktung aufbringen. dann hast du mal ab und zu eine langsame instruktions emulation und dafuer in 99.9..% der zeit einen performance boost.

    wenn es randomizer in hardware gibt, sind sie meistens nicht schnell, da sie gewisse qualitaeten aufweisen muessen die es am ende sehr aufwendig machen, die zielrichtung ist also nicht performance, sondern nutzen den du anders kaum erhalten kannst. entsprechend langsam sind sie, z.b. 200cycle auf intel cpus.

    und das ist um die 10instructions von dir zu sparen. du muestest das natuerlich 40mal machen + lerp fuer perlin noise.

    ps: Einige Vorteile stehen auch in dem von dir verlinkten Beitrag unter Punkt "26.2 Storage vs. Computation".
    Weiters kommt u.U. noch dazu dass Texture-Lookups speziell langsam werden wenn die Texturkoordinaten zu wild "rumspringen", und der Textur-Cache daher schlecht bis gar nicht genutzt wird. Einer berechneten Noise-Funktion ist das dagegen egal, die wird deswegen nicht langsamer.

    ist vermutlich sehr fall abhaengig. bei sowas wie z.b. perlin noise, wo du mehrere oktaven in einer textur hast wirst du vermutlich sehr regelmaessig samplen und es ist super schnell (da die textur vermutlich sehr klein z.b. 32x32 DXT1 ist).

    0

  • Weiters basieren wohl die meisten PRNGs massiv auf Integerarithmetik, die auf vielen aktuellen GPUs unglaublich langsam sein kann...

    0

  • @dot
    Die meisten Shader deren Code ich bisher gesehen habe, die Noise im Shader berechnen, misbrauchen dafür die Sinusfunktion - eben mit fract(sin(x) * SomeMagicNumber) .
    Aber genau das wäre auch ein Argument dafür ne spezielle PRNG Funktion anzubieten. Wo man mit nem float reinfahren kann und einen "Zufallswert" (=einfach nen Hashwert über die Bits des floats) erhält.

    @rapso

    rapso schrieb:

    wenn es randomizer in hardware gibt, sind sie meistens nicht schnell, da sie gewisse qualitaeten aufweisen muessen die es am ende sehr aufwendig machen, die zielrichtung ist also nicht performance, sondern nutzen den du anders kaum erhalten kannst. entsprechend langsam sind sie, z.b. 200cycle auf intel cpus.

    Naja... die aktuellen CPUs haben auch extra Befehle für AES. Das ist auch nix was man sonst nicht bekommen kann, sondern ne Beschleunigung von etwas was häufig gebraucht wird.
    Genau so werden Triangle-Setup, Rasterization und Interpolation der Texturkoordinaten "in hardware" gemacht (damit meine ich: nicht in userdefinierten Shaderprogrammen, sondern mit was auch immer der GPU Hersteller dafür vorgesehen hat - was natürlich auch ein Programm sein könnte das auf den selben Shader-Units läuft wie alles andere).
    (Bzw. zumindest war das mal so, falls das schon wieder outdated ist bitte ich um Korrektur.)
    Die Frage ist mMn. also nur ob man es häufig genug braucht dass es sich auszahlt.

    rapso schrieb:

    bei sowas wie z.b. perlin noise, wo du mehrere oktaven in einer textur hast wirst du vermutlich sehr regelmaessig samplen und es ist super schnell (da die textur vermutlich sehr klein z.b. 32x32 DXT1 ist).

    Wie berechnet man mit einer 32x32x1 Bit Textur Perlin Noise? 😕
    Oder meinst du Noise das sich wirklich alle 32 Pixel wiederholt und an den "Stützpunkten" (per Oktave) immer nur 0% oder 100% hat? Das geht natürlich, aber ich glaube nicht dass das besonders gut aussieht.

    0

  • Weils gerade (ein bisschen) dazupasst...

    Ihr kennt ja vermutlich das "werkkzeug" von Farbrausch, oder?
    Wäre ein Tool in der Art nicht eine feine Sache für z.B. Tablet-/Handyspiele - bzw. generell alles wo der Platz begrenzt ist? Der Vorteil gegenüber klassischer "code art" wäre dass das immer noch ein Editor ist, den man nem Grafiker geben kann, damit er damit die Meshes/Texturen/... macht. Abgespeichert wird aber nur der "Bauplan", wodurch die "Asset-Files" halt super kompakt werden.

    Oder gibt's sowas in der Art vielleicht schon für den professionellen Einsatz?

    (Mir ist klar dass man das dann nicht mehr auf der GPU laufen lassen muss, und es daher mit meiner ursprünglichen Frage nicht viel zu tun hat. Passt hier nur irgendwie dazu weil's auch quasi prozeduraler Content ist.)

    0
  • R
    Mod

    hustbaer schrieb:

    Naja... die aktuellen CPUs haben auch extra Befehle für AES. Das ist auch nix was man sonst nicht bekommen kann, sondern ne Beschleunigung von etwas was häufig gebraucht wird.

    die scheinen nicht so teuer zu sein, 1 cycle pro instruction.

    Genau so werden Triangle-Setup, Rasterization und Interpolation der Texturkoordinaten "in hardware" gemacht (damit meine ich: nicht in userdefinierten Shaderprogrammen, sondern mit was auch immer der GPU Hersteller dafür vorgesehen hat - was natürlich auch ein Programm sein könnte das auf den selben Shader-Units läuft wie alles andere).
    (Bzw. zumindest war das mal so, falls das schon wieder outdated ist bitte ich um Korrektur.)
    Die Frage ist mMn. also nur ob man es häufig genug braucht dass es sich auszahlt.

    ich glaube interpolation ist mittlerweile im shader. wenn du viel texture sampling hast, dann ist die 'software' interpolation schnell genug um waehrend der sample latenz zu arbeiten. Wenn du kein sampling machst, hast du dafuer mehr ALU power.

    rapso schrieb:

    bei sowas wie z.b. perlin noise, wo du mehrere oktaven in einer textur hast wirst du vermutlich sehr regelmaessig samplen und es ist super schnell (da die textur vermutlich sehr klein z.b. 32x32 DXT1 ist).

    Wie berechnet man mit einer 32x32x1 Bit Textur Perlin Noise? 😕

    DXT1 bietet komprimierte 32bit/pixel http://en.wikipedia.org/wiki/S3_Texture_Compression

    Oder meinst du Noise das sich wirklich alle 32 Pixel wiederholt und an den "Stützpunkten" (per Oktave) immer nur 0% oder 100% hat? Das geht natürlich, aber ich glaube nicht dass das besonders gut aussieht.

    ich denke sowas wuerde ok ausschauen und wenn du mehr details willst, dann samplest du die nochmal fuer eine hoehere frequenz.

    0
  • R
    Mod

    hustbaer schrieb:

    ..."werkkzeug"...

    darauf wird dir ein artist antworten: "ich model das dann in max/maya und du konvertierst es dann in dein coder tool, ok?"

    0

  • rapso schrieb:

    hustbaer schrieb:

    ..."werkkzeug"...

    darauf wird dir ein artist antworten: "ich model das dann in max/maya und du konvertierst es dann in dein coder tool, ok?"

    Mag sein.
    Ist aber auch irgendwie traurig, oder?

    0
  • R
    Mod

    hustbaer schrieb:

    rapso schrieb:

    hustbaer schrieb:

    ..."werkkzeug"...

    darauf wird dir ein artist antworten: "ich model das dann in max/maya und du konvertierst es dann in dein coder tool, ok?"

    Mag sein.
    Ist aber auch irgendwie traurig, oder?

    das kommt auf die sichtweise an. wir coder versuchen halt die michelangelo dazu zu bringen einen schaufelbagger zu bedienen mit dem sie dann die decken viel effizienter und mit weniger koerperlicher anstrengung bemalen koennen.

    code mal ein wenig mit spracherkennung, das ist totall effizient, du musst nichts mehr bewegen, nur noch sprechen, das natuerlichste der welt. dann weisst du wie sich artist fuehlen.

    artist machen art. was artist moechten sind werkzeug die nicht darauf zielen moeglichst produktiv und automatisiert 80% quality produkte zu produzieren, sondern synthese tools die die ideen in ihren koepfen moeglichst zu meisterwerken manifestieren.

    oder anders:
    coder: hier ist das tool, nutzt es damit es zeug fuer euch erstellt
    artist: wir wollen das machen, gibt uns ein tool mit dem wir es erstellen

    wenn du bewerbungsgespreche hast als 'spieleentwickler', wirst du gefragt werden wie du mit artist kooperierst, wenn du sagst dass du ein tool erstellst und sie dann einweist bis sie damit umgehen koennen, hast du schlechte karten. sagst du dass du artist fragst was sie brauchen und dann ueber dein tool iterrierst bis sie damit produktiv sein koennen wie sie wuenschen, hast du gute karten.

    0

  • Meinst du jetzt speziell werkkzeug weil das speziell "artistunfreundlich" umgesetzt ist, oder generell jedes Tool, weil Artists halt nicht auf die Art & Weise arbeiten wollen?
    Ersteres verstehe ich, deswegen hab' ich ja auch geschrieben "ein Tool in der Art". Könnte man natürlich viel bedienerfreundlicher machen.
    Was grundsätzlich dagegen sprechen soll weiss ich aber nicht. Einige Grafiker-Tools die ich vom zugucken so kenne arbeiten auch im Prinzip schon genau so. Bis auf ein paar wenige Operationen, wo dann doch der Operator Stack "verschwindet" und nur noch das Objekt im aktuellen Zustand da ist.
    (Bzw. wo Änderungen weiter oben im Stack nicht mehr nach unten propagieren.)

    Bei diesem Tools dann den Operator Stack statt des fertigen Meshes/Bildes abzuspeichern würde ja schon reichen. Klar, bei Tools wie ZBrush wo massig Daten durch das "rummalen" bzw. "sculpten" anfallen bringt das nix. Bei Photoshop oder sogar dem Maya Modeller sollte es aber sehr gut funktionieren.

    rapso schrieb:

    wenn du bewerbungsgespreche hast als 'spieleentwickler', wirst du gefragt werden wie du mit artist kooperierst, wenn du sagst dass du ein tool erstellst und sie dann einweist bis sie damit umgehen koennen, hast du schlechte karten. sagst du dass du artist fragst was sie brauchen und dann ueber dein tool iterrierst bis sie damit produktiv sein koennen wie sie wuenschen, hast du gute karten.

    Und wenn du als Spielefirma ein kleines Casual Game rausbringst das 500 MB hat, wie viele Spieler interessiert das dann?

    0
  • R
    Mod

    hustbaer schrieb:

    Meinst du jetzt speziell werkkzeug weil das speziell "artistunfreundlich" umgesetzt ist, oder generell jedes Tool, weil Artists halt nicht auf die Art & Weise arbeiten wollen?

    ich meine prozedurale tools, dinge die art generieren, die coder viel mehr als zielgruppe als artist haben.

    Ersteres verstehe ich, deswegen hab' ich ja auch geschrieben "ein Tool in der Art". Könnte man natürlich viel bedienerfreundlicher machen.

    selbst eine 100% richtig funktionierende spracherkennung wuerde ich nicht zum programmieren nutzen wollen, ich nutze kaum die maus. ein gutes programmiertool ist fuer mich sowas wie visual assist, wieso? weil es mir erlaubt das zu tun was ich machen moechte, aber effizienter. was ich mache moechte? programmieren, ich habe nicht als ziel kompilierbares sourcecodes zu generieren die zu 80% etwas irgendwie sinnvolles machen. (und das wollen wir hier gerade artist zumuten)

    Was grundsätzlich dagegen sprechen soll weiss ich aber nicht.

    das ist eben genau der punkt. artist wissen was sie machen wollen, sie wollen art erstellen. das ist nicht das problem was zu loesen ist. prozedural etwas zu erstellen ist was fuer uns coder sexy wirkt, fuer artist ist das aber garnichts was mit ihrer arbeit zu tun hat. das ist wie tamagotchi vs haustier.

    Einige Grafiker-Tools die ich vom zugucken so kenne arbeiten auch im Prinzip schon genau so. Bis auf ein paar wenige Operationen, wo dann doch der Operator Stack "verschwindet" und nur noch das Objekt im aktuellen Zustand da ist.
    (Bzw. wo Änderungen weiter oben im Stack nicht mehr nach unten propagieren.)

    das war der ursprung der herangehensweise. frueher waren die meisten dinge nur boolean operations die zur renderzeit synthetisiert wurden, weil einfach nicht genug speicher vorhanden war die daten 'raw' zu halten. eigentlich ist diese vorgehensweise bis heute viel effizienter, ich kenne technical artist die echt in kurzer zeit sonst was hinzaubern. trotzdem kam zbrush, sah und siegte (bzw mudbox).
    total schlechte performance (gerade anfangst), generiert sehr suboptimale meshes, sculpten von objekten dauert relativ lange verglichen mit den 'heightmaps' die man frueher draufklatschte um dann normalmaps draus zu haben.

    rapso schrieb:

    wenn du bewerbungsgespreche hast als 'spieleentwickler', wirst du gefragt werden wie du mit artist kooperierst, wenn du sagst dass du ein tool erstellst und sie dann einweist bis sie damit umgehen koennen, hast du schlechte karten. sagst du dass du artist fragst was sie brauchen und dann ueber dein tool iterrierst bis sie damit produktiv sein koennen wie sie wuenschen, hast du gute karten.

    Und wenn du als Spielefirma ein kleines Casual Game rausbringst das 500 MB hat, wie viele Spieler interessiert das dann?

    mich oder spieler? meine android games <1MB, basic unity3d sample ~50MB wenn ich mich recht entsinne. relevanz fuer spieler: was ist ein MB? dauert es lange ist nicht das riesige spiel schuld, sondern "man ist das netz langsam heute mal wieder".
    so in etwa ist auch der artist gedanken, wieso sollten sie crappy coder art generieren in 2MB? es ist denen egal ob es 2MB oder 2GB hat, sie machen dass es gut ausschaut, coder arbeit ist es dann dass es klein wird. wenn du artist helfen willst, frage was sie gerne moechten und es wird sowas kommen wie "Ich moechte mich nicht mehr um UV mapping kuemmern" "ich will keine LOD basteln, es soll einfach welche generieren" "ich will keine komplizierten budgets haben, ich mache das high-quality objekt und dann soll 'die engine' das beste und noetige automatisch draus machen"

    downloads kleiner machen? natuerlich macht das fuer jeden logisch denkenen menschen sehr viel sinn, aber nicht indem man die art production problematisch macht.
    ( Aus artist sicht ist es sicher traurig, dass sie fuer dich dein prozedurales tool bedienen muessten, weil du es nicht gut genug bekommen kannst, dass du selbst damit art erstellst. 😉 )

    0

  • Also ich kann deine Argumentation zum Teil nachvollziehen, aber eben auch nur zum Teil.
    Ich als Coder kann auch nicht hergehen und nen Shader mit Global Illumination und volumetrischem Licht und was nicht noch alles schreiben, und dann rumjammern dass die Zielplattform einfach 100x zu wenig Rechenpower hat.
    Den Artists gesteht man das aber zu. Unbegrenzte Narrenfreiheit. Da stimmt doch was nicht.

    ich mache das high-quality objekt und dann soll 'die engine' das beste und noetige automatisch draus machen

    Wobei dann ein total suboptimales Ergebnis rauskommt. Ich weiss schon dass die Artists das nicht interessiert. Was ich nicht verstehe ist wieso man denen soviel durchgehen lässt.

    Und was die Grösse angeht: gerade bei Handy Games denke ich schon dass das etliche Leute interessiert. Ich kenne genug Leute die ein Android Handy mit gerademal 4 oder 8 GB Flash haben. Wenn schon ein dummes Dreiwegklickspiel dann 500 MB hat, dann haben die keine Freude damit. Bzw. genau so wenn sie wo auf das Spiel aufmerksam werden wo sie kein gratis WLAN haben, aber es natürlich trotzdem sofort ausprobieren wollen, und dann 500 MB ihres limitierten Traffics verwenden müssen und nochdazu ziemlich lange drauf warten.

    0
  • R
    Mod

    hustbaer schrieb:

    Also ich kann deine Argumentation zum Teil nachvollziehen, aber eben auch nur zum Teil.
    Ich als Coder kann auch nicht hergehen und nen Shader mit Global Illumination und volumetrischem Licht und was nicht noch alles schreiben, und dann rumjammern dass die Zielplattform einfach 100x zu wenig Rechenpower hat.
    Den Artists gesteht man das aber zu. Unbegrenzte Narrenfreiheit. Da stimmt doch was nicht.

    um es auf die artist sicht zu uebersetzen.
    "Ihr coder erlaubt euch jede narrenfreiheit bei art, klatscht ein paar noise funktionen aneinander und freut euch dann das ihr eure 4kb demo mit 1000fps zeigen koennt und wenn es dann 100x scheisse ausschaut muss ich artist euer krappy tool dazu treten irgendwas im entferntesten zu machen was ich mir denke damit das marketing wenigstens einen screenshot hat den ich nicht komplett uebermalen musste damit noch irgend jemand euer noise kauft" 😉

    was passiert wenn man coder machen laesst, siehst du an RAGE. Megatexture FTW, immer 60FPS etc. und dann vergleich mal bei bewegung das texture aliasing bzw den matsch aus der naehe mit pop-up artefakten aus den 90ern mit aktuellen spielen.

    engineering ist halt etwas mehr als programmieren. das endresultat ist das wichtigste und wenn man artist die arme verschraenkt kann man vielleicht performance und daten probleme limitieren, aber dasgleiche gilt dann fuer art. und wenn man artist jede freiheit lassen moechte zur foerderung von content creation, dann kommt eventuell genau so ein shit raus (siehe rage).

    ich mache das high-quality objekt und dann soll 'die engine' das beste und noetige automatisch draus machen

    Wobei dann ein total suboptimales Ergebnis rauskommt. Ich weiss schon dass die Artists das nicht interessiert. Was ich nicht verstehe ist wieso man denen soviel durchgehen lässt.

    dass das ergebnis suboptimal wird, beweist nur dass wir kein tool erstellen koennen was die artist arbeit optimiert wie sie es koennen. wieso ermassen wir uns das wenn es um etwas viel komplexeres geht wie content erstellung?
    wenn es wirklich so fantastisch waere wie wir denken, dann wuerden sich artist doch drauf werfen. Sie tun es nicht? Sind sie bloede? oder ist vielleicht unsere coder sicht ein wenig zu biased?

    Und was die Grösse angeht: gerade bei Handy Games denke ich schon dass das etliche Leute interessiert. Ich kenne genug Leute die ein Android Handy mit gerademal 4 oder 8 GB Flash haben. Wenn schon ein dummes Dreiwegklickspiel dann 500 MB hat, dann haben die keine Freude damit. Bzw. genau so wenn sie wo auf das Spiel aufmerksam werden wo sie kein gratis WLAN haben, aber es natürlich trotzdem sofort ausprobieren wollen, und dann 500 MB ihres limitierten Traffics verwenden müssen und nochdazu ziemlich lange drauf warten.

    natuerlich brechen 10mal mehr leute den download ab wenn das spiel 5MB statt 2MB hat. das gilt genau so fuer ladezeiten, fuer tutorial laenge, fuer die zeit zur ersten 'trophy' etc. nur das sind dinge die am ende problematisch sind und du als coder muss dich drum kuemmern wenn es zu spaet ist. Die artist werden schon in deinem regelwerk arbeiten wenn du moechtest. ob du denen text tools mit 5min turn around time oder UI tools mit instant turnaround gibst, sie nutzen es. das wuerde vermutlich auch fuer ein prozedurals tool gelten. aber das endprodukt wird nicht zwingen besser wenn artist mehr mit dem tool als mit content creation kaempfen.

    prozedural content mag eine moegliche loesung sein - megatexturing mag in die gegenrichtung schiessen (ease of content creation). du kannst vermutlich ewig mit carmack dann diskutieren was besser waere. artist interesiert das weniger, sie wuerden mit dir diskutieren wenn es scheisse ausschaut.

    wenn du ein tool erstellen wuerdest, was prozedural fantastische resultate liefert und art erlaubt, ich bin mir sicher es wuerde den ganzen markt erobern. das problem ist wie so oft the execution, not the idea. wenn megatexturing richtig funktionieren wuerde (gleich grosse datenmenge, gleich gute qualitaet, aber ease of usage fuer artist, waere es genau so ein riesen win).

    von daher, man benutzt es nicht, weil es schlechter ist als was es gibt. nicht die idee, aber die realisierung.

    0
Anmelden zum Antworten