Hi!

Seit ich vor ein paar Monaten angefangen habe für HL zu mappen, bin ich immer wieder auf diese r_speeds gestoßen! *g*

Auf so ziemlich jeder Mapping Site steht: Halt die r_speeds unter 800 oder besser noch unter 600...

Warum??

Ich habe CS maps gesehen, die obwohl sie an einigen Stellen wpolys um die 1000 hatten, selbst auf einem p2 300 mit 64mb ram und v2 flüssig liefen...

Und wer bitte hat einen schlechteren Computer, wenn er ernsthaft CS spielt???

Außerdem ist diese ganze r_speeds Geschichte doch irgendwie Quatsch, oder nicht?
Ich meine, so Tips wie: "Verwandle ein paar Dinge einfache in func_walls, das geht nur auf die epolys nicht auf die wpolys" sind doch Schwachsinn oder??
Die Performance wird dabei nicht anders!

Wieso sollte man also nicht r_speeds um 1000 haben??

Bin auf eure Antworten gespannt :)

Grüße, Waldi

brb waldi...
r_speeds sind beim hl editing das A und O. wer die vorgänge des compilens nicht versteht und nicht mit den verschiedensten polygonreduktionsmethoden zu arbeiten weiss steht doof da. warum jedoch alle immernoch auf der r_speed grenze von 800 beharren weiss ich nicht. da gebe ich dir recht, dieser wert kan inzwischen ohne probleme überschritten werden. doch habe ich das gefühl, das du den weg von der map zur bsp datei nicht kennst. du weisst nicht recht was der umfassende begriff -r_speed- beinhaltet. du solltest crids artikel auf <a href="http://www.crid.de" target="_blank"><!--autohttp-->http://www.crid.de</a><!--autohttp--> sowie meinen auf <a href="http://www.levelediting.de" target="_blank"><!--autohttp-->http://www.levelediting.de</a><!--autohttp--> lesen um zu verstehen was das ganze -getue- nützt.
fazit ist, das -die ganze r_speed geschichte- ganz sicher kein quatsch ist. viele hier im forum ua. the_rising, perfect, crid und ich haben sich lange mit diesem thema befasst und haben eineges -erforscht- und somit viele interesannte dinge über den überlagernden begriff -r_speed- herausgefunden. der begriff -r_speed- hat mit dem thema an sich wenig zu tun. er ist nur die bezeichnung der anzeige, welche einem die zZ zu berechnenden triangles angibt.

schlussfrage:
wie kommst du darauf, dass das alles relativer unsinn ist?

du solltest diese 2 artikel wirklich konzentriert lesen. wenn du sie durch hast wirst du auch wissen warum "Verwandle ein paar Dinge einfache in func_walls, das geht nur auf die epolys nicht auf die wpolys" eine menge performance bringen und kein schwachsinn sind.

Die sinnvolle Grenze von r_speeds. mhmhhhh?

Ich würde sagen alles was über 700-800 ist, ist einfach zu Hardwareabhängig. Einfach pauschal sagen 1000 ist ok finde ich nicht richtig. Ok, heute haben wir geforce2gtsddrsupergeil aber nicht alle. Gerade weil die allgemeine geschwindigkeit hardwareabhängig ist misst man doch mit einem harwareunabhängigen mittel, die r_speeds. Okay, man kann sagen das sie um 100 nach oben verschoben werden kann wenn die mehrheit ein system hat auf dem es nicht dahergeruckelt kommt. ich habe z. b. nur einen p3-500 und v3 und ich weiss das es viele gibt die das nichtmal haben.

Andere engine - andere grenzen. das ist logisch. aber man kann doch nicht hergehen und sagen weil es bei einer q3 eingine vieeel höher ist können wir die hl-grenzen auch anheben. die engine ist für computerverhältnisse ur-alt, das ist klar. sie macht einfach nicht genug polygone in einer aktzeptablen geschwindigkeit, hardware ist nicht alles!

ach ja, das r_speeds wichtig sind bezweifel ich aber nicht :)

