Gamestudio Links
Zorro Links
Newest Posts
Data from CSV not parsed correctly
by EternallyCurious. 04/18/24 10:45
StartWeek not working as it should
by Zheka. 04/18/24 10:11
folder management functions
by VoroneTZ. 04/17/24 06:52
lookback setting performance issue
by 7th_zorro. 04/16/24 03:08
zorro 64bit command line support
by 7th_zorro. 04/15/24 09:36
Zorro FIX plugin - Experimental
by flink. 04/14/24 07:48
Zorro FIX plugin - Experimental
by flink. 04/14/24 07:46
AUM Magazine
Latest Screens
The Bible Game
A psychological thriller game
SHADOW (2014)
DEAD TASTE
Who's Online Now
4 registered members (7th_zorro, Quad, VoroneTZ, 1 invisible), 623 guests, and 2 spiders.
Key: Admin, Global Mod, Mod
Newest Members
EternallyCurious, 11honza11, ccorrea, sakolin, rajesh7827
19046 Registered Users
Previous Thread
Next Thread
Print Thread
Rate Thread
Page 29 of 45 1 2 27 28 29 30 31 44 45
Re: Fotorealistisches Mittelalter: neues Video [Re: HeelX] #414801
01/07/13 23:35
01/07/13 23:35
Joined: Dec 2002
Posts: 3,363
Vindobona (Ostarichi)
Harry Potter Offline OP
Expert
Harry Potter  Offline OP
Expert

Joined: Dec 2002
Posts: 3,363
Vindobona (Ostarichi)
Originally Posted By: Superku
Wegen der Schwalben, guck mal hier:...
Danke, sieht interessant aus. Aber wenn ich jetzt auch noch eine Vogelschwarm-Simulation ins Spiel einbaue, dann wird die Framerate in den Keller sinken.
Diese Vögel sind ja nur zur "Verschönerung" da, sollten also die Framerate so wenig wie möglich belasten. Der Vogelflug wird daher nicht in Echtzeit berechnet werden. Und ich werde auch nur einzelne Vögel einbauen, und nicht ganze Schwärme.
Wahrscheinlich werde ich ein animiertes Model benutzen, das aus nur zwei Polygonen besteht, und das einen vorgegebenen Kurs "abfliegt". Und auf diesem flachen Model wird dann eine Textur-Animation abgespielt.
Als Vorlage für die "Flugroute" und für die Skin-Animation verwende ich Videos wie diese hier:
Youtube: Der große Flug der Schwalben
Youtube: Zeitlupenaufnahme einer Schwalbe im Flug



Originally Posted By: HeelX
Okay, hier dann ein Tipp von mir. ...
Gute Tipps. Sie gefallen mir. Vor allem deshalb, weil ich es eh fast genauso mache, wie Du es beschrieben hast. grin

Hier ein paar Infos dazu:

1.) DDS-Texturen:
Im fertigen Level wird es nur noch Models mit DDS-Texturen geben. Und in den wenigen Fällen, bei denen es auf die Bildqualität ankommt, verwende ich TGA-Texturen. In einigen wenigen Fällen werde ich im laufenden Spiel mit Pixelbefehlen auf die Textur malen müssen. Auch dafür verwende ich dann natürlich TGA- oder BMP-Texturen. Bei Verwendung von DDS-Texturen kann ich fast 3mal so viele Texturen benutzen wie bei Verwendung von Bitmap-Texturen.

Beim Designen der Levels mit einfachen Sprites, und einfachen schnell erstellten Models, verwende ich jedoch immer Bitmaps und TGA-Dateien. Einfach deshalb, weil es am schnellsten geht, und weil ich dann auch besser abschätzen kann, wann die Grafikspeicher-Grenzen erreicht sind. Weil das fertig ausmodellierte Model wird ja normalerweise eine größere Textur benötigen als ein einfaches Sprite. Ein Sprite von einer Hauswand stellt ja nur die Vorderseite dar, während beim 3D-Modell dann auch Seitenteile wie z.B. die Seiten von Tür- oder Fensternischen texturiert werden müssen. Man braucht dann zwar für das fertige 3D-Model mehr Speicher als für das Sprite, dafür gewinnt man aber wieder Speicher durch die Verwendung von DDS-Texturen. Wenn ich beim Designen der Levels bereits mit DDS-Texturen arbeiten würde, könnte es passieren, dass mir im fertigen Level dann der Grafikkartenspeicher ausgeht - also dass meine Models mehr Speicher fressen als geplant. Deshalb arbeite ich beim Designen lieber mit größeren Dateien, damit ich dann nachher noch einen Puffer habe.


