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 Zurück  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: 17.04.2009, 22:06    Titel: Antworten mit Zitat

Danke für Deine schnelle Hilfe!
Der Ascent-Raum hat die Nummer 0. Big Packet findest Du hier: http://intelcentino.in.funpic.de/upload/big_packet.zip

Wir haben den Boden jetzt mit ShinyGridS textuiert:
- einmal mit D3Edita, da war wieder alles viel zu stark gestreckt.
- einmal haben wir nur die face-namen im mesh durch das Funktionierende ersetzt (d.h. gleiche UV-Textkoordinaten), da war wieder alles viel zu stark gestreckt.

Mich wundert am meisten, dass die UV-Textkoordinaten in Ascent alle kleiner als 1 sind. Das hieße ja, keine Textur wird ganz dargestellt.... ?! (In Big Packet sind sie zwischen 1 und 9)
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Atan
Moderator


Anmeldungsdatum: 27.07.2001
Beiträge: 876

BeitragVerfasst am: 17.04.2009, 23:52    Titel: Antworten mit Zitat

Ich musste mir auf die Schnelle eine kleine Erweiterung schreiben die mir die Vert Tex UV's anzeigt.
Ich habe dann den Ascent Room 0, Face 33 für den Test genommen.
Zuerst noch der Hinweis das die U/V's alle floats sind.
Von 0.0 (0) bis 1.0 (100%). Werte > 1.0 wie zB. 1.75 entsprechen dann 0.75 (75%) usw. Aber das denke ich mal ist Euch soweit alles bekannt.

Evtl. vergleicht ihr diese Werte mal mit den Werten die ihr ermittelt habt und verarbeitet.
Ich musste das alles, wie schon gesagt, in Eile machen und hoffentlich habe ich dabei keinen Übertragungsgfehler gemacht.

HIer also die 9 Verts von R0/F33

Vert 0
U= 1.05
V= 0.00

Vert 1
U= 2.30
V= 0.00

Vert 2
U= 2.30
V= 3.75

Vert 3
U= 2.30
V= 4.50

Vert 4
U= 1.80
V= 5.00

Vert 5
U= 0.00
V= 5.00

Vert 6
U= 0.00
V= 2.20

Vert 7
U= 0.00
V= 0.70

Vert 8
U= 0.30
V= 0.50
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
King Lo
Forum-Nutzer


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

BeitragVerfasst am: 18.04.2009, 11:15    Titel: Antworten mit Zitat

OK, dann haben wir wohl eienn kleinen Fehler beim Auslesen gemacht. Wir haben den Ascent-Reaum mal als einzelnen Level gespeichert und da gings dann (siehe Bild unten). Wundert mich eigentlich, da ja die uvls-Koordinaten pro Raum abgespeichert werden - aber da liegt wohl der Fehler. Denn wir hatten nur Werte zwischen 0 und 1 bei mehreren Räumen.

Hier ist nun ein Screenshot, wo es funktioniert: Smilie

Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Atan
Moderator


Anmeldungsdatum: 27.07.2001
Beiträge: 876

BeitragVerfasst am: 18.04.2009, 14:24    Titel: Antworten mit Zitat

das sieht doch schon mal gut aus.

Zitat:
mal als einzelnen Level gespeichert

Also als Ein-Raum-Level und dann gings, Mehr-Raum-Level machen noch Probleme?
Ich vermute das ihr dann die Strukturen noch nicht ganz genau erfasst habt. Dafür spricht auch:
Zitat:
da ja die uvls-Koordinaten pro Raum abgespeichert werden

Die heissen zwar roomUVL aber die uvls werden in der face struct pro vert gespeichert. Evtl. ist es ja überflüssig hier rum zu texten und ihr wisst das alles schon, aber hier lieber doch nochmal ein grober Überblick:

Es sieht in etwa so aus:
Ein Level besteht aus: Rooms[MAX_ROOMS] (hier werden aber nur so viele Räume wie im Level tatsächlich enthalten sind verwendet)

Ein Room selber ist dann: room = Rooms[x] ( x = Raum-Nummer)

Die Faces dieses Rooms sind dann: room[x].faces[MAX_FACES] (hier werden aber nur so viele Faces wie im Raum tatsächlich enthalten sind verwendet)

