Showroom - Aktuelle Arbeiten und Projekte

[Krishty]

Soll ja nicht wieder heißen: „Es ging sooo schnell voran, bis mir Krishty Flausen in den Kopf gesetzt hat.“ ;)

"Wieder"???? ;)

Nicht von dir, aber aus meinem sozialen Einzugsgebiet kriege ich das fast täglich zu hören ;)

[joggel]

Also, wenn ich mal hier was zeige ( vlt. passiert das tatsächlich mal ^^), dann setze ich Kristhy auf meine ganze private Ignorliste :D

[joeydee]

1. weniger Verzerrung, nicht "keine".
2. geht es hier um die Repräsentation echter Daten, bei mir um die Erzeugung künstlicher Daten.
3. das Problem mit dem Aufbringen der Textur auf eine Lat/Long Kugel bleibt bestehen.
4. Du sprichst (wenn ich dich richtig verstehe) davon die Werte der Textur auf ein Mesh (Kugel) zu bringen. Bei mir gehts ja andersrum und ich berechne die Noisewerte an der Position der Pixel der Textur und mappe diese dann auf die Kugel. Dass das zu Artefakten und Anomalien an den Polen führt ist klar liegt aber mehr an dem generellen Problem 2d Flächen auf 3d Körper zu bringen und umgekehrt.
5. das "Framework" ist so gestaltet dass sich der Nutzer die Daten für einen beliebigen rechteckigen Ausschnitt holen kann und was er dann damit anstellt bleibt ihm überlassen. Das mappen auf eine Lat/Long Kugel ist also nur mein stümperhafter Versuch einer Visualisierung. Genausogut kann man es auf alles andere mappen.

1. Keine ist auch unmöglich, aber Krishty hat schon recht: mit einem Cubemesh als Basis ist es viel weniger Verzerrung, da sie sich auf 8 statt nur 2 Pole verteilt. D.h. lange dünne Dreiecke entstehen erst gar nicht.
2. Tut nichts zur Sache woher die Daten kommen. Im Gegenteil: reale Texturen für Kugeln (Planeten) findet man sogar eher als lat/long statt als Cubemap.
3. Nein, das Problem ist damit (deutlich besser) gelöst. Du musst natürlich auch das Mesh austauschen (welches Krishty oben gepostet hat), nicht nur das Mapping.
4. Das geht genauso: man berechnet den Wert an einer Texelposition. Um die 3D-Position eines Cubemaptexels zu rekonstruieren ist nichtmal Trigonometrie erforderlich. 3D-Noise auf die Position anwenden und Texelfarbe setzen ist dasselbe. Das Berechnen eines Noisewertes im Raum sollte jedenfalls unabhängig vom Mappingverfahren sein, falls nicht, rate ich dir dringend, auch das zu ändern.
4b. siehe 1.
5. Wenn es dir zur Visualisierung reicht, ist das doch ok. Wenn du später aber eine höhere, evtl. dynamische Tesselierung (LOD) anstrebst, wirds mit einer Cubemap und dem passenden Mesh aber deutlich einfacher und besser.

[Despotist]

Wie gesagt habe ich Lat/Long gewählt da ich die so erstellte Textur gleich als 2d Karte verwenden kann wo der User auch Punkte auswählen soll so dass ich deren Position (Lat/Long, 3d Raum) auch direkt kenne. Die Kartendarstellung fällt ja für Cubemaps flach da sie keine gewohnte Orientierung ermöglichen (siehe KrishtyÄs Mondbeispiel). Es wird also wahrscheinlich eh auf eine Mischung der Verfahren hinauslaufen eben für die verschiedenen Zwecke/Darstellungsformen.

Das Berechnen eines Noisewertes im Raum sollte jedenfalls unabhängig vom Mappingverfahren sein, falls nicht, rate ich dir dringend, auch das zu ändern.

Der Simplexnoise wird mit 3d Koordinaten aufgerufen ist also entsprechend flexibel. Für die LatLongtextur werden die Positionen der Pixel über eine Umrechung in sphärische Koordinaten ermittelt welche dann in 3d Koordinaten transformiert werden.

