Wenn ich einen normalen block(brush) erstelle was ist er standardmäßig,
func_wall oder func_detail??Oder garnichts von beiden?
Interessiert mich halt nur, weil nicht das es standardmäßig func_detail ist , wäre ja nit ganz so... toll!
wäre nett,wenn es mir jemand beantworten kann.....
mfg
und schon vorraussichtlich!
danke...danke...

Brushes sind worldspawn ( sie haben keine funktion, sind solid und blocken das vising ), also weder func_wall noch func_detail welche zu den entitys gehören.

There is nothing wrong with high standards. It's your problem that you don't meet them.
If you think it's simple, then you have misunderstood the problem.
When a customer says "nothing has changed", assume they're lying.

Diese frisch erstellten Brushes werden auch World-Brushes genannt. Damit ein Brush überhaupt ein func_detail bzw func_wall wird, musst du ihn mit "Tie to Entity" erst einem Entity zuweisen.

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

Das sollte man übrigens mit jedem Brush machen der weder eine Wand, ein Boden noch eine Decke ist.

Mal mich voll!

Und was hat man dann davon? Ist es nicht eigentlich wurst ob ein Brush nun als Worldbrush oder als Entity Brush Resourcen frisst, oder hat man dadurch einen Performance Vorteil? Und wenn ja, inwieweit ungefähr?

Teilweise habe ich auch schlechte Kollisionen bemerkt. Z.B. fielen bei CSS tote Spieler einfach durch ein func_wall hindurch, obwohl ich so weit ich mich erinnere die Kollisionen nicht deaktiviert hatte.

Muh sag ich da!
----------------------
All das ist thewall: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 |

@NighTWolf: Das die Spieler durch func_walls fallen, liegt wahrscheinlich an diesem Problem: http://www.thewall.de/forum/showtopic.php?threadid=44881

Grundsätzlich solle man alles was eben nicht zur Sichtbegrenzung dient (Schräge Wände, Vorsprünge, Ecken, Säulen, etc.) zu func_details machen.
Dadurch lässt vvis diese beim kompilieren weg und fügt diese später wieder als Details für vrad zum beleuchten ein.

Zu func_wall sollte man es nur machen, wenn der Brush auch einen Namen braucht oder einen Parent hat. Ansonsten verhalten sich func_detail und func_wall gleich (ausser bei der Ausnahme aus meinem Thread oben...)

Vor der Umstellung als Alatron bekannt

Aber wenn vvis sie ignoriert dann können sie ja eigentlich keine vis blocker mehr darstellen, wodurch sie praktisch genauso wie z.B. models behandelt werden und keine leaf abgrenzung mehr bieten, wodurch die ganze map ein einziges leaf ist. Oder rede ich gerad Bullshit?

Ich glaub ich hab gerad ne riesen Wissenslücke bei mir entdeckt. Gleich nochmal ein Tut dazu suchen. :)

Ach ja, so ein ähnliches Problem mit der Pflanze hatte ich mal mit einer Lampe . Ich habe es so gelöst, dass ich über dem Tisch eine kleine func_brush platte gebaut hab und den tisch als parent setzte. So konnte er sogar seine dynamik behalten (ansonsten fiel bei mir immer die Lampe durch).

Muh sag ich da!
----------------------
All das ist thewall: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 |

@Technofreak und Alatron: Ich denke ihr liegt falsch.
Wenn man alle "unnötigen" Brushes zu func_walls (oder func_details) macht werden alle Seiten berechnet. Diesem kann man natürlich ausweichen, indem man die Nodraw Textur auf alle Seiten legt, die man ned sieht. Allerdings wird dann immer noch das Plane (vom World-Brush) dahinter berechnet!
Func_walls bekommen außerdem von RAD keine Schatten spendiert.
(Wie es mit der Kollision is' weiß ich ned...)

Func_details bekommen zwar Schatten, allerdings bleibt bei ihnen immer noch das Problem der berechneten Seiten.

func_detail sind zwar praktisch, weil sie eben bei VIS ned beachten werden, und die Leafs ned unnötig zersägen, aber soweit zu gehen und zu sagen: "alles was nicht Wand, Decke oder Boden ist soll ein func_detail sein" würde ich auch wieder ned gehen ;)

äh... ich geh' jetzt schlafen.

Resetting politics:
http://www.onlinepartei.eu

Zitat:

Aber wenn vvis sie ignoriert dann können sie ja eigentlich keine vis blocker mehr darstellen, wodurch sie praktisch genauso wie z.B. models behandelt werden und keine leaf abgrenzung mehr bieten, wodurch die ganze map ein einziges leaf ist. Oder rede ich gerad Bullshit?

Zitat:

Func_details bekommen zwar Schatten, allerdings bleibt bei ihnen immer noch das Problem der berechneten Seiten.

Und jetzt stellen wir uns vor, was wäre, wenn es kein Würfel, sondern eine Treppe wäre:
Viel mehr Leafs, viel mehr unterteilungen. Beim func_detail wird gerade bei so etwas ersichtlich, wofür er da ist: Nicht sichtbare faces werden rausgeworfen, die sichtbaren splitten aber auch nicht auf.
Bei einer Säule, die mitten um Raum steht, ist das natürlich nicht so ersichtlich, da alle faces berechnet werden (ausser der ober und unterseite, wenn sie direkt auf dem Boden/an der Decke steht). Aber trotzdem, sie splittet eben nicht alle leafs auf, was der Hauptpunkt ist.

Edit: Um das ganze noch ein wenig zu verdeutlichen, hab ich gerade mal Screenshots meiner aktuellen Map gemacht:
Der erhöhte Sockel, die Treppe, der Zigarettenautomat: alles func_detail.

Hier sieht man, dass alle faces, die nicht sichtbar sind, auch weggelassen werden.

Vor der Umstellung als Alatron bekannt

Also, func_wall und func_detail nicht für Böden und wände decke... benutzen sondern nur für Gegenstände, z.b einen Pfeiler

Jup, dachte mir schon das es so ist. Wunderte mich nur ab und an das manche erzählen dass es am besten ist seine halbe map zu einem entity zu machen.

Muh sag ich da!
----------------------
All das ist thewall: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 |

Ist auch besser. Bei manchen Konstruktionen zerbricht sich Vis tagelang den Kopf und rechnet am Ende trotzdem nur Müll, was vorallem bei Zylindern etc. zu einem Problem werden kann.

Es gibt 2 Möglichkeiten, eine Kristallkugel zu benutzen:
a) um damit Spekulationen über ein Problem eines Users zu machen und
b) um sie einem besonders unkooperativen User über den Schädel zu ziehen.
- bloggt jetzt auch selbst auf Sclavia.de