Ein Face ist dann wieder: face = room[x].faces[y]( x = Raum-Nummer, y = Raum-face-Nummer)

Die Raum-Vertices (vertex/vert, points oder egal wie man sie nennt)
sind dann: Verts: room[x].verts[MAX_VERTS] (hier werden aber nur so viele Verts wie im Raum tatsächlich enthalten sind verwendet)

Face Verts:
sind pro face als Index gespeichert ( von face_vert Nr.0 bis maximal max_face_verts)

vert_index = room[x].faces[y].face_verts[c]; (das face beinhaltet also die Nummern seiner Verts bezogen auf die Room Verts)

damit kann man dann z.B. so die x coord des verts holen: float x= room[x].verts[vert_index].x

die UV's sind aber etwas anders abgespeichert, nämlich pro face:

face = room[x].faces[y]
u = face.face_uvls[face_vert_nr_x].u;
v = face.face_uvls[face_vert_nr_x].v;


die uvls holt man also über die gültige face_vert_nr aus der Room->Face->UVL Struktur.
Evtl. bringen die Infos euch in der Sache voran. Ich hoffe auch, dass ich das soweit alles richtig wiedergegeben habe.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Tebo
Forum-Nutzer


Anmeldungsdatum: 15.07.2005
Beiträge: 21
Wohnort: Schweiz

BeitragVerfasst am: 18.04.2009, 19:24    Titel: Antworten mit Zitat

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


Dann lass dir doch mal die Normale von Face 82 in Raum 0 von Ascent ausgeben.
Die sollte (1,0,0) sein, mit der obigen Funktion wird man aber eher (0,0,0) erhalten Winken
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
King Lo
Forum-Nutzer


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

BeitragVerfasst am: 18.04.2009, 20:16    Titel: Antworten mit Zitat

Jo Atan wir hams jetzt Smilie Habe versehentlich die uv-Vektoren mit diesen komischen u2/v2-Vektoren überschrieben. Danke für die Anleitung, so hatten wirs auch gemacht.

@Tebo: Hmm also er stellt jedenfalls alles da Smilie Du hast sicher Recht, aber ich verstehe nicht, wozu ich die brauche (habe halt keinen Plan von 3D-Programmierung Auf den Arm nehmen).

Also man kann jetzt durch Ascent (und fast alle anderen Levels) durchfliegen, alle Faces sind korrekt, die Übergänge zwischen den Räumen sind vorhanden. Eigentlich ist es ganz gewohnt, nur die Lichteffekten fehlen noch. Die FPS-Zeit ist soweit wirklich in Ordnung - bei Kantenglättung hat Reactor Gamma ganze 97 FPS (und das mit einer GeForce 8400 M mit 128 MB Speicher). Ohne Kantenglättung sind es noch 3 FPS mehr Auf den Arm nehmen

Was ich nicht verstehe ist, dass Irrlicht zu jedem Vektor auch noch eine Normal haben möchte. Mathematisch verstehe ich den Sinn "Normale auf einen Punkt" nicht so ganz... Ich glaube es hat irgendwas mit der Lichteinstrahlung zu tun. Aber Im D3L-Format sind Normalen leider nur auf Faces angegeben, nicht auf Verts. Wo bekomm ich die her?

Wir wollen für die Anzahl der Vertices ein unsigned short verwenden. Reactor Gamma hat aber schon knapp 22.000 Vertices. Wird das wohl reichen?
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Atan
Moderator


Anmeldungsdatum: 27.07.2001
Beiträge: 876

BeitragVerfasst am: 18.04.2009, 20:58    Titel: Antworten mit Zitat

Zitat:
Wir wollen für die Anzahl der Vertices ein unsigned short verwenden. Reactor Gamma hat aber schon knapp 22.000 Vertices. Wird das wohl reichen?

Die Anzahl der Verts pro Raum sind begrenzt durch MAX_VERTS_PER_ROOM 10000
Dafür reicht ein ushort. (65535) Aber ihr wollt wirklich gleich alle Verts eines Levels auf einmal...?
Das wären dann max 400 x 10000 = 4.000.000

Zitat:
Aber Im D3L-Format sind Normalen leider nur auf Faces angegeben, nicht auf Verts. Wo bekomm ich die her?

