{
( -256 184 116 ) ( 256 184 116 ) ( 256 -184 116 ) X_HEDGE_MUD [ 1 0 0 16 ] [ 0 -1 0 -32 ] 0 1 1
( -256 -184 -116 ) ( 256 -184 -116 ) ( 256 184 -116 ) X_HEDGE_MUD [ 1 0 0 16 ] [ 0 -1 0 -32 ] 0 1 1
( -256 184 116 ) ( -256 -184 116 ) ( -256 -184 -116 ) X_HEDGE_MUD [ 0 1 0 32 ] [ 0 0 -1 -28 ] 0 1 1
( 256 184 -116 ) ( 256 -184 -116 ) ( 256 -184 116 ) X_HEDGE_MUD [ 0 1 0 32 ] [ 0 0 -1 -28 ] 0 1 1
( 256 184 116 ) ( -256 184 116 ) ( -256 184 -116 ) X_HEDGE_MUD [ 1 0 0 16 ] [ 0 0 -1 -28 ] 0 1 1
( 256 -184 -116 ) ( -256 -184 -116 ) ( -256 -184 116 ) X_HEDGE_MUD [ 1 0 0 16 ] [ 0 0 -1 -28 ] 0 1 1.1
}

Was bedeuten die einzelnen Zahlen?
Ich habe schon folgendes herausbekommen:
(irgendein Punkt)(irg. Punkt)(irg. Punkt) TEXTUR_NAME [ ? ? ? SHIFT_X ] [ ? ? ? SHIFT_Y] ROTATION SCALE_X SCALE_Y
Und eine Zeile ist doch eine Ebene?
Was sind die drei Punkte?

mhhh kA so genau aber du hast recht es geht um texes... aber is doch auch egal was ind map steht,,,

Member der Huren GmbH | KillerKuh.com

in .map files werden brushes durch 4 oder mehr ebenen bestimmt, die sich schneiden... die ebenen ergeben sich aus den koordinaten...

because our freedom sits at the end of a gun
we're all here getting beat up and held back
we're all here digging knives from our backs

Zitat:

Aufbau der .map Datei

Auch wenn das dein Thread is, ich will auch mal was sagen/fragen.

Das is das typische Valve 220 (WC/VHE) Format:

{
( -4 4 -64 ) ( -4 -124 -64 ) ( 124 4 -64 ) FIFTIES_WALL14Y [ 1 0 0 4] [ 0 -1 0 -4] 0 1.00000 -1.00000
( -4 4 64 ) ( -4 132 64 ) ( 124 4 64 ) FIFTIES_WALL14Y [ 1 0 0 4] [ 0 1 0 4] 0 1.00000 -1.00000
( -4 -60 0 ) ( -4 -60 128 ) ( 124 -60 0 ) FIFTIES_WALL14Y [ 1 0 0 4] [ 0 0 1 0] 0 1.00000 -1.00000
( -4 68 0 ) ( -4 68 128 ) ( -132 68 0 ) FIFTIES_WALL14Y [ -1 0 0 -4] [ 0 0 1 0] 0 1.00000 -1.00000
( -68 4 0 ) ( -68 4 128 ) ( -68 -124 0 ) FIFTIES_WALL14Y [ 0 -1 0 4 ] [ 0 0 1 0] 0 1.00000 -1.00000
( 60 4 0 ) ( 60 4 128 ) ( 60 132 0 ) FIFTIES_WALL14Y [ 0 1 0 -4] [ 0 0 1 0] 0 1.00000 -1.00000
}

Dann mein liebes Classic Quake. Mit dem ich normalerweise Arbeite:
quark etp sieht bei einem Brush eigentlich genau so aus. Nur mit nem "//TX1" am ende.

{
( -4 4 -64 ) ( -4 -124 -64 ) ( 124 4 -64 ) FIFTIES_WALL14Y 4 -4 0 1 -1
( -4 4 64 ) ( -4 132 64 ) ( 124 4 64 ) FIFTIES_WALL14Y 4 4 0 1 1
( -4 -60 0 ) ( -4 -60 128 ) ( 124 -60 0 ) FIFTIES_WALL14Y 4 0 0 1 1
( -4 68 0 ) ( -4 68 128 ) ( -132 68 0 ) FIFTIES_WALL14Y -4 0 0 -1 1
( -68 4 0 ) ( -68 4 128 ) ( -68 -124 0 ) FIFTIES_WALL14Y 4 0 0 -1 1
( 60 4 0 ) ( 60 4 128 ) ( 60 132 0 ) FIFTIES_WALL14Y -4 0 0 1 1
}

