Descentforum.DE Foren-Übersicht Descentforum.DE
Suchen | FAQ | Mitgliederliste | Benutzergruppen | Newsfeed Newsfeed  Registrieren
Profil | Einloggen, um private Nachrichten zu lesen | Login 
Chat | D3-Taktik | Downloads | Karte | Links | Serverliste | Teamspeak 

Frage zu neuem Level-Format
Gehe zu Seite 1, 2, 3, 4  Weiter
 
Neues Thema eröffnen   Neue Antwort erstellen    Descentforum.DE Foren-Übersicht -> Level-, Design und Entwicklungs - Forum
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen  
Autor Nachricht
King Lo
Forum-Nutzer


Anmeldungsdatum: 14.03.2006
Beiträge: 320
Wohnort: Stuttgart, BW

BeitragVerfasst am: 09.04.2009, 00:07    Titel: Frage zu neuem Level-Format Antworten mit Zitat

Hi,

wie bereits bekanntgegeben im englischen Subforum wollen wir (ODF) das D3L-Format in unser eigenes Format konvertieren, welches momentan noch im Aufbau ist. Anschließend rendern wir es mit der Irrlicht-Engine. Bisher lief alles gut beim Exportieren eines Raums.

Die Frage ist nun: Wie sollen wir vorgehen, um mehrere Räume im Format abzuspeichern?
A,) alle Verts, Faces etc. pro Raum einzeln fassen, so dass im Levelformat bekannt ist, wo ein neuer Raum anfängt
B.) Räume nicht beachten, der ganze Level ist ein Raum (ich tendiere hierzu...)

Klar ist mir, dass D3 die Methode A verwendet. Wahrscheinlich, weil es Vorteile fürs Portal Rendering bringt. Aber welche Vorteile würde es sonst noch bringen?

Ich denke nicht, dass wir Portal Rendering nutzen werden (ich weiß nicht mal, ob Irrlicht das kann); das machen auch die meisten BSP-Renderer nicht so.

Bin für jeden Beitrag dankbar!
Lo
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Atan
Moderator


Anmeldungsdatum: 27.07.2001
Beiträge: 876

BeitragVerfasst am: 09.04.2009, 18:03    Titel: Antworten mit Zitat

Ich kenne Irrlicht leider nicht, kann also auch nicht beurteilen welche Variante da nun besser wäre.

Es war (?) wohl 'damals' besser die Räume nachladbar zu haben um nicht den gesamten Rechner auf Schlag speichermäßig vollzuhauen.
Evtl. brauchte die Graka ja auch noch Systemspeicher. So blieben noch Kapazitäten für die eigentliche Berechnungen, Steuerung usw über.
Und nur so viel wird dann berechnet werden müssen was man auch 'sehen' kann. Begrenzt also auf vorgegebene Portaltiefe.
Wie gesagt ob das bei heutigen Verhältnissen überhaupt noch relevant ist sei ne andere Frage.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Marix
Forum-Nutzer


Anmeldungsdatum: 30.05.2001
Beiträge: 980
Wohnort: Germany

BeitragVerfasst am: 09.04.2009, 22:11    Titel: Antworten mit Zitat

Prinzipiell ist eine Levelgeometriemäßige unterteilung immer Sinnvoll! Nicht nur benötigt man zum Rendern weniger Resourcen, auch Wegfindung, Kollisionserkennung usw. können einige Abkürzungen nehmen. Ohne eine solche Unterteilung muss immer der ganze Level berechnet und gerendert werden. Hierzu kann man BSP-Bäume oder Räume verwenden. Räume können aber AFAIK an sich eine ganz gute Grundlage für einen guten BSP-Baum bilden. Im schlimmsten Fall ist der BSP-Baum nämlich so schlecht geschnitten, dass man immer alle Blätter des Baumes in Sicht-/Reichweite hat, dann bringt er nichts. In Urban Terror kann man das gut sehen. Bei Descent gibt es das Problem in "Ein-Raum-Leveln" (Halcyon?) auch, aber hier ist eine Unterteilung bei der man nur relevante Teile des Levels sieht deutlich intuitiver.
_________________
„Der einzige Weg, die Grenzen des Möglichen zu finden, ist ein klein wenig über diese hinaus in das Unmögliche vorzustoßen.“
--Arthur C. Clarke
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Tebo
Forum-Nutzer