2.) Der hintere Hintergrund in geringerer Auflösung:
Ich versuche immer, nur die Auflösung zu wählen, die auch wirklich notwendig ist. Objekte, die sich nahe bei der Kamera befinden, haben dann eine höhere Auflösung und Texturgröße als Objekte, die weiter entfernt sind. Bei einem Turm zum Beispiel ist nur der untere Teil des Turmes hochauflösend. Wenn man von unten zum Turm hinaufblickt, hat der obere Teil des Turmes eine wesentlich geringere Auflösung.

Wichtig ist dabei, dass man immer bedenkt, dass ein Pixel von einer Textur bei Betrachtung im Spiel nicht größer sein sollte als ein Pixel vom Monitor. Um das besser abschätzen zu können, arbeite ich auch gerne mit Raster-Texturen. Das heißt, ich gebe meinen Models als Textur ein Pixel-Raster. Dann kann man besser abschätzen, ob die Auflösung passt, bzw. ob ein Kästchen von so einem Raster nicht doch zu groß dargestellt wird, oder auch zu klein (was ja Textur-Verschwendung wäre, wenn die Pixel einer Textur gar nicht alle am Bildschirm zu sehen wären). Bei 3D-Models hat so eine Raster-Textur außerdem den Vorteil, dass man besser erkennen kann, wie stark die Textur verzerrt wird. Optimal ist ein Model dann, wenn es alle Kästchen vom Raster auch wirklich möglichst rechteckig und in möglichst gleicher Größe darstellt. So eine Raster-Textur sieht dann z.B. so aus (ist nur ein Ausschnitt von der gesamten Textur, die vollständig aus solchen Kästchen besteht):



Bei der Wahl der korrekten Texturgröße habe ich oft das Problem, dass z.B. die Auflösung "1024 x 1024" zu klein wäre, die Auflösung "2048 x 2048" wäre jedoch zu groß. Zum Beispiel bei der Textur von meinem Himmel und Horizont.
Deshalb verwende ich immer Texturgrößen von 8192 x 8192 Pixel. Egal wie groß das Model ist. Auf so eine riesige Textur passen dann halt die Skins von MEHREREN Models, und diese Models teilen sich dann die Textur. Der Vorteil dabei ist, dass ich dann auch problemlos andere Auflösungen (z.B. 1300 x 1300 für meine Horizont-Textur) verwenden kann. Den Rest des Platzes auf der großen Bitmap benutze ich dann halt für andere Models (z.B. für Bodentexturen).
Dabei achte ich natürlich schon darauf, dass nur jene Models sich eine Textur teilen, die im Level auch nahe beisammen liegen. Weil ich ja dann später eventuell Models auch nachlade bzw. aus dem Speicher lösche. Die große Bitmap, auf der sich auch die Himmels-Textur befindet, die ja die ganze Zeit über im Speicher bleiben muss, enthält dann hauptsächlich Texturen, die ebenfalls ständig im Speicher gehalten werden sollten (z.B. oft verwendete Bodentexturen).


3.) Himmel mit Gradiententextur oder prozedural mit einem Shader:
Mein Himmel verwendet keinen vertikalen Farbverlauf, da das unnatürlich aussehen würde (habe es ausprobiert).
Das heißt, der Übergang vom unteren hellen (bzw. fast weißen Bereich) zum oberen dunkelblauen Bereich entspricht dem natürlichen (ungleichmäßigen) Übergang aus dem Originalfoto.

