[Projekt] StoneQuest lebt noch!

Hier könnt ihr euch selbst, eure Homepage, euren Entwicklerstammtisch, Termine oder eure Projekte vorstellen.
Forumsregeln
Bitte Präfixe benutzen. Das Präfix "[Projekt]" bewirkt die Aufnahme von Bildern aus den Beiträgen des Themenerstellers in den Showroom. Alle Bilder aus dem Thema Showroom erscheinen ebenfalls im Showroom auf der Frontpage. Es werden nur Bilder berücksichtigt, die entweder mit dem attachement- oder dem img-BBCode im Beitrag angezeigt werden.

Die Bildersammelfunktion muss manuell ausgeführt werden, die URL dazu und weitere Details zum Showroom sind hier zu finden.

This forum is primarily intended for German-language video game developers. Please don't post promotional information targeted at end users.
Benutzeravatar
Zudomon
Establishment
Beiträge: 2253
Registriert: 25.03.2009, 07:20
Kontaktdaten:

Re: [Projekt] StoneQuest lebt noch!

Beitrag von Zudomon »

Also ich hätte eventuell die Möglichkeit dass man die Kanäle noch packt. Aber eventuell wäre ganz drauf verzichten auch kein Problem. Ich mach mal Vergleichsbilder, vielleicht kann man dann besser beurteilen:

Beim ersten Bild sind die Steine ziemlich Scharfkantig. Der Effekt bezieht sich letztendlich darauf, wie Stark die Normalmap an den Rändern weich ineinander übergeht.
20170622_3.jpg
Beim zweiten Bild ist der Putz ganz leicht schwächer abgerundet, die Steine mit dem gleichen Wert. So das dann eigentlich kein extra Parameter mehr gebraucht wird.
20170622_4.jpg
Das Erstellen der Texur läuft ja etwas so wie beim Deferred Rendering. Man hat quasi einen G-Buffer im Texturspace, wobei dann in diesem Fall ein ganzer Farbkanal dafür verbraten wird, dass für eckige Materialen und da auch nur für ganz Bestimmte und zudem nur an den Kanten, trotzdem an jedem Texel die Information steht, wie die Kante interpoliert werden soll. Hmmm... jetzt wo ich das so schreibe, kommt mir der Gedanke, wieso ich nicht per Patch einfach in einer Konstante übergebe, wie verfahren werden soll. Wenn das Materialabhängig ist, dann könnte ich ja sagen, scharfkantig. Ein andere Wert, bedeutet dann, z.B. die Höhenkarte als Weichheit zu interpolieren. Also in dem Sinne hätte man dann doch die Möglichkeit, das ganze aus anderen Werten aufzubauen. Könnte eine Lösung sein. Zumindest besser als so, wie ich es jetzt habe.
Benutzeravatar
marcgfx
Establishment
Beiträge: 2050
Registriert: 18.10.2010, 23:26

Re: [Projekt] StoneQuest lebt noch!

Beitrag von marcgfx »

Sieht beides gut aus. Hab es erst nach vielen Vergleichen überhaupt gesehen was anders ist. Scharfkantig ist schon etwas schöner, aber du musst abwägen wie gross die zusätzlichen Kosten an Performance/Aufwand dafür sind.
joeydee
Establishment
Beiträge: 1039
Registriert: 23.04.2003, 15:29
Kontaktdaten:

Re: [Projekt] StoneQuest lebt noch!

Beitrag von joeydee »

Dein letztes Bild:Top.
Im Zweifelsfall hätte ich wahrscheinlich sogar nur eine Übergangskonstante für das gesamte Objekt gesetzt (Fuge + Stein gleicher Übergang, ein Mittelwert). Wenn du das mit 2 Werten steuern kannst, umso besser. Pro Texel wäre wirklich unnötig.

Noch zur Ergänzung was ich meinte, bezogen auf dein altes Bild: Die Fraktalität der hinteren Kante (obere Markierung) gibt praktisch schon vor, wie stark die Überblendung aussehen müsste. Auf der vorderen Kante müssten daher mehr Bumps (und etwas größere) als der markierte auftauchen, um dem zu entsprechen (auch wenn es für "normale" Ziegel hinten etwas zu stark wäre). Vorne mit dem Lineal gezogen, hinten außer Rand und Band, das passte jedenfalls nicht zusammen. Die Fugen sahen hier mit dem Übergang dagegen schon super aus.
zudo01.jpg
Benutzeravatar
Zudomon
Establishment
Beiträge: 2253
Registriert: 25.03.2009, 07:20
Kontaktdaten:

Re: [Projekt] StoneQuest lebt noch!

Beitrag von Zudomon »

@marcgfx
Genau! Und ich befürchte, dass einem das Detail zwar auffällt, aber wieder nur, wenn man speziell überhaupt darauf hingewiesen wird. Vor allem, gibt es andere Stellen im Spiel (z.B. Weitsicht) was viel gravierender ist. Deswegen kam eben auch die Überlegung, das einfach raus zu schmeißen.

