Showroom - Aktuelle Arbeiten und Projekte

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

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


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