Die Face-Normale meinst Du?
Oder die Vert normals?
Wenn Du alle Facenormals hast, dann musst Du noch ermittlen welche Faces denn alle an ein und dem selben Vert hängen.
Aus den Facenormalen dieser Faces dann einen Mittelwert bilden und diesen noch normalisieren. Das ist dann das Vert-Normal.
Darin steckt auch der Hintergrund, die Face-normale einer zusammenhängenden Face-Gruppe, können alle in verschiedene Richtungen zeigen, das gemeinsame Vert aber zeigt auf den Mittelwert aller dieser Facenormale.


Zuletzt bearbeitet von Atan am 19.04.2009, 10:19, insgesamt 2-mal bearbeitet
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Marix
Forum-Nutzer


Anmeldungsdatum: 30.05.2001
Beiträge: 982
Wohnort: Germany

BeitragVerfasst am: 19.04.2009, 11:31    Titel: Antworten mit Zitat

Der Verständlichkeit halber, die Vertex-Normale ist die normale einer Oberfläche, an der das Licht an diesem Punkt gestreut bzw. reflektiert wird. Wie von Atan beschrieben nimmt man hierfür normal eine hypotetische "gemittelte" Fläche.
_________________
„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: 19.04.2009, 12:58    Titel: Antworten mit Zitat

Durch das Mitteln der Normalen erscheint das Objekt nach dem Beleuchten glätter als beim verwenden von nur einer Normalen pro Face.
Dies ist aber in Levels häufig nicht Wünschenswert. Zum Beispiel sollten die Ecken der Räume auch wie Ecken aussehen, anderseits sollten Röhren rund und nicht sechseckig wirken.
Soweit ich weiss hat man als Levelbauer bei D3 aber keine Möglichkeit das zu Beeinflussen.

Werden die Normalen nicht normiert können völlig falsche Helligkeiten entstehen (falls der Renderer oder Irrlicht nicht selber noch normieren).
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Munk
Forum-Nutzer


Anmeldungsdatum: 30.06.2001
Beiträge: 2070
Wohnort: Basel

BeitragVerfasst am: 19.04.2009, 13:33    Titel: Antworten mit Zitat

Der Renderer wird hoffentlich nicht selbst normieren, kostet das doch eine teure Division und eine noch teurere Wurzelfunktion.
_________________
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: 982
Wohnort: Germany

BeitragVerfasst am: 19.04.2009, 17:16    Titel: Antworten mit Zitat

Kommt darauf an. Heutzutage normalisiert man sowas im Shader auf der Karte, und da kostet der Kehrwert der Wurzel nur einen Takt.
_________________
„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
King Lo
Forum-Nutzer


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

BeitragVerfasst am: 06.05.2009, 13:30    Titel: Antworten mit Zitat

O.K. ich denke das mit den Normals dürfte jetzt stimmen. Was Tebo gesagt hat ist zwar problematisch, aber da wir erst den Verts die Normals geben und DANN das Polygon splitten, sollte es stimmen.


Nun zu den Lightmaps:
Ich habe von dem Thema leider nicht viel Ahnung Smilie Also ich weiß nur, dass wohl da so ne Art Schattentextur drübergezogen werden kann. Die Texturkoordinaten sind sicher dann die zweiten UV-Werte der Face-Verts. Aber wo stecken die Schattentexturen? Vllt in der VolumeLights struct byteweise kodiert? Und was ist das lmi_handle?

Außerdem haben wir uns gefragt, ob es nicht cooler wäre, statt Lightmaps das ganze mit dynamischen Lichquellen zu machen (dann hätten Pyros Schatten). Hat jemand eine Vorstellung, wie viel CPU Power sowas braucht? Liefert das D3L format überhaupt die Lichtquellen mit?
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
King Lo
Forum-Nutzer


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

BeitragVerfasst am: 08.05.2009, 21:14    Titel: Antworten mit Zitat

Ahh den Lightmap-Chunk habe ich immerhin schonmal gefunden Smilie ...
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
King Lo
Forum-Nutzer


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

BeitragVerfasst am: 10.05.2009, 22:18    Titel: Antworten mit Zitat

So, ich habe jetzt die Lightmaps einleseklar. Das lmi_handle in den Faces ist tatsächlich der Index zur entsprechenden LightMap-Info-Struct.