Anmeldungsdatum: 15.07.2005
Beiträge: 21
Wohnort: Schweiz

BeitragVerfasst am: 10.04.2009, 14:09    Titel: Antworten mit Zitat

Es hat seine Vorteile zwischen Energiezentren, Flagenräumen etc. unterscheiden zu können.
Mindestens die Portale der entsprechenden Räume müssten also gespeichert werden.

D3 braucht die Raumunterteilung auch damit im Multiplayer nicht die Positionsdaten aller Spieler an alle geschickt werden müssen.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Thomas
Forum-Nutzer


Anmeldungsdatum: 07.02.2008
Beiträge: 226

BeitragVerfasst am: 11.04.2009, 02:14    Titel: Antworten mit Zitat

Ich find's ein bisschen lächerlich, hier Fragen zu stellen, von denen eigentlich jedem Erwachsenen klar sein sollte, daß sie keinen realen Hintergrund haben.

Vergiß Irrllicht, und vergiß die Frage der Raum-Organisation. Die Man-Power, die dazu nötig ist, um das auf die Reihe zu bekommen, kommt garantiert nicht aus einer ODF-Ecke.

Tschuldigung, aber es sieht so aus, als mußte das mal Einer klarlegen.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Zorc
Forum-Nutzer


Anmeldungsdatum: 05.07.2001
Beiträge: 922
Wohnort: Ratzeburg

BeitragVerfasst am: 11.04.2009, 11:45    Titel: Antworten mit Zitat

Nee, Mann, nee.
Muß man nicht. Kann man machen. Sagt auch eine Menge über einen selbst aus, wenn man's denn tut. Aber müssen muss man nicht.

@ Lo & Cent: ich weiss, dass Ihr Euch nicht entmutigen lasst.
Meine Anerkennung und meinen Respekt für das bereits Geleistete.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Thomas
Forum-Nutzer


Anmeldungsdatum: 07.02.2008
Beiträge: 226

BeitragVerfasst am: 11.04.2009, 12:36    Titel: Antworten mit Zitat

Ich möchte Niemanden entmutigen, sondern nur auf den Boden der Tatsachen zurückholen.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
D.Cent
Forum-Nutzer


Anmeldungsdatum: 05.03.2006
Beiträge: 493
Wohnort: Spalt

BeitragVerfasst am: 11.04.2009, 13:10    Titel: Antworten mit Zitat

Thomas hat folgendes geschrieben:
Tschuldigung, aber es sieht so aus, als mußte das mal Einer klarlegen.


Es gab dazu schon eine Menge Auseinandersetzungen - und Du bist nicht der erste, der das Projekt anzweifelt.
Aber was soll's - wir versuchen's. Und solange uns dabei nicht langweilig wird, arbeiten wir weiter.
Bitte für weitere Fragen/Anregungen/Aussagen nicht dieses Thema benutzen.

Back to topic:

Atan und Marix haben da schon recht - für ältere Maschinen wäre das Splitten in Räume wohl besser, auch wenn das Format dadurch ein wenig komplizierter werden würde.
Als Test habe ich mal einen großen Raum geladen und danach 2 kleinere Räume, die den Maßen des großen etwa entsprechen. Das Ergebnis: mehr FPS bei den 2 kleineren Räumen!

Also denke ich mal, dass das Format letztendlich in Räume unterteilt werden wird.


Zuletzt bearbeitet von D.Cent am 11.04.2009, 17:27, insgesamt 2-mal bearbeitet
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
zico
Rebirther


Anmeldungsdatum: 23.11.2005
Beiträge: 452
Wohnort: Ebersbach

BeitragVerfasst am: 11.04.2009, 13:26    Titel: Antworten mit Zitat

<Sarkasmus>

Ja ich muss Thomas jetzt mal voll Recht geben und so voll so....
Was BILDET ihr euch eigentlich ein zu denken aus eigenem Antrieb irgendwas produktives zu erschaffen??? Wo kämen wir denn da hin?
Wenn das funktionieren würde hätte heute vielleicht sogar Jemand ein vollkommen freies OpenSource Betriebssystem geschrieben.
Oder es gäbe vllt. Neuauflagen von Descent 1 und 2.
Gibts das? Natürlich nicht. Und warum? Natürlich weil Niemand sowas kann. Wir sind alle viel zu doof für solche Sachen.