Wenn es dir zur Visualisierung reicht, ist das doch ok. Wenn du später aber eine höhere, evtl. dynamische Tesselierung (LOD) anstrebst, wirds mit einer Cubemap und dem passenden Mesh aber deutlich einfacher und besser.

Da gleich noch eine Frage dazu: Wenn ich die Cubetextur verwende lohnt sich das doch nur wenn ich wirklich die gesamte Kugel abdecke. Wenn ich zb reinzoomen will auf immer kleinere Ausschnitte brauch ich ja den ganzen Rest nicht mehr. Die räumliche Auflösung muss sich aber erhöhen um mehr Detail abzubilden. Wie muss ich mir das in der Technik die von euch vorgeschlagen wird vorstellen? Ich kann ja die Auflösung der Textur nicht beliebig vergrößern (Hardware).
Bei der LatLongtextur sage ich einfach nimm statt den gesamten Planeten nur noch einen Teil von x1,y, bis x2,y2 und berechne die Zwischenpunkte in derselben Auflösung wie vorher (die reale Auflösung bleibt gleich aber die räumliche Auflösung erhöht sich beim reinzoomen).
Was mich auch ein bisschen wurmt ist die "Platzverschwendung" in der Cubemaptextur da ja die Hälfte der Fläche nicht genutzt wird. Oder könnte man das auch vermeiden indem man die Flächen unzusammenhängend speichert und mit den Seiten des Würfels auf den jeweiligen Bereich in der Textur verweist? Das sollte ja relativ einfach gehen wenn die Koordinaten mitgespeichert werden. Oder werden die nur berechnet?

[Krishty]

Was mich auch ein bisschen wurmt ist die "Platzverschwendung" in der Cubemaptextur da ja die Hälfte der Fläche nicht genutzt wird. Oder könnte man das auch vermeiden indem man die Flächen unzusammenhängend speichert und mit den Seiten des Würfels auf den jeweiligen Bereich in der Textur verweist?

Cubemaps werden üblicherweise nur zu Darstellungszwecken zu der Form abgerollt, die ich gepostet habe. Intern speichert man sie als ein Array von sechs quadratischen Texturen bzw. einen vertikalen Stapel in 1×6-Seitenverhältnis, siehe wieder Anhang für das Mondbeispiel.

Ich habe gerade nachgerechnet, und die minimale räumliche Auflösung von Texture Cubes ist bei selber Pixelzahl tatsächlich 10 % geringer (also die Distanz, die Texel maximal weit im 3D-Raum auseinanderliegen, 10 % größer):

Gehen wir davon aus, dass du die Erde mit ihren idealisierten 40.000 km Umfang auf 100 km genau darstellen willst, Texel also nicht größer als 100×100 km sein dürfen. Eine geographische Textur wäre dann (40.000 km ÷ 100 km) × (20.000 km ÷ 100 km) = 400×200 = 80.000 Pixel groß.

Von diesen 80.000 Pixeln kannst du theoretisch sechs Seiten eines Texture Cubes mit je 115,47 Pixeln Seitenlänge erzeugen. Du hast dann einen Würfel, der auf jeder Seitenlänge 115 Mal unterteilt ist. Dabei haben die vier Texel um die je sechs Würfelflächenmittelpunkte minimale Winkelauflösung, d.h. maximale räumliche Entfernung auf der Kugel. Und die überspannt einen Winkel von atan(1 ÷ (115,47 ÷ 2)) auf der Kugel, also 0,99635° von 360°, was 110,7 von 40.000 km entspricht.

Natürlich gesetzt dem Fall, dass ich da jetzt keinen Denkfehler drin habe (wenn der liebe Gott gewollt hätte, dass ich Mathe kann, hätte er mir Solarzellen auf die Stirn gepappt).

Das entsetzt mich nun selber ein bisschen, weil ich eher 10 % höhere Auflösung erwartet hätte, da nicht so viele Texel in die Pole abfließen. Die Masse von acht Polen gegenüber zwei bei geographischen Koordinaten macht’s aber.

Man kann Cubemaps tunen, damit sie überall nahezu gleichmäßige räumliche Auflösung haben. Theoretisch lassen sich dann 87 km Auflösung erreichen, aber dann muss man bei jeder Koordinatenumrechnung den Tangens ausrechnen, und das geht massiv auf die Leistung.

[Despotist]