Zuletzt noch Brush Primitives, das nicht von den ZHLT verkraftet wird.

{
brushDef
{
( -4 4 -64 ) ( -4 -124 -64 ) ( 124 4 -64 ) ( ( 0.00000 -0.00781 0.03125 ) ( 0.00781 0.00000 -0.03125 ) ) FIFTIES_WALL14Y
( -4 4 64 ) ( -4 132 64 ) ( 124 4 64 ) ( ( 0.00000 0.00781 0.03125 ) ( -0.00781 0.00000 0.03125 ) ) FIFTIES_WALL14Y
( -4 -60 0 ) ( -4 -60 128 ) ( 124 -60 0 ) ( ( 0.00781 0.00000 0.03125 ) ( 0.00000 0.00781 0.00000 ) ) FIFTIES_WALL14Y
( -4 68 0 ) ( -4 68 128 ) ( -132 68 0 ) ( ( 0.00781 0.00000 -0.03125 ) ( 0.00000 0.00781 0.00000 ) ) FIFTIES_WALL14Y
( -68 4 0 ) ( -68 4 128 ) ( -68 -124 0 ) ( ( 0.00781 0.00000 0.03125 ) ( 0.00000 0.00781 0.00000 ) ) FIFTIES_WALL14Y
( 60 4 0 ) ( 60 4 128 ) ( 60 132 0 ) ( ( 0.00781 0.00000 -0.03125 ) ( 0.00000 0.00781 0.00000 ) ) FIFTIES_WALL14Y
}
}

Zu Bemerken: Auch wenn Classic Quake kleiner und primitiver aussieht. Is es dem Valve 220 überlegen. Es funzen Texangles ohne das es einschränkungen gibt. Warum hat dann Valve ein eigenes Mapformat entwickelt? Is doch Unsinn sich einzuschrenken...

[edits]
Der Codetag und die Floats (sollten eigentlich aus sein) hatten die Tabellen gesprengt ;)

Hier ein Polyeder bei dem jedes Face:
- anderes Scaling besitzt
- andere Texangles
Scaling habbich einfach immer 1|2, 2|3, 3|4 genommen.
Texangles: 90|45, 45|0, 0|-45 usw.
Ich weiß aber net ob ich die richtige Reihenfolge im Polyeder hab ;)
Wer kanns entschlüsseln?

{
( 60 0 0 ) ( 60 0 128 ) ( 60 91 0 ) FIFTIES_WALL14Y 0 0 -90 5 -4.24264
( -68 0 0 ) ( -68 0 128 ) ( -68 -91 0 ) FIFTIES_WALL14Y 0 0 -45 6 4.94975
( 0 68 0 ) ( 0 68 128 ) ( -91 68 0 ) FIFTIES_WALL14Y 0 0 225 4 3.53553
( 0 -60 0 ) ( 0 -60 128 ) ( 91 -60 0 ) FIFTIES_WALL14Y 0 0 0 3 -2.82843
( 0 0 64 ) ( 0 128 64 ) ( 91 0 64 ) FIFTIES_WALL14Y 0 0 90 1 -1.41421
( 0 0 -64 ) ( 0 -128 -64 ) ( 91 0 -64 ) FIFTIES_WALL14Y 0 0 -45 2 2.12132
}
[/edits]

"[...] you're going to burn in a very special level of Hell. A level they reserve for child molesters and people who talk at the theater." - Book

@khan: wenn du so genau darüber bescheit weisst, kannst hier noch ein paar infos posten?

- welche formate werden von wc/hammer unterstützt?
- wie muss der rest der datei aufgebaut sein? hier das war nur ein brush.
- was genau bedeuten die zahlen? das sind irgentwelche koorninatenangaben, ich verstehe das aber nicht.
- was wird überhaupt gespeichert? die eckpunkte edr brushes oder was jetzt?

mich interessiert das schon, ich wollte vielleicht .map - dateien mit einem programm erstellen lassen.

Entities: HL | HL²
Kompilierfehler
r_speeds | mehr über r_speeds

Ich weiß genau darüber bescheid? Nee... leider net. Ich wüsst ja gerne selbst mehr drüber. Ich hab doch nur QuArK und von daher die Möglichkeit in 4 .mapformaten zu speichern.

WC/VHE macht nur das dafür Entwickelte Valve 220. Das kann man auch in der map erkennen ("mapversion" "220").
Ich geh jetzt aber mal auf das "Classic Quake".map-Format ein, da ich das intressanter und besser finde ;)
Polybasedentities... *werkel* sehen so aus.