Ok!
Ich werde die Artikel mal durchlesen!

Mit den func_walls spart man aber nur dadurch Performance, dass es keine Schatten gibt, oder?
Also nicht immer hilfreich...

Was ist denn eine gute Grenze???
1000 oder 1200 oder mehr???

Grüße, Waldi

Nein, nicht nur wegen dem Schatten. Weiss aber auch nicht mehr genau warum. Die engine kann glaub ich e-polis oder so besser (schneller) verarbeiten.

In singleplayer kann man die grenze 1000-1200 gelten lassen, aber im multiplayer gibt das ein gemetzel. MP würde ich sagen, dass 800 eine nicht schlechte grenze ist, jedoch ist darunter besser, solange die map nicht darunter leidet. Ich habe einen 500 MHz Computer ohne besondere 3D-Grafik Karte; Ich muss also im software modus spielen. Und das merkt man verdammt gut.

...denn das atombrot wird nicht ruhen bis es den letzten erwischt hat...

Also zu dem func_wall Zeugs:
angenommen du baust einen simplen Raum.
Stellst in die Mitte einen Cylinder, der den Boden berührt.
Wenn du dann in den Softwaremodus gehst und danach in der Konsole noch r_drawflat 1 eingibst wirst du feststellen,
dass die Polygone auf dem Boden "gesplittet" wurden! Sprich: Mehr Polygone zu berechnen <- höhere r_speeds. Das liegt an dem Cylinder. Wenn du den Cylinder jetzt in eine func_wall, oder eine func_breakabel oder sonst eine func_xxx setzt
und wieder kompilierst wirst du feststellen, dass der Bodenpolygone nicht mehr so stark gesplittet wurden (sie sind zwar immernoch in einzelne Vierecke aufgeteilt, die jedoch größer sind und nicht so viele Faces beinhalten, aber das liegt an dem texturealignment... ist ne andere sache).

Du siehst also mit Schatten hat das nix zu tun =) (Schatten, Helligkeit oder ähnliches beeinflusst auch nicht die r_speeds oder die generelle Geschwindigkeit).

Zu den Grenzen:
Für Multiplayermaps:

Wege und Orte wo wenig Action ist (wo sich nur wenige Spieler aufhalten) dürfen bis 600 Wpolys haben.
Stellen an denen Krieg herrscht und sich viele Player aufeinmal tummeln solltest du nur 300 bis 400 Wpolys haben.

Für Singleplayermaps:

Stellen an denen wenig Monster/Gegner oder sonstige 3D Figuren sind kannst du ruhig 800 Wpolys haben.
Stellen an denen viel Aktion ist (viele Gegner oder 3D Modelle) sollten höchstens 600 Wpolys haben.

Du musst auch immer an die Leute mit langsameren Rechnern denken. Da gibt es noch genug von!!

MfG,
TheVoice!

Against TCPA | Resourcecode.de | Blender 3D | [ Darkzone | Pandorra | Alpine ]

Na gut... das kann man aber auch umgehen, indem man halt alles mit einer Einheit Abstand baut...
Da brauch man nicht unbedingt func_walls, oder?

Nochmal zu den Grenzen:
300?????
Das scheint mir arg wenig...

Ok, es gibt Leute mit langsamen Computern, aber ich bezweifle mal, dass die dann ernsthaft CS spielen oder?

Und auf nem p2 300 (siehe oben) gibt selbst bei 1000 mit 2-3 Gegnern noch kein Geruckel...

Grüße, Waldi

Na gut... das kann man aber auch umgehen, indem man halt alles mit einer Einheit Abstand baut...
Da brauch man nicht unbedingt func_walls, oder?

Nochmal zu den Grenzen:
300?????
Das scheint mir arg wenig...

Ok, es gibt Leute mit langsamen Computern, aber ich bezweifle mal, dass die dann ernsthaft CS spielen oder?

Und auf nem p2 300 (siehe oben) gibt selbst bei 1000 mit 2-3 Gegnern noch kein Geruckel...