@joeydee
Letzteres Bild ist dann dieser Mittelwert. Ich hatte es pro Texel, weil eben die Fugen auf Texelebene definiert sind.
Und ja, ich hatte befürchtet, dass du das meinst, dass der Übergang wie mit dem Lineal gezogen aussieht. Da steckt glaub ich wieder der Teufel im Detail. Ich glaube, vom Prinzip her ist das ja an der Stelle gar nicht getrickst, das die Silhouette so uneben ist, aber aus einem bestimmten Winkel dann trotzdem so ein gerader Übergang zustande kommt. Ob es dafür ausreicht, nur die Bumpmap zu verstärken, weiß ich ehrlich gesagt gar nicht. Man müsste vielleicht die Vertices nicht nur in die Normalenrichtung (hier wird die gesmoothe Normale genommen, damit die Geometrie nicht zerreißt) verschieben, sondern dann an den Kanten auch in die Tangentialrichtungen. Aber diese Abweichung müsste dann auf Vertexebene statt finden, damit das "Lineal" nicht einfach nur verschoben wird.
Hier nochmal ein Bild, wo man etwas näher dran ist, und wo die Perspektive auch so gewählt ist, dass man nicht "exakt" auf die Kante schaut.

20170622_5.jpg
Benutzeravatar
marcgfx
Establishment
Beiträge: 2050
Registriert: 18.10.2010, 23:26

Re: [Projekt] StoneQuest lebt noch!

Beitrag von marcgfx »

Meine Meinung: Schmeiss es raus. Du weisst ja wie es wieder einzubauen wäre, wenn du irgendwann feststellt, dass du zu wenig Performance brauchst :D
Das was du hier betreibst ist ja extremes polishing, es wird nicht über Erfolg oder Misserfolg entscheiden (sagt einer der grad mal Multiplayer einbaut)
Benutzeravatar
Zudomon
Establishment
Beiträge: 2253
Registriert: 25.03.2009, 07:20
Kontaktdaten:

Re: [Projekt] StoneQuest lebt noch!

Beitrag von Zudomon »

Irgendwie sieht der Lighting Pass mit dem Displacement und dem Mikro AO der Texturen richtig krass aus :D
20170625_4.jpg
Specialist
Establishment
Beiträge: 135
Registriert: 29.08.2003, 14:22
Kontaktdaten:

Re: [Projekt] StoneQuest lebt noch!

Beitrag von Specialist »

So schön grau ;)

Sieht schick aus.
Allerdings finde ich immer noch, dass die Ziegelsteine zu weit hervorstehen.
So ungenau mauert niemand :)
Benutzeravatar
Zudomon
Establishment
Beiträge: 2253
Registriert: 25.03.2009, 07:20
Kontaktdaten:

Re: [Projekt] StoneQuest lebt noch!

Beitrag von Zudomon »

Specialist hat geschrieben:So ungenau mauert niemand
Vielleicht könnte man ja einbauen, dass man je nach skill mauern kann :D
Benutzeravatar
Zudomon
Establishment
Beiträge: 2253
Registriert: 25.03.2009, 07:20
Kontaktdaten:

Re: [Projekt] StoneQuest lebt noch!

Beitrag von Zudomon »

Immer noch am optimieren vom dem Texturerstellungsprozess. Habe nun auch die Pflastersteine und die Goldadern überarbeitet. Die waren noch langsam, weil sie das alte Verfahren genutzt haben.

Außerdem habe ich mir nun ein Material Zoo Level geschaffen, damit ich einen besseren Überblick über die Materialien habe.
20170630_1.jpg
20170630_2.jpg
Benutzeravatar
Jonathan
Establishment
Beiträge: 2352
Registriert: 04.08.2004, 20:06
Kontaktdaten:

Re: [Projekt] StoneQuest lebt noch!

Beitrag von Jonathan »

Mir gefällt die helle und freundliche Lichtstimmung sehr. Und die Materialien sehen auch top aus.
Einziger Kritikpunkt ist für mich das LoD. Im zweiten Bild sieht man das schön. Das Hauptproblem ist m.E.n. dass je schöner der Vordergrund aussieht, desto größer ist die Diskrepanz zum Hintergrund. Derzeit sieht halt das vordere Drittel geil, das mittlere Drittel langweilig und das hintere Drittel gruselig hässlich aus. Und solange es ein 'Freiluft-Spiel' ist, dominiert der Hintergrund halt irgendwie.

Hast du eigentlich einen Blog oder so? Du machst ja einige technisch recht beeindruckende Dinge, ich denke, du könntest eine gewisse Popularität erlangen, wenn du die irgendwo schön übersichtlich in Blog-Posts (vermutlich am besten in englisch) erklären würdest. Solche etwas außergewöhnlichen technischen Spielereien werden eigentlich immer gerne gelesen, insbesondere wenn sie gut aufbereitet sind.
Lieber dumm fragen, als dumm bleiben!
https://jonathank.de/games/
Benutzeravatar
Zudomon
Establishment
Beiträge: 2253
Registriert: 25.03.2009, 07:20
Kontaktdaten:

