Die modifizierten Zoner Tools von http://collective.valve-erc.com/index.php?go=mhlt unterstützen angeblich folgendes:

- Increased maximum subdivide value in hlbsp to 512. You may now specify a value
using the -subdivide parameter other than 240.
WARNING: Doing so may cause problems in software mode. If in doubt, leave at the failsafe
default value of 240

So und ich kann aber nur bis 258 fehlerfrei compilieren. Darüber meldet rad
"hlrad: Error: Bad surface extents (3 x 64)" und HL stürzt ab.

Man kann sich dort auch den Source ziehen, ich hab mir SubdivideFace() mal angesehen und konnte auf anhieb kein limit erkennen, dass den fehler verusachen könnte.

static int subdivides;

/* a surface has all of the faces that could be drawn on a given plane
the outside filling stage can remove some of them so a better bsp can be generated */

// =====================================================================================
// SubdivideFace
// If the face is >256 in either texture direction, carve a valid sized
// piece off and insert the remainder in the next link
// =====================================================================================
void SubdivideFace(face_t* f, face_t** prevptr)
{
vec_t mins, maxs;
vec_t v;
int axis;
int i;
dplane_t plane;
face_t* front;
face_t* back;
face_t* next;
texinfo_t* tex;
vec3_t temp;

// special (non-surface cached) faces don't need subdivision

tex = &g_texinfo[f->texturenum];

if (tex->flags & TEX_SPECIAL)
{
return;
}

if (f->facestyle == face_hint)
{
return;
}
if (f->facestyle == face_skip)
{
return;
}

#ifdef ZHLT_NULLTEX // AJM
if (f->facestyle == face_null)
return; // ideally these should have their tex_special flag set, so its here jic
#endif

for (axis = 0; axis < 2; axis++)
{
while (1)
{
mins = 999999;
maxs = -999999;

for (i = 0; i < f->numpoints; i++)
{
v = DotProduct(f->pts[i], tex->vecs[axis]);
//Weiss jemand welche Information dem Skalarprodukt hier entnommen wird?
//Fläche würde ja eher über kreuzprodunkt und betrag von
//normalenvektor sinn machen
if (v < mins)
{
mins = v;
}
if (v > maxs)
{
maxs = v;
}
}

if ((maxs - mins) <= g_subdivide_size)
{
break;
}

// split it
subdivides++;

VectorCopy(tex->vecs[axis], temp);
v = VectorNormalize(temp);

VectorCopy(temp, plane.normal);
plane.dist = (mins + g_subdivide_size - 16) / v;
next = f->next;
SplitFace(f, &plane, &front, &back);
if (!front || !back)
{
Developer(DEVELOPER_LEVEL_SPAM, "SubdivideFace: didn't split the %d-sided polygon @(%.0f,%.0f,%.0f)",
f->numpoints, f->pts[0][0], f->pts[0][1], f->pts[0][2]);
break;
}
*prevptr = back;
back->next = front;
front->next = next;
f = back;
}
}
}

Der Fehler muss irendwo in dieser funktion liegen, da ähnliche variablen und prozesse auch in der hlrad funktion vorkommen, die den fehler liefert:
hlrad lightmap.cpp:

// =====================================================================================
// CalcFaceExtents
// Fills in s->texmins[] and s->texsize[]
// also sets exactmins[] and exactmaxs[]
// =====================================================================================
static void CalcFaceExtents(lightinfo_t* l)
{
const int facenum = l->surfnum;
dface_t* s;
vec_t mins[2], maxs[2], val;
int i, j, e;
dvertex_t* v;
texinfo_t* tex;

s = l->face;

mins[0] = mins[1] = 999999;
maxs[0] = maxs[1] = -99999;

tex = &g_texinfo[s->texinfo];

for (i = 0; i < s->numedges; i++)
{
e = g_dsurfedges[s->firstedge + i];
if (e >= 0)
{
v = g_dvertexes + g_dedges[e].v[0];
}
else
{
v = g_dvertexes + g_dedges[-e].v[1];
}

for (j = 0; j < 2; j++)
{
val = v->point[0] * tex->vecs[j][0] +
v->point[1] * tex->vecs[j][1] + v->point[2] * tex->vecs[j][2] + tex->vecs[j][3];
if (val < mins[j])
{
mins[j] = val;
}
if (val > maxs[j])
{
maxs[j] = val;
}
}
}

for (i = 0; i < 2; i++)
{
l->exactmins[i] = mins[i];
l->exactmaxs[i] = maxs[i];

mins[i] = floor(mins[i] / 16.0);
maxs[i] = ceil(maxs[i] / 16.0);

l->texmins[i] = mins[i];
l->texsize[i] = maxs[i] - mins[i];
}

if (!(tex->flags & TEX_SPECIAL))
{
if ((l->texsize[0] > 16) || (l->texsize[1] > 16))
{
ThreadLock();
PrintOnce("\nfor Face %d (texture %s) at ", s - g_dfaces, TextureNameFromFace(s));

for (i = 0; i < s->numedges; i++)
{
e = g_dsurfedges[s->firstedge + i];
if (e >= 0)
{
v = g_dvertexes + g_dedges[e].v[0];
}
else
{
v = g_dvertexes + g_dedges[-e].v[1];
}
VectorAdd(v->point, g_face_offset[facenum], v->point);
Log("(%4.3f %4.3f %4.3f) ", v->point[0], v->point[1], v->point[2]);
}
Log("\n");

Error( "Bad surface extents (%d x %d)\nCheck the file ZHLTProblems.html for a detailed explanation of this problem", l->texsize[0], l->texsize[1]);
}
}
}

