ZFX + Developia

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

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?

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.

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

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

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.

klickverbot hat geschrieben:Ein gelungenes Lebenszeichen ... Photonen?

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

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

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

Krishty hat geschrieben: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

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

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

Helmut hat geschrieben: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.

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

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.

Despotist hat geschrieben: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.

Despotist hat geschrieben: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

Redest du jetzt von der Bahntechnik? :)

Hiermit kannst Du es ganz "konform" gestalten:

http://www.iwr.de/wind/raum/luftfahrt.html

Stichwort "Hindernisbefeuerung".

Viel Spass!

Joerg

Parallel-split shadow mapping (3 Splits, 1024x1024 Pixel pro Shadow Map) mit zufällig gedrehter 12-Sample Poisson-Disc beim Shadow-Look-Up, die Schatten werden im Voraus auf den Tiefenpuffer projeziert und müssen dann nur noch von den schattierten Objekten aus der so generierten Shadow Mask gelesen werden (1 simpler Texture Look-Up). Die Verteilung der Splits ist noch etwas suboptimal, das Rendern der Schatten auch noch nicht optimiert. Die Shadow-Map-Pixel sind am World-Space ausgerichtet, um Flirren bei Kameraverschiebungen und -drehungen zu unterbinden. Das Flirren bei Drehen der Lichtquelle konnte ich zwar reduzieren, aber auch nicht vollständig beheben. Im Moment dreht sich die Sonne weich alle 10 Sekunden eine halbe Sekunde lang, da bei schnellen Drehungen das Flirren weniger auffällt.

Schöne Farbgebung, aber je öfter ich Videos von Deinem Demo sehe, desto mehr stören mich diese schwarzen SSAO-Kanten überall. Die werden wie ein Halo vor der Kamera hergeschoben. Die Kernelgröße des SSAO sollte zumindest mit der Entfernung skalieren, aber auch ein Ausschluss von Samples, die allzuweit vor der Oberfläche liegen, würde ein bisschen was bringen.

Und wenn Du schon 3x1024er nimmst, dann nimm doch noch ne vierte, damit der Schatten wirklich bis zum Horizont geht :-) ein Viertel müsstest Du ja noch auf der 2048er frei haben

Sieht wirklich sehr gut aus … gibt es auch Screenshots in „voller“ Auflösung? Videos sind zwar schön, aber Details kann man da nur selten erkennen.

Schrompf stimme ich voll und ganz zu, da wird zuviel schattiert, was nicht schattiert werden sollte – man siehe nur die Kabel im Vorschaubild des Videos. Was mir auch immer wieder auffällt: Müsst ihr die Wasseroberfläche wirklich in den Tiefenpuffer schreiben, könntet ihr nicht die Tiefe der gespiegelten Geometrie nehmen? Wasser reflektiert und erzeugt deshalb so gut wie keine indirekten Schatten.

Das AO ist in der Tat zu stark, ohne Schatten war es neben einfachem Phong Shading die einzige Art des Kontrastes, mit Schatten muss es nun neu angepasst werden (besonders sollte ab sofort nur noch das Ambient Light beeinflusst werden, Tiefen-Falloff muss verstärkt werden etc.). Der Radius wird aufgrund von Problemen mit MSAA (heftige Artefakte bei kleinem Sampling-Radius aufgrund der falschen Tiefenkontinuitäten nach dem Resolven) nicht an die Tiefe angepasst, auch das muss behoben werden.

Die Schattenreichweite wird sich mit optimierter Splitverteilung und möglicherweise einem Split mehr ebenfalls noch ändern. :-)

Habe noch ein paar Artefakte vom Himmel beseitigt. Der nachfolgende Screenshot wurde zwar mit Gimp im Kontrast verbessert, weil mein Tonemapping-Operator alles ein wenig eingraut, das hängt aber nurnoch an ein bisschen Feintuning des Weiß- und Schwarzabgleichs. Ich finde den Abendhimmel mit aufgehendem Mond und durch die Täler kriechendem Nebel sehr hübsch: Vom Windrad gibt es keine Screenshots, bis die Hindernisbefeuerung gemäß Jörgs Post richtig funktioniert.

Also jetzt werde ich neidisch. Wow, das sieht toll aus.

