Hi@all! Hab eben in der Forensuche rumgestöbert und bin dabei auf ein Forum gestoßen in dem etwas über ein nodraw-Textur stand! Was ist denn jetzt daraus geworden?? Hat sich Valve daran gestzt??? Kann sich einer vielleicht noch den Fragen aus meinem Thread unter diesem hier annehmen???
Ciao!!!

Diese Textur nennt sich neuerdings "null"-Textur und ist bei den aktuellen ZHLT's dabei. Flächen mit der null-Textur werden definitiv nicht berechnet und angezeigt. Anders als bei der herkömmlichen Weise mit der sky-Textur spart man mit null tatsächlich viele r_speeds ein!

K:R-I)Z++
"CSS ist cascading style sheets. Und nicht so'n Ranzspiel." - dp
In memory of Voice († 2005/03/30)

jo, die neuen ZHLTs giebts auf
www.thedoenerking.de

Nihil timeo, nulla re opprimor, nulli periculo cedo.
www.TheDoenerKing.de

Sieht aber aus als täta man in den unendlichen Weiten des HamemrWeltraumes
schweben.
Oder anders. Schaut aus wie ein leak. Is aber keins

greetz freezer

fr?her "M.D.Freezer"

Das nennt sich "hall of mirrors" - Das ist eine stelle, an der nchts gerendert wird. Deshalb behält half-Life einfach die Bilddaten vom letzten Frame an dieser stelle bei.

Dies geschieht aber nur bei falscher Anwendung der NULL-Textur...

Hey, ich merks grad erst
"Anders als bei der herkömmlichen Weise mit der sky-Textur spart man mit null tatsächlich viele r_speeds ein!"
Ich hab Anhänger gefunden! ;-)
Noch vor 1-2 Wochen wollte mir das keiner glauben.

Nihil timeo, nulla re opprimor, nulli periculo cedo.
www.TheDoenerKing.de

Is aber eigentlich flasch, oder? r_speeds spart man keine. Aber Berechnungszeit. Sprich mehr FPS ;)

"[...] 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

jo, genau

Nihil timeo, nulla re opprimor, nulli periculo cedo.
www.TheDoenerKing.de

andrerseits verschwendet man auch keine polies (vorrausgesetzt die "himmelsrichtungen" bleiben die gleichen)

wenn man jetz ne sky box hat dann verbrauchen alle sky-flächen zusammen 12 (waren doch 12?) polies

wenn man allerdings nur von 5 seiten einen sky hat und dann eine fläche mit der sky textur belegt die nicht zu den 5 "himmelsrichtungen" gehört
sinds wieder 12, statt 10 die es mit den 5 flächen alleine war

Wenn du ne Skybox machst und nen Startpunkt reinsetzt, das ganze compilest und dann startest und dir die r_speeds anschaust, wirst du exakt 0 w_poly haben.

Sky-Textur erzeugt prinzipiell keine Plies, allerdings wird an der entsprechenden Stelle der Sky gerendert, was auf die FPS geht, selbst wenn anschließend andere Polies drübergerendert wurden.

voice - Ruhe in Frieden

Hmm, da ich mal davon ausgehe, dass ihr beide gebildete und intelligente Menschen seid (Verrückt muss man sein, gell ;-) schlussfolgere ich, dass ihr in diesen letzten 2 Posts aneinander vorbeigeredet habt.

Das Problem liegt hier wohl in der Definition von "polies".

das könnte einerseits eine Abkürzung für Polygone darstellen, oder sich auf die w_polys der r_speeds anzeige beziehen.

Im ersten Falle ist campersnightmares Post (fast) komplett richtig. Denn die Skybox besteht aus 6 quadratischen Flächen und polygone sind immer dreieckíg (zumindest bei Q-Engine) also 12 polygone.
Worin ich mir aber nicht so sicher währe, ist die Theorie aus dem 3. Absatz. Da der sky ja keine Leafs berührt, ist auch keine sichtbarkeitsberechnung möglich. Daher wird (afaik) einfach immer wenn sich ein brush mit sky-textur in deinem Sichtbarkeitsbereich befindet der komplette Sky (na gut, nur die 180° vor dir) gerendert. Mhhh da fällt mir ein: Weis einer von euch, ob bei der Frage ob der sky sichtbar ist Backface culling verwendet wird?

Wenn man aber mit polies w_polys meint, ist LePrau's Post richtig...

Nihil timeo, nulla re opprimor, nulli periculo cedo.
www.TheDoenerKing.de