Re: [Projekt] StoneQuest lebt noch!

Beitrag von Zudomon »

Was das LOD angeht, da weiß ich aber auch überhaupt keine Lösung... es werden ja immer Blöcke betrachtet, ob diese gesetzt sind oder nicht.
Im Hintergrund wird dann nur noch jeder 2te, jeder 4te, jeder 8te Block betrachtet... und daraufhin entweder ein Block gesetzt oder nicht.
Das einzige, was ich bisher wüsste, um die Weitsicht zu verbessern, wäre auch im Hintergrund eben die Objekte zu generieren, das kommt ja später noch.

Einen Blog führe ich nicht. Mal abgesehen davon, dass ich die Details über diese "außergewöhnlichen technischen Spielereien" sowieso für mich behalten möchte, ist es mir viel zu aufwendig, da etwas "aufzubereiten".
Das einzige, was ich zur Zeit noch Pflege ist meine FB-Dev Seite, da poste ich eigentlich das gleiche wie hier, aber auf englisch.
https://www.facebook.com/Zudomon/
Wäre cool, wenn man das auch noch später irgendwie automatisieren könnte... weil auch das kostet immer ein wenig Zeit.
scheichs
Establishment
Beiträge: 845
Registriert: 28.07.2010, 20:18

Re: [Projekt] StoneQuest lebt noch!

Beitrag von scheichs »

Also die Materialien finde ich auch super.
Zum LOD: Ich weiss gar nicht ob das Problem die geringere Abtastung ist. Ich finde am "schlimmsten", dass die Vegetation schon sehr früh aufhört. Du hast doch LOD in den Pflanzen oder (meine ich mal in Deinen Settings-Vergleich Bildern gesehen zu haben)? Kostet es so viel das niedrigste LOD bis, sagen wir mal, etwa 100m zu ziehen?
Oder funktioniert die Vegetation nur auf höchster Block-Abtastung?

EDIT: Zum Grass: das müsste man mit steigender Distanz dann vermutlich etwas größer als in Wirklichkeit skalieren .
Benutzeravatar
Zudomon
Establishment
Beiträge: 2253
Registriert: 25.03.2009, 07:20
Kontaktdaten:

Re: [Projekt] StoneQuest lebt noch!

Beitrag von Zudomon »

scheichs hat geschrieben:Oder funktioniert die Vegetation nur auf höchster Block-Abtastung?
Genau das ist das Hauptproblem. Ich müsste die Items (Vegetation) auch schon in höheren Landschafts LOD's verteilen... aber auch dazu habe ich noch keine richtig gute Lösung.
scheichs hat geschrieben:EDIT: Zum Grass: das müsste man mit steigender Distanz dann vermutlich etwas größer als in Wirklichkeit skalieren .
Ja, man könnte da ja auch reguläre Gras Sprites nehmen.
Was noch ein größerer Brocken in der Richtung ist, dass dann auch die Vegetation, wie Klee, Blätter usw. auf Distanz in die Texturen bekommt. Es sind immer noch viele Probleme, die ich nicht wirklich zu lösen weiß.
20170630_3.jpg
DerAlbi
Establishment
Beiträge: 269
Registriert: 20.05.2011, 05:37

Re: [Projekt] StoneQuest lebt noch!

Beitrag von DerAlbi »

Kannst du nicht die LOD-Blöcke einzeln rendern?
Vielleicht kannst du einen Block mit vollen details in eine Textur rendern (aus der perspektive des Spielers). Das Renderergebnis wird dann die neue Grastextur oder so... für weit entfernte LOD-Blöcke sollte das klappen und es ist auch nur ein seltenes update der Blöcke nötig.... maximal 1 Block pro frame sollte ok sein. Das Texturupdate sollte aber per Alphablending zum letzten Zustand erfolgen sonst hat man kleine Sprünge, die durch die Landschaft wandern, wenn man sich bewegt.
Alternativ könnte man einen LOD-Block von oben gesehen mit einer Ortho-Matrix in eine Textur klatschen (ohne bäume) und das Renderergebnis als Grastextur für den Block benutzen. Das sollte wenigstens die Farbgebung und die Features der entfernten Geometrie aufrecht erhalten. Geht aber auch nur für Nicht-überhängende Landschaften, was bei dir also leider... hmmh :-(

Für mittlere Entfernungen habe ich leider auch erstmal keine Lösung. Ich denke aber, dass man die Lösung für entfernte Blöcke erstmal implementieren könnte und schaut, wie das überhaupt klappt. Ich weiß, dass ich das irgendwo schonmal geschrieben habe, du gesagt hast, dass du sowas ähnliches schon mal probiert hast und es nicht geklappt hat. Ich finde aber immer noch, dass alles besser ist als der jetzige Zustand.

Für die LOD-Block Texturen würde ich wie folgt vorgehen:
1) "BoundingRect" der porojizierten BoundingBoix des LOD-Blocks berechnen. Daraus bekommst du die nötige Texturgröße für den Block
2) In die Textur rendern.. mit vollem Detail und einer Projektionsmatrix deren projiziertes Frustum das "BoundingRect" abdeckt
3) Den LOD-Block im normalen Rendervorgang ohne alles Rendern (kein gras, keine Textur, nur einen LOD-Textur Index) - aber die verwendete Baumgeometrie sollte zumindest die Siluette der in 2) verwendeten Bäume enthalten.
4) Die Geometrie in einem Renderpass mit der entsprechenden Textur überziehen
5) 1-2 periodisch jeden Frame für einen Blocks ausführen um die Perspektive langsam zu aktualisieren. Eine Aus der anzahl der LOD-Blöcke ergibt sich eine Update-Frequenz.. ich denke das Überblenden zu einer aktualisierten Textur sollte etwa die hälfte der Update-Periodendauer dauern.

