schnelle GPU "hash" Funktion (gesucht)

[hustbaer]

@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.

[hustbaer]

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.)

[rapso]

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.

[rapso]

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?"

[hustbaer]

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?

[rapso]

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.

[hustbaer]

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?

[rapso]

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. )

[hustbaer]

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.

[rapso]

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.