Ich bin zurzeit dabei Methoden zu suchen, welche meine r_speed runtersetzen...
habe jetzt auf dieser Seite gelesen:

Func_Walls....
…genausowenig als Visblocker innerhalb der Map (für die Kompiler sind ausschließlich die World-Brushes relevant!).

Her habe ich diesen Satz von: http://www.thewall.de/content/half-life:tutorials:r_speeds

also entweder habe ich da was falsch verstanden, oder es stimmt nicht was da steht.

Ich habe mir mit der funktion gl_wireframe 2 die polys anzeigen lassen, die ich nicht sehe, die aber trotzdem berechnet werden...
dann habe ich stellen, hinter denen zu viel berechnet wurde als func_wall editiert und sofort wurde hinter den Wänden nichts mehr berechnet.

Jetzt wollte ich wissen ob meine Beobachtung richtig war...
ob Func_Walls die w_poly wirklich runtertreiben durch verhindern der Berechnung von Polys hinter ihnen

und dann noch warum ich nicht einfach aufgrunddessen sogut wie die ganze map als wall bezeichne...irgendwelche Nachteile müssen mir dann ja entstehen, das ich auf eine so einfache Optimierung der r_speed verzichte.

Ein Nachteil kenne ich....
Func_Walls werfen keine Schatten.

Ich bin über jede Hilfe dankbar
MFG Jamye

Der Computer rechnet mit allem....
ausser mit seinem Nutzer.

Fakt: Entities werden von VIS nicht in die Sichtbarkeitsberechnung einbezogen und können daher nicht dazu eingesetzt werden diese zu beeinflussen.

Deine Beobachtung muss also durch etwas anderes zustande gekommen sein (hast du auch mal auf die r_speeds geschaut oder nur das, was du gesehen hast, als Indikator genommen?). func_walls blocken die Visibility auf jeden Fall nicht.
Des weiteren zählen sämtliche sichtbare brushbasierte Entities als Models (drücken aufs Modellimit) und deren Faces gehen in die e_polies ein (die ebenfalls gerendert werden müssen).

Zitat:

und dann noch warum ich nicht einfach aufgrunddessen sogut wie die ganze map als wall bezeichne...irgendwelche Nachteile müssen mir dann ja entstehen, das ich auf eine so einfache Optimierung der r_speed verzichte.

Du solltest dich für den Anfang erstmal aufs Mappen konzentrieren. Optimierungen kannst du im Nachhinein immer noch anbringen wenn es nötig ist (deine ersten Maps baust du eh für die Tonne). Das Gefühl für die Engine-Beschränkungen entwickelt sich mit der Zeit.
Es ist natürlich gut, dass du dich versuchst vorab zu informieren. Aber auch beim Mappen gilt "probieren geht über studieren".

The C language combines all the power of assembly language with all the ease-of-use of assembly language.
"humorig is n blödwort :>" by -CarniGGeLjumpR-

Genau deswegen probier ich ja auch...

Also ich hatte bei r speed geguckt und war im Hauptraum auf ca. 8 - 900 w-polys

Dann bin im im open-gl modus in den singleplayer gegangen und habe festellen müssen, nachdem ich in die Console gl_wireframe 2 eingegeben habe, das sogut wie alles in der mapp selbst alles was ich nicht sehe mitberechnet wird.

Darauf habe ich aus Spaß eine Trennwand, die zu einem Treppengang führt als Func_Wall definiert. Neu Complimiert etc...
Wieder im gl_wireframe 2 modus gestartet und konnte die polys der Treppe nicht mehr durch die Trennwand sehen, was ja so viel heißt, wie das sie nicht mehr berechnet werden.

Dann habe ich einmal die kompletten Wände als func_waal definiert und habe nocheinmal alles gestartet und sie da, meine w-polys haben maximal noch 500 erreicht.

Ich versteh ja selber nicht wie es dazu kommt, aber wenn du mir nicht glaubst, dann mach ich gerne einmal Fotos davon und verlink die hier.

mfg Jamye

Der Computer rechnet mit allem....
ausser mit seinem Nutzer.

Bilder würden definitiv etwas Licht ins Dunkel bringen.

Wobei du beachten solltest, dass beim Anzeige-Modus gl_wireframe 2 Entities (z.B. dein func_wall) über den Gitterlinien dargestellt wird, was aber noch lange nicht heisst, dass der Hintergrund dann auch nicht berechnet wird.

btw: Auch Brush-Entities erzeugen w_polys. ;)

edit: Ein zusätzlicher Nachteil von func_walls ist, dass diese zusätzliche Clipnodes erzeugen, z.B. Flächen die an Wände anliegen, die der Spieler sowieso nicht berühren kann, welche aber trotzdem berechnet werden.

Richman's Hazardous Course - Status: 100% !!!
www.richmans-maps.ch.vu - wieder online!

hmm ic hhatte gelesen das ich damit genau sehen kann was berechnet wird und was nicht....wenn ich mich darauf nicht verlassen kann, dann bringen ja auch die bilder nichts hmmm ^.^

Der Computer rechnet mit allem....
ausser mit seinem Nutzer.

Die zusätzlichen Clipnodes kann aber wieder mit nem dicken "clip-block" loswerden.

http://www.naturalselection2.com/

Das stimmt eben nicht. Da ein CLIP Brush entweder WORLD oder ENTITY sein muss. Wenn du jetzt einfach über den func_wall einen WORLD-CLIP-Brush platzierst, erzeugst du mehr WORLD-CLIPS während die ENTITY-CLIPs des func_walls erhalten bleiben.
Machst du den CLIP-Brush dem func_wall hinzu, kann er zwar die ENTITY-CLIPS des Entitys reduzieren, Total hast aber trotzdem mehr CLIPs als wenn alles Worldbrushes wären.

Gesamthaft macht die Differenz aber sicherlich einen vernachlässigbaren Anteil aus, vorausgesetzt, man übertreibt es nicht (ich rede hier von Erfahrung ;).

Für besseres Verständnis der CLIP-Nodes siehe hier: Glossar: Clipnode

Richman's Hazardous Course - Status: 100% !!!
www.richmans-maps.ch.vu - wieder online!

Okaaay, das wusste ich nicht hehe ich dachte die wären dazu da xD

http://www.naturalselection2.com/