Vielleicht sollte man sowas mal ausführlicher diskutieren. Ich hab davon praktisch leider keine Ahnung :-(
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: [Projekt] StoneQuest lebt noch!

Beitrag von Krishty »

Das nennt man Impostor, und unter dem Stichwort gibt es auch massig Material dazu, das Zudo bestimmt schon kennt :)
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Zudomon
Establishment
Beiträge: 2253
Registriert: 25.03.2009, 07:20
Kontaktdaten:

Re: [Projekt] StoneQuest lebt noch!

Beitrag von Zudomon »

Diese Imposter Geschichte hatte ich ja lange für Objekte drin. Da wurden diese aus der Perspektive immer gerendert und dann nur bei Perspektivenwechsel geupdated. Damit das ganze auch bei Tag/Nacht wechsel klappt, habe ich die wie Deferred Rendering als Albedo und Normalen gerendert. Der Speicherbedarf war da aber schon recht hoch. Die Qualität war bei mittlere Texturenauflösung nicht wirklich schön.

Im Hintergrund sieht man die Imposter auf diesem alten Screen:
20130306_1.jpg


Aber das KO Kriterium war dann, als ich wieder die 3D Landschaft hatte und Schatten auf die Sprite Bäume fallen sollte. Also bräuchte ich da auch die Tiefe. Dazu kommt, wenn dann der Spritebaum auch irgendwie realistischen Schatten werfen sollte, dann müsste man den auch nochmal aus der Lichtperspektive rendern. Und da war das Problem für mich, denn diese Tiefe vernünftig mit den Sprites für die Selbstschattierung zu berechnen, fand ich so aufwendig, dass ich mir gedacht habe, wenn man ein sehr grobes LOD Objekt nehmen würde, dann könnte man davon auch tausende rendern und bräuchte dafür keinen Texturspeicher. Deswegen ist das Impostersystem dann raus geflogen.

Die Idee, die Landschaftsstücke als Imposter zu rendern, hatte ich damals schon, aber dann doch schnell verworfen, weil das sicherlich auffallen würde...
Aber das größte Problem an der ganzen Geschichte ist, dass ich eigentlich Daten darstellen möchte, ohne diese wirklich erfassen zu können. Also mit den Bäumen war ja schon ein Beispiel... die genauen Positionen kann ich erst in der höchsten Landschaftslod Stufe erfassen. Wenn ich Bauwerke auch im Hintergrund detailliert darstellen möchte, müsste ich zuvor alle Daten vom Server laden, um diese dann zu nutzen. Wenn ich die Vegetation in die Texturen baken möchte, dann muss ich auch diese vorher irgendwie dort erstellen. Dazu kommt noch, dass man, damit die Vegetation auch glaubwürdig aussieht, eigentlich auch Schatten und SSAO berechnen müsste... sieht man auf dem vorherigen Screenshot gut, wo man die Szene von oben sieht und der Schatten schon auf kurze Distanz deaktiviert wird.
Ich muss mir also überlegen, wie ich die Welt von oben herab generiere... also z.B. Baumkarten im groben erstellen und diese dann zum verteilen der Bäume nutzen, statt erst auf höchster LOD die Landschaft zu generieren. Vor allem kann ich das "detailliert betrachten" vergessen, weil ja im Vordergrund schon nicht so schnell ist, das höchste Detail zu erzeugen. Und auf Entfernung wächst das ja Exponential an.

Also prinzipiell ist deine (DerAlbi) Idee nicht schlecht. Aber ich glaube, mein eigentliches Problem liegt noch etwas daneben.

EDIT: Krishtys Beitrag war gerade noch nicht da ;)

EDIT2: Eigentlich finde ich das Imposter System geil, seit dem ich es das erste mal gesehen hatte. Damals bei Trespasser. Da konnten die dann schon 1998 ganze Städte rendern... die ganze Kirche ist dann auf einmal zu einem Sprite mutiert, die aus der richtigen Perspektive dargestellt wurde.
Zuletzt geändert von Zudomon am 01.07.2017, 00:59, insgesamt 1-mal geändert.
DerAlbi
Establishment
Beiträge: 269
Registriert: 20.05.2011, 05:37

