Showroom - Aktuelle Arbeiten und Projekte

[kimmi]

Niemand sonst kann RTFM so stilvoll von sich geben, stimmt ;). Und seine Heldengallerie wird endlich wieder von ZFX-Postings gefüllt werde ;) ;) ;).

Gruß Kimmi

[Seraph]

Niemand sonst kann RTFM so stilvoll von sich geben, stimmt ;). Und seine Heldengallerie wird endlich wieder von ZFX-Postings gefüllt werde ;) ;) ;).

Ach nach solanger Zeit ist er doch sicher erwachsen geworden. :)

[Stefan Zerbst]

Ach die alte Plaudertasche. Immer noch so gesprächig wie zuvor :)

@Seraph
Na hoffentlich nicht. Wenn man mir meine Klischees wegnimmt sterbe ich :mrgreen:

Wie dem auch sein, herzlich willkommen zurück nach langer Phase der Abstinenz auf dieser URL.

Ciao,
Stefan

[Specialist]

Hier mal was von uns. Der ein oder andere kennt das Projekt vielleicht schon, immerhin werkeln wir schon seit 2004 daran rum ;)
Die BugSoft-Engine wird so ganz langsam fertig. Es fehlen eigentlich nur noch Partikel, Schatten und Kollision.
Danach kann es dann endlich mit dem Shooter losgehen...

Ein paar Fakten:
- DirectX9c (D3D, DSound, D3DX, DInput)
- Shadermodell 2.0, Fixed Function wurde vor einiger Zeit aus der Engine rausgeworfen
- Postprocessing-Effekte möglich, zur Zeit nur ein Glow-Effekt realisiert
- Terrain basiert auf Heightmaps und wird durch Geomipmapping vereinfacht
- Sämtliche Objekte stecken in einem Quadtree
- dichter Grasbewuchs durch Shader-Constants-Instancing
- Beleuchtung für nichtbewegliche Objekte durch Lightmaps, ansonsten dynamische Beleuchtung per Vertex
- Skydome, Volumetrische Wolken, sanftes Durchfliegen möglich
- Wasser mit Reflection, Refraction und Fake-Unterwassernebel
- Partikelsystem mit eigenem WYSIWYG-Editor ist gerade in Arbeit
- 3D-Sound
- Netzwerk über Winsock

Ich weiß, dass das meiste nicht mehr State of the Art ist, aber das lässt sich bei der langen Entwicklungszeit wohl nicht vermeiden...
Weitere Infos auf http://www.bug-soft.net

Zu guter Letzt ein paar Screenshots :)

[Zudomon]

Hi!
Das sieht ja schon ganz Nett aus. Allerdings habe ich da eine kleine Frage zu den Volumetrischen Wolken.
Hatte mir eure mal genauer angesehen und da sind mir doch Recht viele Wiederholungen aufgefallen. Für mich sieht das eher nach einfachen Sprites, als nach richtigen Volumetrischen Wolken aus.

Falls ich da jetzt was missverstanden habe, dann korrigier mich bitte!

[Specialist]

Ja, es sind letztendlich ganz viele Billboards. Zur Zeit gibt es nur vier unterschiedliche Texturen für die Wolken.
Es handelt sich also nicht um volumetrischen Nebel oder dergleichen, aber sind die Wolken nicht trotzdem volumetrisch? ;)

Ach jo, falls sich einer über die fehlende Beleuchtung bei den Bäumen beschweren möchte, die hatte ich versehentlich ausgeschaltet.
Kommt davon wenn man kurz vorher im Shader rumspielt :D

[Krishty]

… aber sind die Wolken nicht trotzdem volumetrisch? ;)

Sprites sind 2D, also nein ;)

Wie sieht das ganze denn aus, wenn man senkrecht drauf blickt? Wird für einen Shooter ja relevant, wenn man da Wolken über dem Kopf hat …

[Specialist]