Eh sagt mal werden auch die Texuren auf der Rückseite einer mauer die zum Void abgrenzt berechnet? (Also die texturen die uasi im aus sind?

Member der Huren GmbH | KillerKuh.com

wenn du eine mauer hast dessen rückseite ins void zeigt dann werden sie nicht berechnet
wenn du allerdings ne skybox drum hast dann kann man sie theoretisch sehen, diese faces werden berechnet

@fraghunter

Polygone sind nicht immer 3 eckig. Poly ist griechisch und heißt 'viel' demnach heißt Polygon VielEck und nicht dreieck. In der Q engine gibt es 3 Sorten von Polygonen, die w_polys, die e_poly und die polygone vom sky.

Da der Sky aus maximal 12 Polygonen besteht, egal wie die jetzt geartet sind, können wir den mal außen vor lassen. Die E_polys sind naturgemäß immer 3 eckig, weil die model-editoren das vorschreiben und alle models von milkshape & co direkt in 3ecke unterteilt werden.

Kommen wir zu den W_polys. Diese müssen, im gegensatz zu den e_polys NICHT 3eckig sein. Ich habe grade eine map gemacht mit 6 wänden und nem start drin --> 6 w_polys. Kannste ja nachprüfen, aber achte drauf, dass die wände <224 units groß sind *g*

Mal abgesehen davon glaube ich kaum, dass es einen halbwegs modernen PC (sprich > 500 mHz CPU und Voodoo3) kratzt, ob er jetzt nen sky oder so ein grafikgematsche sieht. Soviel Ressourcen frisst der sky echt nicht.

Wee - o - wee - o - weeee

nein, der sky nicht aber ich glaube, dass die berechnung der mit sky-textur belegten polys das ganze verlangsamt...

"Diese müssen, im gegensatz zu den e_polys NICHT 3eckig sein"

genau, aber ich spreche nicht von w_polys, sondern von Polygonen, die dann gerenert werden - und diese sind bei der Q-Enginge immer dreieckig. Und wenn die Wände 240 Units groß und mit ner 256x256 Textur belegt sind, gehts auch...

Und dieses Grafikgematsche, wie du das nennst ;-) wird garnicht berechnet - es kratz den halbwegs modernen PC also schon ob das ein Sky ist oder ein "gematsche" - egal wie einfach der Sky gerendert wird - er muss doch gerendert werden. Also kommt wohl jeder PC spätestens bei 6*10^23 Skys ins wanken, wogegen er unendlich viele "gematsche" rendern kann.

Und zu deinem griechischen Argument ( :D ):
Demagoge z.B. heist übersetzt auch Volksführer und dennoch ist es im deutschen der Volksverhetzer...

Nihil timeo, nulla re opprimor, nulli periculo cedo.
www.TheDoenerKing.de

Noch neFrage:

Nehmen wir an wir haben einen button an der wand das sollte so ausehen:

|
|
|
|--
|--
|
|

Also die gestrichelten linien sind der button...

Werden die Texturen die zwischen button und wand liegen eigentlich brechnet (die man ja noicht sehen kan...)

Member der Huren GmbH | KillerKuh.com

"Also die gestrichelten linien sind der button..."

hmm ich seh da nur gestrichelte linien :p hab aber verstanden was du meinst :)

[ maps: www.planet-zYk.de ]
[ contact: #zYk @ Quakenet ]

öhm ich denke ja weil der button ein entity ist und bei nem entity alle faces berechnet werden
falls du mit texturen die faces meinst
wenn nicht versteh ich nicht was du willst, da die texes entweder im speicher der graka sind, oder eben nicht, die werden nich groß berechnet

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

jo das mit den poligonen stimmt - es sind Vielecke -
das man aber dreiecke berechnet liegt daran , dass es die einfachste form der fläche ist . (klar ein 2eck ist ja nur ein strich und ein 4eck ist komplexer).

so kann der pc pracktisch lauter kleine portionen berechnen und die wände gestückelt darstellen.
sieht man wenn man mal eine extrem lange box macht mit beschränkter sichtweite in den mapoptions.
man sieht direkt in die skybox , weil die wände dazwischen nicht berechnet wurden.

töte tausende und du bist ein held -
töte einen und du bist ein mörder
chinesisches sprichwort
(da ist was faul)

Ich quetsch mich hier auch mal rein.
Die r_speeds sind... sagen wir mal: ungenau!

Also ein Polygon ist ein Vieleck. Das könnt ihr auch Paint fragen. Da gibts ein Polygon zeichnen ;) Zudem gibts in QuArK Polyeder (Vielflächner) auch bekannt unter dem Geistreichem namen "Brush". Also Poly = Viel.

Die w_polies geben die Anzahl der Polygone an, die zu dem Zeitpunkt berechnet werden. Das bedeutet aber noch lange nicht das die GraKa auch nur soviel Triangles (Dreiecke) berechnen muss. Deshalb hattich auch mal den Thread hier http://www.thewall.de/forum/showtopic.php?threadid=26878 geöffnet.

Dabei habbich auch die Skybox berechnen lassen: 0 w_polies. Das liegt daran, das der Sky auch nicht wirklich "Polies" hat! Dadurch das des Teil keine Paralaxe (Duke 3D Editor bildet ;)) besitz, kann man ihm sich nicht nähern und wird deshalb auch anders von der Engine verarbeitet. Das Teil fällt also unter die s(onder)_speeds, in denen auch die Sprites drin sind ;)

"[...] 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

ne jungs das meinte ich net...

ich meinte den (oder die?!) face die zwischen mauer und butoon liegt also die die man absolut nich sehen kann...

Member der Huren GmbH | KillerKuh.com

dann lies dir doch pl mal meinen post durch
der müsste richtig sein

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

hmmmm - mir gings nur m die speeds

Member der Huren GmbH | KillerKuh.com

nix berechnen=keine zusätzlichen r_speeds

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

Backfaces werden zudem garnet berechnet (Backface-Culling).

"[...] 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

@Bulldozer: Die nicht sichtbaren Flächen von Entities werden NICHT beim kompilieren entfernt. Es ist als durchaus möglich, dass die Rückseite deines Buttons auch mal (trotz backface-culling) berechnet werden muss, z.B. wenn neben dem Button eine Tür zu einem Nachbarraum ist, 'sieht' man aus diesem Nachbarraum die Rückseite des Buttons. Genau deswegen werden solche Flächen mit der NULL-Textur belegt. Man spart dadurch r_speeds, die Engine braucht einen backface-Test weniger zu machen und außerdem wird die BSP mit jeder entfernten Fläche ein ganz klein bisschen kleiner, was ja auch kein Nachteil ist.