Ich meine, in was für einer Welt würden wir heute leben wenn Menschen plötzlich einfach so anfangen würden selbst zu Denken und etwas mit anderen auf die Beine zu stellen.. Total lächerlich, oder?

</Sarkasmus>

Geschockt Geschockt Lachen

_________________
http://www.dxx-rebirth.com
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
King Lo
Forum-Nutzer


Anmeldungsdatum: 14.03.2006
Beiträge: 320
Wohnort: Stuttgart, BW

BeitragVerfasst am: 11.04.2009, 13:45    Titel: Antworten mit Zitat

Um dieses OT-Thema zu beenden:
Wir haben auch nix von dem Streit. Ich mache jedem das Angebot die alten Streitereien zu begraben.
Wenn wir so etwas entwickeln wollen sind wir auf die Hilfe und Erfahrung von jedem angewiesen.
Danke auch Atan, dass Du - trotzt alter Streitereien - überhaupt geantwortet hast. Danke zico.

Und ich halte dieses Thema für einen wichtigen Thread, sonst hätte ich ihn nicht gepostet.
Ich möchte nicht, dass man mich grundlos provoziert und dabei den halben Thread OT macht!
Thomas, wenn Du Probleme hast, dann mach einen neuen Thread auf.

--

Scheinbar kann Irrlicht Portal Rendering. Ich frage mich nur, ob es sich
- vor allem für die ganzen Multiplayer-Missions, die keine Türen haben - den Aufwand lohnt?
Nicht nur bei Halcyon, auch bei Ascent würde das doch nichts bringen? (weil keine Türen)

Tebo hat folgendes geschrieben:
Es hat seine Vorteile zwischen Energiezentren, Flagenräumen etc. unterscheiden zu können.

Das ist ein gutes Argument. Ich glaube das wird der Grund dafür sein, dass wir nicht um Raumnummerierung rum kommen... Winken
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Atan
Moderator


Anmeldungsdatum: 27.07.2001
Beiträge: 876

BeitragVerfasst am: 11.04.2009, 14:14    Titel: Antworten mit Zitat

Zitat:
Missions, die keine Türen haben - den Aufwand lohnt

Aufpassen, hier geht es bei den Portalen nicht um Türen!!
Der Grund das MP-mäßig in D3 kaum Türen vorhanden sind ist eher ein anderer.
Im Gegensatz zu D1/D2 sind die Türen in D3 laggy, stören das Spiel. Im SP ist das kein Problem, in MP schon.
Portale sind eher als Grenzen zu verstehen, sie grenzen Bereiche ein fürs Rendern, Sound!, werden benutzt um zu Triggern, um Lichtflackern, Schaden, Nebel etc auf einen Raum zu begrenzen und einiges mehr. Denk auch an Entropy oder andere Mods, die brauchen Räume, und die Nahtstelle zwischen diesen Räumen sind die Portale. Ansonsten müsste man Bereiche definieren, sprich viele Faces checken die zu einem Bereich (Raum) gehören um zu wissen ob man sich noch in einen Raum aufhält. Durch die Portale gelingt das durch Prüfen einiger weniger Portalfaces.

und OT
KL, DC, ich denke nicht das Thomas das wirklich böse gemeint hat, bzw rumstreiten will. Er sieht es halt aus seiner Sicht des Berufsprogrammieres, da gelten halt andere Gesetzmäßigkeiten...
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Munk
Forum-Nutzer


Anmeldungsdatum: 30.06.2001
Beiträge: 2070
Wohnort: Basel

BeitragVerfasst am: 12.04.2009, 01:21    Titel: Antworten mit Zitat

Atan hat folgendes geschrieben:
Ansonsten müsste man Bereiche definieren, sprich viele Faces checken die zu einem Bereich (Raum) gehören um zu wissen ob man sich noch in einen Raum aufhält. Durch die Portale gelingt das durch Prüfen einiger weniger Portalfaces.


Nicht zu vergessen gehört zu einem Raum auch ein "Volumen". Das definiert sich eindeutig nur durch eine abgeschlossene Menge von Faces.

D1 und D2 waren das eine Extrem, indem jeder Cube ein eigener Raum mit genau 6 Faces war, und der gesamte Level von Portalen durchzogen war.