Sieht eigentlich nicht viel anders aus als von der Seite. Das einzig nicht so schöne daran ist halt, dass sich die Billboards mitdrehen wenn die Kamera sich dreht. Fällt aber wirklich nur extrem auf, wenn man fast senkrecht draufschaut. Vielleicht lässt sich das auch noch durch andere Texturen oder mehr Billboards etwas unauffälliger gestalten.
Das System für die Wolken habe ich übrigens aus dem Paper von Microsofts Flightsimulater größtenteils übernommen und da war die Rede von volumetrischen Wolken :P
Ist zugegebenerweise schon eine ganze Weile her. Nur ich glaub zu der Zeit war es besser nicht möglich :)

Hier der Link: http://www.gamasutra.com/features/20040 ... g_01.shtml

[Zudomon]

Ich habe damals einfach feste Sprites gemacht, also die drehten sich nicht mit der Kamera mit sondern lagen da fast flach im Himmel.
Werde mal ein paar Bilder davon hochladen. Das Problem ist, man kann da nicht durchfliegen, aber sollte man bei einem Shooter ja vernachlässigen.
Auf den Bildern gibt es nur 2 verschiedene Wolkensprites! Eins für die unteren, eins für die oberen Wolken.

[Specialist]

Sieht ganz gut aus. Nur wir wollten halt die Möglichkeit haben da durchzufliegen. Wird auch kein konventioneller Shooter, bei dem man auf dem Boden rumrennt, sondern einer mit Raumschiffen/Gleitern, die zwar die meiste Zeit knapp über dem Boden fliegen werden, aber durch Powerups die Möglichkeit haben sollen auch höher zu fliegen. Deshalb kam so eine "Skyplane" nicht in Frage.
Auf deinem letzten Bild sieht es aber so aus, als würde die Bergspitze in die Wolken reinragen, also müsste man doch auch durchfliegen/durchlaufen können?
Vielleicht stelle ich morgen mal ein Video mit den Wolken in Aktion online :)
Jetzt ist erstmal schlafen angesagt ;)

[Zudomon]

Ich verstehe. Klar, sobald man dadurch fliegen kann, dann sieht man bei flachen Sprites, wie ich sie da angewendet hatte, den Schwindel. Aber vielleicht sollte man in diesem Spezialfall dann was anderes machen. Weil ansonsten klappt die Methode ja super.

Auf dem letzten Bild sieht es wirklich so aus, als ob die Berge in die Wolken rein ragen. Aber wenn man genau hinschaut, dann liegt es wohl nur daran, das die Nebelfarbe ziemlich identisch mit den Wolken ist. Letztlich sind die Wolken aber immer im Hintergrund und die Berge davor.

[TGGC]

Erst mal wird noch nicht mehr verraten!

[keepcoding]

Wirklich toll was ihr hier für Projekte habt! Da kriegt man richtig lust, wieder mal was in 3D zu machen :)

In letzter Zeit hatte ich leider keine Zeit mehr für grössere Projekte, deshalb hab ich stattdessen ein paar kleine Tools erstellt. Vielleicht kann jemand von euch ja eines der Tools gebrauchen oder evtl. den Source Code davon. Auf jeden Fall würde ich mich über eine Rückmeldung freuen. Ich lass euch mal den Link hier:

http://keepcoding.bplaced.com/kcdev/ind ... le=kctools

Wäre super, wenn ihr eines oder mehrere Tools kurz testen und mir Fehler oder Unklarheiten mitteilen könntet ;)

Hier ein Screenshot vom Tool "kc Movie Database":

[Aramis]

So, nun will ich auch mal. Die Assimp-Webpräsenz hat in den vergangenen Wochen (mal/schon wieder) ein gewisses Finetuning überstehen müssen. Zugegebenermaßen, etwas Perfektionismus und Rumspielerei war tonangebend. Wenigstens bin ich nun aber (erstmals/schon wieder) rundweg zufrieden damit und denke dass wir damit (erstmals/schon wieder) ganz brauchbar repräsentiert werden :-)

Und ja, ich war auch schon die letzten 3 Mal 'rundweg zufrieden' damit. Aber diesmal, wirklich. Versprochen. Und zu guter letzt, weil ich grade so gute Laune habe, auch noch ein Link.

[Zudomon]

@TGGC
Das sieht für mich etwas nach SSAO aus. :)