Zusätzlich blendet der Himmel oben in eine einzige blaue Farbe über. Nur der UNTERE Teil des Himmels hat also einen Farbverlauf, der obere Bereich hat nur noch eine einzige Farbe. Und obwohl der Himmel sehr hoch hinauf geht, ist die Textur für den Himmel nur ein eher schmaler Streifen (gerade so breit wie der sichtbare Farbverlauf über dem Horizont). Der obere Teil des Himmels benötigt als Textur eigentlich theoretisch nur einen einzigen blauen Pixel. Das heißt, meine Himmelstextur ist also in Wirklichkeit sehr viel niedriger als sie im Spiel aussieht. Und weil der dunkelblaube Bereich im oberen Teil des Himmels ja nur eine sehr kleine Skin benötigt (theoretisch nur 1 Pixel), wirkt sich das auch sehr positiv auf die Framerate aus.

Die Wolken am Himmel sind momentan Sprites. Später werde ich dafür ebenfalls Models verwenden, damit die Wolken ein wenig 3-dimensionaler wirken.

Der Himmel ist übrigens nachkoloriert. Weil auf Fotos sieht ein Himmel nie so aus wie in Wirklichkeit. Entweder ist auf den Fotos die Landschaft darunter zu dunkel (dafür ist der Himmel dann schön blau), oder die Landschaft hat eine realistische Farbe, dann ist aber meist der Himmel überbelichtet, und wirkt eher weiß. Daher habe ich im original RAW-Foto die Helligkeit so verändert, dass einmal der Boden korrekt belichtet ist, und einmal der Himmel. Und aus den beiden Bildern habe ich dann ein einziges zusammengesetzt.

Ich hoffe, ich habe das Blau des Himmels gut getroffen?! Weil jetzt im Winter habe ich leider keinen schönen blauen Vergleichs-Himmel in freier Natur, bei dem ich überprüfen könnte, ob die Farbe optimal passt. Hab den Himmel also eher aus dem Bauchgefühl heraus eingefärbt. wink


4.) Kleines Problem mit dem Farbverlauf des Himmels:
Da der Farbverlauf des Himmels sehr fein ist, und das Auge mehr Blautöne unterscheiden kann als mit 24bit-Farbtiefe möglich ist, sieht man eventuell Abstufungen im Farbverlauf. Vor allem dann, wenn man einen Monitor hat, der nicht so viele Farben darstellen kann. Und auch auf Videos sieht man durch die Kompression dann deutliche Abstufungen bzw. Artefakte.
Wie ich das am besten wegbekomme, weiß ich noch nicht. Aber ich werde es mal mit Dithering probieren.


5.) Die Hügel im Vordergrund:
Momentan verwende ich für die großen Hügel im Vordergrund Texturen mit Alphakanal - damit der Übergang zum Horizont dahinter schön weich ist.
Allerdings sind so große Texturen mit Alphakanal nicht gerade optimal für die Framerate. Daher werde ich hier auch noch etwas optimieren. Die Hügel werden dann als normale Models modelliert, mit einer Textur OHNE Alphakanal. Und nur im schmalen oberen Bereich werde ich ein Model mit Alphakanal überlagern. Sodass der semi-transparente Bereich auf ein Minimum (also einen schmalen Streifen) reduziert wird.

Re: Fotorealistisches Mittelalter: neues Video [Re: Harry Potter] #414802
01/07/13 23:49
01/07/13 23:49
Joined: Jul 2001
Posts: 6,904
H
HeelX Offline
Senior Expert
HeelX  Offline
Senior Expert
H

Joined: Jul 2001
Posts: 6,904
Du hast das sehr gut dargelegt. Gefällt mir. Ich hätte Interesse an deiner Kacheltextur in einer handelsüblichen Größe smile

Das mit den Texturatlassen ist sehr ökonomisch. Ich bezweifle aber dass es deiner Performance zuträglich ist, wenn du solch große Texturen jedesmal die pipeline runterstopfst. Und: es muss garantiert sein, dass die meshes, die die Textur sharen, in genau einem Modell sind, ohne Gruppen (!).

Re: Fotorealistisches Mittelalter: neues Video [Re: HeelX] #414803
01/08/13 00:00
01/08/13 00:00
Joined: Sep 2003
Posts: 6,861
Kiel (Germany)
Superku Offline
Senior Expert
Superku  Offline
Senior Expert