Grüße, Waldi

1. lichteinflüsse werden vorberechnet, werden nicht in echtzeit berechnet und fressen somit keine performance
2. functions werden nicht zu den epolys sondern zu den wpolys gezählt(!) einzig models(charaktäre, eingefügte details, waffen etc) sind epolys.
3. TheVoice: das ist nur bedingt richtig, wir hatten mal nen thread wo perfect und ich das auseinander genommen haben. sind aber zu keinem wahren ergebnis gelangt. auf jeden fall werden brushes NICHT in 224x224 grosse teile gesplittet wie es fälschlicherweise in crids artikel zu lesen ist.

Trotzdem beeinflussen die Texturen auch die Größe der Polygone!
Hier ein Beispiel aus meiner Mappingszene:

Ich hab mich mal gewundert weshalb in einer Map mit Customtexturen so hohe R_speeds (400) in einem einfachen Raum waren.
Es war nicht viel in dem Raum drin. Da merkte ich, dass die Texturen die ich benutzte sehr groß waren und ich sie im Mapeditor kleinergescaled habe damit es besser aussieht. Danach hab ich sie mal auf normalgröße gescaled und ich hatte wieder normale R_speeds.
Also hat das nix mit der Größe von der Textur zu tun, sondern die Größe die man gescaled hat beeinflusst die Polygongröße!