Re: [Projekt] StoneQuest lebt noch!

Beitrag von DerAlbi »

Danke für den Namen Kirshty und danke für deine Erklärung Zudo :-)
Deine "Ausreden" ;-) klingen prinzipiell nach Problemen, die du so oder so irgendwann angreifen musst - klingt zumindest so. Es klingt für mich so als wärst du auf einer Konzeptfalle gelandet, die es dir nicht ermöglicht auf Distanz noch Qualität zu simulieren die du in der Nähe tatsächlich hast bzw einen konsistenten Übergang zu schaffen.. Das Problem daran ist, dass der kahle Hintergrund praktisch in jedem Screenshot auffällt - die Landschaft wirkt so halt irgendwie.. kA.. das ist immer meeeega schade und wird ja auch öfter schon erwähnt. Ich kann absolut nicht abschätzen, was nötig wäre aus dem Massel rauszukommen, hoffe für dich aber, dass du dich da irgendwann ransetzt. Ich denke allerdings, dass es besser früher als später geschieht, da das nach einer Menge redesign klingt.

Wenn das Nachladen der Daten z.B. für dich so ein Problem ist, dann solltest du die Imposter einfach nach und nach und gerne auch sichtbar langsam generieren. Ich denke da hat absolut niemand was dagegen, wenn sich das Detail langsam aufbaut... solange es dann irgendwann konsistent da ist wird das immer noch vielmals besser sein, als das, was jetzt gerade passiert. Große Engines machen das übrigens auch so: die laden das LOD von schlecht nach gut nach und nach wenn man in die Map spawnt. Das juckt niemanden.

Aber ich verstehe auch langsam die Probleme... wenn man nur LOD-Block für LOD-Block betrachtet wirft der Nachbar keinen Schatten auf den Block... man muss es irgendwie hinbekommen, dass da der Renderaufwand nicht ins unendliche steigt. Ich denke aber, dass auf die Entfernung eine art Shadow-Map ausreichen würde. Ich glaube auch, dass Gras nicht unbedingt einen Schatten braucht. Du brauchst eigentlich nur das statistische Wissen, wie Gras aufgrund des Eigenschattens sich in der Entfernung abdunkeln würde... Ich glaube egal wie wenig Effekte zu mit in die Imposter nimmst, alles sieht besser aus als diese Nacktheit im Hintergrund. Von daher würde ich mir über diese Details erst im nachhinein Gedanken machen.
Benutzeravatar
Zudomon
Establishment
Beiträge: 2253
Registriert: 25.03.2009, 07:20
Kontaktdaten:

Re: [Projekt] StoneQuest lebt noch!

Beitrag von Zudomon »

Da ist konzeptionell noch vieeeel viel mehr im argen... und da will ich mich auch erst langsam rantasten. Denn eins steht so langsam fest. Halb vernünftige Ideen bringen mir auf lange Sicht nicht viel. Deswegen drücke ich mich auch so lange noch vor.

Was du sagst, mit den einzelnen LOD Blöcken, genau das Problem habe ich schon beim AO. Denn wie soll ich AO generieren, wenn die Nachbarn mit reinspielen, aber noch nicht generiert sind. Ich denke, da muss ich nochmal die komplette Grunddatenstruktur ändern. Ich habe ja schon etwas Octree ähnliches, aber eher gefuckelt statt wasserdicht. Außerdem sind die 32³ für mich irgendwie zu langsam. Das generieren eines Chunks ist merklich langsam. Zum rendern ist es eigentlich ganz gut, aber zum generieren scheinen 16³ doch wesentlich praktischer zu sein. Aber bleiben wir mal bei der aktuellen 32³ Datenhaltung. Um normalen bzw. Nachbarn vernünftig zu generieren muss ich noch 1-3 Randvoxel betrachten. Nun liegt über diesen Chunks noch die Userdatenstruktur. Idealerweise auch in 32³ Chunks. Und nun kommt das große Problem... möchte ich einen (32+Saum)³ Chunk generieren, so muss ich bei den Daten auch die Nachbarn runterladen... also 3 x 3 x 3 = 27 Chunks! Speichere ich nun einen Saum mit in den Userdaten, muss ich aufpassen, dass es konsistent bleibt, es entstehen ja redundante Daten. Allerdings muss ich dann in Randbereichen auch entsprechend viele Chunks hochladen. Da habe ich auch noch gar nicht an LOD's gedacht. Ich möchte nur darauf hinaus, dass da noch viele ungelöste Probleme lauern.
Ein anderes Problem ist, dass ich fest auf die (abgerundeter) Block festgefahren bin. Da es alles Nurbs Flächen sind, kann ich schlecht noch andere Formen generieren. Z.B. nochmal halbhohe Platten oder Zylinder oder sowas wäre cool. Aber die bekomme ich dann schlecht mit der eigentlichen Struktur verbunden. Also alleine für das Displacementmapping ist es sehr wichtig, dass darunter eine gesmoothe Normale existiert. Angenommen es gäbe nur Flat-Normalen, dann würde bei einem Block jede Fläche in eine andere Richtung displaced und entsprechend würde die Struktur an den Kanten zerreißen.
Ich würde gerne noch wesentlich weiter kommen... aber so richtig effektiv ist das ganze irgendwie noch nicht. Vor allem arbeiten ja die meisten Spiele dieser Art heutzutage mit 3D Objekten, die man platziert. So habe ich mir das damals auch vorgestellt, weil ich mir dachte, Voxel, auch wenn sie winzig wären, sind nicht ideal. Sobald man ein Objekt drehen möchte, und diese aber auf dieses winzigen Einheitsvoxel abgebildet werden, wird es unschön. Zudem wären die Datenmengen einfach auch extrem groß. Daher besser Objekte platzieren.