[Schrompf]

@Aramis: ja, ich bin spät. Ich weiß. Hab mir jetzt mal wieder die Assimp-Seite genauer angeschaut und erst da gemerkt, was Du da alles umgebaut hast. Separate Seiten für die Features, die überarbeitete Download-Seite... prrrima! Nur dass jedes unterstützte Format nochmal ein Link zu einer Unterseite ist, würde ich rausnehmen... ich weiß nicht, was Du da zu jedem Format erzählen willst. Ein kleines Wiki dazu, welche Exporter für das Format zu haben sind und welche davon taugen, wäre zwar ein ungemein nützlicher Dienst an der Gesellschaft, aber schwer zu verifizieren und mühsam in der Pflege. Davon würde ich abraten.

@Specialist: Schöne Bilder! Und schön zu sehen, dass Du/Ihr nach all den Jahren immernoch dran bleibt! Leider hat die Engine keine Schatten... alternativ würde sich auch eine Per-Vertex-Farbe für das Terrain anbieten, die die diffuse Abdunkelung unter Bäumen modelliert. Ohne sowas sehen die Bäume irgendwie immer losgelöst aus, finde ich.

Aber verzettelt euch mal nicht allzu sehr in der Technik - fangt mal mit dem Spiel an! Die Technik wird nebenher sowieso mitwachsen, wenn es nötig ist.

[Aramis]

prrrima!

*freut sich*

Nur dass jedes unterstützte Format nochmal ein Link zu einer Unterseite ist, würde ich rausnehmen... ich weiß nicht, was Du da zu jedem Format erzählen willst. Ein kleines Wiki dazu, welche Exporter für das Format zu haben sind und welche davon taugen, wäre zwar ein ungemein nützlicher Dienst an der Gesellschaft, aber schwer zu verifizieren und mühsam in der Pflege. Davon würde ich abraten.

Genau das hab ich nach einiger Überlegung jetzt auch getan. Zu jedem Format kann man beim besten Willen nichts erzählen, die meisten sind sonnenklar. Eine Datenbank für Importer/Exporter/Fileformat-Specs o.ä. - klingt irgendwie nach Lebensaufgabe :-) Also keine Subseiten. Das Problem ist, ich hätte ganz gerne einen Platz, an dem man auf ganz bestimmte Besonderheiten einzelner Loader hinweisen kann. Beispielsweise der LWO-Loader. Ich glaube, ich hab jetzt schon 3-4 Leuten separat erzählt, welche Knöpflein in LichtWave sie nicht drücken dürfen um vollständig korrekte UV-Koordinaten zu kriegen. Oder bei deinem X-Loader, die Tatsache dass er den Typ einzelner Texturen nicht erkennen kann und daher nur diffuse Texturen ausspuckt. Wo soll so etwas hin? Als neue Seite in die Doxygen-Dokumentation? Oder doch Wiki?

[Schrompf]

Gute Frage. Solche Details sind ja teilweise auch Exporter-abhängig, was die Informationen ziemlich schnell veralten lässt. Ein Wiki wäre das Beste dafür, weil da ja auch andere Leute ihre Erfahrungen eintragen könnten... allerdings wissen wir ja nun auch alle, dass sowas nur vorkommt, wenn Weihnachten und Ostern auf den selben Tag fallen. Man bräuchte also jemanden, der das Wiki pflegt. Und an der Stelle ist die Idee gestorben. Ein separates Kapitel in der Doxygen-Doku wäre da vielleicht eine bessere Idee, wo wir formlos zusammentragen können, was wir wissen, und man schon an der Form sieht, dass die Informationen mit Vorsicht zu genießen sind.

[kimmi]

Ich halte die Idee, solche Infos per Doxygen-Doku festzuhalten, auch für zukunftsträchtiger. Wie wäre es mit einer Liste von Remarks per Format? Das ist doch sogar als Doxygen-Tag verfügbar.

Gruß Kimmi

[ponx]