Hmm... Ich trau mich nach der letzten Erfahrnung dieser Art gar nicht mehr zu fragen, aber... darf ich eventuell Deinen Himmelsshader benutzen? Ich muss den unsrigen nämlich irgendwann demnächst mal komplett neuschreiben und mir graut bereits davor, die ganzen Paper dazu zu wälzen. Bei Deinem Perfektionsdrang wäre ich zumindest sicher, dass die Implementation stimmt und die Werte vorgestimmt sind :-) das würde mir eine Menge Arbeit ersparen.

Danke für den Lob :)

Der Himmelsrenderer wurde von Anfang an als eigenständige Bibliothek („Ozonblau“) entwickelt, um ihn so schnell wie möglich in beliebige Programme einbinden zu können. Auch habe ich Abstraktionen für die Streuungsmodelle entwickelt – so dass die Atmosphären austauschbar sind (z.B. um die Atmosphären fremder Planeten zu simulieren) – und ein System zum Management von Gestirnen wie Sonnen, Monden und den Sternen.

Jetzt aber zu den Downsides (abgesehen davon, dass das erst halbfertig ist und noch nie mit einer richtigen Anwendung getestet wurde): Alles ist kompromisslos D3D10 / D3D11. Ich hatte, bevor D3D10 released wurde, D3D9-Umsetzungen in der Mache, die aber alle gnadenlos an der 24-Bit-Präzision der Rechenwerke gescheitert sind und eine solche Umsetzung – zumindest mit den Modellen, die ich verfolge – unmöglich machen.

Ozonblau verfolgt einen „vereinheitlichten“ Ansatz, mit dem die Atmosphäre nicht nur aus den üblichen, bodennahen Blickwinkeln betrachtet werden kann, sondern auch aus größer Höhe oder aus dem Weltraum (ich liebe Sonnenaufgänge aus dem Orbit, bei denen man den Erdschatten wandern sieht). Es gibt Systeme, die sowas durchaus brauchen (vor allem Flugsimulatoren), aber ich glaube nicht, dass Splitterwelten dazugehört. Da sollte man auf einen einfacheren Ansatz zurückgreifen (flache Planetenoberfläche statt Kugel, wie es z.B. WindLight macht) und kann das Problem dadurch um einige Dimensionen reduzieren … das sollte sich sehr positiv auf den Implementationsumfang und die Performance auswirken, vor allem aber D3D9-Implementationen ermöglichen.

Wenn du also auch nichts mit dem Code selbst anfangen kannst, kann ich dich gern bei der Implementation unterstützen und dich mit Parametern, Tabellen, Lookup-Texturen und Code-Schnippseln versorgen.

Ja, da gehen unsere Anforderungen doch deutlich auseinander :-) Ich brauche eine Lösung, die mindestens auf SM2 läuft und hinreichend glaubwürdige Farbspiele für beliebige Tageszeiten, aber nur mäßig schwankende planare Atmosphären simuliert. Notfalls auch im VertexShader. Und unbedingt ohne Sterne, Mond, sonstewas. Du dagegen verpackst gleich ein komplettes Planetarium in den Shader :-)

Ich werde gern auf Dein Angebot zurückkommen. Aber wann das wird, kann ich noch nicht sagen... momentan bin ich beim Parallelisieren, und das kann man ja nahezu beliebig weit treiben :-)

Mein neuestes 64k Intro. Die Musik stammt mal wieder von Turri. Das ganze basiert auf DirectX. Ich hab mir einen kleinen Konverter geschrieben, der die Bildchen moeglichst klein packt und dann daraus Quellcode erzeugt - das ist dann einfach ein BYTE Array. Beim Start wird das dann wieder in eine Textur umgewandelt und die Transparenzen erstellst usw. Die Bilder und die Musik belegen auch den Grossteil des Platzes, der Rest hätte wahrscheinlich wirklich in 4k gepasst. So ist es dann doch 10 mal soviel geworden.

Noch Fragen? Keine, dann ab dafuer!

This is serious prod!
Download CMath 4k Intro Wannabe
Live Video

Das ganze wurde auf der Evoke präsentiert und hat in der Kategorie 64k den zweiten Platz belegt, wobei es aber leider auch nur 3 Beiträge gab.

So und noch ein paar mehr:

Hm, die Zip Datei scheint bei Virenscannern nicht so beliebt zu sein: http://www.virustotal.com/de/analisis/7 ... 1249314915
Liegt wohl am Packverfahren.

naja das ist ja fast üblich bei kleinen demos... :)

Ja, das Problem ist nicht, das da Viren drin waeren, sondern das der Virenscanner es nicht entpacken kann.