Cubemaps werden üblicherweise nur zu Darstellungszwecken zu der Form abgerollt, die ich gepostet habe. Intern speichert man sie als ein Array von sechs quadratischen Texturen bzw. einen vertikalen Stapel in 1×6-Seitenverhältnis, siehe wieder Anhang für das Mondbeispiel.

Ja so hatte ich mir das vorgestellt. Dann ist ja alles ok.

[joeydee]

Ja, man verwaltet intern 6 einzelne Texturen. Je eine für ein gewölbtes Quad, welche zusammen eine Kugel ergeben. Die Quads kannst du dann leichter und sinnvoller unterteilen (Quadtree z.B.) als eine lat/long-Map. Und natürlich ebenso Ausschnitte in höherer Auflösung berechnen etc.
Das einfachste Rendern per Shader geschieht dann so: du lädst die Texturen als eine Cubemap hoch und renderst dein Mesh per Cubemap-Lookup. Dazu brauchst du nichtmal Texturkoordinaten im Stream.

Noch ein wenig Mathe from Scratch hierzu, ich hoffe es sind keine groben Fehler drin, aber das Prinzip sollte klar werden:
Das Vorzeichen und der maximale absolute Wert der Koordinatenkomponenten x,y,z eines Vektors verraten, welche Textur zu diesem Punkt gehört. Ist z.B. abs(x) der größte Wert gegenüber abs(y) und abs(z), und ist x<0, liegt dieser Punkt auf der linken Fläche.
alle Werte durch abs(x) teilen, und du hast mit y und z die normalisierte Texturkoordinate des Punktes, gesehen aus der Mitte der Textur mit einer Kantenlänge von 2, das musst du noch auf übliche Texturkoordinaten kompensieren.
Also z.B. (-5,3,1) heißt linke Fläche, (3/5*0.5+0.5, 1/5*0.5+0.5) sind die Texturkoordinaten auf die dieser Vektor auf die linke Fläche zeigt.
Umgekehrt gehts natürlich auch, also Texel (0.4/0.7) der linken Textur in einen Vektor umrechnen: x=-1, y=(0.4-0.5)*2=0.2, z=(0.7-0.5)*2. Den Vektor dann noch normalisieren und mit dem Radius multiplizieren, damit er auf der Kugel liegt.

@Mods: ich denke auch, diese Diskussion sollte evtl. in einen eigenen Thread getrennt werden.

[Chromanoid]

Habe die entsprechenden Beiträge mal dupliziert, bitte ab jetzt dazu hier weiter diskutieren: Generierung von Planetentexturen - Texturkoordinaten.

[neon]

Nachdem ich hier etwas länger mitlese, dachte ich mir: warum nicht ein paar Screenshots von meinem aktuellen Projekt, der auch von dieser Community profitiert, posten.
Das Projekt befindet sich noch im sehr frühen Anfangstadium, es ist noch nicht viel zu sehen. Es sind zwei Personen beteiligt(leider nur Programmierer).
Mein Ziel ist, einen Egoshooter zu entwickeln. Aus wolfire Blog weiss ich, wie wichtig es ist, seine Fortschritte schon früh zu dokumentieren, aus diesem Grunde werde ich versuchen ein oder zweimal im Monat(vorzugsweise immer am ersten oder zweiten Tag des Monats) aktuelle Screenshots zu posten. Wenn mehr zu sehen gibt, werden auch Videos folgen.

Ich entwickele die meiste Zeit noch an der Engine, deshalb sind es keine Gameplay Screenshots.
Die engine ist Directx11 basiert, auf den Screenshots sieht man Quadtree Heightfield, Spriteanimation beim schießen und Testmodelle(von Blendswap), die mithilfe von Assimp in ein eigenes Format konvertiert wurden und weitere Standardsachen wie Skybox.
Was man hier nicht sieht, aber vorhanden ist: 3D Sound, Kollision(auch mit Terrain), simple GUI, first person camera movement.

Jetzt versuche ich, wie man aus meinem letzten Thread lesen konnte, Skeleton Animation einzubauen.

so hier die ersten Pics: progress screenshots Nr. 0
(Die fps Zahl ist konstant auf den Wert um 50 eingestellt)

cleardemo screenshot2