Joined: Sep 2003
Posts: 6,861
Kiel (Germany)
Ich glaube, dass es nicht nur deutlich besser und vor allem dynamischer und abwechslungsreicher mit einer Vogelflugsimulation aussähe, sondern auch spürbar schneller wäre als mit einer Skin-Animation. Die Berechnung in einem Flocking-Algorithmus ist sehr einfach und besteht nur aus wenigen Vektorbefehlen, wenn es nicht zu viele Vögel werden ist auch der quadratische Rechenaufwand bei einer einfachen Implementierung bedeutungslos.


"Falls das Resultat nicht einfach nur dermassen gut aussieht, sollten Sie nochmal von vorn anfangen..." - Manual

Check out my new game: Pogostuck: Rage With Your Friends
Re: Fotorealistisches Mittelalter: neues Video [Re: HeelX] #414805
01/08/13 01:27
01/08/13 01:27
Joined: Dec 2002
Posts: 3,363
Vindobona (Ostarichi)
Harry Potter Offline OP
Expert
Harry Potter  Offline OP
Expert

Joined: Dec 2002
Posts: 3,363
Vindobona (Ostarichi)
Originally Posted By: HeelX
Ich hätte Interesse an deiner Kacheltextur in einer handelsüblichen Größe smile
Meinst Du die Rastertextur, die ich zum Überprüfen der Auflösung verwende?
Oder die gekachelte Textur vom Horizont und vom Himmel?
Falls Du die Textur mit dem Horizont meinst: willst Du lieber eine mit der Original-Landschaft (da sind dann auch moderne Häuser zu sehen).
Oder willst Du die überarbeitete "mittelalterliche" Variante? Die ist jedoch erst zu ca. 30% fertig. Nur im oberen Bereich, also nahe dem Horizont habe ich alles moderne entfernt. Den Bereich weiter vorne müsste ich noch überarbeiten.

Und was genau verstehst Du unter einer "handelsüblichen Größe"? wink

Re: Fotorealistisches Mittelalter: neues Video [Re: Harry Potter] #414810
01/08/13 09:54
01/08/13 09:54
Joined: Jul 2001
Posts: 6,904
H
HeelX Offline
Senior Expert
HeelX  Offline
Senior Expert
H

Joined: Jul 2001
Posts: 6,904
Originally Posted By: Harry Potter
Meinst Du die Rastertextur, die ich zum Überprüfen der Auflösung verwende? [...] Und was genau verstehst Du unter einer "handelsüblichen Größe"? wink


Genau die meine ich wink unter handelsüblich verstehe ich 512x512 oder 1024x1024.

Re: Fotorealistisches Mittelalter: neues Video [Re: HeelX] #414817
01/08/13 15:21
01/08/13 15:21
Joined: Dec 2002
Posts: 3,363
Vindobona (Ostarichi)
Harry Potter Offline OP
Expert
Harry Potter  Offline OP
Expert

Joined: Dec 2002
Posts: 3,363
Vindobona (Ostarichi)
Bitte sehr, hier ist die Rastertextur (Auflösung 1024 x 1024 Pixel):
Download Raster-Bitmap (ca. 3 MB)

Re: Fotorealistisches Mittelalter: neues Video [Re: Superku] #414824
01/08/13 16:02
01/08/13 16:02
Joined: Dec 2002
Posts: 3,363
Vindobona (Ostarichi)
Harry Potter Offline OP
Expert
Harry Potter  Offline OP
Expert

Joined: Dec 2002
Posts: 3,363
Vindobona (Ostarichi)
Originally Posted By: Superku
Ich glaube, dass es nicht nur deutlich besser und vor allem dynamischer und abwechslungsreicher mit einer Vogelflugsimulation aussähe, sondern auch spürbar schneller wäre als mit einer Skin-Animation.
Ich fürchte, dass Du das unterschätzen tust. wink
Der Flocking-Algorithmus ersetzt ja nicht die Skin-Animation (oder Animation des Flügelschlags eines 3D-Models). Die Animation des Vogels selbst (die Bewegung seiner Flügel) erstparst Du Dir ja damit nicht.
Noch dazu ist die Bewegung der Flügel ja auch abhängig von der Flugrichtung. Es reicht also nicht aus, die Flügel immer gleichmäßig zu bewegen. Du müsstest in Deinen Flocking-Algorithmus dann also auch einbauen, dass bei einem Kurswechsel die Flügel entsprechend anders bewegt werden. Eine Landung auf z.B. einem Baum (wie auf einem der Youtube-Videos oben zu sehen) ist mit einem Flocking-Algorithmus auch nicht möglich.

