Suche Mitarbeiter für Game Framework

[rapso]

für ein omni light braucht man 2 shadowmaps (siehe google -> dual parabolid maps)

das nachlassen der auflösung auf entfernung hin ist ja gerade das, was softshadows erlaubt, damit schaut es besser aus als mit volumes, die sogar ein flugzeug von der sonne aus beleuchtet mit hardshadows verzwingen. (falls jemand sowat beklopptes machen würde )

an sich sind volumes leicht zu berechnen, siehe nvidia GDC2003 paper, wenn man's geschickt anstellt, kann man das sogar 100% im vertexshader machen (wenn man das mit der cpu rumfummeln würde, dann erwartet man ja eh nicht top performance )

der stencil pass ist an sich erheblich langsammer, für die shadowmap (sogar beim omni light) braucht man 2 passes falls die lichtquelle im frustum liegt. bei den shadowvolumes braucht man mindestens 2, bei entgegen der clippingplane extrudierten volumes sogar 3 (front,back,cap)

shadowsmaps:
beim zeichnen der beleuchtung braucht man ein zread+colorread+colorwrite falls nicht schatten

volumes:
(z&Stencil)read + colorread + colorwrite falls nicht schatten + stencilclear am ende damit man keine stencilartefakte bekommt für die nächste lichtquelle oder man schreibt jedesmal beim colorwrite auch noch den stencil auf 0, dürfte sich aber nichts nehmen beim performanceverlust.

mit shadowmaps kann man außerdem jede geometrie ohne aufwand beschatten, bei schadowvolumes muss man dafür sorgen, dass die volumes noch extrudet werden, egal ob blendshappes,skinned-mesh, partikel (z.b. blätter auf bäumen)

also bis auf dass shadowvolimes mehr akkurate schatten werfen, sehe ich keinen vorteil, weder in performance noch flexibilität, und die qualität hebt sich je nach scene gegenseitig auf denk ich mir.

hmm... vielleicht habent volumes nen kleineren speicherverbrauch.. aber sonst?

rapso->greets();

[DerSensemann]

hui, das mit der dual parabolid map muss ich übersehen haben *g* Jetzt ändert sich natürlich einiges, statt 6 Passes nur noch 2 zum Erstellen einer kompletten Map *g*
Shadowing ist nach Lighting das nächste Teilthema, wurde also noch nicht wirklich bearbeitet.. daher bin ich auch noch nicht so ganz informiert drüber

stencilclear am ende damit man keine stencilartefakte bekommt für die nächste lichtquelle oder man schreibt jedesmal beim colorwrite auch noch den stencil auf 0, dürfte sich aber nichts nehmen beim performanceverlust

Der StencilBuffer befindet sich in mitten des ZBuffers, ist also kein Problem, fast im Gegenteil, sogar gleich schnell alles zu löschen statt nur die ZWerte.

mit shadowmaps kann man außerdem jede geometrie ohne aufwand beschatten, bei schadowvolumes muss man dafür sorgen, dass die volumes noch extrudet werden, egal ob blendshappes,skinned-mesh, partikel

Das ist mit SVs auch np, solange man für alle eine gemeinsame Geometrie Basisklasse nimmt.. ist aber natürlich mit SMaps einfacher, stimmt wohl

[ChaosAngel]

Ich muss sagen du weisst wie man jemanden überzeugt.
Ich hab das Problem das ich mit ShadowMaps nicht wirklich was anfangen kann. Mit net soo das Mathegenie wie unser Sense hier
Und alles was mit Matrizen zu tun hat könnte schon fast kompliziert werden *G*

Aber was hast du gegen HLSL ??? Ich meine Grafiker lernen doch eher HLSL als deine Scriptsprache
Momentan arbeiten wir noch mit HLSL aber besser würde ich schon CG finden, alleine weil unsere "Engine" ja auch für MultiApi ausgelegt ist. Und verschiedene Shader für ein und das selbe, i weiss net

Vielleicht kann man ja von deinem aktuellen Projekt mal was sehen ... falls es OpenSource sein sollte. Würde mich brennend interessieren. Mitarbeiten willste ja sicherlich nicht, ich meine gebrauchen könnten wir dich sicherlich, aber wer n eigenes Projekt hat, hat meistens keine Zeit
Aber das Angebot steht !

