also ich hab ne map gebastelt aber die wird in tausende stücke zerhackt nach dem compile. damit ihr wisst was ich meine hier nen ingame pic.

nun hab ich lang nachgedacht und da kam mir eine idee diese recht komplexen wände zu ner func_wall zu machen dahinter enganliegende sky. sky wegen r_speeds. dann wollt ich noch nen key in die fgd einfügen damit func walls mit in die licht berechnung mit einbezogen werden. damit wollt ich erstens die r_speeds senken zweitens wollt ich das zerschneiden der wände verhindern. nun wollt ich fragen ob das sinn macht was ich da baue. also hier noch nen pic aus wc damit ihr es auch besser vorstellen könnt was ich meine.

wenns kein sinn macht dann hör ich auf.
mich intressiert wirklich ob das sinn macht.

alles was in komplexen Karten die r_speeds senkt ist sinnvoll!
Aber deine Karte ist nicht gerade komplex, also benötigts du das net!
Aber für viele andere, wie mich :), währe diese Methode eine gewaltige Senkung der r_speeds!

nach dem compile ist jede ecke in so viele stücke zerhackt deswegen hats mich gestört weil es sch***** aussah. deswegen auch die frage obs sinn macht. die map ist schon nen bissel komplex.

p.s: die map hatte maximal 550 w_polys trotz dessen das alle ecken und wände zerschnitten wurden. aber ich fand das war doch schon recht viel die 550 w_polys.

ich hab den gleichen Waffenersatz :D

weiss denn keiner ob die methode die r_speeds senken oder steigen lässt.

ps ich hab nen shotgun sound als schuss sound und nen von blau lila ins orangene gehende muzzleflash. und graue patronen mit nem roten punkt drauf*g*

.....kannst Du nochmal nen screenshot mit "gl_wireframe 1" machen (von der Mapversion ohne die func_walls)? Dann könnte man die Polygone sehen und die Sache etwas genauer beurteilen. Aber wenn ich mir das Layout so anschaue, kann ich keine Notwendigkeit für func_walls erkennen...

crid

Ausserdem ist die Berechnung (compile) von brushbasierten entitys (zB func_wall) identisch mit der von worldbrushs. Also komplexe funcs zerschneiden sich selbst genauso wie brushs auch, nur wordbrushs und entitys zerschneiden sich nicht, wenn sie sich kreuzen. Allerdings haben sie den Nachteil, das ihre Rückwände immer mitberechnet werden und sie nicht als visblocker dienen. Daher dürfte das Ganze bei Dir eher unangebracht sein.
Man kann die Zerstückelung Deiner Wand aber wirklich nicht genau erkennen, so wie von Crid angesprochen. Ich tippe ja mal darauf, daß sich Deine brushs überschneiden.

... bei meinem "StarshipTroopers-M41" hab ich nur die Textur geändert...

aber zur map: auf dem ersten pic kann man die zerstückelung noch erkennen, da passen die texturen wohl nich so ganz.
ich würde es aber auch eher so machen, dass man normale brushes nimmt, die aber nich überschneiden lässt, sondern die Enden mit dem Clip-Tool im Gerungsverfahren zusammenfügt (zu deutsch: abschneiden).

Dann würdst die Polygonzahl beibehalten, die Faces aber zumindest verringern (glaub ich *g*).

MfG,
Recon aka =SF=Daywalker | Daywalkers LCARS Page

Leute, wenn ihr mir noch eine letzte Gnade erfüllen wollt...
Tutorials | Entity-Bibliothek | Thread-Suche ... danke

...ich vermute auch mal, daß Du da beim Vertexen der Rohrecken etwas "gemurxt" hast (gebogene Faces etc.)...

crid

also hier noch mal pics mit gl_wireframe 1
ich hab nicht einmal gevertext ich hab immer geclippt weil ich sowieso immer zu faul bin die texes richtig zu ziehen. also kann ich beim vertexen nicht gemurxt haben*g*





und hier nen pic von der waffe *g* mit muni und sprite

das sieht so aus, als hättest du gecarvt... *TADEL*

ansonsten würd ich bei meinem vorherigen Vorschlag bleiben, die Zerstückelung lässt sich nich umgehen, da du ja konkave Flächen hast...

MfG,
Recon aka =SF=Daywalker | Daywalkers LCARS Page

Leute, wenn ihr mir noch eine letzte Gnade erfüllen wollt...
Tutorials | Entity-Bibliothek | Thread-Suche ... danke

An den Ecken scheinen einige Brushes schon irgendwie nicht ganz zu passen. Aber das ist einfach ein allgemeines Problem bei schräg im Raum liegenden Brushes, die dann auch noch schräg abgeschnitten sind. Da findet man selbst bei Rastergröße 1 nicht für alle vier Vertices einer Fläche geometrisch exakt passende Rasterpunkte. Und Teilweise scheinen die Röhren selbst nicht mal rechtwinklig zueinander zu stehen, geschweige denn parallel zum Raster zu liegen --> in allen drei Achsen gekippte Flächen. An solchen Stellen stößt auch das sonst recht exakte Clipping-Tool an seine Grenzen --> Vertices nicht exakt auf dem Raster (hier sowieso nicht möglich) --> zig Nachkommastellen bei den Koordinaten --> Rundungsfehler beim Kompilieren --> Brush-Häckselmaschine

Was die r_speeds angeht: das scheint ja eine Kreuzung von mehreren solchen Röhren zu sein. Da ist's eigentlich kein Wunder, daß sich recht hohe Poly-Werte ergeben. Jede Röhre besteht für sich schon mal aus 18 Segmenten. Das ergibt je 240 Units Länge mindestens 36 w-polys. Dann noch die Splitter an den Ecken uswusw......

crid

mich als nub würd interresieren wie du die röhren gemappt hast, (nur das prinzip und welches prog)

"Wenn schon Sklave, dann überzeugter Sklave" - Steindl über techn. Zeichner

der trick des ganzen ist eigentlich das diese "röhren" aussen eckig aber innen rund sind. jede fläche ist nen geclipter block. und damit ihr euch vergewissern könnt das ich exackt gearbeitet hab. hab ich die map mal hochgeladen.
http://www.karasawa.de.vu/rtest.zip
eins kotzt mich mittlerweile an mindestens fünf maps sind daran gescheitert das hl meine architektur nicht verkraftet hat. jedesmal wurden meine maps in unschöne teile zerstückelt. es lag nicht an zu hohen r_speeds oder zu hoher sichtweite. es lag jedemal daran das die maps absolut scheisse nach dem compile aussahen. bei mir war noch nie irgendwas nen einfacher block *g*.