ZFX + Developia

Weil mir das Grau auf Dauer zu langweilig wurde: Ein paar Texturen und Fog. Keine Lichtquellen, ganz simpler Shader, in die Texturen gemalte Effekte - reicht schon um etwas Atmo zu erzeugen. Minimalismus-Shooter, you remember?


Ambient-Only funktioniert auch mit einer hellen Szene. Die Texturen haben übrigens keine Bedeutung, also nicht fragen was das darstellen soll :D

Das erinnert mich irgendwie an Dark Forces. Vielleicht durch die Texturen oder weil alles gleich hell ist.

Mich an das gute alte Jedi Knight :) Sehr effizient (Atmosphäre mit wenig Aufwand)!

Da habt ihr aber ein paar Vergleiche ausgegraben - wer wird nicht gern mit Star Wars verglichen :D ;)
Ja, vorerst soll der Renderer einfach bleiben, aber die Geometrie trotzdem hoffentlich besser "lesbar" sein als bei manchen älteren Titeln vor GI-Lightmaps.
Aus zwei Gründen: a) steckt die aktuelle Arbeit eher hinter den Kulissen, und b) einfacher One-Man-Workflow da ich mir die ganzen Texture-Maps spare.

Entwurf eines Polizeifahrzeugs, das noch in den Driver-Dateien rumschwirrte. Ich bin sicher nicht der erste, der es gefunden hat (insbesondere markiert Someone972 die Textur prominent am Ende eines seiner Videos), aber es zeigt halt schön, wie die Designer vorgegangen sind: Erstmal einen Längsschnitt in 2D zeichnen, dann extrudieren, und die Vertices zurechtrücken.

Ich bin mir auch relativ sicher, dass Autos ursprünglich einmal ausbrennen können sollten, denn es existieren viele unbenutzte Modelle mit vollkommen vergrieseltem Fahrgastraum.

Drüben bei Driver Madness ist noch mehr Zeug; etwa McDonald’s- und Red Bull-Werbung, die es nicht ins fertige Spiel geschafft haben.

Ich bastel an einer Game Engine (mal wieder) und überarbeite grade das grafische Gerüst mit meinen ersten Gehversuchen bezüglich PBR.

Zu sehen sind die 4 Modi, die mein Shader zur Zeit rendern kann... Die vier Ansichten gleichzeitig gibt es aber noch nicht...

Meine eigene Kryptowährung erfunden: Papier-Kryptogeld

[youtube]g9pk-yESt2Q[/youtube]

Funktionsweise: ECC-Schlüsselpaare werden als QR-Code auf Papier gedruckt. Ein Register aller im Umlauf befindlichen Public Keys bestimmt den Wert der Scheine. Eine Transaktion entwertet alle Input-Scheine und erzeugt neue Output-Scheine. Damit sind Überweisungen, Aufsplittung usw. möglich.

Also ich finde das ganze erstmal sehr interessant.
Aber so wie es noch ist, wird sich sowas bestimmt nicht durchsetzen. Also im Gegensatz zu normalem Geld ist es viel zu kompliziert. Vor allem sehen die QR Codes zwar noch schön futuristisch aus, aber ich finde es auch sehr abschreckend. Weil hinter einem Code alles mögliche sein kann.