cleardemo screenshot1

[Chromanoid]

Sieht vielversprechend aus :)

[Aramis]

Sieht nach mehr aus als die meisten Hobby-FPS-Projekte jemals erreichen - viel Erfolg :-)

[Krishty]

Ich habe hier erst ein- oder zweimal eine Waffe vor der Kamera gesehen. Und dann nie mit echtem Mündungsfeuer. Darum ein ganz dickes Lob.

Ich könnte ja jetzt sagen, dass die Mündungsflamme additiv geblendet werden sollte. Aber das ist der erste Schritt, um doch nie fertig zu werden ;)

[neon]

Vielen Dank,

Ich könnte ja jetzt sagen, dass die Mündungsflamme additiv geblendet werden sollte. Aber das ist der erste Schritt, um doch nie fertig zu werden

Werde ich heute noch hinzufügen, kommt dann in späteren Screenshots. Danke für den Hinweis.

[Chromanoid]

Btw das Gewehr da links im Bild sieht etwas unpraktisch zu halten aus :)

[neon]

Ja das stimmt, leider ist es schwer gute Testmodelle zu finden, deshalb nehme ich als Platzhalter was ich finden kann, und auch gut Konvertierbar ist.

[Chromanoid]

Naja wenn's ein Testmodell ist, dann ist jetzt wenigstens kein Künstler in eurem näheren Umfeld beleidigt :)

[Blood]

Hiho

Vielleicht erinnert sich der ein oder andere noch an meine Screens und die kleine Spielbare Demo von 7 Days. Ich habe mir die Kritik zu Herzen genommen und das ganze aus meiner Sicht aus, verbessert.
Hoffe die Screens gefallen euch. Achja, dass mit dem Rohrbruch.....sieht noch net wirklich besser aus :D

Gruß
Blood

[Schrompf]

Sehr stimmungsvoll. Auch wenn ich immernoch Decals an den Wänden vermisse. Dreckflecken, Abriebstellen, abgeplatzter Putz. Habe aber nicht mehr genau in Erinnerung, was bei der Diskussion über die Engine-Features rauskam, daher kann ich das nicht bewerten.

[Grimasso]

Gibts schon nähere Vorstellungen worum es im Spiel selbst gehen soll?

[Blood]

Hiho

Das Spiel ist ein Horror/Adventure.
Die Story steht schon, emhr zum Spiel selber wird es geben, wenn ich einen Vorstellungsthread öffne ;)
Nur Soviel.
Das Spiel hat 2 "Welten", einmal real und einmal ficiton. Wo man sich gerade befindet, wird der Spieler nicht wissen.

Hier noch 2 Screens ;)

Gruß
Blood

[neon]

Hallo,

ich stelle wieder aktuelle screenshots von unserem FPS rein. Eigentlich wollte ich immer am ersten Tag des Monats posten, aber da bald Prüfungen sind, mach ich das diesmal früher.

Was hat sich geändert?
- Es gibts sehr viele neue Assets, da ich bei Dexsoft sehr preiswerte Angebote gefunden habe, leider kann nicht alles in den screenshots gezeigt werden. Die Skybox und die Waffe sind die einzigen Modelle, die noch später ersetzt werden müssen, da sie nicht mir gehören.
- Normalmapping wird jetzt unterstützt, auch vom Objektformat
- Erste rudimentäre Menuführung für das Spiel, damit nicht nur an der Engine entwickelt wird. Ist mit XML files leicht skinnbar.
- weitere Engine Verbesserungen
- angefangen Leveleditor zu entwickeln

Die nächsten Screenshots gibt es wahrscheinlich erst in 2 Monaten, da ich wegen Prüfungen möglicherweise nicht dazu komme, was sehenswertes hinzuzufügen.

Das was ich hier poste, wird auch auf dem Entwicklerblog gepostet: http://www.symplatonix.com/site/

So hier sind die screenshots - Progress1:
Die screenshots entsprechen wahrscheinlich nicht dem Spiel, was am Ende rauskommt, da alles noch in einem extrem frühen Entwicklungstadium ist.

shootout progress1

shootout progress1

shootout progress1

shootout progress1

[Top-OR]

Kurze und knackige Antwort von mir: Ich finds cool. Weitermachen!