{
"classname" "func_wall"
"rendermode" "2"
"renderamt" "255"
{
( -68 -60 -64 ) ( 60 -60 -64 ) ( 60 68 -64 ) FIFTIES_WALL14Y 68 -60 0 1 1
( -68 68 64 ) ( 60 68 64 ) ( 60 -60 64 ) FIFTIES_WALL14Y 68 -60 0 1 1
( -68 -60 64 ) ( 60 -60 64 ) ( 60 -60 -64 ) FIFTIES_WALL14Y 68 -64 0 1 1
( -68 68 -64 ) ( 60 68 -64 ) ( 60 68 64 ) FIFTIES_WALL14Y 68 -64 0 1 1
( -68 -60 -64 ) ( -68 68 -64 ) ( -68 68 64 ) FIFTIES_WALL14Y 60 -64 0 1 1
( 60 -60 64 ) ( 60 68 64 ) ( 60 68 -64 ) FIFTIES_WALL14Y 60 -64 0 1 1
}
}

Classname is halt der Entity-Name und der rendermode und der ganze Quark is dann da noch aufgelistet. Dazu muss ich noch sagen, das QuArK auch nur die Werte speichert, die auch wirklich eingetragen wurden. Lässt man rendermode 2 (Texture) wech, stehts auch net in der .map und schätze mal das die Compiler den Standart für HL dann einsetzten.

Was jetzt die Cords genau bedeuten weiß ich selber net. Eckpunkte können es eigentlich net sein. Woher soll der Compiler sonst wissen, ob das jetzt nen 3 oder 4-Eck is?

"[...] you're going to burn in a very special level of Hell. A level they reserve for child molesters and people who talk at the theater." - Book

nocheinmal genau was ich wissen will:

ich möchte worldbrushes erstellen, die texturierung ist dabei ziemlich egal. ich muss dazu natürlich wissen, was die zahlen da bedeuten, denn danach mus ich mein programm auslegen.
entity-einstellungen sind eigentlich egal.

ich möchte nach möglichkeit das valve220-format nehmen, da ich wc und quark-maps machen mochte.

hoffentlich finde ich überhaupt zeit, das programm zu machen...

Entities: HL | HL²
Kompilierfehler
r_speeds | mehr über r_speeds

Mach ich morgen... hab für morgen leider noch was anderes zu machen. Morgen werd ich auch mal sehen was die Coords bedeuten könnten.

"[...] you're going to burn in a very special level of Hell. A level they reserve for child molesters and people who talk at the theater." - Book

achso,
durch die drei Punkte ist die Ebene bestimmt, aber was steht in den [ ? ? ? ? ] [ ? ? ? ? ]. Ich muss das wissen, da ich nen Compiler für meine eigene Engine schreibe.

Nimm lieber Classic Quake. Das scheint mir besser aufgebaut zu sein ;)

Ich mach mich spätestens heute Abend mal an die .map von Valve wenn ihr wollt.

"[...] you're going to burn in a very special level of Hell. A level they reserve for child molesters and people who talk at the theater." - Book

Aber ich benutze WC, da kann ich doch nur ein .map Format benutzen, oder?

achja ich könnte dazu auch noch mein Sempf geben:

Hierbei handelt es sich - wie bereits erwähnt - um eine Ebenendefintition.
Von diesen Drei Punkten wird nun eine Ebenengleichung erstellt. ( Mathe lässt grüßen ). Hie ein wenig Pseudo-Code
Quellcode:
( a1 a2 a3 ) ( b1 b2 b3 ) ( c1 c2 c3 ) ...
normal = CrossProduct( vector( a-b ), vector( c-b ) );
normal /= normal.length(); // auf länge 1.0 bringen!
dist = DotProduct( normal, b );

Dabei ist jedoch zu beachten, dass bei einem Brush natürlich die Normalen-Vektoren nach außen schauen! ( logisch oder? ). Jetzt habt ihr euch sicherlich gefragt wie man von den Ebenen zu den fertigen Polygonen kommt oder? Das ist eigentlich ganz einfach: man erstellt auf der Ebene einen ganz großen Polygon und zerschneidet ihn mit allen anderen Ebenen, wobei nur mit Polygonstück hinter der Ebene weitergearbeitet wird. Mit anderen Worten: man schnippelt also mit allen Brush-Ebenen den Polygon zurecht.