Hallo die Herren !
Ich hab vor einer Weile angefangen, den Render-Code aus dem AssimpViewer in eine eigene Library auszulagern, und mittlerweile hat es einen Stand erreicht, sodass vielleicht schon jemand was damit anfangen kann. Das ganze ist als Nebenprodukt zu meinem Spiel entstanden, und dementsprechend funktioniert auch nichts, was ich nicht dafür brauche und dementsprechend noch nicht kapiere.. dazu gehört auch so grundlegendes Zeug wie z.B. durchsichtige Meshes oder Animationen! Also bitte keine Wunderdinge erwarten... die Stellen im Code, die ich noch nicht kapiert/portier habe, sind auskommentiert und gekennzeichnet, (was sind Bones ?? Cube Maps ?? Teufelswerk!) können also ggf. hoffentlich in endlicher Zeit wieder eingebaut werden. Richtig weggelöscht hab ich nur so AssimpViewer-spezifisches Zeug wie das Rendern der Normalen.

Einige neue Features hab ich eingebaut:
- Rotieren und Skalieren der Assets auf Vertex-Ebene
- Speichern/Laden der D3D-Datenstruktur (AssetHelper), was vor allem bei der Debug-Lib deutlich fixer ist, als immer neu zu importieren
- Eigene Lichtquellen pro Asset (im Moment nur ein Directional Light und Ambient Light, Point Lights sind fest eingeplant und werden als nächstes eingebaut)
- Specularity und Shininess für ein ganzes Asset verändern

Der zweite Dämpfer ist, dass das ganze auf einer relativ alten Assimp-Version basiert, Revision 259 vom Dezember 2008 ! Ich weiß nicht wie viel Arbeit das wird, das auf eine aktuelle Assimp-Version upzudaten, aber ich wollte mich jetzt erstmal wieder in erster Linie um mein Spiel kümmern. Falls es jemanden gibt, der am Renderer mitbasteln will, ist er natürlich herzlich willkommen ! Sourcecode ist natürlich dabei, ne kleine Doku gibts auch, hier noch ein Screenie von meinem Spielchen:



den AssimpRenderer gibt's hier: http://ponx.net/code/assimprenderer.7z

viele Grüße von der alten frau
ponx

[Krishty]

Nettes Minispiel, nur tauchen die feindlichen Flieger immer an den gleichen Stellen auf ;) Außerdem flimmert der Innenraum des Fliegers durch, da sollten noch die Near- und Far-Clipping-Plane angepasst werden!


Nach längerer Zeit mal wieder was von mir …:

Ich arbeite momentan an einem C++-Framework, das verschiedene Bildformate abstrahiert. Bisher sind über 20 Formate – von den gängigen RGB-UNorm-Formaten über Gleitkommaformate bis hin zu exotischen Formaten z.B. für Graustufen – implementiert, weitere werden folgen (insbesondere blockkomprimierte Formate wie 1-Bit-Alpha und DXTn).

Der höhere Sinn dahinter ist, dass so LDR-, MDR- und HDR-Texturen geladen und verwaltet werden können, ohne die Programmlogik zu verkomplizieren. Die Daten können verändert, gammakorrigiert oder zu anderen Formaten konvertiert und in Texturen gespeichert werden, ohne dass man auch nur einmal mit formatspezifischen Dingen zu tun hat. LDR-Daten können so z.B. weiter in 32-Bit-UNorm mit Gamma 2,2 vorliegen, während HDR-Daten von vornherein in 128-Bit-Gleitkomma im Linear-Space gespeichert sind. Auch SNorm-Formate für Normal-Maps können behandelt werden. Für das Programm sehen alle Bilder gleich aus, was direkt mit DXGIs sRGB-Formaten ineinander greift.

Auch andere Dinge werden dadurch erheblich erleichtert: Hat man beispielsweise einen Zeiger auf die Daten des Back-Buffers und dessen Pitch, kann man innerhalb von drei Code-Zeilen einen Screenshot in eine Datei schreiben, ganz gleich ob der Back-Buffer nun LDR- oder HDR-Daten enthält. Ebenso wird in drei Code-Zeilen aus den Rohdaten einer Drittbibliothek (z.B. FreeType oder auch GDI) eine Textur beliebigen Formats oder aus einer HDR-Textur eine LDR-Textur – hat man Zeiger und Pitch, stehen einem alle Türen offen.