Code:
struct LightMapTextureInfo
{
   short width, height;
   ubyte type;
   short x1, y1;
   ubyte xspacing, yspacing;
   math_vec upperleft, normal;

   short data_handle; // index in LightMapTextureData array

   void read_from_file(FILE* d3l_fp) throw(ErrorClass);
};

struct LightMapTextureData
{
   vector<ushort> data;
   void read_from_file(FILE* d3l_fp) throw(ErrorClass);
};


Eine Sache ist mir hier aber nicht klar: Outrage trennt die Infos von der Data. (Also ein Info-Array und ein Data-Array). Das könnte doch nur heißen, dass einige Daten die gleichen Infos haben. Aber die Normal oder der Upper-Left-Vector müssen doch fast überall verschieden sein...? Wie soll das funktionieren?

Des Weiteren verstehe ich nicht, wozu man die Daten x1, y1, xspacing, upperleft und normal braucht. Jemand Ideen?


Zuletzt bearbeitet von King Lo am 10.05.2009, 23:14, insgesamt einmal bearbeitet
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Atan
Moderator


Anmeldungsdatum: 27.07.2001
Beiträge: 876

BeitragVerfasst am: 11.05.2009, 19:29    Titel: Antworten mit Zitat

Zitat:
Outrage trennt die Infos von der Data

Warum das so ist würde ich evtl. so sehen:
Lightmaps sind Texturen (Game-Bitmaps) und werden zum Renderer rübergeschoben.
Viele Faces können die selbe Bitmap haben.
Die Bitmap-Informationen sind dann grundsätzlich für alle Faces gleich.
Unterschiedlich ist aber z.B. wie sie letztendlich dann auf die jeweiligen Faces 'aufgezogen' sind, wie dann das Normal für dieses Face ist, wieviel Speicher sie jeweils pro face beanspruchen (Fläche). Es gibt also zu jedem Face noch weitere spezielle Daten zu ein und der selben Bitmap zum Rendern zu übermitteln.
Liegen einige Faces 'nebeneinander' und haben sie die selbe Texture, kann ich sie zum Beleuchten evtl sogar zusammenfassen da das Normal in die selbe Richtung zeigt. Sehr komplexes Thema, mir fehlt die Zeit da tiefer einzusteigen.
Aber ich denke doch, dass es hier einige Spezialisten gibt, die da mit dem grundsätzlichen Prinzip durchaus weiterhelfen könnten.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
King Lo
Forum-Nutzer


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

BeitragVerfasst am: 16.05.2009, 17:08    Titel: Antworten mit Zitat

Welche Spezialisten? Hast du Namen, so dass ich mal anfragen könnte?

Also ich bin sehr erstaunt, Ascent hat 33 Data-Structs und ca. 1490 Info-Structs.
JazzyBox (2 Räume) hat nur EINE Data-Struct und einige mehr Info-Structs.

Ich meine wie Soll ich eine 128x128 Lightmap-Textur über einen ganzen Raum spannen? Das würde doch viel zu unscharf werden! Traurig
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Atan
Moderator


Anmeldungsdatum: 27.07.2001
Beiträge: 876

BeitragVerfasst am: 16.05.2009, 18:39    Titel: Antworten mit Zitat

Was ist z.B. mit den M's? Marix, Munk.

Wie gesagt, ich habe im Moment leider sehr sehr wenig Zeit um das anhand des QC's genauer zu erforschen, ich muss erstmal ein wichtiges Projekt fertig stellen.
Wenn ich das zeitnah schaffe, und kein anderer bis dahin helfen kann, versuche ich diese Sache für Euch nochmal etwas genauer zu ergründen.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Do_Checkor
Administrator


Anmeldungsdatum: 19.11.2000
Beiträge: 7571
Wohnort: Oldenburg (Oldb.)

BeitragVerfasst am: 16.05.2009, 19:48    Titel: Antworten mit Zitat

King Lo hat folgendes geschrieben:
Ich meine wie Soll ich eine 128x128 Lightmap-Textur über einen ganzen Raum spannen? Das würde doch viel zu unscharf werden! Traurig


Mal so von einem Ahnungslosen: Ist das nicht 'n Denkfehler? Ein Room kann doch mehrere Faces haben. Besser gesagt: In der Regel hat ein Room ja eh mindestens 6 Faces, aber auch eine Fläche (wegen mir aus förmlich glatte Raum-Decke könnte X Faces haben.