Das andere Extrem, daß der gesamte Level ein einziger Raum darstellen soll, ist wohl möglich - aber vermutlich nicht sehr flexibel.
Allein schon aus organisatorischer Sicht ist das quatsch: Zur Kollisionserkennung mit Faces will man sowenig Faces wie möglich testen, da macht es Sinn nur die Faces des eigenen Raums zu testen.

_________________
Da Munk is da Munk
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden
Marix
Forum-Nutzer


Anmeldungsdatum: 30.05.2001
Beiträge: 980
Wohnort: Germany

BeitragVerfasst am: 12.04.2009, 13:14    Titel: Antworten mit Zitat

D.Cent hat folgendes geschrieben:

Atan und Marix haben da schon recht - für ältere Maschinen wäre das Splitten in Räume wohl besser, auch wenn das Format dadurch ein wenig komplizierter werden würde.


Nicht nur auf älteren Maschienen. Die Frage ist ja, wie viel Resourcen du für unnötige Berechnungen verschwenden möchtest. Wenn ich schon eine Rakete habe, dann will ich mit der auch fliegen, und nicht nur Rauch produzieren.

_________________
„Der einzige Weg, die Grenzen des Möglichen zu finden, ist ein klein wenig über diese hinaus in das Unmögliche vorzustoßen.“
--Arthur C. Clarke
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Thomas
Forum-Nutzer


Anmeldungsdatum: 07.02.2008
Beiträge: 226

BeitragVerfasst am: 12.04.2009, 16:14    Titel: Antworten mit Zitat

King Lo hat folgendes geschrieben:
Wir haben auch nix von dem Streit.

Leute, das ist ja ganz schön ausgeartet hier. War nicht meine Absicht. Hat doch Keiner von Streit gesprochen.

OT oder nicht OT vermag ich nicht zu beurteilen, aber geh mal das Szenario real durch. Du möchtest ein 3-D-Spiel ähnlich D3 erstellen und bist dir noch nicht im Klaren, welches Format die Maps haben könnten. Da du das Format mit einer anderen Engine lesen mußt, dürfte es doch wohl selbstverständlich sein, daß die Ziel-Engine die Vorgaben macht.

Das ist aber nur einer der Punkte, warum ich glaube, daß das Projekt nicht das ergeben wird, was ihr euch erhofft.

Sicherlich kommt aber jede Menge Erfahrung dabei raus.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Munk
Forum-Nutzer


Anmeldungsdatum: 30.06.2001
Beiträge: 2070
Wohnort: Basel

BeitragVerfasst am: 13.04.2009, 19:03    Titel: Antworten mit Zitat

Thomas hat folgendes geschrieben:

Sicherlich kommt aber jede Menge Erfahrung dabei raus.


Daran besteht absolut kein Zweifel - und schon deswegen lohnt sich damit überhaupt weiterzumachen.
Nur Ergebnisse versprechen sollte man in solch einem unüberschaubaren Zeitrahmen (bis zur Fertigstellung) nicht.

_________________
Da Munk is da Munk
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden
King Lo
Forum-Nutzer


Anmeldungsdatum: 14.03.2006
Beiträge: 320
Wohnort: Stuttgart, BW

BeitragVerfasst am: 17.04.2009, 13:41    Titel: Antworten mit Zitat

Back To Topic:

Wir haben mittlerweile einen Exporter, der uns die Texturen extrahiert und konvertiert und der Loader lädt sie mit entsprechenden Textur-Koordinaten (UV) an die richtigen Faces.

Mit einigen Leveln/Texturen klappt es vollkommen korrekt, leider bei einigen anderen nicht. Zum Beispiel ist der Fußboden bei Ascent total gedehnt.

Wir vermuten, dass da noch irgendein Faktor (zwischen 16 und 32) im Levelformat steht. Der könnte Textur-abhängig sein. Wir wissen, was MipMaps sind, aber damit hat es scheinbar nix zu tun. Ist Euch irgend so ein Faktor bekannt? Wenn wir die Texturkoordinaten mit einem (differierenden) Faktor multiplizieren, sieht es besser aus.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Atan
Moderator


Anmeldungsdatum: 27.07.2001
Beiträge: 876