Ne, ich darf da auch gar nicht so lange drüber nachdenken, sonst lande ich gleich wieder im Thread für Motivationsprobleme. Also lieber in kleinen Schritten das was ich habe verbessern und den Weg frei räumen, damit sich der Rest auch nach und nach herauskristallisiert.
Als nächstes würde ich gerne noch ein bisschen diese Texturengeschichte refaktorisieren und vielleicht hier und da verbessern. Und dann wäre schon cool, wenn ich die Texturen, die bereits für die Welt prozedural sind, nicht nur für die Welt, sondern auch für Objekte bzw. die Vorschau genutzt werden können. Denn dann könnte ich schon einige der ursprünglichen Materialtexturen raus schmeißen. Und dann muss ich noch die restlichen Materialtexturen prozeduralisieren. Und wenn dann das Internet ausfällt, dann kann ich SQ auf wenigen Disketten verteilen :D
Benutzeravatar
Zudomon
Establishment
Beiträge: 2253
Registriert: 25.03.2009, 07:20
Kontaktdaten:

Re: [Projekt] StoneQuest lebt noch!

Beitrag von Zudomon »

Übrigens spiele ich im Moment Ori and the Blind Forest, gibs noch günstig im Summer Sale von Steam. Ich liebe dieses bunte Licht, überhaupt die Stimmung und Musik. Bei Unreal 1 habe ich ja schon dieses "bunte" geliebt... ich würde das gerne bei mir so mit einfließen lassen. Aber da brauch ich auch noch ein bisschen mehr Skill, um das so künstlerisch hin zu bekommen.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: [Projekt] StoneQuest lebt noch!

Beitrag von Krishty »

Zudomon hat geschrieben:EDIT2: Eigentlich finde ich das Imposter System geil, seit dem ich es das erste mal gesehen hatte. Damals bei Trespasser. Da konnten die dann schon 1998 ganze Städte rendern... die ganze Kirche ist dann auf einmal zu einem Sprite mutiert, die aus der richtigen Perspektive dargestellt wurde.
Ich wollte erst schreiben, dass du das von Trespasser kennst (warst ja auch ein Fan von Fabien Sanglards Analyse des Quelltextes), war mir aber nicht mehr sicher genug. Gut, dass mich mein Gedächtnis nicht getrügt hat :)
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
joeydee
Establishment
Beiträge: 1039
Registriert: 23.04.2003, 15:29
Kontaktdaten:

Re: [Projekt] StoneQuest lebt noch!

Beitrag von joeydee »

Im Hintergrund wird dann nur noch jeder 2te, jeder 4te, jeder 8te Block betrachtet...
Dann dürftest du eben auch in der besten Stufe Bäume nur auf Basis der Informationen jedes 8ten Blocks setzen, Büsche auf Basis jedes 4ten usw. - nur so hättest du schnelle Entscheidungen bei unvolständiger Datenlage im Hintergrund, die aber mit denen des Vordergrunds zu 100% übereinstimmen.
3D-Mipmapping würde da noch bessere Dienste leisten als nur jeden x-ten Block isoliert zu betrachten, denn da gehen auch die Informationen der Nachbarblöcke mit ein.
Oder warst du da schon und es gab auch dagegen triftige Gründe?
Benutzeravatar
Zudomon
Establishment
Beiträge: 2253
Registriert: 25.03.2009, 07:20
Kontaktdaten:

Re: [Projekt] StoneQuest lebt noch!

Beitrag von Zudomon »