Meine Gedanken und Anregungen (keine Ahnung wie umsetzbar das ist, ich möchte es nur einfach loswerden):
Geldscheine, die ungültig sind, sollten nirgendwo auftauchen, dass ist ja so, als ob ich 10 mal den gleichen Geldschein in der Tasche hab, und man darf jetzt raten, welcher davon noch echt ist. Und weil das noch nicht einfach genug ist, kann man das nicht mal mit den eigenen Sinnen prüfen, sondern muss das erst per App checken. Ein NOOOOO-GO. Vielleicht ist es möglich, Geldscheine gar nicht aufzunehmen solange die einem nicht gehören und entwertete direkt zu entfernen. Das dahinterliegende System kann man sicher verbergen.
Was die QR Codes angeht, ich würde mir da ein eigenes Format überlegen... und vielleicht nicht quadratisch, sondern rechteckig und darüber BILDER!!! Keine Ahnung was, vielleicht das man pro Wert schon ein Bild bekommt, natürlich gleich mit Geldwert. Man könnte ja machen, dass z.B. [10-20[ ein Bild ist, [20-50[ dann ein anderes. Aber ich denke, wenn man ein Geldsystem baut, dann muss es auch dem normalen Geld sehr ähnlich sein, sonst wird sich wohl niemand daran gewöhnen.
Es ist zwar auch gut, dass man Geldscheine beliebig aufteilen kann, aber vielleicht sollte man auch das unterbinden. Dass man zwar doch aufteilen kann, aber eben auch nur nach festen Beträgen. Warum nicht einfach echtes Geld nachahmen, will man den 10 ner splitten, bekommt man automatisch zwei 5er. Und splittet man einen 5er, dann erhält man automatisch 2x2er und 1x1er. Umgekehrt genauso das Geld zusammen fügen... aber nicht nen 10er und 5er zu 15... sondern wieder nur in übliche Beträge.
Und kleine Beträge sind dann auch kein Schein mehr, sondern "Münzen". Auch wenn man es vielleicht ausdruckt und auf dem Papier eine Münze gedruckt ist... egal, wichtig ist, dass man weiß, es soll eine Münze sein.

Also alles in allem, ich denke, du hast schon eine gute Basis geschaffen... nun musst du das ganze nur noch Anwenderfreundlich machen.

Hast du denn schon eine Hintertür drin, dass du bei jeder Transaktion mit verdienst? :lol:

Ein Problem bei "normalem" Geld ist ja gerade das Wechselgeld. Mit dem Papier-Kryptogeld kann man mit einem Klick einen Schein erzeugen, der 13,30 Euro beinhaltet. Prinzipiell ist die Vorgehensweise, dass man immer sein Taschengeld zu einem einzigen Schein (z.B. 50,38 Euro) zusammenfasst und davon abgehende oder hinzukommende Beträge immer miteinander verschmilzt. Für das Geld im Safe gilt dasselbe: man fasst alles zu einem großen Schein zusammen und kann ihn ausdrucken und verstecken.

Hat man einen Kinobesuch vor, kann man sich sein Geld bereits in der Höhe des Eintritts, sowie 3 Eimern Popcorn zurechtstückeln und kann mit der Abgabe eines einzigen Scheins bezahlen. Die Kassiererin muss lediglich den Schein auffalten und in die Kamera halten, dann könnte das Kassen-Programm automatisch das Geld entwerten und Rückgeld evtl. auf Thermopapier drucken.

Was das Design angeht: Das Projekt ist quelloffen. Der Client ist komplett in JavaScript gecodet und kann beliebig angepasst werden. Den Scheine-Server besteht aus ~100 Zeilen PHP-Code, den kann sich jeder auf seinen Server packen und hat damit seine eigene Währung geschaffen. Momentan ist die Währung noch zentralisiert. Es wäre aber auch eine Blockchain-Variante möglich, die alle Entwertungen von einem Netzwerk kontrollieren könnte. Transaktionsgebühren gibt es übrigens keine!

Angedacht ist die Währung für einen Verein: Die ursprüngliche Geldmenge wird vom Verein geschöpft und damit werden gemeinnützige Arbeiten bezahlt. Anschließend kann mit dem Geldbestand weitergehandelt werden.

"Entwicklung einer smarten LED-Zimmerleuchte mit Sprachsteuerung" lautete das Thema meiner Masterarbeit... hier möchte ich euch kurz das Ergebnis vorstellen:

Sprachsteuerungen gibt es inzwischen viele am Markt, von Google, Amazon, Apple, Microsoft usw.. Bei den meisten Systemen ist allerdings eine Internetverbindung erforderlich und die eigentliche Spracherkennung findet in der Cloud statt. Vom Datenschutz her ist das natürlich nicht das beste, wenn man eine Wanze in seinem Wohnzimmer hat, die quasi jedes gesprochene Wort an einen Konzern zur analyse schickt. Daher die Idee, eine Sprachsteuerung für eine Zimmerleuchte komplett von Grund auf selbst zu entwickeln.

Zum Einsatz kommt ein dsPIC. Dies ist ein 16 bit Mikrocontroller von Microchip. Die Spracherkennung selbst erfolgt durch Hidden Markov Modelle. Programmiert habe ich den Controller in C. Momentan können 7 Worte erkannt werden: "Licht, an, aus, heller, dunkler, wärmer, kälter", wobei aufgrund der begrenzen Rechengenauigkeit bei 16 bit die Wörter heller, dunkler, wärmer und kälter noch nicht so sicher unterschieden werden können. Auch mit Umgebungsgeräuschen kommen die Algorithmen noch nicht so gut klar. Da gibt es aber auch Möglichkeiten mit einem zweiten Mikrofon (z.B. blind source seperation). Ein zweiter Analogkanal für ein zweites Mikrofon ist vorhanden. Auf der Elektronik sind noch zwei LED-Treiben um z.B. eine Warmweiße und eine Kaltweiße LED anzusteuern.

Hier ein kurzes Testvideo, das ich gestern Abend aufgenommen habe. Sorry für das Englisch, aber Elon Musk stammelt ja auch immer bei seinen Präsentationen^^ https://www.youtube.com/watch?v=U4KIs4pP_DQ

Ich arbeite grade an Just Cause 6 :P

Terrain Rendering einer 16km² großen Karte. Die grünen Linien stellen Höhenlinien dar und haben einen Abstand von 10 Metern...


Was jetzt noch fehlt ist ein ordentliches "Nahfeld-Texturemapping", damit man nicht nur einen Terrain-Texturpixel pro 2m×2m hat ^^

Sieht gut aus.
Benutzt du unity?

Was mir spontan dazu einfällt:
SRTM-Daten. Man kann sich von fast jedem beliebigen Gebiet diese Daten runterladen, soweit das noch immer so ist.
So hätte man ein Terrain was halt eines in der wirklichen Welt entspricht^^

Zu SRTM: Outerra Anteworld

Zu Unity: Warum fragt mich das jeder? ^^
Das gehört zum selben Projekt wie der folgende Screenshot sowie der Screenshot mit der Beleuchtung weiter oben: Einem Engine-Projekt

Das Terrain, jetzt mit Multitexturing (6 Texturen):

MasterQ32, Das sieht super aus!
Kannst du noch etwas zum Projekt erzählen? Hat das etwas mit Deiner PBR-Engine zutun oder ist das etwas eigenes?

Gruss starcow

Das sieht super aus!

Danke dir!

Kannst du noch etwas zum Projekt erzählen? Hat das etwas mit Deiner PBR-Engine zutun oder ist das etwas eigenes?

Im Endeffekt ist das Terrain ein "Addon" zur Engine, welches ich entwickel, um eben Terrains in der Engine zu rendern, ohne aber einen Sondernfall in die Engine einzufügen...
Mittlerweile nutzt das Terrain auch die selben PBR-Funktionen wie oben schon gezeigt und wird wohl auch demnächst noch mit so Sachen wie Normalmapping und sowas ausgestattet werden... :)

Es geht voran: Jetzt kann man mit einem Generator Bäume setzen lassen, zudem gibt es Distance Fog... Leider ruckelt das mit 750 Bäumen grade bei ca. 10 FPS rum, was wohl an ein paar Sachen liegt: Fehlendes LOD, fehlendes Instancing, fehlendes Clipping. Aber hey, jetzt gibt es ja wieder was zu optimieren :)

Nahansicht:


Übersicht:

Das geht ja rund hier :)
Schönen Gruß mal an dieser Stelle, vor allem an @MasterQ32, bin gerade täglich bis spät unterwegs und daher Chat-Abstinenz, entsprechend auch keine Projekt-Updates.

Ich habe zusammen mit dem guten xTr1m mal ein bisschen an der Performance geschraubt und festgestellt: ist kacke, wenn man jeden Baum Bone-Animieren will *hust*

Neue Performance: 38.9220 ms / 33.6510 ms GPU Time / 6117 Drawcalls / 25.6924 FPS
Nächster Schritt: automatisches Instacing für gleiche Modelle, damit das ganze noch etwas arg flotter wird :)