Langsam frage ich mich ob einfach nur die konstante in der bsp5.h auf 512 gesetzt wurde und die mapper ihrem schicksal überlassen wurden....

bsp5.h :

#ifdef ZHLT_GENERAL
#define MAX_SUBDIVIDE_SIZE 512
#else
#define MAX_SUBDIVIDE_SIZE 240
#endif

Wenn ich texturen sehr gross scale (so 100 z.b.), tritt der fehler nicht mehr auf, da dann die ursprüngliche subdivide size wohl schon grösser als das brush face ist.

Ich habe selbstverständlich immer unter openGL getestet.

Was eine suddivide size von 512 units bedeuten würde, ist hoffentlich jedem klar: Eine unglaubliche performance steigerung der engine, bzw eine im günstigsten falle halbierung der wpolies, bei allen bisher gemappten maps. Wenn man von einer durchschnittlichen texture scale von 2 ausgeht, würde erst alle 1024 units eine neue fläche berechnet!

War in Europe - the first WW2 modification for HL http://www.warineuropemod.com

Mh, frag doch einfach Zoner direkt.

TheTinySteini
Coder Poke646
"Don't Panic" - Hitchhiker's Guide to the Galaxy

Ich bin immer noch sehr skeptisch, was die Lauffähigkeit der so kompilierten Maps im Software-Modus angeht.
Wir von Project Timeless haben an einem 256er-Subdivide nämlich schon mal vor einem halben Jahr intensiv gearbeitet, mit dem Ergebnis, dass es zwar unter OpenGL und D3D funktionierte, aber jeden Server oder Client im Softwaremodus zum Absturz brachte.

Die Antwort von Valve war damals ziemlich eindeutig: Es geht nicht. Und das glaube ich solange, bis ich eine vernünftige Map bei mir im Server laufen habe.

Ich hab gerade mal getestet, als Client und Server läuft ne Map im Softwaremodus mit subdivide 258 ohne Probleme. Aber 258 ist gegenüber 240 noch keine echte Verbesserung....

War in Europe - the first WW2 modification for HL http://www.warineuropemod.com

Zoner sagt, das -subdivide höherstellen könne gar nicht fehlerfrei funktionieren... hängt irgendwie mit der Engine zusammenen.
Jedenfalls hab ich das gefunden als ich vor ein paar Tagen mal zu dem Thema recherchiert habe. Was ich auch gefunden habe war ein Tool, das angeblich -subdivide 256 (bis wohin das funktioniert hängt afaik u.A. von der Komplexibilität der Map ab) zum funktionieren brachte, indem irgendwas an den planes herumgewurstet wurde. Naja, drüber geredet wurde viel, aber einen funcenden DL-Link habe ich nicht gefunden.

Hm.. das mit dem 256er subdivide-Programm hab ich auch mitbekommen, es hieß nur "es funktioniert" usw... aber nix von wegen selber testen!

Es gibt aber eine einfachere Möglichkeit ein 256er subdivide wenigstens zu "simulieren", wenn man eine Textur z.B. einfach (1.00) skaliert, dann wird es in 240*240 größe stücke zerteil, wenn man aber jetzt eine Textur mit
1.14 skaliert, geht das über 256*256!
0.14 ist nicht viel, man merkt das bei den meisten Texturen ÜBERHAUPT nicht, es bringt - richtig angewandt - aber einige Performance!