@Tips:
Nunja, nichts was du nicht auch weisst
Wir konzentrieren uns eigentlich eher auf die StandardOptimierungen, also optimales Ausnutzen des VRAM's etc... Presorted Meshs, bla, bla ... Wir wollen halt wirklich das richtige PPL unterbringen so das es keinen Performanceverlust dadurch gibt. Naja, werd mich mal wieder ransetzen an unseren MS3D-Loader ...
*gähn* Bin nur irgendwie so müde *schnarch*

[rapso]

Original erstellt von DerSensemann:
**
Der StencilBuffer befindet sich in mitten des ZBuffers, ist also kein Problem, fast im Gegenteil, sogar gleich schnell alles zu löschen statt nur die ZWerte.
**

wenn du multipass machst (was man mit shadowvolumes bei mehr als einer lichtquelle machen _muss_, dann mußt du nur den stencil clearen und nicht den zbuffer, den brauchst du ja noch für die folgenden passes, der clear gestalltet sich dann in der gpu so: zread, stencil wegmaskieren,zwrite ... wenn man stencil und zbuffer gleichzeitig löscht (muss man sogar machen, man sollte nie nur den zbuffer löschen), dann nutzen die karten ihr zero-cycle-clear, sie löschen also den ganzen zbuffer in einem takt, indem sie einen bittable in der graka auf null setzen, da der ganze bittable auf dem chip ist, ist das _wirklich_ möglich alles in einem takt zu löschen und da das parallel zu anderen befehlen abläuft, heißt das zero-cycle-clear (je nach marketingabteilung)

Original erstellt von DerSensemann:
**
Das ist mit SVs auch np, solange man für alle eine gemeinsame Geometrie Basisklasse nimmt.. ist aber natürlich mit SMaps einfacher, stimmt wohl**

was meinst du mit SV, software? falls du mit software das ganze objekt skinnen möchtest und dann das volume daraus generierst, wird das nicht sehr performant. alleine schon wenn du jedes frame den buffer lockst, sachen reinschreibst, unlockst limitiert das schon sehr.
außerdem frage ich mich wie ne basisklasse die sprites mit volumes versehen will beim partikelsystem (wie schon gesagt, z.B. die blätter von bäumen).
und wenn ihr mal viele animierte objekte habt mit 3bones skinning (nötig für z.B. schulterblätter bei menschen, damit die bewegungen dort einigermassen gut aussehen), habt ihr zig matrizen die ihr verrechnen müßt und dann noch die transformation von tausenden von vertices.. was die cpu sowieso nebenbei kann beim transformieren (weil pixelshader viel limitierender sind als die vertexshader es sind)

naja, das sind jedenfalls mit die gründe, weshalb ich maps nehme.

rapso->greets();

[DerSensemann]

SVs ^= ShadowVolumes

Aber stimmt mit dem Stencil Buffer.. Erst denken, dann posten *grummel*

Naja, wie dem auch sei, kannte bisher keine Möglichkeit ne 360° Rundumsicht in 2 Passes in ne Texture zu rendern und nu wo ich es kenn, schaut die Sache wie gesagt scho ganz anders aus

[rapso]

Original erstellt von ChaosAngel:
**Ich muss sagen du weisst wie man jemanden überzeugt.
Ich hab das Problem das ich mit ShadowMaps nicht wirklich was anfangen kann. Mit net soo das Mathegenie wie unser Sense hier
Und alles was mit Matrizen zu tun hat könnte schon fast kompliziert werden *G*
**

naja, ihr könnt ja volumes nehmen und ich mache maps, und was besser ausschaut und läuft wird genommen ;), aber nein, wie im richtigen leben ist es schlecht nur eines sache zu machen, ich werde mir auch überlegen wie ich rigendwie ne hybride lösung mache, vielleicht wird's ma von nütze sein, who knows.

Original erstellt von ChaosAngel:
**Aber was hast du gegen HLSL ??? Ich meine Grafiker lernen doch eher HLSL als deine Scriptsprache
Momentan arbeiten wir noch mit HLSL aber besser würde ich schon CG finden, alleine weil unsere "Engine" ja auch für MultiApi ausgelegt ist. Und verschiedene Shader für ein und das selbe, i weiss net
**