Wie funktioniert dein Generator für Bäume? Verwendest du Grammatiken bzw. Lindenmayersysteme oder ein mathematisches Parametrisierungsmodell wie bei "Weber und Penn"? Bewegung von Bäumen macht man normalerweise nicht über Bones, sondern verwendet Federsysteme. Die Literatur/Papers hierzu ist endlos.
Falls Dich dazu mein Paper interessiert http://www.vis.uni-stuttgart.de/uploads ... 314465.pdf . Allerdings hat das einen nicht unerheblichen Schwerpunkt auf korrektem Rendering der Blattfarben mit BRDFs. Was man halt so an der Uni macht. Muss in der Praxis nicht immer einen erheblichen Unterschied ergeben ;)
Außerdem erinnere ich mich an ein Paper für da Rendern von Wäldern, wär wohl mal einen Blick wert. :) (Ich meine es war folgendes: https://hal.inria.fr/hal-00650120/file/article.pdf )

Danke für die Links! Was so ein bisschen "Baum drehen" doch gleich für einen Unterschied macht :P

Das ist alles im Moment der selbe Baum, nur jeder Baum hat eine eigene Drehung, nichts wirklich geiles, was das angeht ^^

Ich bastle fleißig weiter an der Engine, diesmal Fokus auf Modell-Editor:



Aber irgendwas mach ich noch beim Import der Animationen falsch...

Okay, Kommutativität ist böse, die kann einem die ganzen Animationen zerschießen.

Aktueller Screenshot, etwas in Szene gesetzt:


Und das ganze nochmal in dunkel (und ja, der Fog sollte auch nachtig werden)

Wie schon im IRC geschrieben: sehr sehr cool! Ich hab nach Ewigkeiten auch mal wieder was zu zeigen. Nämlich den Baumgenerator in seiner halbwegs finalen Form. Fehlen noch ein paar Parametrisierungen, und die Farbgebung wird sicher so nicht bleiben, und ich muss dringend noch optimieren. Der braucht für diesen Baum aktuell 9,2s, ich muss aber für ein flüssiges Spielerlebnis eher in den Bereich <1s kommen. Aber nuja... es entwickelt sich. Dank Elternzeit mit aktuell ein bis zwei Arbeitsstunden Fortschritt pro Tag.

Auch dir ein "sehr sehr cool", der Baum sieht auf jeden Falls schon mal sehr baumig aus, vorallem auf dem Thumbnail!

Hui, ein Tree Generator. Sehr nice :)

