In zhlt hab ich folgende gelesen:

[-maxnodesize n]
Sets the largest size a portal can be. The default value is 1024. Larger values can help speed up the
compile process at the cost of r_speeds, and lower values can do the opposite. Efficiveness varies
greatly with the map.

stimmt es, dass man damit r_speed verbessern kann und wenn wo muß ich das dann dranhängen?

hm...vielleicht verarscht dich zoner*g*, ne... schau mal in der zoner tools-readme, da stehen viele zhlt fehlermeldungen....

Das ist gar keine Fehlermeldung sondern ein Parameter für qbsp.exe . Kurze Erklärung dazu: qbsp zerteilt ganz zu Anfang die gesamte Map in 1024x1024 Einheiten große Teilstücke. Diese werden dann im weiteren Verlauf weiter unterteilt (vgl. dazu auch: r_speeds-Artikel und den "r_speeds-Artikel/Gedanken zu vis"-Post im Allgemeinen Forum), um letztendlich die "Leafs" zu erstellen. Wenn Du nun qbsp z.B. mit dem Parameter "-maxnodesize 1536" laufen läßt, wird die Map nicht in 1024x1024 große Einheiten unterteilt (1024 ist der Standardwert), sondern in 1536x1536 große. Je größer dieser Wert gewählt wird, umso gröber wird letztendlich die Aufteilung der Map in Leafs (--> in der Regel schlechtere r_speeds), allerdings dauert das Kompilieren nicht so lange. Wenn man den Wert kleiner als 1024 wählt, kann das dann die gegenteiligen Folgen haben (bessere r_speeds, aber längere Kompilierdauer). Die Betonung liegt aber ausdrücklich auf "KANN", da -wie Zoner das ja schon schreibt- die resultierenden Effekte sehr stark von der jeweiligen Map abhängen, Patentrezepte kann man da nicht geben. --> Probieren geht über Studieren.

PS: Ich vermute, daß die Zahlenwerte des Parameters ein Vielfaches von 16 sein müssen.

[BSE] crid

Compile-Errors-Artikel (Version 09-01)

http://www.crid.de oder http://www-public.tu-bs.de:8080/~y0009981/

LOOOL, das hab ich wohl verpeilt=) sorry

hey thx crid

Hiho ich würde eher schätzen das das Ganze in 1024 gehen muß, denn 256 lief einwandfrei während 240 sich bei 90% Make Scales totrechnet :(

........jo, kann gut sein. Sollte man sich auf jeden Fall merken. Ich denke auch, daß 16er-Abstufungen bei diesem Parameter dann doch etwas übertrieben wären, da man die Ergebnisse ja doch nicht so genau voraussagen kann bzw. dieser Parameter nur für die allererste Aufsplittung der Map verwendet wird, und diese ja dann noch viel weiter geht....

[BSE] crid

Compile-Errors-Artikel (Version 09-01)

http://www.crid.de oder http://www-public.tu-bs.de:8080/~y0009981/

also ich hab da mal -maxnodesize 512 genommen um die r_speeds zu steigern, aber hlvis (full) hat sich totgerechnet... nach knapp 30 std compiling hab ich dann abgebrochen... hat jemand vielleicht ne ahnung was ein annehmbarer wert waere?

....wenn es keinen zwingenden Grund gibt, würde ich diesen Parameter überhaupt nicht verwenden --> wird dann standardmässig mit 1024 angenommen...

[BSE] crid

Compile-Errors-Artikel (Version 09-01)

http://www.crid.de oder http://www-public.tu-bs.de:8080/~y0009981/

kann mir mal jemand sagan wie ich nub das genau mach?
also wo kann ich den Wert umstellen und was wäre ein möglicher Wert wenn in meine Map unbedingt noch ein paar sachen rein müssen?
Ich habe die Halle unserer Lan nachgebaut und da müssen einfach alle details stimmen...nur das gibt der Editor nicht her...
Ich muss unbedingt mehr entenys und mehr Brushes einbauen.
HIIIIILLLLLLLLLFFFFFFEEEEEEEEEEEEEEEEEE!

und nun?

wenn dus für ne lan baust is der speed doch eigntlich scheissegal (ausser irgendjemand krebst mit nem schlechten rechner rum)

wie du es verwendest:
du gibst es unter den parametern von "hlbsp" an ... einfach " -maxnodesize 256" oder so dahintersetzen !

wenn du net weisst, wie man des macht ... vergiss es ;)

ps:viele "details" kann man über texturen sehr gut regeln ... notfalls modeln

... die nodesize muß höchstwahrscheinlich zu Basis 2 gewählt werden ... also 2, 4, 8, 16, 32, 64 (diese Werte dürften natürlich WAHNSINN sein ... ;), 128, 265, 512, 1024, 2048 etc ...

@Bino

... RealLife Sachen 'nachbauen' gibt immer Probleme mit den r_speeds ... wer hat so schön in seiner SIG stehen "Das menschliche Auge kann problemlos 2000 W-Polies verarbeiten ..." - die HL-Engine leider überhaupt nicht ... :(

[EDIT]
... werd's heute abend mal probieren ... aber mit maßvollen 512 ... =)

god is real - unless declared integer

Dank an [PDL]MrJ für's "Aufmerksammachen" & BSE_crid für's "Mutmachen" ;) !

... ich hab mal eine Map mit "hlbsp.exe -high -maxnodesize 512" kompiliert und - TUSCH - es hatte teilweise erstaunliche Effekte.

Ein HotSpot, an dem ich 1000er W_polies hatte, verwandelte sich in ein 350er Warmduscher ! Dabei ist vor Allem zu bemerken, daß große (offene) Flächen dadurch kaum beeinträchtigt werden - hier gingen die w_polies zwischen 50-150 zurück. Der HotSpot war prädestiniert für MaxNodeSize ... eigentlich nichts besonderes an der Stelle, man konnte halt nur etwas in 3 higpoly Bereich sehen ... durch kleinere nodes hat sich hier irgendwie die Line of Sight besser 'gefangen' -> es wurde nicht mehr in die highpoly Bereiche 'geschaut'
Die Kompilezeit hielt sich in Grenzen (eine Simpsons Werbepause ;).
Eine Verkleinerung auf 256 hatte dann allerdings keinen größeren Effekt (HotSpot bei 300).

Soweit mein amateurhafter Forschungsbericht =)

@vorticone

... ich hab bei hlvis.exe -high keine Probs gehabt ... is einwandfrei durchgelaufen ...

god is real - unless declared integer