Die Konvertierung nimmt die Bibliothek dabei zwar von allein vor (durch Double-Dispatching und triviale Konvertierungsoperationen), ist damit aber recht langsam. Sollte das jemals zum Bottleneck werden, kann man seine eigene Konvertierungsfunktion spezialisieren (für die meisten trivialen Formate habe ich das schon getan), welche die Konvertierung dann mit maximaler Effizienz durchführt.

[TGGC]

Ein gelungenes Lebenszeichen ... Photonen?

So, habs jetzt nochmal geupdatet! Miit Photonen hat es aber nichts zu tun.

[Krishty]

Mal ein kleiner Fortschritt von mir:

Ich habe zum ersten Mal seit Jahren ein (nennenswertes) 3D-Modell gebastelt. Hat zwar ein paar Stunden gedauert, bis ich wieder drin steckte, aber dann ging es ganz gut. Es handelt sich um eine Windkraftanlage:

Totale

Wireframe-Ansicht

Das Modell besteht aus fast 3000 Dreiecken und 1500 Vertices, verteilt auf unterschiedliche Meshes für Turm, Gondel, Rotor und Rotorblätter. Ich habe über die letzte Woche verteilt rund zehn Stunden Arbeit investiert (davon die meiste in vernünftiges UV-Unwrapping, was für ein Krampf bei solchen Formen), Einarbeitungszeit inbegriffen. Vorbilder gab es nicht – ich habe alle Maße und Formen nach ein paar Fotos geschätzt. Resultat ist aber immerhin ein solides, unique-textured und animierbares Mesh mit dem einzigen Mangel, dass die Rotorachse nicht geneigt ist – dass das bei echten Windkraftanlagen der Fall ist, habe ich erst gemerkt, als ich quasi fertig war :(

Hintergrund ist, dass ich gerade Scenegraph und Scripting-Frontend meiner Engine teste. Das Windrad richtet sich also eigenständig nach der Windrichtung aus und dreht sich entsprechend der Windstärke schnell oder langsam – die Screenshots stammen aber noch aus 3D Canvas, weil die Beleuchtung in meiner Engine momentan zu saumäßig für Screenshots aussieht.

[Schrompf]

Schick. Wenn das Ding dann animiert rumsteht und schön Schatten wirft, ist es für sich allein bereits eine sehenswerte Szene :-)

Ich hab 3D-Modelling immer gehasst, aber irgendwie kommt man da nicht drumrum, wenn man ein Projekt an der Backe hat. Als Chef ist man immer auch Mädchen für alles...

[Stefan Zerbst]

Das Windrad richtet sich also eigenständig nach der Windrichtung aus und dreht sich entsprechend der Windstärke schnell oder langsam

Erstmal Lob für das Modell. Modellieren konnte ich nicht-organische Objekte schon immer solala, aber bei den Texturen scheitert es bei mir immer.

Und nun der unausweichliche [klugscheißmode]

Windräder drehen sich nur mit festen Geschwindigkeiten, i.d.R. glaube ich zwei je nach Anzahl enthaltener Generatoren. Würde sich das Rad zu schnell (oder zu langsam) drehen dann würde es zu viel Energie (zu wenig) produzieren die der Generator nicht aufnehmen könnte (oder zu wenig die den Generator nicht auf Touren bringen würde). Daher haben Windräder immer eine oder zwei konstante Geschwindigkeiten unabhängig von der Windgeschwindigkeit. Der Energieüberschuß eines schnelleren Windes wird durch eine Drehung der Rotorblätter um ihre jeweilige Längsachse quasi nach hinten durch den Rotor abgeleitet, ähnlich wie die Anstellwinkel-Anpassung bei einem Hubschrauber je nachdem wie viel Energie man vom Rotor haben möchte.

[/klugscheißmode]

Ciao,
Stefan

[Helmut]

Na toll, jetzt muss sich unser Perfektionist ein neues Modell zum Testen seines Scenegraphsystems ausdenken ;)