Oder wie jetzt?
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
King Lo
Forum-Nutzer


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

BeitragVerfasst am: 16.05.2009, 20:33    Titel: Antworten mit Zitat

Um es nochmal zu erklären, wie ichs verstehe (hoffe es hilft!):

Ein Raum hat Verts, also die Ecken. Über die Spannen wir dann zunächst virtuelle Faces.
Jedes Face hat jetzt Informationen:
a.) Info, WELCHE TEXTUR wir draufspannen
b.) Info, WIE wir diese Textur draufspannen (d.h. zum Beispiel welchen Ausschnitt der Textur aus a )
- BIS HIER ALLES KLAR -
c.) Info, WELCHE Lightmap-Textur wir über die Textur spannen (Also eine ID, die auf die entsprechende Lightmap verweist. Lightmaps sind irgendwelche Bit-Arrays, die auch im D3L-Format drin stehen) - Das Ergebnis ist dann die Textur aus a überlagert mit dieser Lightmap-Textur
d.) Info, WIE wir die Lightmap über die Verts spannen. Siehe Structs in obigem Post.

Man kann eine Textur tatsächlich über einen Raum spannen. Wenn Du einen Würfel mit den Zahlen 1-6 hast, schreibst Du die in eine Bitmap nebeneinander. Dann hast Du eine Bitmap, die Du jedem Face zuweist (a), aber jedes Face zeigt eine andere Teilfläche der ganzen Bitmap an. (@ Checkor)

Das komische ist, dass es viel weniger Lightmap-Textur-Data (c) als Lightmap-Textur-Infos (d) gibt, und dass es z.T. für einen Raum weniger als eine (128x128-)Lightmap-Textur gibt.


Zuletzt bearbeitet von King Lo am 16.05.2009, 20:35, insgesamt 2-mal bearbeitet
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Atan
Moderator


Anmeldungsdatum: 27.07.2001
Beiträge: 876

BeitragVerfasst am: 16.05.2009, 21:05    Titel: Antworten mit Zitat

Kann es sein das Du hier evtl. einen Gedankenfehler machst?
Zitat:
Das komische ist, dass es viel weniger Lightmap-Textur-Data (c) als Lightmap-Textur-Infos (d)


Die Data sind die Bilder, die LightmapInfos sind pro face. Daher sind für einen Würfel 6 Infos nötig und einmal Data.

Ich habs auf die Schnelle und ohne Anspruch auf absolute Richtigkeit mal für Dich zusammengebraten:
Zitat:
Multiple faces können sich eine Lightmap teilen.

Jedes face hat einen Zeiger auf einen Index in der LightmapInfo. (fp->lmi_handle)
Darüber greift man auf die LightmapInfo zu. (LightmapInfo[fp->lmi_handle].xxx)

Die LightmapInfo struct sieht so aus:
{
ubyte xspacing,yspacing;
ushort lm_handle; *****
vector upper_left,normal;
ubyte width,height,x1,y1;
ubyte used;
ushort dynamic;
short spec_map;
ubyte type;
} lightmap_info;


In der LightmapInfo steckt das lm_handle. Darüber greift man auf die GameLightmaps zu. GameLightmaps[LightmapInfo[fp->lmi_handle].lm_handle].xxx

GameLightmaps struct:
{
ubyte width,height; // Width and height in pixels
ushort *data; // 16bit data ****

ushort used;
ubyte flags;
short cache_slot; // for the renderers use
ubyte square_res; // for renderers use
ubyte cx1,cy1,cx2,cy2; // Change x and y coords
} bms_lightmap;

GameLightmaps[handle].data ist der Zeiger auf die Bitmap im File.
Gibt also an, wo sich die für diese Bitmap (das Bild) nötigen Informationen innerhalb des Level Files befinden.


Ich hoffe das hilft weiter.
Hiermit kann ich leider nichts anfangen:
Zitat:
und dass es z.T. für einen Raum weniger als eine (128x128-)Lightmap-Textur gibt.

Weniger als Eine wäre keine. Was meinst Du genau?
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 Zurück  1, 2, 3, 4  Weiter
Seite 2 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