@Waldi:
Ob du es glaubst oder nicht 300 Wpolys für Multiplayermaps ist super! Und diese Orte können auch noch gut aussehen!!
Lad dir doch mal meine Map ( <a href="http://hllabs.net-games.com/filez/map.html" target="_blank"><!--auto-->http://hllabs.net-games.com/filez/map.html</a><!--auto--> ) runter und schau dir das mal an (mit r_speeds).
Ich finde die Map ist ein gutes Beispiel. Dazu ist noch zu sagen, dass Texturmacher und Mapper gut zusammenarbeiten müssen um beste Ergenbnisse (ein schönes Level mit wenig R_speeds) zu erzielen. Was ich damit meine:
Der Texturmacher sollte seine Texturen nicht so groß machen, dass der Mapper sie unendlich kleinscalen muss damit sie in die Map passen! Das würde hohe Wpolys zur Folge haben.

Against TCPA | Resourcecode.de | Blender 3D | [ Darkzone | Pandorra | Alpine ]

thevoice: weiss ich, du hast mich falsch verstanden. ich wollte nur sagen das es nicht stimmt, das sie in 224x224 unterteilt werden. wie genau haben wir mal in dem besagten thread herausgetüftelt. stichwort ist "individuell nach anordnung der leafs..." mehr dazu in dem thread.

Jetzt brauche ich aber auch nochmal eine Erklärung: wieso gehen denn die w_polys nach oben, wenn die Texturen größer sind??? Also sagen wir mal meine Textur hat Maximalgröße (256x256) und ich pappe sie auf einen Brush der Größe 256x256x256 (macht ein scaling von 1). Wieso sollten den nun weniger w_polys entstehen, wenn die Textur nur 128x128 groß wäre und auf dem Brush 4x wiederholt werden müsste? Oder hab ich Voice da jetzt falsch verstanden?

[ - Mindmotor.Studios - ]|[ - Poke646 - ]|[ - Spaceman - ]

an terms antwort sehe ich, dass er meinen polygonreduktionsartikel nicht gelesen hat(!) ein brush wird individuell nach der anordnung der leafs gesplittet. 256x256 ist -normalerweise- das max. wenn man eine textur jedoch auf das 40x hochscalt wird der zugehöhrige brush nurnoch sehr selten gesplittet da die texturwiederhohlungen um ein vielfaches gesunken sind. so lässt sich der standart prozess beeinflussen und performance sparen.

Und an Deiner großkotzigen Antwort merke ich, daß Du meine Frage nicht gelesen hast. Deinen Artikel (oder den von Crid, weiß nicht mehr so genau) habe ich sehr wohl gelesen, was ich nicht verstanden habe ist, wie die Originalgröße einer Textur einen Einfluß auf die r_speeds haben soll und dieses kleine Beispiel verdeutlicht, daß ich recht habe:

<img src="http://www.spaceman.de/half-life/r_speeds.jpg" border="0">

Wie man sehen kann, gibt es absolut keinen Unterschied zwischen der großen Textur (256x256), die nur einmal wiederholt wird auf einer 256x256 Wand oder der kleineren Textur (128x128 ), die auf jeder Wand 4x drauf ist. Im Gegenteil, der Wert ist bei der großen Textur sogar noch etwas niedriger (ich weiß nur nicht mehr, wofür genau "24/19" bei der r_speeds-Anzeige im Softwaremodus steht).

Also stimmt auch Eure Binsenweisheit nicht, daß das Hochskalieren von Texturen automatisch die w_polys runterschraubt. In meinem Beispiel würde es nämlich auch nichts bringen, die zweite Textur (128x128 ) auf den Faktor 2 zu scalen, dann hätte ich nämlich dasselbe wie auf dem linken Bild. Und daß an der Zahl 224 sehr wohl was dran ist, kann man auf den Screens auch ganz gut erkennen.

So, Ihr R_speed-Artikelschreiber, jetzt kommt mal von Eurem hohen Roß runter, schließlich habt Ihr da nicht die Bibel verfasst. Ich könnte ja auch mal einen umfassenden Artikel über das Erstellen von Texturen schreiben und dann jeden anmaulen, der ihn (scheinbar) nicht gelesen hat. Dies soll nicht heissen, daß man die Artikel nicht lesen soll, aber es gibt den Verfassern auch nicht das Recht, jeden anzupflaumen der eine weitere Frage dazu hat.

Zum eigentlichen Thema: also die Grenze von 300-400 finde ich auch stark übertrieben, schließlich haben sogar Originalkarten wie z.B. die "subtransit" Stellen mit weit über 800 w_polys. Und Valve ist damals von einem 166Mhz-Prozessor als Standard ausgegangen (sagen sie zumindest selber), also können wir heute getrost an der 1000er-Grenze kratzen, denke ich. Wer ernsthaft zocken will und noch mit 166 PS unterwegs ist, ist dann echt selber schuld. Außerdem finde ich es gerade spannend, ein Spiel das verhältnismäßig alt ist, durch das Ausreizen der Engine aufzuwerten (mehr Texturen dank größerer Grafikkarten, mehr Archtektur und Details dank schnelleren Rechnern) und somit wieder konkurrenzfähig zu machen. My 0.02$.

[ - Mindmotor.Studios - ]|[ - Poke646 - ]|[ - Spaceman - ]

so viel ich weiß muss man die Texturen auf eine Größe von über 256x256 scalen damit es die größe der Poligon beeinflusst wird.

also, jetzt versteh i nix meeehr...
wenn die Größe der brushes nach dem Compilevorgang (und darauf kommts doch an) nur von der Anordnung der Leaf´s abhängt, dann dürfte die Texturengröße wirklich nichts beeinflussen, denn seit wann beeinflussen Texturen die Leafs ? die werden doch schon von den Compilern aufgeklebt ? dachte ich zumindest immer...und dann hat Term wohl recht. Vielleicht sollten sich mal ein paar Coding-Gurus der Sache annehmen und uns arme Mapper aufklären.

Sig as a brick ┴┬┴┬┴┬┴┬┴┬┴┬┴
WW

errm term, 1. übertreibst du wohl etwas was meine grosskotzigkeit angeht und 2. verstehe ich dich nur teilweise.
natürlich besteht kein unterschied zwischen einer textur die 256x256 1xscale und einer 128x128 2xscale. die texturwiederhohlungen folgen bei beiden texturen nach 256 units, somit auch die splittung. um dein recht zu verundeutlichen+g* mach doch mal eine map mit einer 256x1 textur und einer 256x40 textur. die wand mit der standartmässigen 256 textur wird nach 256units gespilttet, die andere mit der selben textur welche jedoch auf 40x hochgescalt wurde wird erst nach 10240units gespittet, damit dürfte das geklärt sein der?
sei nicht so sauer, du bist einer der einzigen hier, die mich noch halbwegs -in schwung- halten*g*
such auch mal den thread:
"jede texturwiederhohlungen=bruhes splitten?"
hier die addresse:
http://www.thewall.de/ultraboard/UltraBoard.pl?Action=ShowPost&Board=allgemein&Post=1358&Idle=45&Sort=0&Order=Descend&Page=0&Session=

dort hatten perfect und ich einige -krasse- sachen herausgefunden. die idee kam mir aufgrund der tatsache, dass der software renderer -eigendlich- keine texturwiederhohlungen auf einem brush vornehmen kann. ist wirklich interresant finde ich. wir sind allerdings noch zu keinem schluss gekommen. wenn du eine idee dazu hast lass es mich wissen (der thrad lässt sich nichtmehr"nach oben hohlen" da er geschrieben wurde bevor dieser komisch fehler das halbe board gekillt hat.)

@ warewolf, les du auch den thrad....ich würde gern daran weiter-forschen-. leider ist perfect (coder) im mom weg und kommt erst weihnachten wieder:,(

um meine etwas gereizte antwort zu term ein wenig zu rechtfertigen kann ich nur sagen, das ständig fragen bei mir eintrudeln in denen vieles gefragt wird was auf meiner page und insbesondere in meinem artikel beantwortet sind. das frustriert eben und senkt die lust sich ständig den arsch für seine page aufzureissen...sorry wenn ich arrogant klinge, das ist für gewöhnlich etwas, was ich verabscheuhe...

Also ich glaube, dass ich schuld bin dass Term so ein bissl durcheinander ist =)

Ich hab da glaube ich einen Satz formuliert, den anscheinend nur Linga halbwegs verstanden hat... *g*
Eigentlich meinte ich es ja so:

Wenn ich eine Teppichtextur habe die 256x256 groß ist und mir ist das Teppichmuster einfach zu groß gemalt worden (nämlich genau so groß wie die Textur), dann scale ich das Ding erstmal runter! Das SCALEN hat zur Folge, dass der Brush öfter gesplittet wird! Mit der Texturgröße hat das rein garnix zu tun!!

Für alle die sich immernoch fragen Wie die Brushes jetzt abhängig vom Scalen gesplittet wurden kann ich nur den Mapeditot QuArK empfehlen!!
Es ist nämlich bei QuArK so, dass man gleich Sieht wie der Brush beim scalen gesplittet wird (da ist dann immer ein Gitter über den Brush, das das einzeigt... wenn ich mich nicht irre... kann gut sein, dass ich mich irre * hab das noch nie nachgeforscht ob das stimmt was ich jetzt gesagt hab *

Ok Linga ich werd mir euer Topic auch mal anschauen und versuchen einen Schluss zu finden =) aber lasst uns dieses Thema abschließen... ich glaube wir birngen zu viele Leute damit durcheinander...

und jetzt mal @WareWolf:

Was haben denn die Coder mit den R_speeds zu tun ???
Ich bin selber Coder (und Mapper) einer Mod und habe beim Coden eigentlich nix mit den R_speeds zu tun.

Against TCPA | Resourcecode.de | Blender 3D | [ Darkzone | Pandorra | Alpine ]

aber coder können anhand des compile-tool-source-codes die vorgänge genau nachlesen

Na gut... überredet =)

PS:
Ich hab mal in meinem Profil nachgeschaut und gesehen, dass ich nur 112 Postings hab...
Das liegt daran, dass ich meinen Namen des öfteren gewechselst habe... kann ich die alten Posts auch in mein neues Profil übertragen ??

Against TCPA | Resourcecode.de | Blender 3D | [ Darkzone | Pandorra | Alpine ]

nö