[Krishty]

@Stefan Zerbst: Das ist vollommen richtig - ich habe als Vorbereitung tagelang auf Zugfahrten Windräder beobachtet ;) Ich war mir aber nicht ganz sicher, noch dazu kam, dass ich bei konstanter Geschwindigkeit keine Parameter aus meiner Szene brauche - ich könnte also nicht testen, ob die Parameter der Engine richtig in den Skripten ankommen. Danke für die Gewissheit!

Na toll, jetzt muss sich unser Perfektionist ein neues Modell zum Testen seines Scenegraphsystems ausdenken ;)

Überhaupt nicht, die Rotorblätter habe ich ja auch beweglich modelliert und sobald das Skripting ausreichend getestet ist und ich die passenden Formeln beisammen habe, baue ich das korrekte Verhalten ein ;)

Übrigens: Sind die Positionslichter den ganzen Tag über an, oder werden sie durch die Umgebungshelligkeit gesteuert? Letzteres wäre mir lieber, denn dann muss ich keine Städte mit Lichtkulisse bauen, um den Code mit der Helligkeitsberechnung zu testen.

[Despotist]

Ohne mir vollkommen sicher zu sein aber soweit ich weiß hängt die konstante wingeschwindigkeitsunabhängige Rotation von der Frequenz des Stromes ab. Da man 50 Hz haben möchte und die Verdrahtung in den Spulen des Generators fix ist kann man nur vielfache der Basisfrequenz verwenden die dann gleichgeschaltet werden. Es stimmt aber dass der Output durch die gebremste Geschwindigkeit immer suboptimal ist.

Zum Modell selber:
Das ganze wirkt schon ein bisschen grob. Ist die Zahl der Polygone technisch bedingt limitiert oder wird das ganze durch technische Spielereien zur Laufzeit noch gepimpt?

Gruß
Despotist

[mikesc]

Und noch ein Klugscheißer... :D

Tatsächlich ist es so, dass fast alle modernen WKAs ihre Drehzahl variabel einstellen (etwa von 5 U/min bis 30 U/min), je nachdem wo das größte Antriebsmoment zu erreichen ist. Zum Netz siehts dann etwa so aus: Generator -> Gleichrichter -> Filter -> Wechselrichter -> Trafo.

[Krishty]

Zum Modell selber:
Das ganze wirkt schon ein bisschen grob.

Finde ich nicht: Überleg mal, wie nah du da jemals rankommst. Wenn du dir das Windrad im Detail anschauen möchtest (in wievielen Spielen tut man sowas? :D ) und dich deshalb 50 m davor stellst und hoch schaust, sieht es immernoch so aus:

Da ist (selbst an den Blättern, wo ja kaum was rund ist) keine Polygonkante länger als zehn Pixel, an der abgerundeten Gondel sind die Polygone sogar noch kleiner und gleichmäßiger (da die teils mit Splines modelliert ist, sind die Vertices nur da, wo sie gebraucht werden). Ab drei Pixeln Kantenlänge kann man auch bei kreisrunden Formen und hohem Antialiasing-Grad kaum noch Ecken erkennen, daher finde ich die Detaillierung vollkommen ausreichend. In den meisten Ingame-Fällen wird es, da es ja nur Beiwerk ist, wohl so aussehen wie im ersten Bild des Posts oben – und dort finde ich Detaillierung (obwohl es mit Vertex-Lighting gerendert ist) völlig in Ordnung.

Ist die Zahl der Polygone technisch bedingt limitiert oder wird das ganze durch technische Spielereien zur Laufzeit noch gepimpt?

Sie ist nur dadurch limitiert, dass ich in der ursprünglichen Version jedes Vertex von Hand positionieren musste :D Danach habe ich die Polygonzahl im Editor mit Subdivision und Smoothing vervierfacht und ein wenig nachkorrigiert, das hat etwa eine Viertelstunde gedauert. Falls ich also mal Bosskämpfe auf der Spitze der Gondel austragen möchte, kostet mich das noch eine Stunde Arbeit :D


Kann den niemand klugscheißen, wie die Signalleuchten funktionieren? :P