Ihr wollte jetzt wissen wie ich (das habe ich natürlich selber rausgefunden) das ausgerechnet habe, ganz einfach:

(256*256) : (240*240) = 1,1377periode
~ 1.14

Klar, ihr kommt jetzt: "Das Texturenskalieren polys spart war ja schon lange klar"

Aber ich erwiedere: "Warum nehmt ihr dann nicht "1.14" anstelle von "1.00", oder "2.28" anstelle von "2.00"? So spart man polys - und es fällt nicht sehr auf!"
Ich habe schon vor über nem Jahr eine Liste mit umgerechneten Werten erstellt, ich stelle sie hier gradmal zur Verfügung:

_________________________________________
Neues | Orginal| Ungerundete Lösung |
0.15 | 0.125 | 0.1422... |
0.29 | 0.25 | 0.2844... |
0.43 | 0.375 | 0.4266... |
0.57 | 0.5 | 0.5688... |
0.86 | 0.75 | 0.8533... |
1.14 | 1 | 1.1377... |
1.43 | 1.25 | 1.422... |
1.71 | 1.5 | 1.7066... |
1.85 | 1.625 | 1.8488... |
2.00 | 1.75 | 1.9911... |
2.28 | 2 | 2.2755... |
2.55 | 2.25 | 2.5499... |
2.85 | 2.5 | 2.844... |
3.13 | 2.75 | 3.1288... |
3.42 | 3 | 3.4133... |
3.70 | 3.25 | 3.6977... |
3.99 | 3.5 | 3.9822... |
4.56 | 4 | 4.5511... |
5.41 | 4.75 | 5.4044... |
5.69 | 5 | 5.688... |
6.83 | 6 | 6.8266... |
7.97 | 7 | 7.9644... |
9.11 | 8 | 9.1022... |
10.24 | 9 | 10.24 |
11.38 | 10 | 11.377... |
-----------------------------------------

Das hier kann man sich nur im Texteditor gescheit ansehen!
"Neues" ist die Gerundete Lösung, um das 256er-subdive zu simulieren
"Altes" ist wohl klar, wenn man eine Textur vorher mit "2.00" skaliert hat, dann guckt man eben links davon auf die Lösung "Neues" (in diesem Fall 2.28)
"Ungerundete Lösung" ist noch klarer, kein Kommentar

So, ich hoffe dass das hier nicht wie letztes Mal, als ich es erklären wollte in Vergessenheit gerät!

--< Spirit of Half-life

Interessant, sowas steht ja sonst nirgends. *notier*

http://choerbaert.org
Ein Gespenst geht um im Netz - das Gespenst des Open Source
csndr

Ist ja auch nur von mir! ;-)

PS: *Spam*

--< Spirit of Half-life

Ach ja, was mich noch interessieren würde: Wie bist du auf die Zahlen gekommen, die bei "Original" stehen. Gibt es da einen bestimmten Algo? Man kann ja nicht jede x-beliebige Zahl nehmen und einfach mit 1.377 multiplizieren.
Mich interessiert das weil ich gerade dabei bin dafür ein Programm zu schreiben (für mich)

http://choerbaert.org
Ein Gespenst geht um im Netz - das Gespenst des Open Source
csndr

Original? Also das ist ja mehr als einfach!

Wenn du eine Textur vorher (bevor du sie auf 256er subdive gestellt hast) um 2 skaliert ist, dann sagst du nun "skaliere auf 2.28", somit werden weniger polys verbraucht... (wenn ein brush-länge durch "256" teilbar ist (und eine "normale" Zahl ohne Komma rauskommt))!

Zitat:
Man kann ja nicht jede x-beliebige Zahl nehmen und einfach mit 1.377 multiplizieren.

Natürlich, nur das bei "Original" sind halt häufige Werte, das spart euch Zeit!

Ein Programm? Wirkt unnötig, der Windows Taschenrechner reicht!

EDIT:

Mit Original meinte ich die Werte, die man vorher hat... herr gott, das ist SOOO einfach aber man kanns nicht gescheit erklären!

--< Spirit of Half-life

Hmm so meinte ich das eigentlich nicht.
Egal

http://choerbaert.org
Ein Gespenst geht um im Netz - das Gespenst des Open Source
csndr

Für alle die dieses FixTool mal testen wollen, sollten sich einmal die ZHLT von www.thedoenerking.de runterladen. Dort ist es in der Zip enthalten. Dummerweise funktioniert es bei mir net und stürzt ab.

[Dennis "Dr.Zenz" Jenz][Photon Audio Player]