joeydee hat geschrieben:
Im Hintergrund wird dann nur noch jeder 2te, jeder 4te, jeder 8te Block betrachtet...
Dann dürftest du eben auch in der besten Stufe Bäume nur auf Basis der Informationen jedes 8ten Blocks setzen, Büsche auf Basis jedes 4ten usw. - nur so hättest du schnelle Entscheidungen bei unvolständiger Datenlage im Hintergrund, die aber mit denen des Vordergrunds zu 100% übereinstimmen.
3D-Mipmapping würde da noch bessere Dienste leisten als nur jeden x-ten Block isoliert zu betrachten, denn da gehen auch die Informationen der Nachbarblöcke mit ein.
Oder warst du da schon und es gab auch dagegen triftige Gründe?
Also was du sagst hatte ich auch als Notlösung ins Auge gefasst. Wäre natürlich irgendwie besser, wenn man die Verteilung nicht so grob quantisieren müsste. Aber was man macht, wenn z.B. ein Baum gefällt oder gepflanzt wird, ist mir auch ein Rätsel.
3D-Mipmapping würde wieder bedeuten, dass man erst detailliert betrachten muss, um dann wieder runter zu MipMappen, oder habe ich da einen Denkfehler?
Aber da ist auch schon das nächste Problem, wie werden die Chunks eigentlich auf dauer verwaltet? Momentan ja eigentlich gar nicht. Die werden aus dem Nichts generiert, Userdaten drüber, Items erstellt und fertig. EIGENTLICH sollte aber jeder Chunk aber auch igrendwie simuliert werden. Bäume/Pflanzen wachsen, einpflanzen, Tiere usw.
Da die Welt dann aber auch nicht wirklich begrenzt ist, eine Aufgabe, zu der ich auch noch keine Lösung habe.

Was ich mir wegen der Verteilung noch überlegt hatte, vielleicht eine grobe Verteilungskarte zu machen. Z.B. eine Baumkarte, die würde ja auch 2D reichen. Aber auch das sind eher noch grobe Überlegungen.

Konsistent wäre, wenn man tatsächlich ALLE Daten in der Welt vorliegen hätte.
Benutzeravatar
xq
Establishment
Beiträge: 1581
Registriert: 07.10.2012, 14:56
Alter Benutzername: MasterQ32
Echter Name: Felix Queißner
Wohnort: Stuttgart & Region
Kontaktdaten:

Re: [Projekt] StoneQuest lebt noch!

Beitrag von xq »

Zudomon hat geschrieben:Da die Welt dann aber auch nicht wirklich begrenzt ist, eine Aufgabe, zu der ich auch noch keine Lösung habe.
Das ist halt imho die Frage, ob das wirklich notwendig ist. Du könntest ja beispielsweise deine Spielwelt immer als Insel machen und man selbst ist schiffbrüchig. jaja, ich weiß, das ist jetzt kein neues Konzept, liefert aber einen guten Grund, warum deine Spielwelt begrenzt ist.

Mit einer beschränkten Spielwelt hättest du eben auch einige Vorteile wie eine bekannte Weltgröße und eine Welt, die du eben zu beginn komplett durchgenerieren und auch simulieren kannst
War mal MasterQ32, findet den Namen aber mittlerweile ziemlich albern…

Programmiert viel in ⚡️Zig⚡️ und nervt Leute damit.
Benutzeravatar
Zudomon
Establishment
Beiträge: 2253
Registriert: 25.03.2009, 07:20
Kontaktdaten:

Re: [Projekt] StoneQuest lebt noch!

Beitrag von Zudomon »

Die Spielwelt in der Fläche beschränken möchte ich eigentlich nicht.

Nun kann ich die Welttexturen auch anderweitig verwenden und mir somit die alten Texturen, die ich noch für die Blöcke nutzen musste, sparen. Damit sinkt der das ganze Projekt von 15 auf 11,5 MB. Ein KKrieger wird das nicht. Aber ich bin trotzdem schon sehr zufrieden damit! :D

Ansonsten hatte ich noch den Wind optimiert und ein paar Kleinigkeiten optimiert. Das Spiel sollte an sich doch nun auf jeden Fall noch etwas besser laufen.

Beim Refactoren der Materialen habe ich mir das alte Felsmaterial nochmal Spasseshalber aktiviert, bevor ich den Code dafür raus schmeißen wollte. Das Material läuft sowieso ziemlich langsam und bildet auch grobe Artefakte. Das blöde dabei war allerdings, dass mir das irgendwie doch sehr gut gefällt. Habs mir dann nochmal an verschiedenen Stellen angesehen und muss sagen, ja es wirkt nicht annähernd so einheitlich wie der aktuelle Fels. Wäre es jetzt irgendeine Textur, dann würde ich es einfach dabei belassen, damit ich weiter komme. Aber da konnte ich jetzt nicht. Der Fels macht ja viel vom Spiel aus. Also habe ich gestern nochmal Felsen gebaut und heute den ganzen Tag daran optimiert. Der läuft nun fast so schnell wie der aktuelle. Wobei auf dem aktuellen aber kein Moos generiert wird.
Es ist nicht perfekt. Also wenn man drauf achtet, dann wird man die "Schwächen" des Materials erkennen können. Aber es sieht an vielen Stellen doch schon schön felsig aus, dass es definitiv erstmal so bleibt.

PS: Ich will nur meinen Fortschritt zeigen. Also keine Felsenbilder ;) [/b]


Hier sieht man den bis gestern aktuellen Fels