[Lynxeye]

Kann es sein, dass die Textur am Tor auf dem zweiten Bild auf dem Kopf steht?

Ansonsten noch ordentliche Beleuchtung dazu und schon wird was draus.

[neon]

Ja, die Texturen werden im Modell komischerweise nicht einheitlich addressiert, bei manchen muss ich eigentlich die Texturkoordinate flippen und bei manchen nicht.


Shadowmapping ist in Arbeit, wird bei der nächsten Screenshots zu sehen sein, wird sicherlicht die Gesamtdarstellung verbessern

[j.klugmann]

Ist das Projekt kommerziell?

[Zudomon]

Die Spielfigur ist zu klein oder das Modell zu groß. Auf dem vorletzten Screen ist das Geländer an der Treppe fast auf Kopfhöhe.

[neon]

Ist das Projekt kommerziell?

Da es noch in Entwicklung ist, gibt es noch nichts kommerzielles.
Aber es soll kommerziell werden, anvisiert ist erstmal Steam. Wenn was publishfähiges rauskommt, wird das Studio auch als GmbH gegründet. Entwicklungszeit würde ich so mit 2.5-3 Jahre ab diesem Monat einplanen, In vielleicht 1.5-2 Jahren, wenn was spielbares gibt soll es auch Preorder Möglichkeiten geben, wo die User auch Zugriff auf aktuelle Builds erhalten. Es ist noch ein riesen haufen Arbeit, und ich weiss, dass es viele gibt, die von so einem Projekt mit einem kleinen Team(wir sind zur Zeit nur zwei, und beide schon allein durch Uni ausgelastet) abraten würden, aber ich bin optimistisch. Ich werde versuchen mich an das "Wolfire Model" zu halten, also häufige und von Anfang an Progress Reports/Videos/Bilder, sehr frühe Communityaufbau vor dem eigentlichen Release oder Betastatus etc.
Assets(Models, Sounds) werden extern eingekauft, Engine+Gameplay und alles rund um Programmierung wird selbst geschrieben. Wer gute Angebote für Models/Sounds kennt, oder selbst eins hat, kann sich gerne melden.

Bei Gelegenheit werde ich irgendwann mal mehr über das geplannte Game erzählen, aber in so einem frühen Stadium wird meist alles Gamerelevantes, ausser Grobkonzepte, bestimmt mehrfach geändert. Aber kurz gesagt, es soll am Ende ein postapokalyptischer Mech FPS rauskommen(schneller als übliche mech shooter, keine Mechsimulation), gute Sci-fi Assets könnten wir auch jetzt schon gut gebrauchen, wobei Gebäude/Assets von Menschen(Industrie etc.) haben auch ihr Platz im Gameplay.

Die Spielfigur ist zu klein oder das Modell zu groß. Auf dem vorletzten Screen ist das Geländer an der Treppe fast auf Kopfhöhe.

Danke, an gameplay Elementen wurde noch nicht so häufig gearbeitet, deshalb sind noch nicht viele Details richtig, aber wird ab nächsten Screenshots gerne berücksichtigt.

[Chromanoid]

Gelegenheit werde ich irgendwann mal mehr über das geplannte Game erzählen, aber in so einem frühen Stadium wird meist alles Gamerelevantes, ausser Grobkonzepte, bestimmt mehrfach geändert. Aber kurz gesagt, es soll am Ende ein postapokalyptischer Mech FPS rauskommen(schneller als übliche mech shooter, keine Mechsimulation), gute Sci-fi Assets könnten wir auch jetzt schon gut gebrauchen, wobei Gebäude/Assets von Menschen(Industrie etc.) haben auch ihr Platz im Gameplay.

Sowas? :)

[neon]

Ja das kenn ich, sowas ich der Art soll es werden.
Natürlich kommen Abwandlungen und andere Elemente rein(nicht nur reines combat), aber das Grundprinzip ist sollte änlich sein.
Die Leute haben dort eine sehr gute Arbeit geleistet.

[Chromanoid]

Das Ding wird mit dem UDK entwickelt, vielleicht wäre das ja auch was für euch? Bei FPS Gameplay ist das UDK so ziemlich das beste was man kostenlos bekommen kann. Siehe auch http://udk.com/showcase-hawken