ich hab nix gegen HLSL, ich mag leiber in c coden als mich damit abzuquällen das rendering mit scripts zu beschreiben. aber wenn selbst du meinst, dass du mit matrizen probleme bekommen könntest, dann werden grafiker die vorher nichtmal normalen benutzten, weil smoothinggroups reichen, total ins schleudern kommen, wenn sie etwas derartiges lernen müssen (schliesslich gibt es nen grund weshalb sie nicht coder sondern grafiker geworden sind)
CG ist doch aber an sich auch eine HLSL, soweit ich bisher las, ist es sogar compatible vom source her mit dem HLSL von m$.
mein kolege ist aber von RenderMonkey total begeistert, und da ati heutzutage im durchschnitt um faktor 2schneller im pixelshader ist als NV, ist es nicht verwschendete zeit sich das anzuschauen.

aber manchmal erzeugen die dinger nicht optimalen code, ich hab schon mehrmals gesehen dass sie mul und add hatten anstatt mad, wieso auch immer.

Original erstellt von ChaosAngel:
**Vielleicht kann man ja von deinem aktuellen Projekt mal was sehen ... falls es OpenSource sein sollte. Würde mich brennend interessieren. Mitarbeiten willste ja sicherlich nicht, ich meine gebrauchen könnten wir dich sicherlich, aber wer n eigenes Projekt hat, hat meistens keine Zeit
Aber das Angebot steht !
**

meine engine wird free sein für die, die freeware machen, mods... und für kommerzielle kann man halt anfragen, ich arbeite schliesslich (alleine) seit nem jahr dran, hab editoren, converter, scriptsrapche, culling algos.. alles selber von grund auf implementiert.. sowas möchte ich nicht gerne verschenken.. (so nebenbei, habt ihr das bei heise letztens gelesen, dass einer mit nem opensource projekt pleite ging und sich wundert, weshalb ihm niemand was bezahlt wenn er sein opensource projekt nutzt, war ein ein-disketten-server oder so )

wäre es jetzt gemein euch das selbe angebot zu machen? *gggggggg* ich suche auch ewigkeiten leute, aber naja, ich würde mein projekt ja auch um nichts auf der welt verlassen.
ps. ein framework hab ich schon zum teil fertig, läuft mit plugins, so kann man ein plugin machen für ein menü, und wenn das zuende ist, returnt es nen string mit dem namen und den parametern des plugins, dass ausgeführt werden kann. das lässt sich super debuggen und mit mehreren leuten entwickeln.. *tip*

Original erstellt von ChaosAngel:
@Tips:
Nunja, nichts was du nicht auch weisst
Wir konzentrieren uns eigentlich eher auf die StandardOptimierungen, also optimales Ausnutzen des VRAM's etc... Presorted Meshs, bla, bla ... Wir wollen halt wirklich das richtige PPL unterbringen so das es keinen Performanceverlust dadurch gibt. Naja, werd mich mal wieder ransetzen an unseren MS3D-Loader ...
*gähn* Bin nur irgendwie so müde *schnarch*

[/QB][/QUOTE]

ich hatte meine MS3D loader nach langer zeit mit sammt animationen und optimierungen fertig, ich war wirklich dermassen dämlich das sourceverzeichniss zu löschen.. (nein, hab kein cvs am laufen gehabt), aber an sich würde ich das lieber alles aus max raushollen, weil es oft ein argument ist ob man ne engine benutzt oder nicht, ob die grafiker die contenttools bedienen können.
wenn ich alles von max aus machen lasse, bzw. von meinen editoren, dann hat man ein paar kleien ++.

ich hab auch nen textur manager der abhängig von der meshauflösung nur die richtigen daten, für die vertexdaten muss ich noch einen schreiben... in oGL mit den nvidia extensions bekommt man eh nur ein riesiges array das man vollstopft, so will ich das auch mit d3d anstellen.

bin auch müde
aber noch ist es nicht zeit für meine 2h schöhnheitsschlaf täglich...

[ChaosAngel]

ich hatte meine MS3D loader nach langer zeit mit sammt animationen und optimierungen fertig, ich war wirklich dermassen dämlich das sourceverzeichniss zu löschen..

Nunja, das ist wirklich ... ... *Pech*

Naja, ich sitz gerade an den Optimierungen, gleich kommen die TriangleStrips ...
Aber das Modelformat ist nur vorläufig, damit man einfach mal was zum testen hat ... Sonst gibt es irgendwie keine guten Modelformate die ich ausfindig machen konnte. Auch an Levelformaten haperts arg... dazu kommt das ich mich mit dem Job vom Grafiker überhaupt nicht auskenn. Naja, Sense arbeitet an nem 3DS Converter.