Also ich denke, dass eine vorberechnete Vertex-Animation da wesentlich schneller ist, als jede Art von Echtzeit-Berechnung. Und dass man dabei auch viel flexibler ist, und man auch so Dinge wie Landung und Abflug darstellen kann.

Für komplexe Bewegungsbahnen, wie z.B. vorberechnete Kameraflüge, oder eben jetzt auch Vogelflüge, verwende ich auch gerne UNSICHTBARE Hilfs-Models, die nur aus einem einzigen Polygon bestehen. Die Flugbewegung dieses Polygons berechne ich dann in Max (dort kann man schöne runde Flugbahnen definieren, und auch die Fluggeschwindigkeit beliebig anpassen).
Weil es nur ein einziges Polygon gibt (also 3 Vertices), verbraucht die Vertexanimation dann auch nur sehr wenig Speicher. Und zur Laufzeit hänge ich dann an eines der drei Vertices das eigentliche Objekt an, das sich bewegen soll (z.B. die Kamera, oder eben auch ein animiertes Sprite für den Vogel, das dann immer in Richtung Kamera ausgerichtet wird, während es der Flugbahn folgt).

Für die Ansteuerung des momentan abzuspielenden Frames der Skin/Sprite-Animation könnte man von dem unsichtbaren Bewegungs-Model den zweiten Vertex der drei Vertices zweckentfremden. Dessen Z-Koordinate könnte dann für jedes einzelne Animationsframe die Frame-Nummer der Skin-Animation hinterlegt haben.

Re: Fotorealistisches Mittelalter: neues Video [Re: Harry Potter] #414828
01/08/13 17:49
01/08/13 17:49
Joined: Sep 2003
Posts: 6,861
Kiel (Germany)
Superku Offline
Senior Expert
Superku  Offline
Senior Expert

Joined: Sep 2003
Posts: 6,861
Kiel (Germany)
Ich verbleibe leider skeptisch, lasse mich aber gern vom Gegenteil überzeugen. Landung auf einem Baum und sonstiges ist natürlich möglich, warum sollte es das nicht? Es geht beim Flocking nur darum, dass die nicht direkt in einander fliegen oder aber harmonisch ihre Runden drehen. Das System bzw. Prinzip ist übrigens nicht nur auf den Vogelflug beschränkt, sondern wirst du auch in Strategiespielen oder Pfadfindung allgemein antreffen, sogar später selbst benutzen müssen, wenn du mehr als einen NPC zu einem Zielort schicken willst. Die Programmierung ist leider, wie ich schon mehrfach sagte, etwas, was DU unterschätzen tust. wink Insbesondere bei den Dingen, die du dir vorgenommen hast. Es ist etwas anderes, ob man hier mal ein Skript dafür oder ein einfaches Movement-Skript zum Testen schreibt oder aber ein ganzes Spiel deiner Größenordnung programmiert, welches sich auch nicht ganz wie Murks steuert und spielt. Wenn du deinen Demolevel fertig hast, solltest du dich wirklich mal nach einem vorzugsweise festen Programmierer umgucken.


"Falls das Resultat nicht einfach nur dermassen gut aussieht, sollten Sie nochmal von vorn anfangen..." - Manual

Check out my new game: Pogostuck: Rage With Your Friends
Re: Fotorealistisches Mittelalter: neues Video [Re: Superku] #414839
01/08/13 21:39
01/08/13 21:39
Joined: Dec 2002
Posts: 3,363
Vindobona (Ostarichi)
Harry Potter Offline OP
Expert
Harry Potter  Offline OP
Expert

