guten tag.
ich hab mir ne grosse map gemacht die fast nur aus blöcken besteht...
w-poly-count ist 1500..
wie kann ich die anzahl der w-poly verringern?
darf ich keine blöcke ineinander tun oder wie geht das?
aus dem r_speeds artikel werd ich ned schlau...
gruss

... definiere "gross" ...
... und Forensuche hat dir nicht weitergeholfen ... ?

god is real - unless declared integer

"gross" hm die hälfte vom maximum die man im hammer machen kann... ne nix geholfen :(

Mhm, r_speed Artikel nohmal lesen, anders gehts nicht.
Wenn du weisst wie die Engine aus den Blöcken in WC die wpolys macht, dann kannst du die Blöcke viel schonender zusammenstecken.
Zum Beispiel wüsstest du dann dass es nicht so wichtig ist _das_ die Blöcke ineinader geschoben sind (das ist zwar nicht belanglos, aber nicht ganz so wichtig im Zusammenhang mit r_speeds) sondern _wie_ die Blöcke ineinander geschoben sind. Solange durch das Ineinanderschieben der größere Block nur wenig zerschnitten wird ist alles in Ordnung, aber wenn du den z.B. schräg rein machst oder irgendwie verquer, dann steigen die polys ins unermessliche (da ist es dann egal ob die Blöcke ineinader geschoben sind oder nur aneinander liegen - zerschneiden tun sie sich gleichermaßen).

Der Optimist glaubt, dass wir in der Besten aller Welten leben.
Der Pessimist fürchtet, dass dies stimmt.

die grössten blöcke sind alle nicht zerstschnitten, nur die kleinen, jemand hat mir gesagt ich solll alle kleinen auf func_wall setzen bringt das was?

Ich erkläre das mal: Die Compiler nehmen sich deine Map vor und schauen wo "Innen" und "Außen" ist (daher der Fehler "Leak", wenn durch ein Loch in der Map mathematisch kein Innen/außen ersichtlich ist. Wenn die Compiler das "Innere" für sich definiert haben, versuchen sie alle Brushseiten (Die Brushs sind ab hier nur noch ihre Seiten, die einzeln zu sehen sind), die im Spiel definitiv nicht zu sehen sind zu löschen. D.h. der komplette Außenbereich wird entfernt und im Inneren beginnt die Schälerei. Wenn du z.B. eine Säule auf dem Boden stehen hast, wissen die Compiler dass unter der Säule der Boden nicht zu sehen ist. Da aber konkave (nach Innen gewölbte) Flächen in Half-Life nicht berechnet werden können, müssen die Compiler den Boden in Stück teilen, die nicht konkav sind und zusammen einen Boden mit rundem Loch ergeben. Dies führt zu den vielen wirr anzusehenden Einzelstücken, die die r_speeds in die Höhe treiben. Die Compiler ignorieren dabei allerdings Entites, weil diese mit Hilfe eines env_renders oder trigger_relays unsichtbar gemacht oder gelöscht werden können und so das dahinterliegende sichtbar sein muss. Wenn die Säule also zu einem func_wall gemacht wird, wissen die Compiler, dass der Boden unter der Säule durchgehend sichtbar ist und so bleibt dieser ganz. Du musst also versuchen, immer dann, wenn ein konvexes (nach außen gewölbtes) Objekt eine Fläche in eine konkave Fläche zwingen würde, die Berührung der Objekte zu vermeiden, oder aber das konvexe Objekt zu einem Entity zu machen. Das gilt natürlich auch für Lampen oder Schalter die ein tetragones (viereckiges) Loch in eine Fläche schneiden würden. Wichtig ist nur zu wissen, dass nach innen gewölbt nicht geht und alles nach innen gewölbte später in Einzelteile zerlegt wird.

okay