BeitragVerfasst am: 17.04.2009, 17:10    Titel: Antworten mit Zitat

Evtl. hilft das ja weiter:
Code:
'Normal' texture = 128x128

#define NORMAL_TEXTURE     1     // a normal size texture
#define SMALL_TEXTURE      2     // 1/4 of a normal texture
#define TINY_TEXTURE       3     // 1/8 of a normal texture
#define HUGE_TEXTURE       4     // Double the size of a normal texture
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Tebo
Forum-Nutzer


Anmeldungsdatum: 15.07.2005
Beiträge: 21
Wohnort: Schweiz

BeitragVerfasst am: 17.04.2009, 18:02    Titel: Antworten mit Zitat

Mir ist bis jetzt kein solcher Faktor bekannt.
Ich habe mir gerade room_data.cpp angeschaut, die folgende Zeile könnte allerdings andere Fehler verursachen:

Code:
normal = get_normal_of_3_verts(parent->verts[verts[0]], parent->verts[verts[1]], parent->verts[verts[2]]);


Wenn die drei Vertices auf einer Linie liegen, was zum Teil vorkommt, bekommt man so einen Nullvektor.
In diesem Fall müssten andere Vertices gewählt werden.
Ausserdem ist mir aufgefallen, dass die Normale nicht normiert wird, dass könnte später beim Lighting stören.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
King Lo
Forum-Nutzer


Anmeldungsdatum: 14.03.2006
Beiträge: 320
Wohnort: Stuttgart, BW

BeitragVerfasst am: 17.04.2009, 19:49    Titel: Antworten mit Zitat

@Atan: Das scheint's leider nicht zu sein. Wir haben richtig und falsch aufgespannte Texturen verglichen, aber viele von denen haben in den genannten Flags die gleichen Werte (zum Vergleich: ShinyGridS, welche problemlos anzuzeigen war, und Grey Pipes, welche total gestreckt war).

Bilder (siehe unten) haben wir von Ascent und Big Packet (ein kleiner Testlevel von D.Cent) gemacht.

Bei Big Packet kommen insgesamt nur 2 Texturen vor: ShinyGridS und BlueBase, welche beide korrekt dargestellt werden.
Bei Ascent allerdings wird keine einzige Textur normal dargestellt.

@Tebo: Wir splitten die Polygone nur in Dreiecke auf. Dadurch ändert sich nichts an dem Normalen.

Bilder
====

Big Packet: http://intelcentino.in.funpic.de/upload/big_packet.png
Ascent: http://intelcentino.in.funpic.de/upload/ascent.png
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Atan
Moderator


Anmeldungsdatum: 27.07.2001
Beiträge: 876

BeitragVerfasst am: 17.04.2009, 21:08    Titel: Antworten mit Zitat

Seid ihr wirklich sicher das es ein Problem der Texture ist?
Die Frage ist, ob ihr in Ascent mal die Texturen vom Big Paket auf ein ('Fußboden') Face gepackt habt und wie es danach dann exportiert und wieder geladen aussieht. Immer noch gedehnt oder passt es dann. Wenn es passt liegt es wohl echt an der Texture, ist es immer noch gedehnt, ist es halt was anderes Smilie
Falls es nicht zu klären ist, könnt ihr mir dann bitte mal weiterhelfen und mir sagen welchen Raum (Nr) in Ascent das Bild zeigt?
Und falls möglich hätte ich dann auch gerne mal den Big Packet Raum (orf). Vielleicht kann ich ja einen Hinweis finden wo der Unterschied ist.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Beiträge der letzten Zeit anzeigen:   
Neues Thema eröffnen   Neue Antwort erstellen    Descentforum.DE Foren-Übersicht -> Level-, Design und Entwicklungs - Forum Alle Zeiten sind GMT + 2 Stunden
Gehe zu Seite 1, 2, 3, 4  Weiter
Seite 1 von 4

 
Gehe zu:  
Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
Du kannst Dateien in diesem Forum posten
Du kannst Dateien in diesem Forum herunterladen


Descent is a trademark of Interplay Productions.
Descent, Descent II are © Parallax Software Corporation.
Descent III is © Outrage Entertainment.
Descentforum.DE and Descentforum.NET is © by Martin "Do_Checkor" Timmermann.
Powered by phpBB © 2001-2008 phpBB Group