20170706_1.jpg
Dagegen bot der alte doch wesentlich mehr Variation
20170706_2.jpg
Dies ist nun der neue Fels...
20170706_3.jpg
20170706_4.jpg
20170706_5.jpg
Zuletzt geändert von Zudomon am 11.07.2017, 02:54, insgesamt 2-mal geändert.
Benutzeravatar
Schrompf
Moderator
Beiträge: 4838
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: [Projekt] StoneQuest lebt noch!

Beitrag von Schrompf »

Der neue Fels rockt ganz gewaltig! Weitermachen :-)
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
xq
Establishment
Beiträge: 1581
Registriert: 07.10.2012, 14:56
Alter Benutzername: MasterQ32
Echter Name: Felix Queißner
Wohnort: Stuttgart & Region
Kontaktdaten:

Re: [Projekt] StoneQuest lebt noch!

Beitrag von xq »

Stimme Schrompf zu, das ist alles in Ter tat sehr felsig und lädt zum Klettern ein
War mal MasterQ32, findet den Namen aber mittlerweile ziemlich albern…

Programmiert viel in ⚡️Zig⚡️ und nervt Leute damit.
Benutzeravatar
Zudomon
Establishment
Beiträge: 2253
Registriert: 25.03.2009, 07:20
Kontaktdaten:

Re: [Projekt] StoneQuest lebt noch!

Beitrag von Zudomon »

Vielen Dank für das Lob!

Hier noch ein Screen, wenn man näher ran ist. Diese weißen Flecken sollen diese Quarz/Kristalleinschlüsse sein, keine Ahnung was das wirklich ist... aber ihr wisst ja sicher, was ich meine. Die treten verschieden stark auf, damit man etwas Abwechslung hat. Die "Risse" in den Steinen ergeben noch nicht immer sinn, steckt halt auch nur ein Noise für die Struktur. Überhaupt könnte man vielleicht noch bessere Form hinbekommen, aber wie gesagt, es reicht mir erstmal so.

20170706_6.jpg
Eventuell mache ich noch ein paar Farbvariationen rein, damit es auf der Makroebene noch Abwechlsungsreicher wird.
Ich habe auch mal vom Distanzbereich einen Screenshot bei High Einstellungen gemacht. Rechts ist es noch im Vordergrund. Links ist es dann schon so weit weg, dass da keine Normalmap mehr generiert wird. Da müsste man auch mal schauen, ob sich das in Zukunft noch ändert.
Dieser weiße Fleck da in der Mitte ist ein Stück "Goldader". Da muss ich wohl auch nochmal ran. Da könnte man dann auch gleich mal ein paar andere Erze machen. Ich habe richtig viel Lust neuen Content da mit rein zu bringen und es mal mehr zu einem Spiel werden lassen :D
20170706_7.jpg


Aber ich denke, statt jetzt noch Zeit in den Fels zu hauen, lieber auch die Holzmaterialen und die anderen prozeduralisieren.
Zuletzt geändert von Zudomon am 11.07.2017, 02:47, insgesamt 1-mal geändert.
Benutzeravatar
Zudomon
Establishment
Beiträge: 2253
Registriert: 25.03.2009, 07:20
Kontaktdaten:

Re: [Projekt] StoneQuest lebt noch!

Beitrag von Zudomon »

  • Nun ist es möglich, zwischen dem globalen Level und dem Material Zoo Level zu wählen
  • Die Glühwürmchen wurden repariert und haben bei der Gelegenheit noch ein bisschen Glow rings rum verpasst bekommen
  • Es ist nun möglich, Tooltipps für die Menüpunkte zu setzen. Auf dem Screenshot ist der Cursor nicht mit drauf. Aber das "YouTube" stellt diesen Tooltipp da.
20170707_5.jpg
Zuletzt geändert von Zudomon am 11.07.2017, 02:47, insgesamt 1-mal geändert.
Benutzeravatar
marcgfx
Establishment
Beiträge: 2050
Registriert: 18.10.2010, 23:26

Re: [Projekt] StoneQuest lebt noch!

Beitrag von marcgfx »

Ich habe richtig viel Lust neuen Content da mit rein zu bringen und es mal mehr zu einem Spiel werden lassen :D
Das hör ich echte gerne :)

Weitermachen Zudo, sieht super aus!
Benutzeravatar
Zudomon
Establishment
Beiträge: 2253
Registriert: 25.03.2009, 07:20
Kontaktdaten:

Re: [Projekt] StoneQuest lebt noch!

Beitrag von Zudomon »

So, ich denke, der Fels ist nun erstmal gut so.
Da fehlten tatsächlich noch Farben.
Das Moos ist nochmal überarbeitet und die Quartzadern besser gesetzt und überarbeitet.

Hier noch ein paar Impressionen... (auf maximalen Einstellungen) :o

20170708_14.jpg
20170708_15.jpg
20170708_17.jpg
20170708_18.jpg
20170708_19.jpg
Zuletzt geändert von Zudomon am 11.07.2017, 02:47, insgesamt 1-mal geändert.
Antworten