Joined: Dec 2002
Posts: 3,363
Vindobona (Ostarichi)
Originally Posted By: Superku
Landung auf einem Baum und sonstiges ist natürlich möglich, warum sollte es das nicht?
Versteh mich nicht falsch, natürlich ist es möglich, soetwas in ECHTZEIT zu BERECHNEN. Aber WOZU? Warum CPU-Ressourcen für etwas vergeuden, was nicht unbedingt notwendig ist?

Wie Du schon sagtest, beim Pathfinding macht soetwas durchaus Sinn. Ich bin mir auch ziemlich sicher, dass ich so einen (oder ähnlichen) Algorithmus verwenden werde, wenn ich z.B. eine große Anzahl von marschierenden Kriegern darstellen möchte. Aber bei Dingen, die nur schmückendes Beiwerk sind, wäre soetwas Verschwendung von Ressorcen. Ich könnte dann viel weniger marschierende Soldaten darstellen, nur weil gleichzeitig auch am Himmel Vögel herumfliegen. Eine Echtzeitsimulation muss auch wirklich SINN machen. Sie sollte nur dann angewendet werden, wenn es WIRKLICH NOTWENDIG ist, dass man etwas in Echtzeit berechnet.

Originally Posted By: Superku
Es geht beim Flocking nur darum, dass die nicht direkt in einander fliegen oder aber harmonisch ihre Runden drehen.
Vergleiche einfach mal unsere beiden Videos.
1.) Dieses hier mit dem Flocking-Algorithmus: http://www.red3d.com/cwr/boids/
2.) Und dieses hier von einem ECHTEN Vogelschwarm (bei 2:12 und bei 5:17 ist ein großer Schwarm zu sehen): http://www.youtube.com/watch?v=Hhxq0a0sJTY

Merkst Du den Unterschied? Der Flocking-Algorithmus ist alles andere als harmonisch. Die Flugobekte ruckeln dabei sehr mechanisch am Himmel herum, und man erkennt deutlich den Algorithmus der Annäherung. Echte Vögel hingegen fliegen viel rundere Flugbahnen und umkreisen sich eher gegenseitig als sich einem Parallelflug anzunähern.

Wie gesagt: für marschierende Soldaten ist der Algorithmus wahrscheinlich optimal. Aber nicht für einen Vogelflug.

Re: Fotorealistisches Mittelalter: neue Screenshots [Re: Harry Potter] #419064
03/05/13 17:37
03/05/13 17:37
Joined: Dec 2002
Posts: 3,363
Vindobona (Ostarichi)
Harry Potter Offline OP
Expert
Harry Potter  Offline OP
Expert

Joined: Dec 2002
Posts: 3,363
Vindobona (Ostarichi)
Seit Weihnachten bin ich leider mit meinem Projekt nicht viel weiter gekommen (weil ich seit 3 Monaten meine kranke Mutter pflegen muss, und, während sie im Spital lag, alles mögliche für sie erledigen musste. Meine Weihnachtsfeiertage hatte ich zum größten Teil im Krankenhaus verbracht. Dazu kam dann auch noch beruflicher Stress ab Februar).

Aber ein paar Kleinigkeiten habe ich dann doch machen können.
Und weil ich schon so lange nichts mehr hier gepostet habe, gibts davon jetzt wieder 3 Screenshots zu sehen. wink

a) Hier der erste Entwurf vom Tor auf dem Weg hinauf zur Abtei
(ist eigentlich schon ein älterer Screenshot, der noch vor Weihnachten entstanden ist):



b) Am Himmel fliegen jetzt schon die ersten Schwalben herum:



c) Und aktuell arbeite ich am 3-dimensionalen Seil für die Glocke.
Hier die ersten beiden Versuche (bin aber mit der Textur noch nicht so ganz zufrieden).
Da der Spieler an dem Seil ziehen wird können, muss es in Augenhöhe besonders detailiert sein.
Deshalb sind die einzelnen Seilstränge in Augenhöhe auch tatsächlich in 3D ausmodelliert.



Page 29 of 45 1 2 27 28 29 30 31 44 45

Gamestudio download | chip programmers | Zorro platform | shop | Data Protection Policy

oP group Germany GmbH | Birkenstr. 25-27 | 63549 Ronneburg / Germany | info (at) opgroup.de

Powered by UBB.threads™ PHP Forum Software 7.7.1