Exclude Bereiche bearbeiten
 

Hi!

Beim Switzerland-Pro Autogen Projekt fiel es mehrfach auf, daß AddOn Flugplätze (viel zu) große Exclude Bereiche mitbringen, auf denen dann keine Autogen-Objekte sichtbar sind.

Gibt es eine Möglichkeit, diese Exclude-Bereiche nachträglich zu verkleinern oder komplett zu ersetzen?

Grüße,
Thomas (Mack)

PS: Warum werden sie überhaupt praktisch generell (viel) zu groß gewählt???

Eine Lösung ist mir nicht bekannt.

Der Grund, warum eine Exclude meistens zu groß gerät ist der, dass man sie nur im Rechteck setzen kann. Das heißt, man kann sie nicht drehen und somit entsteht oft ein Exclude-Bereich außerhalb der Szenerie (besonders in den Ecken des Excludes).

Was ich aber auch schon bemerkt habe, ist dass entweder der FS oder gmax (bzw Makemdl) automatisch bestimmte Bereiche exkludiert, auch wenn man das eigentlich nicht will...

Aber vielleicht kann man eine Exclude ja excludieren? :D

Ein Excludegebiet kann man ändern, sofern es eine Exclude.BGL gibt.

ABER:

Das kommt vom GMAX, gibt es dazu Erkenntnisse?

Uwe

Ah, ok. Dann macht es nicht so viel Sinn sich darum zu bemühen, die Excludebereiche anzupassen, weil es eh nicht funktionieren würde.

Vielleicht baue ich die Autogen-Häuser und Bäume nach, um sie als Library Objekte auf den Flugplatz-Excludes zu plazieren, so daß es keine Bruch zum normalen Autogen gibt.

Mal schauen, wie weit ich mit dem Texturieren in gmax komme...

Danke,
Thomas

Ohne Ahnung von Sceneydesign zu haben: Wie wärs mit mehrere unterschiedliche Rechtecke aneinander zu fügen?

Richtig. So wirds auch meistens gemacht. Ist aber mehr Arbeit und auch so erreicht man meist mehr mit dem Exclude, als erwünscht...

Da würde ich doch statt Exclude-Rechtecken lieber ein VTP-Polygon vorschlagen. Das wird in der Form des Flugplatzgeländes z.B. mit einer Wiese als Textur gestaltet. Die Textur funktioniert wie bei LC. Man hat Texturen mit und ohne Autogen. Als Freeware kann dazu SBuilder nehmen.

Stimmt. Eigentlich keine schlechte Idee. Aber wenn da irgendwelche Häuser rumstehen (kein AutoGen), dann sind die doch trotz VTPpoly noch zu sehen oder?

bei Sceneryobjekten bleiben die Häuser/usw. stehen, aber dann gibt es eine *.BGL dazu. Da muß man dann wieder excluden.

Zu

--------------------------------------------------------------------------------
Was ich aber auch schon bemerkt habe, ist dass entweder der FS oder gmax (bzw Makemdl) automatisch bestimmte Bereiche exkludiert, auch wenn man das eigentlich nicht will...
--------------------------------------------------------------------------------

Das kommt vom GMAX, gibt es dazu Erkenntnisse?






Das ist normal bei Sceneryobjektcode. Hängt mit Steuerparametern für die Objektsteuerung zusammen. So etwas kann man aber optimieren, das möglichst wenig platt gemacht wird. Allerdings sollte das der Designer vorher schon bei der Programmierung beachten.

So findet man leider (speziel ältere) Addons die auch ohne Excludefile riesige Gebiete hinsichtlich Autogen vernichten.

Ich würde daher vorschlagen ein ev. vorhandenes Excludefile zunächst zu entfernen, dann sieht man ob durch Objektcode zu viel Autogen vernichtet wird.

Ist das der Fall, dann hat man eigentlich eh keine Chance hier etwas zu verbessern.

Bleibt das Autogen aber erhalten, dann lag es am Excludefile. Dann könnte man einfach ein neues kleineres erstellen.

Und wie kann man das als Designer vermeiden? Hilft manuelle Code-Bearbeitung, oder liegt es an der Konstruktion (bzw. der Koordinaten-Parametern)?

Zu

Ich bin damals von einem Designteam angesprochen worden, die mir Ihr Leid bezüglich großflächiger Autogenvernichtung beklagt haben.

Ob ich nicht irgendeine Idee hätte wie man das verhindern kann.

Bis dahin hatte ich mich mit dem Problem nie beschäftigt. Ich habe das dann damals etwas genauer untersucht und die Gründe ermittelt.

Auch wie man den Code optimieren kann.

Recht erfolgreich.

Die ganze Geschichte ist aber mindestens über zwei Jahre her, ich habe den Mail Verkehr nicht mehr und kann mich nicht mehr 100% genau erinnern wie es war.

Auch klar sollte sein, dass wir damals noch gemäß FS2002 SDK programmiert haben.

Wie es sich gemäß FS2004 verhält kann ich nicht sagen, da ich mich seitdem auch nicht mehr mit BGL Objektcode intensiv beschäftigt habe.

Ich meine mich daran zu erinnern, dass es einer der Steuerparameter V1= oder V2= war, weiterhin der Parameter Scale im Zusammenspiel mit dem refpoint.


Mit diesen Parametern konnte man bei geschickter nachträglicher Manipulation der Werte die aus dem Designtool kamen die Autogenvernichtung minimieren.

Auch ganz wichtig war ob sich mehrere Objekte auf einen refpoint bezogen.

Wenn das der Fall war, dann konnte man das beste Ergebnis erreichen, wenn der refpoint zentral lag.

Bei sehr vielen Scenerien ist das nicht der Fall.

Ich erinnere mich an einige GAP FS2002 Scenerien bei denen im Umfeld quasi großflächig Stadtgebiet hinsichtlich Autogen ausradiert wurde.

(selbst wenn man das Excludefile entfernte)

Besonders schlimm war das, wenn die Objekte dann noch recht weit auseinander lagen. Lag der Refpoint z.B nahe bei einem außenliegenden Objekt konnte es passieren, dass man dann mindestens die Entfernungen zum entferntesten anderen Objekt (in der Regel wesentlich mehr) welches sich ebenfalls auch auf diesen Refpoint bezieht als gedachten Radius um den refpoint zirkeln konnte. Dieser gedachte Kreisbereich war von Autogen leider befreit.

Logisch das man mit einem zentralen refpoint besser fahren konnte. Denn mit einem kleinen Kreis schliesst man alle Objekte ein. Liegt der refpoint bei einem Außenobjekt, wird der kreis größer um alle einzuschliessen.

Im größten Anteil des Kreises befinden sich dann aber überhaupt keine zugehörigen Objekte mehr.

Auch sinnvoll war es nur möglichst nah bei einander liegenden Objekte auf einen Refpoint zu beziehen. Lieber zusätzliche refpoints bei weit entfernten Objekten.

Ist wie gesagt aber schon lange her bekomme das nicht mehr richtig zusammen.

Danke für die Erläuterung, Joachim.

Das ist ja schon mal ein Anfang. Und fall mal Probleme diesbezüglich bei mir auftreten, hab ich wenigstens etwas zum Anfangen.