|
Zu
quote: -------------------------------------------------------------------------------- "Perfekt ich beanspruche diese Idee als erstes gehabt zu haben oder etwa nicht?" -------------------------------------------------------------------------------- Der Satz war auch nicht ernst gemeint deshalb diese Variante des Smilies. Ok wenn Ihr im Winter oder Spätherbst fliegt seht Ihr die Waldwege da gebe ich euch recht. Das zuvor geschriebene stellt auch nur meine Meinung dar. Ich wichte hier nur die Problematik. Mir wäre ein Verzicht auf Waldwege im Frühjahr/Sommer lieber als sie dann im Spätherbst oder Winter zu haben. Denn ich finde halt im Sommer/Frühling zerstört es die Scenery. Ich hätte als Ortsfremder mit Sicherheit Schwierigkeiten mich in einer FS Scenery zu orientieren wenn da so ein Wust an Straßen auf einen zu kommt wo man im FS nun nicht eindeutig sagen kann was ist das für ein Weg/Straße. Da sie Performance kosten ist ein Verzicht darauf nicht schwerwiegend. (Meine Meinung) Sie kosten Performance weil es letztendlich keine Texturen sind. Es sind Polygone. Aus diesen Polygonen formt der FS dann Basisflächen die immer wieder aneinander gehängt werden. Diese Polygone müssen definiert werden. vereinfacht gesagt muß jeder Richtungswechsel wieder durch neue Polyinformationen definiert werden. Deshalb fressen Straßen natürlich Performance. Diese Polygone werden hinterher mit unseren Straßentexturen belegt. Das nur kurz zur vereinfachten Erklärung was Straßencode ist und warum es Perfomance killt. Noch ein vereinfachtes Beispiel eine ellenlange Straße könnte ich durch zwei Punkte definieren Start und Endpunkt. Da die Straße eine gewisse Breite hat stelle ich sie durch zwei Dreieckspologone dar die ein lang gezogenes Rechteck bilden. Das wäre der Idealfall. Nun ist es aber so das man je nach Designtool gerade wenn es um Automatismen geht hier ein Problem bekommt das so ein Designtool diese gerade Straße aus sehr vielen Polygonen zusammenbaut. Das ist Nutzinformation für den FS die er Verarbeiten muß. Das kostet eben Performance. Ideal ist also wenn man möglichst wenig Polygone nutzt. Das geht am besten wenn die Rohdaten für den späteren Straßencode optimiert sind. Das hat man wohl bei den USA Roads realisiert. Horst kann wohl das selbe da auch er die Daten vor der Speisung des FS Designtool ideal vorbereitet. Das selbe übrigends beim Vectorautogen (Lampenmaste usw). Hier vertrete ich auch die Meinung da wo keine Straßenlampen, Telegrafenmaste usw. in der Realität rumstehen diese auch nicht zu definieren. Denkt mal dran zurück es gab damals in diversen Foren und auch in einem FXP Bericht zur FS9.CFG usw. den Tipp Vectorautogen ganz zu deaktivieren wegen der besseren Performance. Wie gesagt generell wäre es mir auch lieber es kommt zuviel an Straßen als gar nichts. Ganz klar. Persönlich wenn ich die Möglichkeiten und Zeit dazu hätte würde ich halt auf Waldwege und innerörtliche Straßen verzichten aber das ist wie gesagt meine Meinung. |
Zitat:
Ich kann deine Meinung durchaus unterschreiben. Waldwege im Winter haben nicht viel mit Orientierung zu tun. Auch oder gerade weil sie sowieso eingeschneit sein könnten. Aber auch so würde ich aus dem Framratensicht und aufgrund der visuellen Überladung darauf verzichten wollen. Ich denke auch kaum, dass die Linien so gut integriert wären wie auf Luftbildern. Auch wegen der Breite der Strassen. |
Hallo,
Habe derzeit wirklich wenig Zeit und Möglichkeiten irgendjemanden etwas zu beweisen. Habe dies auch sicher nicht vor!! Außerdem habe ich sicher nicht vor, irgendjemanden etwas zu verkaufen. Ich merke nur, dass nur wenige das Potential dieser Tools erkennen!!! Habe nur gestern keine Zeit gehabt, und mit großer Verwunderung diesen Thread wieder gefunden Also einen kurze Anleitung, da mein Satz anscheinend mit Daten aus Deutschland in Beziehung gebracht wurden. Stellt sicher keine Werbung für ein Produkt dar, jeder soll dies selbst entscheiden. Ich denke dieses Produkt würde sehr brauchbar sein, da auch noch nicht sehr alt. http://www.garmin.de/index-MapSource...land-TOPO.html Dies ist eine Vektorkarte mit Höhenlinien. Dies verwendet man zur Orientierung mit GPS oder kann sie in dieses Spiel integrieren. Hat den Vorteil, dass du Höhenlinien mitbekommst (die man zu Mesh interpolieren kann) und natürlich Points of Interest. Und wie es gehört auch in lat/long WGS 84. Dann braucht man: http://www.geopainting.com/en/ Ein Tool mit welchem es möglich ist Karten zu erstellen oder zu ändern, die ich anschließend meinem GPS Empfänger zur Verfügung stellen kann. Mit diesem Tool konvertiert man zu mp Format. Anschließend nimmt man SBuilder oder AutoAsm und integriert die Daten Mit Sbuilder benötigt man für diese Fläche und ein paar Straßen nicht mehr als eine Stunde. Die Straßen dieser Karten sind natürlich unterteilt in (Autobahn, Bundeststraße, Autobahnauffahrt,….) Also dieser Vorgang hat absolut nichts mit Automatismen zu tun! Man kann nur Daten integrieren, die jemand mühselig gezeichnet hat. Zu den Tiger files: Vom Link in Beitrag 1: Dies sind Esri shapefiles, die man umsonst runterladen kann. (esri.com oder wo anders) Wie man sie sinnvoll ohne teure Programme differenzieren kann: Die Antworten geben luissa und rhumbaflappy: http://forums.avsim.net/dcboard.php?...3311&mode=full Man muss solche Daten separieren, ansonsten kann man nur eine bestimmte Textur zuweisen. (diese Entdeckung für mapedit hat mich gefreut) Keine Ahnung, welche Daten jeder sucht: http://www.maps.ethz.ch/map_catalogue.html Dies hat alles nichts mit Theorie zu tun! Das Verständnis für solche Vorgänge und Zusammenhänge ist Grundvoraussetzung für die Integrierung. Leute, die selbst zeichnen für den FS, machen nichts anderes!! Also ein paar zusammenhanglose Screenshots (zwecks Theorie und Praxis), die ich mal gemacht habe. Screen1: Tausende Polygone in Sbuilder integriert und anschließend zu einer bgl verwandelt. Dauer der Prozedur keine Minute. Definiert mit -9999. Screen2: So überprüfe ich, ob mein erzeugtes Mesh zu den Linien passt. Screen3: Überprüfung von integrierten Linien, in Bezug zu Append VTP in Sbuilder (Überlagerung) Screen4: Einfluss von terrain.cfg auf Linie, und korrekte Darstellung von Linie, wenn korrekte Daten integriert. MS Daten wurden nicht deaktiviert. Zusammenfassung: a)Dies ist kein Automatismus. b)Man kann sämtliche Daten bis zur Erzeugung von bgl ändern c)Man zeichnet nicht selbst – integriert dies aber genau und differenziert Wäre ich jetzt Geschäftsmann und benutze diese Daten (Topo Map): A)Verkaufe ich das Mesh B)Verkaufe ich LC C)Verkaufe ich Linien D)Verkaufe ich Polygone Wer glaubt, dies geht auch ohne Zustimmung des Lizenznehmers mit 1:1, der wird sich irren. Sämtliche Daten haben kleine Fehler. Wer glaubt er bekommt es von MS, ist ein Träumer. Wer jetzt beleidigend war – keine Ahnung – war ja, wie immer, nur ein theoretischer Vortrag. Wenn man es nicht benutzt, sollte man es auch nicht beurteilen! Sondern eine simple Frage wie Simeon schreiben. Wem solche Vorgänge interessieren, soll gezielte Fragen im Designer Forum stellen. Mein Interesse ist nur die sinnvolle Integration in FS, zu einem angemessen Preis. Ich erstelle meine Gebiete so und so selber. Und in ein paar Sätzen kann ich es auch nicht zusammenfassen! Horst |
Screen2
|
Screen3
|
Screen4
|
Danke Horst,
die von Dir genannten Karten kosten (es sind 2 Versionen) jeweils knapp 130 Euro oder zusammen (als Bündel) knapp 200 Euro. Ist vielleicht interessant, diese Zahlen hier auch dann mal zu nennen. Ciao, Rainer. |
Hallo zusammen,
sehr gute Diskussion und Ideen zur Praxis! Stimme den Beitraegen von Rolf, Michael und André voll zu. Zum Beispiel hat da André eine sehr clevere Idee mit der horizontalen Autogentextur fuer Baeume. Das Problem mit der Umsetzung wird sein, dass zum einen VTP2 Linien das Autogen in der naeheren Umgebung excludieren, seltsamerweise auch dann, wenn in der terrain.cfg der "ExcludeAutogen" Parameter auf "0" gesetzt wird, und zum anderen, dass alle an Haengen stehende Objekte eine teils schwebende Textur"platte" haben werden. Trotzdem sinnvoll, sich darueber mehr Gedanken zu machen. Z.B. koennte man die strassenbegleitenden Schilder oder Lichtmasten durch Baeume ersetzen und somit zumindest einen Allee-Effekt erzielen (da die Abstaende regelmaessig sind). Uebrigens, Felix, der Parameter fuer den Abstand zwischen den Autogenobjekten ist "ObjectSize=". Fuer die Strommasten steht der per Default auf 600 (Meter) und du kannst ihn auf auf jeden beliebigen kleineren oder groesseren Wert aendern, allerdings nur global! Zitat:
Der entscheidende Punkt fuer mich ist, dass ich Spass daran habe, alle Ideen und Daten fuer ein interessantes Gebiet zusammenzutragen und das Beste daraus zu machen. Dabei wird mir immer wieder klar, dass wir erst ganz am Anfang stehen mit dem, was mit lokalen Texturen, hochgenauen Rohdaten und interessanten Tricks moeglich ist. Und es sieht ganz danach aus, als ob das Projekt von Peter Werlitz und Sascha Normann einer aehnlichen Liebe zum Detail entspringt. Und da wird es in Zukunft sicher noch mehr geben, von Rainer, Christian, ... Ciao, Holger |
@ Rainer
Dies kann ich auch für reale Navigation verwenden! Also zwei Fliegen mit einem Schlag. Und rechne bitte auch Addon Preise hoch, die ich bei der nächsten Version wegwerfen kann. @Holger Interessanter Beitrag! Slartibartfast kann ich leider nur ein paar Daten zuführen (eben LWM). Dies habe ich mit AutoAsm schon längst bewerkstelligen können (seit Beginn) Daher auch viel Handarbeit für dein Projekt! Ansonsten einen nette Aufklärung für dein Projekt. Viel Glück Horst |
@ Horst:
Du machst es einem wirklich schwer, nicht persönlich zu werden. Da schreibst Du, " ich mach mir meine Gebiete so und so selber". Hauptsache, Du hast was? Oder? Wenn Jim Keir und andere so dächten - Du hättest nichts. Denn deren Programme nutzt Du fleißig und animierst die Leute, sich zu strecken und die Dinge weiter zu entwickeln. Will sagen, trenn Dich mal von diesem autistischen Verhalten. Wenn Du die Community abschöpftst, dann hast Du die verdammte Pflicht, wieder was retour zu geben. Und zwar keine Links, sondern Deine "Gebiete", die Du Dir mit den Tools Anderer erstellt hast. So funktioniert Gemeinschaft, lieber Horst. Ich mache das nicht gern, aber manchmal tut es Not, gewisse Mitmenschen an elementare Grundregeln zu erinnern. Gruß Rolf |
@Rolf
Diesen Beitrag verstehe ich jetzt wirklich nicht ganz. Kannst du mir dies näher erklären? Aber bitte ohne Vorurteile. Gemeinschaft endet heutzutage in Payware! Und Arbeiten von Christian Fumey, Lee Swordy werden geuützt ohne Anerkennung. Ich verstehe die Einstellung von Pete Dowson voll und ganz, auch Jim Keir und Luis Sa. Eine richtige Entscheidung für diesen Schritt. Horst |
Hallo,
Also, ich bin nicht der Meinung, dass irgendjemand dazu verpflichtet ist, seine Privatprojekte mit der Allgemeinheit zu teilen. Was mich stoert, sind besserwisserische Sprueche und absurde Pauschalaussagen, wie "Gemeinschaft endet heutzutage in Payware!" und "Und Arbeiten von Christian Fumey, Lee Swordy werden geuützt ohne Anerkennung" von jemandem, der genau weiss, dass sie sachlich falsch und provozierend sind. Horst darf natuerlich, wie jeder andere auch, seine persoenliche Meinung mitteilen. Aber wer gerne austeilt, muss auch einstecken koennen und nicht immer nur das Opfer spielen, a la, mich versteht ja eh keiner :heul: ... und sorgfaeltig die Beitraege andere lesen hilft auch. Glaubst du ernsthaft, dass ich mir unnoetig Arbeit machen wuerde, Horst? Die Moeglichkeiten der verschiedenen Utilities sind mir durchaus bekannt. Wie oben geschrieben, liegt der Hauptaufwand des Projektes in der Verbesserung der Qualitaet der Rohdaten von Suedost-Alaska. Uebrigens, wen es interessiert: die Autoren der von uns verwendeten Tools erhalten von ihnen selbst festgelegte Lizenzgebuehren, so wie es sich bei Payware gehoert. Ciao, Holger |
@ Holger,
Ja richtig, es ist niemand verpflichtet, seine Projekte mit der Allgemeinheit zu teilen. Verpflichtet sicher nicht. Aber wer kann, hilft. Auch mit seinen Arbeiten, die er der Allgemeinheit zur Verfügung stellt Das hast Du gemacht. Das machen Rainer und viele andere auch. Keiner von Euch war dazu verpflichtet, auch ich nicht, als ich Freeware ins Netz gestellt habe. Keiner hat als Star und Payware Entwickler angefangen. Jeder von uns war froh, wenn ihm irgendwo bei den ersten Schritten geholfen wurde. Ich mache das wieder gut, indem ich Anfängern Tipps gebe. So, wie mir einst geholfen wurde. Was mich stört ist die Einkassier Mentalität - alles für lau haben wollen, und auf dem was man hat hocken. Kommerz ist die eine Seite, das kann man meinetwegen generell verurteilen, aber dann sollte man auch so gerecht sein, das was man umsonst genommen hat, in irgendeiner Form wieder zurückzugeben. Das ist vielleicht altmodisches Gedankengut. Manche nennen das Solidarität. Und die ist ja ( verbal zumindest) modern. Gruß Rolf |
Zu Horst
Ist das etwa kein Automatismus wenn Du ein Tool wie SBuilder hast welches Dir automatisch einen VTP2 Code erzeugt? Also von Hand möchte ich den VTP2 Code nicht erzeugen wollen. Zu Holger "Zum Beispiel hat da André eine sehr clevere Idee mit der horizontalen Autogentextur fuer Baeume. Das Problem mit der Umsetzung wird sein, dass zum einen VTP2 Linien das Autogen in der naeheren Umgebung excludieren, seltsamerweise auch dann, wenn in der terrain.cfg der "ExcludeAutogen" Parameter auf "0" gesetzt wird, und zum anderen, dass alle an Haengen stehende Objekte eine teils schwebende Textur"platte" haben werden. Trotzdem sinnvoll, sich darueber mehr Gedanken zu machen". So wie ich das interpretiere bzw. die Auswirkungen sehe hat dieser Paramter "ExcludeAutogen" wohl nur dazu gedient unter MaskClassMap Funktion (und nur dann) Autogen zu excludieren. Damit wäre es logisch das er anders nichts auslöst. Demnach hätte er nichts mit dem VTP2 Code selbst zu tun. Ich denke man könnte das eindeutig beweisen. Aber man sieht ja z.B auch das dieser Parameter keine Auswirkung auf Autogen hat wenn man wie im Falle meines Patches einfach dem VTP2 Airportrasenpoly eine LC zuweist. Dort drückte dann auch obwohl der Parameter auf 1 war das Autogen durch desahlb ja auch bei mir damals die Texturen. Man müsste nach dem FS9.1 Patch mit ""original FS2004 Terrain.CFG" jetzt einfach mal bei den Airportbackgrounds diese Zeilen von 1 auf 0 ändern. Hat man dann Autogen auf einem der Airportrasen wäre das der Beweis das es definitiv nur der MaskClassMap Funktion dient. Zu der Baumidee. Die als solches von Andre ist nicht schlecht mit den von Dir genannten Problemen. Aber ich denke auch hier wird man im Überflug aus schräger Sicht nach unten das Problem haben das man die seitlichen Baumtexturen sehen wird die teilweise durch die neu hinzugefügten Dachtexturen verdeckt sind. Ich hatte da mal ganz zu Anfang des FS2004 eine andere Idee. Das man die terrain.cfg erweitert (ist natürlich nicht so schön wir wissen das) und VTP2 Wälder erzeugt ev. eine Wald LC oder eine nackte Textur zuweisen die kein Autogen hat. Diesen geben wir in der terrain.cfg ein Meshoffset ca. +20 bis +30m bei und schon haben wir Wälder sie sich aus dem Mesh erheben und natürlich meshclinging sind. Den Rand maskieren wir mit Autogenbäumen oder ähnlichem. Nur leider ist man damit abhängig vom Terrain_Max_Vertex_Level. Je nachdem wie dort dran tumgeschraubt wird von diversen Addons sieht das dann auch nicht mehr Toll aus. |
Muß man etwas der Allgemeinheit zur Verfügung stellen?
Nein, ein "MUSS" ist es meiner Ansicht nicht. Aber ich kann da Rolf schon sehr gut verstehen, es ist ein Geben und Nehmen. Hier sind einige im Forum, die haben noch keinen einzigen VTP-Code oder sonstwas erzeugt, geben aber mit sehr qualifizierten Bemerkungen/Tipps anderen Fragestellern oder Problemsuchenden derartig viele gute Tipps, dass für diese dann der Flugsimulator einfacher zu handhaben ist. Beispiel wär z.B. Börries (Buschflieger). Oder Michael (Andragar) mit seinem Patch-Überprüfprogramm. Was wären wir ohne diese Überzeugungstäter? Jetzt mal von Joachim (Jobia) ganz abgesehen. Dann sind da Leute, die vielleicht mit beschränkten Möglichkeiten versuchen, einfach irgendwas für andere (und natürlich auch für sich, schließlich ist es ein Hobby und wir machen das alle freiwillig) so zu bauen, dass die Flusiwelt realer wird. Die machen einfach und setzen hunderte Stunden Freizeit für andere in ein Projekt. Über die Zeit erschienen jetzt immer mehr Tools. Zu meinen ersten Fluß-Zeiten war an irgendwelche Automatismen nicht zu denken, Ground2k war ein Vorreiter und wenn ich mich entsinne, dass alleine für einen See (den ich in Ground2k innerhalb von Sekunden passig gelegt hatte) unser Sascha händisch ohne vorhandene Tools beim Scenery Germany 1 - Projekt tagelang rumprobiert hatte, bis er es "auf der Reihe" hatte... Was hatte er gestaunt, als ich damals meine erste 2002-OWL mit den Straßen etc... erstellt hatte. Die neuen - ich nenne sie jetzt mal - automatisierten Tools erleichtern die Arbeit bestimmt sehr. Viele Beiträge darüber waren ja mittlerweile zu finden, auch von Horst. Und sie waren und sind Grund, warum ich händisch mit dem Flüssebauen aufgehört hatte. Meine Hoffnung war (und ist), dass endlich jemand herkommt und diese ja nun immer wieder genannten Tools nutzt und endlich einfach das tut was theoretisch ja anscheinend so leicht von der Hand geht. Sehe oder lese ich aber jetzt, was u.a. von Holger geschrieben wird, so verliere ich dann doch langsam die Geduld mit diesen Autotools. Peter und Sascha haben was komplett händisch erzeugt, es erscheint in wenigen Tagen. Rolf und Christoph wissen auch, was sie tun und was nicht, Holger hat schon beschrieben, wie er händische Ergänzungen nutzt und warum die nötig waren. Was ist also mit den so glorifizierten Autotools? Nichts ist innerhalb Europas (oder auch nur Deutschlands) erschienen. Darum meine erste Bemerkung zu Horst seiner forschen Formulierung. Und was wären - es wurde auch schon erwähnt - die ganzen Theoretiker ohne diese Vorarbeiten der Tool-Erzeuger? Sie müßten händisch - wie damals Sascha - 'nen See bauen. Ich weiß zumindest, wie dies noch ohne Tools funktionieren würde. Viel Spaß! Ciao, Rainer. |
Rainer, kleine Anmerkung. Es gibt bereits Straßenprojekte in Europa:
http://secure.simmarket.com/default.php?cPath=22_107 Da gibts Straßen für Dänemark, Schwede und UK, aber auch Payware. |
Rainer, kleine Anmerkung. Es gibt bereits Straßenprojekte in Europa:
http://secure.simmarket.com/default.php?cPath=22_107 Da gibts Straßen für Dänemark, Schwede und UK + Irland, aber auch Payware. |
Tja... leider ist jetzt wieder so eine Diskussion entstanden. Musste aber wohl auch.
Wenn Horst seine Sourcen mit 200€ und mehr bezahlt hat er immer noch nur eine "Single-User-Lizenz". Wenn er diese Daten nutzt um sich mit den Tools und den Infos aus dem Netz ein Strassennetz zusammenbaut bzw. generieren läßt, dann hat er leider nicht die rechtliche Möglichkeit seine Strassen einfach zu veröffentlichen. Dazu müsste er entweder die Daten für diesen Flusizweck kaufen - und niemand kann erwarten, dass er das tut um dann Payware zu veröffentlichen - oder er gibt die Daten nur gegen Nachweis des Besitzes der Rohdaten weiter. Würdet ihr das Geld für die Karten ausgeben? Was er aber durchaus machen kann - und, das was ihr theoretisieren nennt, durchaus macht - ist die Methodik seiner gewonnenen Strassen zu erläutern. Leider kommt das aber in diesem Ton herüber "ist nur eine Arbeit von einer Stunde" "man muss es nur wollen" - gerade im geschriebenen Wort ist immer viel herein zu interpretieren - welches die Reaktionen hier auslösen. Das Horst dann die Payware verurteilt halte ich aber für Quatsch. Warum soll man nicht dem Paywarehersteller Geld für ein Produkt geben, wo er sich zum einen die Arbeit bezahlen lässt (auch die Mehrarbeit bezüglich der Nacharbeit von automatisch gewonnenen Daten, was Horst ja augenscheinlich nicht gemacht hat) plus die "Mehr-User-Lizenz" die garantiert nicht mit den 200 € aus kommt? Wenn dann Freeware Tools bei der Produktion eingesetzt werden sollten sie natürlich zumindest erwähnt, wenn nicht sogar wie in Holgers Fall die Programmierer eine Aufwandsentschädigung bekommen. Als Freeware jedoch werden wir die Strassen in der von Horst erwähnten Auflösung und Qualität solange nicht bekommen können, solange die entsprechenden Quellen nicht auch "Free" sind. Warum Payware dann verdammen? Eine andere Geschichte sehe ich derzeit in den SRTM-Mesh Daten. Da gibt es ja nun eine sehr genaue Quelle, die zudem noch Frei verfügbar ist. Wenn sich da Payware Hersteller drann zu schaffen machen, dann erwarte ich aber auch den Mehraufwand an Kontrolle und Korrektur der Daten. Nicht "einfach" das Durchjagen durch ein Tool zur Generierung der bgls. Dann lade ich mir lieber die vielen Freewaremeshs herunter. Bei den Payware Meshs ist es zumindest sehr fraglich ob sie den Preis wert sind. Darum habe ich hier ja schon lange auf einen Vergleichstest gepocht, der mir ja bisher von FXP verwehrt wurde. Gerne würde ich nämlich mal die ganzen SRTM Meshs vergleichen, die ja auf der gleichen frei Verfügbaren Datenbasis erstellt wurden. Aber jetzt komme ich schon wieder ins Schwätzen. :) |
Doch noch ein Nachschlag:
@Horst Was natürlich den Standpunkt von dir angeht: Die Freeware-Tool Programmierer bekommen nicht den nötigen Respekt und darum mache ich erst gar nichts sondern nur für mich. Ich weiss nicht ob du wirklich so darüber denkst, aber wenn, dann ist das einfach nur falsch. Du bekommst positives Feetback und Dank wenn das, was du als Freeware baust ok ist. Dummerweise gibt es immer Leute, die entsprechend laut deine Arbeit schlecht machen, womöglich ohne Grund. Dummerweise ist das immer lauter als die positiv eingestellte Mehrheit. Viele Leute geben eher negative als positive Kritik/Lob. Und wie du am Beispiel von Holger siehst wird Freeware Arbeit durchaus geschätzt und sogar belohnt. Auch das Beispiel mit Peter Downsen ist irgendwie falsch wenn du die wirklichen Hintergründe dazu kennst, warum sein FSUIPC inzwischen zum Teil Payware ist. Übrigens kann deine Einstellung nur dann funktionieren, wenn es Leute gibt, die nicht so denken wie du es scheinbar tust. |
Und um mal wieder zum Thema zurück zu kommen:
Zitat:
|
Noch ein Nachschlag
Ich glaube, da machen wir einen Fehler, wenn wir Landstrassen durch Wälder auslassen. Ich hab mich jetzt selbst überzeugen müssen, sie sehen zwar nicht wie Strassen aus, aber sind doch als solche erkennbar.
Ich bin in Real-Germany 1 mal die Strecke von meinem Studienort in Darmstadt nach Moosbach der Strecke durch den Odenwald gefolgt, die ich damals immer gefahren bin. Ich konnte mich prima orientieren und nur einmal, als ich wirklich Schleichwege gefolgt bin, hab ich mich auf einem kleinen Eck nicht orientieren können. (Die Orientierung war immer noch da, ich hatte ja auf andere Wegpunkte gute sicht, die ich auch erkennen konnte.) Und dann gibt es auf der Strecke viele Waldabschnitte. Ich bin nach den Landstrassen geflogen und wenn ich diese nicht so typisch durch den Wald durch erkennen hätte können wäre meine Orientierung bedeutend schlechter gewesen. Wenn man also doch die (Haupt-!)Strassen in den Wäldern realisieren wollte, dann steht man vor der Aufgabe sie in den LC-Waldfarben hinfurch zu führen. Leider geht das wohl nur, wenn man explizit andere Strassentypen für diese Abschnitte nehmen würde. Ein Anpassen des Aussehens aufgrund der darunter liegenden LC Texture geht nicht, oder? http://pics.flightxtreme.com/Waldwege.jpg |
Ich fürchte, ich muss mich hier einmal kurz melden.
Habe den ganzen Thread noch nicht durchgelesen, aber doch schon einiges Interessantes gesehen... Grund für die Meldung: Wir (FSQuality) arbeiten gerade am kompletten europäischen Strassennetz. Die Daten sind nicht umsonst, im Gegenteil, sie sind teuer. Aber sie sind gut und ich denke, Ihr werdet das Ergebnis mögen... Mehr sei hier aber noch nicht verraten. Auch Screenshot gibt's noch keinen. Der Grund für letzteres: Wir haben noch keine Screenshots, die dem endgültigen Aussehen nahe kommen und die Screens, die wir haben, sind wahrscheinlich noch nicht das, was Ihr sehen wollt... So... und jetzt habe ich Schlingel doch glatt Werbung gemacht... :D Wehe mir... :hammer: |
Hallo Guido,
Zitat:
Zitat:
Bin gespannt. Mal sehen mit welchen Meshs und LCs das dann harmoniert. :D Und wieso Werbung? Was hat den FS Quality mit dir zu tun? *Autsch* :hammer: *Aua* *nicht schlagen* :engel: |
Re: Noch ein Nachschlag
Zitat:
Problem ev. DXT3 Format oder anderes Format beim Liniencode nötig. Muss man testen ob das der FS mag. Nichts desto trotz bleibe ich natürlich bei meiner persönlichen Meinung das man sie nicht braucht, schon garnicht wenn man normale Texturen nutzen würde. Denn wie gesagt dazu muss das ganze auch wieder auf die Landclass oder VTP2 Scenery abgestimmt werden. Es bliebe dann dabei es müsste ein Gesamtpacket sein was ganz klar das beste wäre. Das würde sich dann natürlich mit anderen Addons wie die neue SG2 beissen. Es wäre halt noch mehr drauf zu achten was muss ich als Anwender nutzen was muss ich deaktivieren. Aber da kommen wir ja eh nicht mehr drum hin. Diesen Screenshot von so einer umgesetzten Idee wird nicht von mir gewesen sein. ich habe die Äußerung damals ganz am Anfang des FS2004 gemacht und habe davon meines wissens auch nichts als Screenshot gepostet. Was ich bei Dir jetzt nicht erkennen kann ob man hier meshclinging arbeitet. Denn das setzt auch hier wieder eine Landclasszuweisung vorraus. Da könnte es Probleme geben wegen Texturformat und Transparenz. Das habe ich im FS2004 selbst noch nicht getestet z.B andere Formate als DXT1 bei Landclass. Beim FS2002 ging nur noch 8Bit nicht aber DXT3 z.B. Auch habe ich bei meiner Idee nie semitransparente Texturen in Betracht gezogen. Mit den durchscheinenden Waldspitzen das hatte ich auch schon im Hinterkopf. Nur das setzt voraus das man einmal den Wald mit regulären VTP2 Poly mit Autogenwald programmiert um die Bäume zu haben. Dann das selbe Poly nochmal mit positiven Meshoffset (denn es soll ja meshclinging sein) mit Zuweisung einer anderen WaldLC die kein Autogen hat. Am besten macht man das Urpoly welches Autogenwald zuweist noch größer dann erscheinen die Bäume aus der sich langsam zum Polyrand absenkenden Waldfläche. Das müsste man glatt mal ausprobieren wie das aussieht. Habe momentan die Möglichkeit nicht. Rainer oder irgendwer habt Ihr Lust das mal zu testen. Wenn nicht irgendwann komme ich bestimmt dazu. |
Hallo JOBIA,
bitte nicht durcheinander bringen. Den Screenshot aus RG1 (hab ich auch erwähnt gehabt) dient nur zur demonstration wie Waldstrassen in Wirklichkeit aussehen können. Wenn ich ein Luftbild hätte, hätte ich das genommen. Das was du auf dem Screenshot siehst sind einfach nur die normalen Phototexturen, der räumliche Einruck kommt rein von den Texturen ohne irgendwelchen Modifikationen mit meshclinging oder anderen Dingen. Edit: Jetzt hab ich, glaub ich, was durcheinander gebracht. :) |
Jau da hast Du was durcheinander gebracht.
RG1 ist eine gemäß SDK programmierte Custom Fotoscenery. Diese hat eine Basis zur Landclasstechnik und ist dem entsprechend von Grund auf meshclinging also macht jede Meshgeländeform optisch mit. Leider mit dem Manko der maximalen Bodenauflösung ca. 4,77m pro Pixel. Übrigends meine Idee mit Wäldern die sich aus dem Mesh erheben habe ich doch recht früh im FXP Forum erwähnt. Sie liegt länger zurück als ich dachte. Ich habe diese Möglichkeit schon vor dem erscheinen des FS2004 erwähnt als mir damals anhand von Betatesterscreenshots in diversen Foren diese texturierten Linien aufgefallen sind. Rainer hatte die ja folgerichtig als Hochspannungstrassen identifiziert. Dann wurde diese Flattengeschichte bei Straßen erwähnt und auch das Linienflüsse Ihr Bett ins Mesh drücken. Ich hatte dann Kontakt zu einem Betabesitzer. Da die Liniencodes im FS2002 schon über die terrain.cfg liefen war klar wo so eine Änderung her kam. Hier der Link mit der damaligen Idee für Wald. War am 29 Juli 2003. Man wie die Zeit vergeht. steht in der unteren Hälfte auf Seite2 und entspricht im Prinzip dem was ich hier auch geschrieben habe, allerdings ohne Autogenspitzen die innerhalb des aus dem Mesh erhobenen Waldes durchschauen. Aber das mit dem Autogenwaldrand hatte ich auch schon damals drin. http://www.wcm.at/forum/showthread.p...g&pagenumber=2 |
Hallo Guido!
Aber die Screenshots in der neuen FXP sind doch von den FSQuality -streets oder habe ich da was falsch gelesen? Wenn ja, dann finde ich sie super! Hoffentlich sind sie mit der AA2005 kompatibel! Viele Grüße Andi |
Ich denke nicht das diese Straßen etwas mit FS Quality zu tun haben.
Diese dort gezeigten Straßen sind ein eigenständiges amerikanisches Paywareprojekt welches sich im wesentlichen nur auf den Raum USA beschränkt. Wenn ich Guido richtig interpretiere hat man mit diesem Team der USA Roads (ev. auch mit jemand anderen) Kontakt aufgenommen um ein ähnliches Projekt für Europa auf die Beine zu stellen. Dieses wird dann unter FS Quality laufen. Natürlich nur wenn ich es richtig verstanden habe. Praktisch ist zunächst mal nichts kompatibel zur ATP2004. Nur wenn man so ein Projekt von FS Quality aufstellt und man weis das der Guido auch einen heissen Draht zu Heinz Rückeshauser (ATP2004) hat dann kann man davon ausgehen das es so erscheinen wird das es auch eine zusätzliche Option geben wird die es kompatibel zur ATP2004 macht. |
@Andragar
Hallo, zu Payware: Ich wehre mich nicht gegen Payware, und bin mir sehr bewusst, wie viel liebevolle Arbeit bis ins Detail notwendig ist, um gute Scenery zu erzeugen. Diese Arbeit soll auch bezahlt werden. Gegen was ich mich wehre, sind eben Produkte, wie dieses Eingangs erwähnte Produkt von FSGenesis. Wo man ein paar Linien anbietet. Genauso wie bei USRoads. Dies kann zu keinen anderen Daten passen (Brücken, Flüsse, usw.). Zumindest nicht so genau, wie ich es sehen will. Wir werden überhäuft werden mit solchen Angeboten und kennen uns genauso wenig aus wie mit den ganzen Meshdaten. Wer glaubt, mit dieser Methode die ganze Welt zu erobern, wird maßlos enttäuscht sein. Nicht der Erzeuger, sondern der Konsument. Das Chaos sieht man bei Mesh. Deshalb fordere ich eigentlich nur Gesamtpakete, die es in Europa ja gibt, und mehr als liebevoll gemacht wurden. Eben mit Mesh, Landklassen, Linien und Polygonen, und jede Menge Objekte. Freeware natürlich nicht. Zu den Freewareautoren: Ich beschäftige mich mit AutoAsm und Sbuilder schon sehr lange! Und stehe mit beiden Autoren in Kontakt. Genauso virtuell, wie mit allen Leuten hier, da ich keinen persönlich kenne. Eines meiner Hauptanliegen war die Integration von Polish Format. Da ich eben dadurch nicht nur bln Dateien importieren kann, sonder auch sehr viele andere Formate. Sämtlich Ambitionen meinerseits waren und sind darauf ausgerichtet, dies eben ohne ein spezielles (meist sehr teures) GIS Tool zu ermöglichen. Es oll eben jeden möglich sein. (Ich kann die Daten so und so anders manipulieren) Mit der Zeit habe ich gemerkt, was ich mit diesen Tools im FS eigentlich anstellen kann. Ich war und bin fasziniert davon. Aber gerade solche jahrelange Arbeit soll für mich auch belohnt werden. Daher verstehe ich es voll und ganz, dass Luis Sa Shareware geworden ist. Ich finde es nicht nur sehr unhöflich, sondern auch den Autoren gegenüber die profitlos enorme Arbeit geleistet haben, eigentlich eine Frechheit, dies nicht einmal zu erwähnen. Den ohne z.B Lee Swordy wäre unser Simulator gar nichts. Gerade die hier beitragenden Designer, Rainer Duda und Holger Sandmann, haben dies in einer mehr als vorbildlichen Weise in ihre Readme geschrieben. Bei Rolf kann ich es leider nicht sagen, dies habe ich nicht gelesen. Ich habe die Arbeit von Christoph Rieger und ihm nicht. Finde aber ihr Verhalten zu ihrem Produkt in diesem Forum mehr als positiv. Zur Methodik: Habe ich nur kurz beschrieben, aber das Angebot gemacht, detaillierte Fragen im Designer Forum zu stellen. Wie es Microsoft gemacht hat, habe ich keine Ahnung Diese Methodik ist im Prinzip dieselbe. Ich konvertiere eigentlich nur die Daten von A nach B. Diese von mir erwähnte Stunde reicht derzeit aus für diese Straßen, Eisenbahn, und Bäche (Linien) und einem Gebiet wie Deutschland Man kann auch die Europa Map nehmen. Damit generierst du sämtliche Straßen für Europa (mehr oder weniger gut, je nach Produkt) Diese Karten sind unterteilt, in ca. 5-8 verschiedene Straßen. Dies sollte ausreichen für FS Design. Dauert natürlich etwas länger. Das Verständnis für solche Integration natürlich noch länger. Aber ich denke es ist bereits relativ einfach geworden. Warum es auf einmal so viele Straßen für ganze Länder und Kontinente gibt, habe ich keine Ahnung. Dasselbe hätte man schon für den Fs2002 machen können Sbuilder arbeitet z.B noch immer mit SCASM. Aber wahrscheinlich haben es die Paywaredesigner (die eben nur Teile anbieten) eben erst jetzt herausgefunden, dass man auch die Straßen korrekt darstellen kann :) Auch für Europa hat es damals die Daten bereits gegeben. Und Michael man kann auch den Rest sehr genau darstellen. Jeden Klick den ich wiederholte Male mache, sollte zum Teil automatisch erfolgen. Die Orientierung an der Mesh Map ist sehr wichtig. Aber dazu muss man sehr langsam den Autor heranführen. Denn wenn er es nicht benötigt, oder kein Interesse hat, wird er dies auch nicht umsetzen wollen. Darum freut es mich, dass man auch ASM und XML überlegt. Meine persönlich Interessen interessieren keinen Autor, die Gemeinschaft der Nutzer wird es aber. Und wenn du jetzt sämtliche Daten von der Topo Map, die ich erwähnt habe (da gibt es jede Pfütze, Industriegebiete, Golfplätze, Gletscher, usw. usw.) sinnvoll integriert hast, beginnt die Liebe zum Detail und des Addons. Die Änderung von Küstenlinien (Texturbreite oder ganz weglassen), der sinnvolle Hintergrund der nicht darstellbaren Texturen (regionale LC und Linien Textur) usw. usw. Aber auch dies kann man, meiner Meinung nach, dem Tool (derzeit nicht) überlassen. Und anschließend kommt für VFR Flieger der wichtigste Teil – Objekte. - richtige regionale Brücken, Burgen, Schlösser usw. Erst dann werde ich mir Gedanken über ein Addon machen. Und deshalb kaufe ich mir auch keine globalen Daten. Nein, diese Liebe zum Detail und der Qualität fehlt. AutoAsm und Sbuilder können nur helfen, diese Details auszuarbeiten, da man sich sehr viel Zeit erspart, für die Vorarbeit. Ich denke halt anders und kann es mit Worten nicht darstellen. Aber ich werde mich zurückhalten mit pauschalen Aussagen und werde nur mehr versuchen Details aufzuarbeiten. Aber in diesem Forum sehr schwer. Horst Ergänzung: @Joachim Auch im FS2002 hat man die Straßen an der Grenze an ATP2002 sinnvoll anschließen können. Da ich es jetzt noch immer kann. Ob man dies in ATP2004 kann, noch keine Ahnung. |
Zu
"Joachim Auch im FS2002 hat man die Straßen an der Grenze an ATP2002 sinnvoll anschließen können. Da ich es jetzt noch immer kann. Ob man dies in ATP2004 kann, noch keine Ahnung". Klar man hätte das damals als auch heute machen können. Die neue ATP2004 habe ich nicht und kann daher nicht beurteilen wie es mal mit diesem Roads Projekt von FS Quality werden wird. Ich weis auch nicht wie jetzt aktuell das Straßennetz der ATP halbwegs an die zum Teil falschen FS Straßen angebunden ist. Ich kann nur das beurteilen wie es mal war. Da sah die Historie wie folgt aus. Ein FS2002 SDK war nicht vorhanden. Die ATP2002 kam daher mit alten FS2000 Straßencode. Damit das nicht mit dem FS2002 VTP Code kollidierte wurden gezielt Default FS2002 Straßenfiles abgeschaltet. Folge wie so oft auch heute noch es fehlten riesige Bereiche des Default FS2002 Straßennetzes außerhalb der ATP2002 bzw. wurden durch alten FS2000 Code ersetzt. Dann war irgendwann ein schuldiger gefunden. Die erste Version von SG1 war schuld. Falsch, das nahm man an weil sich diese in diesem Bereich abspielte. Es rechnete in diesem Bereich keiner mit der ATP. Das habe ich dann im Forum klar gestellt woher diese FS2000 Straßen in Deutschland kamen. Irgendwann kam das Addpack1 mit neuem Mesh und LC. Dann irgendwann das Addpack2 welches dann alles in FS2002 LWM und VTP2 Code brachte. Aber auch dieses wurde nicht an den Default FS angepasst. Man hätte es ja in den Randbereichen anpassen können. Klar kann man nicht unbedingt verlangen das ein Addonproduzent etwas an ein falsches Defaultstraßennetz anpasst. Man muß z.B auch bedenken das die ATP2002 im Endzustand überhaupt nicht mehr Defaultstraßentexturen verwendete. Es wurden hier eigene Straßennachttexturen verwendet. Diesen Umstand wollte ich mit Anpassung ausdrücken. Nicht das man es vielleicht im stillen Kämmerlein für sich selbst anpasst sondern das es später bereits angepasst geliefert wird das FS Quality Europastraßennetz. Einmal durchgehend für die Anwender die keine ATP2004 haben und einmal eine Variante wo die Bereiche die durch die ATP2004 ev. genauer und besser abgedeckt sind ausgelassen sind. Nur halt so, das ein nahtloser Übergang da ist ev. auch hinsichtlich Texturbreite usw. Nur es steht mir nicht zu über ungelegte Eier zu reden. Ev. entsteht ja das Produkt in direkten ATP Programmierumfeld? |
Hallo Horst,
Zitat:
Zudem ist dies ja auch der Grund, warum Peter und Sascha für die SG2 eben meine norddeutschen Flüsse NICHT übernommen haben, sondern komplett und vollständig alles in dem Bereich aus einer Hand neu gemacht haben. So wie ich mit der OWL2003 im FS2002 und FS2004, wo ja für einen kleineren Teil auch bereits alles neu enthalten war. Bedeutete für die beiden zwar irgendwie doppelte Handarbeit, aber wohl doch noch schneller wie gegenseitige Anpassungen/Rücksichtnahme etc. Und meine Flüsse sind schon an die SG2-Grenzen angepaßt. Veröffentlichung der neuen Flüsse (dann als German Rivers - Gesamtpaket) steht bald an. Das FSQuality-Addon werde ich mir natürlich trotzdem so schnell wie dann möglich anschauen (wollen). Zumal dann ja innerhalb Deutschlands große Teile schon besser für uns alle aussehen werden. Unsere südlichen Nachbarn in Österreich genießen ja schon Ihre geniale Austria Pro 2004. Ciao, Rainer. |
Hallo Miteinander,
Da hat sich wieder einiges an guten Ideen angesammelt, was man unbedingt kommentieren müßte. @ Horst: Kommunikation ist, was ankommt, nicht was man sagen wollte. Ich schließ mich Rainer an, so bist Du besser zu verstehen. Und was Deine Aussage von einem Gesamtszeneriepaket versus einem isolierten Straßenpaket betrifft, da stimme ich Dir zu. Es sei denn, das neue Produkt von Fs Quality bringt was völlig anderes als die US Straßen. Schaun mer mal. In diesem Zusammenhang habe ich mir nochmals die Screenshots der Scenery Germany 2 angesehen. Gut, Screenshots ( und vor allem wenn Peter Werlitz diese erstellt) beschönigen manchmal das Produkt. Trotzdem, das könnte es treffen. Was die Straßen anbetrifft, da ist auch nicht jeder Feldweg dargestellt, dafür aber die markanten Auffahrten auf Autobahnen und mehrspurige Bundesstraßen. Industriegebiete sind erkennbar, das heißt als Objekte integriert. Sieht richtig stimmig aus. Kann mir nicht vorstellen, daß ein Automatismus das nur annähernd so könnte. Aber, schaun mer mal. Zu Michaels Bild der Photoszenerie mit den Straßen im Wald. Machen wir mal einen Zeitsprung. Der FS 20 ist gerade erschienen. Inzwischen werden inflight aus einer weltweite Datenbank Fotoszenerien mit einer Auflösung von 1m pro Px geladen. Das Mesh hat einen Gitterabstand von 1m. Aus Schrägbildaufnahmen werde 3D Objekte generiert und vorbildgetreu platziert. Nicht Addons, wohlgemerkt, sonder default von MS. Guidos Nachfolger hat aus FXP eine Hochglanzbroschüre gemacht ( u.a.mit festangestelltem Layouter) :). Im FXP Forum heftige Diskussionen, wann endlich ein vernünftiger Straßen-, Schienen- und Wasserverkehr funktioniere. Garnicht zu sprechen, daß man in den Städten Fußgänger, an den Terminals Passagierverkehr sehen wolle. Aber bitte bei fliegbaren Framrates ab 40 fps. Michael wird ein Screenshot vom FS9 posten, die dann minderjährigen Forumsjünger werden nicht glauben, daß man mal damit " spielen" konnte. Ja, man muß nur warten können. Gruß Rolf |
Rolf,
da konnte ich mir bei gewissen Passagen Deines Textes ein Grinsen nicht verkneifen. Sehr schön formuliert. :D Peter kann übrigens mit seinem 1,6 GHz PC und nicht-aktueller Grafikkarte gar nichts mehr beschönigen. Selbst wenn er wollte. Ciao, Rainer. der sich noch gut an die erste C64-Version des Flugsimulators erinnern kann und damals schon regelmäßig Flugzeuge (damals noch in der Bucht von San Francisco) geschrottet hat. So eine Darstellung wie heute war damals blanke Science Fiction. Und dies nicht nur auf Heimcomputern. |
Noch eine Idee zum Thema Feldwege:
Wenn man bei den Stromleitungen MaskClassMap=0 setzt und dafür RederToTexture=1 wird ja die utilitymask.bmp (bzw der Alphachannel) auf die Textur "aufgetragen". Richtig? Kann man das nicht nutzen, um Feldwege etwas realistischer darzustellen? Wenn man die MaskClassMap Modi verändern oder erweitern könnte könnte man vielleicht diesen Effekt so steuern, dass dies nur in Waldgebieten geschieht. Aber das geht ja wohl noch nicht, oder? (Wie ist eigentlich die utilitymask.bmp aufgebaut? Es scheint ein bitmap mit 256 Farben und Alpha zu sein. Ich habe die Datei mit DXTbmp auseinandergenommen in Alpha Channel und das normale Bild und dann bearbeitet, dann wieder zusammengesetzt und in das ursprüngliche Format konvertiert. Hat aber nicht funktioniert. Außerdem wird die Textur und der Alpha Channel in DXTbmp ganz anders angezeigt als in imagetool...) Das mit den Strommasten hab ich schon selbst rausgefunden und bin sehr zufrieden. Ich hab auch die Autogenzuordnungen der Straßen angepasst indem ich die Lampen entfernt habe und die Abstände der Schilder vergrößert habe, gefällt mir sehr gut! |
Zu
"Wenn man bei den Stromleitungen MaskClassMap=0 setzt und dafür RederToTexture=1 wird ja die utilitymask.bmp (bzw der Alphachannel) auf die Textur "aufgetragen". Richtig?" MaskClassMap=0 schaltet diesen Texturwechsel der abhängig von der jeweiligen Landclasscenery ist ab. Da es ein Liniencode ist, eben diese texturierte Linie. Das ist das was ich auch mit meinem Patch damals bewusst gemacht habe. Ich habe dieses nie gemocht siehe meine Homepage. RenderToTexture=1 ist z.B die Änderung die die ATP2004 zusätzlich macht. Das hat in Kombination mit MaskClassMap so eine Art Schattenbildung bzw. Abdunklung der LC Scenery im Bereich des Liniencodes zur Folge. Es kommt dann halbwegs real rüber als wenn die Hochspannungsleitungen eine leichten Schattenwurf erzeugen. Zusätzlich ändert die ATP den seitlichen Offset der Hochspannungsmasten zum Liniencode. Die Masten stehen dann nicht mehr mittig sondern seitlich in dieser leicht abgedunkelten Linie die sich in der Landclasscenery bildet. Dadurch wirkt es nochmals realer. Sehr schön gelöst vom ATP Team. Sieht sehr schön aus. War damals auf deren Homepage ich meine sogar in einer FXP zu sehen. Habe mir das mal so im FS eingestellt da sisht man es dann noch besser. Die utilitymask.bmp ist wenn man es genau nimmt eigentlich fast nur ein Alpha. Es ist wie auch die Straßen eine spezielle Linientextur. Diese gibt es in verschieden Ausführungen hinsichtlich Segmenten. Diese Segmente hängt der FS aneinander an wenn er z.B eine VTP Polystraße mit diesen Texturen verkleidet. Bei einigen Liniencodes ist das vierte Segment noch mal in der Länge in Segmente geteilt. Das sieht man so aber nicht. Deshalb schaue man ins SDK. Übrigends nicht allein die Breite die man im VTP2 Liniencode programmieren kann bestimmt die Breite einer Straße im FS sondern auch der Alphakanal den man den Texturen beifügt. |
Hallo,
Ja, die südlichen Nachbarn sind ja verwöhnt! Steht aber auch bei Flugwerk, das GPS Daten verwendet wurden. Ich möchte aber zu dem Begriff „Automatismus“ noch etwas schreiben: Wen dies jemand falsch versteht, bitte nur eine Frage stellen. Und nicht meine Aussagen interpretieren. GPS Leute und FS Leute haben im Prinzip das gleiche Problem! Sie wollen alle, akkurate Daten am richtigen Fleck Der mit GPS navigiert benötigt nur den Hintergrund in Form von Linien, Punkten und Polygonen. Der im FS herumfliegt benötigt dies genauso dargestellt, jedoch mit anderen Texturen und den Punkt mit Gebäuden. Daher will ich solche Produkte, wie Straßen, ja nicht verurteilen, sie machen für mich nur alleine verkauft, keinen Sinn. Und wenn sie noch so genau sind!! Nur man soll bei den Preisen und Produkten auch Schüler, Studenten und Arbeitlose nicht vergessen. Auch sie wollen unseren Gedanken folgen und Freude am Fugsimulator haben. Für jede Szenerie brauche ich eine Vorlage: eine Karte oder ein Orthofoto oder eine Landsat. Ansonsten orientiere ich mich nicht an der Realität, sondern bin ein Künstler. Ich kann diese nachzeichnen, oder ich importiere die Daten. Und hier kann ich mir viel Arbeit ersparen! Ich mache beim Import nichts anderes, als jener der dies händisch nachzeichnet. Ich definiere die Texturen genauso. Anders bei Holger, der sich z.B auch über Afrika macht, den dort findet man nicht sehr viele Daten. Ich brauche die importierten Daten halt nicht noch einmal nachzeichnen. Bei kleineren Szenerien kann man sicherlich „illegal“ arbeiten. Abändern kann ich sie in vielen Stadien. Ich mache keine Werbung für bestimmte Produkte, würde mir aber eine Vereinigung der Produkte oder Tools wünschen. Wir hätten dann auch einen „Terra-Max“ Abseits von Thema (?): Finde aber die Importierung von LWM und VTP in Sbuilder sehr sinnvoll, da ich endlich sinnvoll die originalen Files exkludieren und deaktivieren kann. Und über die sinnvolle Integration von Ufervegetation und Bäume an Straßen mache ich mir selbst schon sehr lange Gedanken! Ehrlich, wer nimmt den Orthofotos her, um dies exakt einzuzeichnen? Ich mache mir Gedanken über die Ufer. Wie sinnvoll man dies Linien unterbrechen kann und dies mit Vegetation und teils breiteren Linie abhängig von Mesh machen kann. Jemand eine Idee? (Händisch ja, (dazu bitte keinen Kommentar, außer man hat die Gegend selbst vermessen - bzw. teilt mit wie man dies selbst macht Und nach welchen Vorlagen) – aber die Natur hat dies auch nicht händisch gestaltet?) Horst |
Hallo,
zum Thema Uferlinien: Jim's Slartibartfast hat eine Option, die Texturbreite automatisch zu beeinflussen. Urspruenglich war das so gedacht, dass steilere Ufer schmalere Uferlinien haben sollten, nur ist die Umsetzung nicht so einfach und es ist eine Art Zufallsgenerator daraus geworden. Sieht aber immer noch besser aus, als in einheitlicher Breite. Allerdings: fuer mich liegt das Unschoene der Uferlinien in den Texturen selbst, unabhaengig von Breite - die sind fuer viele Gegenden der Welt einfach zu gerade. Also Texturen selber erzeugen, was auch saisonale Unterschiede erlaubt. Nach einigen wenig erfolgreichen Versuchen kam fuer mich die "rettende Idee" von Lennart Arvidsson, der ja auch schon sehr gute Landclass-Austauschtexturen fuer den FS2000/2002 erzeugt hat. Schaut euch mal die "Farm Sognefjorden" Freeware-Szenerie etwas genauer an: http://www.flightsim.no/file/FS2004/...ropa/Fly_Fish/ (anscheinend nur dort erhaeltlich). Die Austausch-Uferlinien sind dort sehr stark gezackt, was wegen der etwa 4-fachen vertikalen Verzerrung der Uferlinien-Darstellung im Sim einen sehr realistischen Effekt erzeugt. Keine Ahnung warum er 512x512 Texturen benutzt, da die meinen Beobachtungen nach keine Qualitaetsverbesserung bringen, aber die Idee selber ist halt gut. Darauf aufbauend habe ich mir dann saisonale Texturen fuer Seen und Meer selber erstellt und bin damit sehr zufrieden (Im Austausch habe ich ihm dann meine "Wasserfalltextur" fuer steile Baeche zukommen lassen). Habe momentan keinen "technischen" Screenshot anzubieten, aber der angehaengte kann das vielleicht ansatzweise zeigen. Ciao, Holger |
Ich nochmal, mit zwei weiteren Anmerkungen:
Es macht natuerlich wenig sinn, solche neuen Uferlinien global anzuwenden, sondern nur da, wo sie auch dem Landschaftstyp entsprechen. Das kann man bei Ground2K4 per "ownlines" Feature erreichen oder direkt im Header des VTP2 Codes. Eine andere interessante Herangehensweise habe ich neulich beim Finnish Scenery Design Team entdeckt. Deren FinnTerain, Landclass, und 3D Szenerien sind sowieso den Download wert - http://fisd.fsnordic.net/projects.php - und bei den Kuestenlinien des FinnTerrain haben sie ganz pfiffig eine zweite Linie, breiter, gruenlich und halb-transparent, unter den eigentlichen Strand gelegt, und damit ganz gut einen ufernahen Flachwasserstreifen erzeugt. Sicherlich auch etwas, wo man mit weiterem experimentieren einen realistischen Effekt auch anderswo erzielen koennte. So, jetzt gehts aber erst mal fuer eine Woche in den Wald - Arbeit zwar, aber immerhin ohne Computer. Cheers, Holger |
Zu
"Schaut euch mal die "Farm Sognefjorden" Freeware-Szenerie etwas genauer an: http://www.flightsim.no/file/FS2004...uropa/Fly_Fish/ (anscheinend nur dort erhaeltlich). Die Austausch-Uferlinien sind dort sehr stark gezackt, was wegen der etwa 4-fachen vertikalen Verzerrung der Uferlinien-Darstellung im Sim einen sehr realistischen Effekt erzeugt". Hier speziell die Thematik 4 fache vertikale Verzerrung. Das war auch damals im FS2002 der Grund warum man bei meinen Straßentexturen im Urzustand nur einfache Punkte sieht wenn man die Textur selbst betrachtet. siehe auch hier inkl. Bildern des Problemes Straßentexturen für den FS2002 Mit einer der Gründe warum man das ganze nur so hintrimmen kann das optisch ein Effekt von einer Straße entsteht. Korrekt darstellen kann man das nicht. Zumal leider diese Dehnung der Straßen nicht linear ist. Denn da kommen die Einzelsegmente und speziel im letzen Segment die zusätzlichen vertikalen Segmente der Textur zum Einsatz. Aus diesen Möglichkeiten muss sich der FS eine Möglichkeit schaffen die Polygonfläche der Straße zu verkleiden. Eine Straße kann in der Länge bekanntlich variieren daher dann die oftmals nicht lineare Verzerrung. |
Hallo,
Herzlichen Dank für die Infos. Ich habe mich derzeit lange mit den Fehlern bei Sbuilder und der Erzeugung von LWM Polys beschäftigt. Na ja, man kann jetzt mehr als ca.32000 Polys (16 bit – 32 bit) machen, aber eine Restquote an Fehler ist noch vorhanden. (Kontrollieren). Daher habe ich dies Thema immer vernachlässigt. Holger, kann ich dir nur zustimmen. Ohne bedacht auf die Texturen geht es nicht. Daher hänge ich zu deinem schönen Shot ein Archivbild an, das einen hässlichen Übergang zwischen Linie und Polygon zeigt mit den normalen Texturen. Importiert mit 1024 für stream und default LWM für Polygon (ohne Küstenlinie). Ich denke, es muss mehr aus der Meshmap in Sbuilder herauszuholen sein. Ich habe immer die Information der Höhe, und muss die Information mühselig selbst ändern. Und mir fällt kein sinnvoller Vorschlag für Luis ein. Eure Gedanken und Beobachtungen muss ich erst selbst nachvollziehen. Für die Straßen, denke ich auch an die Änderung von Telfonmasten zu Bäumen an Landstraßen. Ich denke auch eine sinnvolle Ergänzung der terrain.cfg (keine Abänderung!) macht Sinn. Horst |
| Alle Zeitangaben in WEZ +2. Es ist jetzt 13:49 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
© 2009 FSL Verlag