nun noch kurz was zur wc-Texturdef: das ist praktisch die fertige u/v Texturdefintion:
Quellcode:
[ u1 u2 u3 offsetx ] [ v1 v2 v3 offsety ] rot scalex scaley


um jetzt die s/t Texturaxen zu bekommen teilt man einfach die u/v vektoren duch scalex/y. Jetzt kann man ganz einfach für jeden Punkt auf einem Polygon die Textur-Koordinaten ausrechen. Zur Demonstration mal etwas code:
Quellcode:
// s/t Axen berechnen
for( i=0 ; i<2 ; i++ )
  st_vecs[i] = uv_vecs[i] / st_scale[i];

// eine Texturkoordinate ist also
coord.x = vector::DotProduct( vertex, st_vecs[0] ) + offset.x; // s
coord.y = vector::DotProduct( vertex, st_vecs[1] ) + offset.y; // t

coord.x /= texturwidth;
coord.y /= texiurheight;


ich hoffe mal dass das auch weiter hilft

Kannst du das auch für Nicht-Coder verständlich machen?

"[...] you're going to burn in a very special level of Hell. A level they reserve for child molesters and people who talk at the theater." - Book

ähhh.....
was willst du bitteschön mit dem .map-Format anfangen wenn du nicht coden kannst?

was verstehst du denn jetzt nicht? Vektor-Mathe is natürlich Grundvorraussetzung um das *.map-Format zu verstehen. Wenn du kein Plan hast wie man aus 3 Punkten eine Ebene erstellt dann kann ich dir leider auch nicht weiterhelfen...

falls doch hätte vielleicht noch erwähnen sollen das ich mit CrossProduct() das Vektor/Kreuzprodukt und mit DotProduct() das Skalarprodukt meine.

*nixpeil* Aber ich will ja eigentlich auch nichts mit machen. Die anderen wollten ja irgentwas mit Coden ;)

Was mich nur ein bissel Intressiert, wär jetzt warum Classic Quake mit so wenig auskommt, aber Valve 220 so viel braucht. Ideen?

"[...] you're going to burn in a very special level of Hell. A level they reserve for child molesters and people who talk at the theater." - Book

naja bei Quake1-3 erledigt das der Compiler selbst, der errechnet aus der rotation die Texturxen ( bei wc 220.map ist der rorate-value eigentlich überfläüssig ). Wc hat das ganze nur eingebaut damit die Texturausrichtung beim drehen von Brushes beibehalten werden kann (Texture-lock )

Naja... die Textur kann ja nicht nur rotiert sondern auch verzogen werden. Was ja beim großen Texturedef von Valve nicht mit bei is... mich wunderts deshalb, das Valve ein eigenes Format gemacht hat, was in meinen Augen einen Nachteil mit sich bringt...

"[...] you're going to burn in a very special level of Hell. A level they reserve for child molesters and people who talk at the theater." - Book

@KhanRKerensky:
Das Valve 220.map-Format hat den Vorteil, das der Compiler weniger rechnen muss ;)

@Diablo_bth:
Danke, genau die Infos wollte ich. Aber muss das bei der Tex-Koo-Berechnug nicht so heißen:
Quellcode:
for( i=0 ; i<2 ; i++ )
  st_vecs[ i ] = uv_vecs[ i ] / st_scale[ i ];


oder wie sonst?? (die 2 Zeilen kapier ich nicht ganz)

Also das risiko von 5mins mehr Compiletime bei csg und bsp geh ich ein um Texangles zu bekommen...

"[...] you're going to burn in a very special level of Hell. A level they reserve for child molesters and people who talk at the theater." - Book

oobs... natürlich muss das so heißen *peinlich*
ausgeschrieben ist dass dann so:

Quellcode:
// scale is ein float[2] für x&y
// st_vecs & uv_vecs is ein vector[2], wobei ein vector{ float x, y, z }; is
for( i=0 ; i<2 ; i++ )
{
(st_vecs+i)->x = (uv_vecs+i)->x / *(st_scale+i);
(st_vecs+i)->y = (uv_vecs+i)->y / *(st_scale+i);
(st_vecs+i)->z = (uv_vecs+i)->z / *(st_scale+i);
}


*edit*
argh...!!
diese sch*** Forum-Formatierung macht dass [buchstabe_i] nicht mit!! das wird dann einfach kursiv Da sollte DP mal einschreiten das geht ja bei code-tags wohl nicht, weil man sowas villeicht öfters mal postet!! Ich habs dann hier nochmal vornehm umgangen *g* - oder [ i ] schreiben *andenkopfklasch*