@Plugins
Hatten wir im vorherigen Framework ebenfalls. Ist uns aber nicht gelungen umzusetzen, scheiterte am Runtime-ApiSwitch. Ausserdem legen fertigen DLL's einen auf einen Compiler fest. Da ansonsten DLL's nicht Exceptionsafe arbeiten. StringProbleme mit std::string und ihrem beschissenen cctor gibts auch noch (wrong heap deletion)

[rapso]

du mußt die dll als multithreaded DLL compilen, dann übernimmt der den heap von der exe, ansonsten nimmt er für die dll nen eigenen, jedenfalls war es bei mir so.

das problem tritt dann auf, wenn man in der exe delete macht für etwas was im heap der dll ist, dafür muss man sonst creator und destroyer funktionen bereitstellen in der dll.

ich würde euch von 3ds abraten, besonders wenn ihr für eure berechnungen normalen braucht (z.b. tangent space bumpmpping), denn es gibt nur smoothgroups in den 3ds, exportiert mal mit max eine texturierte kugel in 3ds rein und laded die dann wieder, dort wo die texturkante ist wird es auch für die normalen ne kante geben.
das kann man wohl eventuell rausbekommen, aber es kann passieren, dass man dann ne kante glättet, von der man eigentlich wollte dass es ne kante bleibt.
im *.ase file sind die normalen gespeichert, auch wenn man da vertices splitten muss, weil manche von ihnen doppelt belegt sind mit normalen, es schaut wenigstens richtig aus.
und da es nur text ist, ist sehr sehr simpel das format zu debuggen, man kann ja sofort sehen (im WatchWindow vom debug), wenn ein string falsch ist.
das texturzusammensuchen koennte nervig sein, falls die verteilt rumliegen, filenames waren oft zu kurz... das alles hat mich an Dionysos 1 dazu bewegt ASE zu nutzen...
es sei den euer converter ist zuweit um ihn neu zu schreiben

habt ihr schon einen archiver?

rapso->greets();

[ChaosAngel]

Woher das Heap Problem stammte wussten wir ...
Das mit der Multithreaded DLL allerdings nicht
Das Problem war das der cctor von std::string nicht wirklich kopiert, sondern intern mit Referenzen arbeitet...
Wenn man also n String an die DLL übergibt (copy by value) und der dann dort gelöscht wird wenn der ursprüngliche string bereits gelöscht ist. Der string in der DLL hält dann den letzten refcount und wird dann mit einem delete in der DLL gelöscht -> falscher Heap zugriff

@3ds I finds auch scheisse
Da streite dich mal mit Sense

@Archiver
Was meinst du damit ...
Sowas wie PakFiles ? Also n virtuelles Filesystem ham wa ... Wenn auch für eigene PakFiles, bei richtigen habs wieder stringlength Begrenzung und andere Probleme

[rapso]

dann haben wir beide wat von eurem bug gelernt

und ja, das meine ich mit archiver... ich muss mich noch dran setzten und möchte nicht wirklich etwas wie zip verwenden.. dachte ihr habt vielleicht scho wat.

ich werde das archivieren vielleicht mit nem plugin für den windowscommander machen (bzw totalcommander), mal sehen wat drauss wird.

rapso->greets();

[ChaosAngel]

und möchte nicht wirklich etwas wie zip verwenden.. dachte ihr habt vielleicht scho wat.

Na klar ...
Ich weiss nicht inwiefern das schon im alten Source vorhanden ist ... Ansonsten frag einfach mal sense (die aktuellste Version ist vom ihm) wie es mit dem Source aussieht (sein Source, seine Erlaubniss, nur sicherheitshalber :D). Projekt is ja OpenSource.

[DerSensemann]

Das Format hab ich scho festgelegt, ein unkomprimiertes Format ähnlich dem Standard PAK, nur mit einer Directory Struktur statt einer einfachen Auflistung der Dateien... Kam allerdings noch nicht zum ArchiverTool, hab immo sehr wenig Zeit Ab nächster Woche gehts weiter...

Den schreib ich wohl schnell in Delphi mit ner hübschen Oberfläche und gut is.. Das eigentliche Archivieren ist ja kein Ding, solange man nich auch die Daten komprimiert..
Die ZIP Libs die ich bisher gefunden hab sind auch alle.. nunja *g* Und Datenkomprimierung ist ja auch erstmal nicht sooo wichtig.. Das VirtualFileSystem ist so aufgebaut, dass es problemlos auf weitere ArchivFormate erweitert werden kann... später ev. dann auch ZIP, wenns gewünscht wird *g*