Descentforum.DE Forum Index Descentforum.DE
Search | FAQ | Memberlist | Usergroups | Newsfeed Newsfeed  Register
Profile | Log in to check your private messages | Log in 
Chat | D3-Tactics | Downloads | Map | Links | Serverlist | Teamspeak 

Frage zu neuem Level-Format
Goto page Previous  1, 2, 3, 4  Next
 
Post new topic   Reply to topic    Descentforum.DE Forum Index -> Level-, Design und Entwicklungs - Forum
View previous topic :: View next topic  
Author Message
King Lo
Forum-Nutzer


Joined: 14 Mar 2006
Posts: 320
Location: Stuttgart, BW

PostPosted: 17.04.2009, 22:06    Post subject: Reply with quote

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)
Back to top
View user's profile Send private message
Atan
Moderator


Joined: 27 Jul 2001
Posts: 876

PostPosted: 17.04.2009, 23:52    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
King Lo
Forum-Nutzer


Joined: 14 Mar 2006
Posts: 320
Location: Stuttgart, BW

PostPosted: 18.04.2009, 11:15    Post subject: Reply with quote

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

Back to top
View user's profile Send private message
Atan
Moderator


Joined: 27 Jul 2001
Posts: 876

PostPosted: 18.04.2009, 14:24    Post subject: Reply with quote

das sieht doch schon mal gut aus.

Quote:
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:
Quote:
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.
Back to top
View user's profile Send private message
Tebo
Forum-Nutzer


Joined: 15 Jul 2005
Posts: 21
Location: Schweiz

PostPosted: 18.04.2009, 19:24    Post subject: Reply with quote

King Lo wrote:
@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
Back to top
View user's profile Send private message
King Lo
Forum-Nutzer


Joined: 14 Mar 2006
Posts: 320
Location: Stuttgart, BW

PostPosted: 18.04.2009, 20:16    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
Atan
Moderator


Joined: 27 Jul 2001
Posts: 876

PostPosted: 18.04.2009, 20:58    Post subject: Reply with quote

Quote:
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

Quote:
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.


Last edited by Atan on 19.04.2009, 10:19; edited 2 times in total
Back to top
View user's profile Send private message
Marix
Forum-Nutzer


Joined: 30 May 2001
Posts: 1015
Location: Germany

PostPosted: 19.04.2009, 11:31    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Tebo
Forum-Nutzer


Joined: 15 Jul 2005
Posts: 21
Location: Schweiz

PostPosted: 19.04.2009, 12:58    Post subject: Reply with quote

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).
Back to top
View user's profile Send private message
Munk
Forum-Nutzer


Joined: 30 Jun 2001
Posts: 2140
Location: Herzogenrath

PostPosted: 19.04.2009, 13:33    Post subject: Reply with quote

Der Renderer wird hoffentlich nicht selbst normieren, kostet das doch eine teure Division und eine noch teurere Wurzelfunktion.
Back to top
View user's profile Send private message Send e-mail
Marix
Forum-Nutzer


Joined: 30 May 2001
Posts: 1015
Location: Germany

PostPosted: 19.04.2009, 17:16    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
King Lo
Forum-Nutzer


Joined: 14 Mar 2006
Posts: 320
Location: Stuttgart, BW

PostPosted: 06.05.2009, 13:30    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
King Lo
Forum-Nutzer


Joined: 14 Mar 2006
Posts: 320
Location: Stuttgart, BW

PostPosted: 08.05.2009, 21:14    Post subject: Reply with quote

Ahh den Lightmap-Chunk habe ich immerhin schonmal gefunden Smilie ...
Back to top
View user's profile Send private message
King Lo
Forum-Nutzer


Joined: 14 Mar 2006
Posts: 320
Location: Stuttgart, BW

PostPosted: 10.05.2009, 22:18    Post subject: Reply with quote

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?


Last edited by King Lo on 10.05.2009, 23:14; edited 1 time in total
Back to top
View user's profile Send private message
Atan
Moderator


Joined: 27 Jul 2001
Posts: 876

PostPosted: 11.05.2009, 19:29    Post subject: Reply with quote

Quote:
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.
Back to top
View user's profile Send private message
King Lo
Forum-Nutzer


Joined: 14 Mar 2006
Posts: 320
Location: Stuttgart, BW

PostPosted: 16.05.2009, 17:08    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Atan
Moderator


Joined: 27 Jul 2001
Posts: 876

PostPosted: 16.05.2009, 18:39    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Do_Checkor
Administrator


Joined: 19 Nov 2000
Posts: 7768
Location: Oldenburg (Oldb.)

PostPosted: 16.05.2009, 19:48    Post subject: Reply with quote

King Lo wrote:
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?
Back to top
View user's profile Send private message
King Lo
Forum-Nutzer


Joined: 14 Mar 2006
Posts: 320
Location: Stuttgart, BW

PostPosted: 16.05.2009, 20:33    Post subject: Reply with quote

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.


Last edited by King Lo on 16.05.2009, 20:35; edited 2 times in total
Back to top
View user's profile Send private message
Atan
Moderator


Joined: 27 Jul 2001
Posts: 876

PostPosted: 16.05.2009, 21:05    Post subject: Reply with quote

Kann es sein das Du hier evtl. einen Gedankenfehler machst?
Quote:
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:
Quote:
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:
Quote:
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?
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    Descentforum.DE Forum Index -> Level-, Design und Entwicklungs - Forum All times are GMT + 2 Hours
Goto page Previous  1, 2, 3, 4  Next
Page 2 of 4

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum
PayPal


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