Wenn du das realistischer haben willst solltest du dir die Struktur eines Baumes noch mal genauer anschaun. Das sieht zwar schon mal nicht schlecht aus, ist im Moment aber in der Struktur noch recht weit weg von einem realistisch aussehenden Baum. Was deine Arbeit natürlich in keinster Weise schmälert. Ich würde so ein Ding nicht hinbekommen ^^

Meist sind das vier bis fünf Detailebenen. Stamm. Dicke Äste. An den dicken Ästen schmalere Äste. An den schmaleren Ästen die Zweige mit den Blättern. Und die Blätter stehen auf den Zweigen selten so dicht aneinander. Mut zur Lücke! Wobei wir hier einen Zierahorn vor der Tür haben der eine richtige Blätterkuppel hat. Die berühmten Ausnahmen. Aber auch da passt die Struktur. Die einzelnen Zweige haben auch hier jeweils für sich nur recht wenig Blätter. Es hat nur sehr viele Zweige ...

Wie das im Detail gestaltet ist kommt jetzt natürlich drauf an ob du hier ein High oder Low Poly Ergebnis willst. TreeD hatte seinerzeit nur die Stämme und Äste als Polygonobjekte generiert. Der Rest waren Planes mit Zweigtexturen. Leider nicht mehr zu kriegen. Oder du nimmst mal ein SpeedTree Modell auseinander. Unreal und Unity haben den ja mit dabei. Die sind ja spieletauglich. Und dann wahlweise einen aus XFrog. Das ist dann High Poly, und schon sehr dicht dran an real. Da kann man die Struktur studieren. Die haben kostenloses Samplematerial. http://xfrog.com/category/samples.html .

Oder du gehst in den Wald und nimmst dir mal so einen Baum mit nach Hause ^^

Mehr Zweige und dafür keine Blätter an den Haupt-Ästen - das habe ich auf dem Schirm. Ich mache das alles ja aber nicht, um was Bestehendes selbst zu schreiben, sondern weil das eine Voxel-Engine ist und ich meine Bäume in Voxeln braucht. Das setzt leider auch den Zweigen eine harte Grenze - weniger als 5cm Astdurchmesser kann ich nicht abbilden. Aber ich könnte da ja dann ohne Holzkern nur die Blätterwolke erzeugen. Aktuell aber wie gesagt erstmal Performance.

Habe jetzt sinnvollerweise mal dear imgui in die Engine integriert, damit kann man jetzt doch auch nochmal besser debuggen:

Und um das ganze auch ein wenig nützlicher mit der GUI zu gestalten: Profiler!

Optimierungen. Da ringst Du ein paar Tage lang mit einem konzeptionell neuen Ansatz, der massiv viel weniger rechnen sollte, um nachher festzustellen: anstatt 8,5s braucht die Aufgabe jetzt 7,5s. Toll. Dann mal nachgeschaut und festgestellt, dass die Optimierungen massiv was gebracht haben. Nur wird die eine Funktion 210 Millionen mal aufgerufen. Ups. Ein bisschen grob vorab aussortieren und schon sind es nur noch 5 Millionen Aufrufe. Und der Baum rechnet nur noch 0,6s. Grrrrroßartig! Muss leider immer noch deutlich was rausholen, aber jetzt ist es erstmal schnell genug, um ein paar lose Enden einzusammeln und dann ein Häkchen dranzutackern.