Hallo Joachim, hallo alle,

Du bringst das ganz fantastisch rüber, wie Tag- und Nachttexturen zusammenspielen (müssen)! Ich selber flieg auch sehr gerne in diesen Übergangsstunden, da hier vom Licht, vom tiefen Sonnenstand und eben von den beginnenden Lichtquellen alles viel plastischer ausschaut.

Mit diesem Wissen werde ich jetzt alle zukünftigen Taustexturen ganz genau prüfen und wahrscheinlich vieles gar nie installieren!

Beste Grüße,
Fritz

Hallo,

Zu:
"Ich auch nicht.
Das was man lesen kann, bzw. die Screenshots sprechen aber dafür, dass man bei UT den Weg über eine geänderte terrain.cfg gehen wird"

Dachte ich ursprünglich auch, aber dem scheint nicht so zu sein.
http://www.simforums.com/forums/foru....asp?TID=11451
Sehe dir die Bilder hier genauer an.
Eine eigenartiger Versuch diesen Effekt darzustellen.
Vor allem, da er aus unterschiedlichen Quellen (Mesh) erzeugt wird.
Die Erzeugung ist sicher über ein bestimmtes mesh file entstanden, der Anwender benutzt aber andere Höhendaten.
Suche den Abstand der "Lichtpunkte" zu Vtp Linie, man erkennt die Unregelmäßigkeit.
(abgesehen von den "eigenartigen" Vtp Texturen)
Bei terrain.cfg wäre es konstant.
Auch habe ich gelesen, dass Holgers "zweite Linie" (für Vtp offset) verwendet wird.
(= Framerate – Problem)

Zu:
"Meiner Meinung nach übertrifft normale Landclasstechnik bisher auch VTP Polytechnik um Ortschaften darzustellen."

Ja und Nein (IMHO)
Man kann exakte (realistische) Polygone auch mit Landclass darstellen, bzw. mehr oder weniger genau "einfach" platzieren.
Oder diese Polygone auch gezielt verwenden.
Der "Mix" ist meiner Meinung nach entscheidend. (und natürlich die Daten, die man verwenden kann)

Zu:
"Ähnlich finde ich es wenn man zuviel Wert auf VTP Straßencode als optische Komponente legt. Ich finde den Weg der AROE da ganz gut.
Kleinere Straßen sind erkennbar, drängen sich aber nicht gegenüber den Straßenfragmenten der Landclasstexturen vor."

Ich kenne auch die AROE Daten nicht!
(außer Bilder)
Derzeit würde ich die ganzen Nebenstraßen überhaupt weglassen. (auch streams, die AROE ja nicht hat)
Sie passen nicht zu LC.

Über die verwendeten Tools und deren Umsetzung und Korrektheit der Darstellung kann man sich ebenfalls Gedanken machen.

Horst

Ich weis nicht, ich finde die Leuchtpunkte sind doch schon recht konstant über der Erdoberfläche. Kann man vermutlich nur mittels Besitz der scenery beurteilen. Außerdem könnten ja durchaus mehrere unterschiedliche hohe Lichtdefinitionen einer Straßennummer zugewiesen werden.

Was mich aber in der Tat wundert ist das mit der halo.bmp.

Habe mich damit nie befasst. Frage mich nur was da für ein Polygon/Objekt hinter dieser halo.bmp steckt.

Muss ich mir doch mal betrachten.


Zu
"Zu:
"Meiner Meinung nach übertrifft normale Landclasstechnik bisher auch VTP Polytechnik um Ortschaften darzustellen."

Ja und Nein (IMHO)
Man kann exakte (realistische) Polygone auch mit Landclass darstellen, bzw. mehr oder weniger genau "einfach" platzieren.
Oder diese Polygone auch gezielt verwenden."

Hier ist jetzt die Frage was wir meinen.

Ich vermute mal mit dem Satz:

"Man kann exakte (realistische) Polygone auch mit Landclass darstellen,"


meinst Du jetzt ein VTP Poly welches jetzt eine LC Nummern zuweist.



Sehe ich das richtig?


Klar das Verfahren selbst ist bekannt. Nur wenn ich mir das bisher in den Addons anschaue wo so etwas verwendet wird, dann sehe ich das optisch sofort. Es sieht immer unrealistisch aus.


Ich habe das auch sofort in den Screenshots der letzten FXP beim sogenannten Landclasstest gesehen, das man hier zum Teil reines Landclass mit Landclass über VTP Poly verglichen hat.


Problem ist z.B, dass man in der Regel mit einem VTP Poly die realen Ortsumrisse nachbildet. Man arbeitet aber nicht wie bei reiner Landclasstechnik anhand Texturstrukturen wie Straßenzügen, Feldkanten usw.

Klar man könnte folgendes machen. Einfach den Zwischenweg gehen. Versuchen mit einem Poly möglichst genau den realen Ortsumriss einhalten aber diesen nur anhand Strukturkanten der Texturen zu bilden.

Das bedeutet natürlich, dass so ein VTP Poly dann sehr viele Definitionspunkte bekommt.


Weiterhin ist die Erstellung dieses optisch optimalen VTP Polys nicht einfach. Das setzt voraus das man im Prinzip schon vor dem Zeichnen des Polys wissen muss wo Strukturkanten der Bodentexturen liegen werden.

Was wiederrum bedeutet, dass man genau wissen muss wo auf der Erdoberfläche bei z.B LC107 jede der sieben 035 Texturen auf der Erdoberfläche genau liegt.

Man wird bei so einem optisch optimalen Poly aus meiner Sicht mindestens den doppelten Aufwand betreiben müssen.

Man wird nicht drumhinkommen zunächst das reale Poly anhand Ortsumriss zu zeichen. Diesem müssen dann die LC Texturen korrekt positioniert hinterlegt werden. Jetzt wird das Poly neu gezeichnet.

Möglichst nah anhand dem realen Ortsumriss aber nur so nah, das man auf jeden Fall die Strukturkanten mit einbezieht.

Hallo Joachim,

bei UT wird alles mit BGLs erzeugt, auch die Lichtpunkte. Mit dem mitgelieferten Konfigurationstool kann man diese auch komplett abschalten bzw. ausdünnen falls es einem "zuviel Licht" ist.

Ein Review zu UT findest Du z.B. unter:

http://www.simflight.de/modules.php?...ticle&sid=5922

Da gibt's auch Screenshots von dem besagten Konfigurationstool was sehr einfach und mit wenigen Klicks schnell zu bedienen ist:

http://www.simflight.de/users/reviews/UT-USA/ut19.jpg

http://www.simflight.de/users/reviews/UT-USA/ut20.jpg

Viele Grüße,
Michael Grüterich

Danke für die Info Michael.

Wenn die Lichtpunkte über BGls erzeugt werden, so könnten es natürlich dennoch VTP Linien BGLs sein. Ev. als doppelte Version zu den Straßen. Das könnte natürlich die Performance belasten.

Da Du offensichtlich UT besitzt wäre es für mich natürlich interessant ob man den Weg über terrain.cfg geht.

Ein abschalten wäre ja auch über Editierung der terrain.cfg möglich wenn es denn darüber läuft. Dann bräuchte man keine doppelten BGLs.

Findet sich dort etwas editiertes oder hat man gar eine neue terrian.cfg eingespielt. Die org hat 51687Bytes.

@Jobia

Zu:
"Ich weis nicht, ich finde die Leuchtpunkte sind doch schon recht konstant über der Erdoberfläche."
Siehe:
http://holger.fs-shipyards.net/image...lights%201.jpg

Siehe die Punkte im SW Teil (schwarzer Hintergrund)

Zu:
"meinst Du jetzt ein VTP Poly welches jetzt eine LC Nummern zuweist."

Nein, und wenn ich dich richtig verstehe, meine ich gerade den umgekehrten Weg.

Die Ortsumrisse hast du in einer Topo-Karte definiert.
Diese Umrisse kann man anhand von Raster als auch von Vektor Karten relativ einfach mit normaler LC Definition darstellen. (Soweit es die Auflösung der Darstellung von LC erlaubt)
Du verwendest im Prinzip nicht das Polygon, sondern nur deren Flächenabdeckung.
Ohne Ortkenntnis nicht einfach.

Die Information aus herkömmlichen Topo Karten ist zu gering (Stadt-Land-Spiel).
Und die Arbeit und die Darstellung mit VTP Polygonen wird erst logisch, wenn du exakte Daten verwenden kannst.

Vielleicht finde ich Zeit die Gedanken exakter und verständlicher niederzuschreiben.

Horst

Hallo Joachim,

ich habe hier UT-Kanada, aber daß die Terrain.cfg manipuliert wird, kann ich mir eigentlich nicht vorstellen. Ich habe hier vier von mir modifizierte Terrain.cfgs die ich öfter mal zu Testzwecken wechsele, das hätte mir dann auffallen sollen...ich schau aber nachher nochmal nach.

Ferner "killen" die UT-Lichtpunkte auch das Autogen, je nach Einstellung der Dichte im Konfigurationstool stark bis unauffällig. Ich schätze mal, es wird über VTP Linien BGLs gemacht, wie Du schon gesagt hat.

Viele Grüße,
Michael Grüterich

...so, ich habe jetzt mal nachgeschaut.

Die Terrain.cfg wird nicht geändert, sondern das Konfigurationstool benennt im UTCananda/Scenery Verzeichnis jede Menge BGLs von *.XXX in *.BGL um.

Die BGLs der Lichtpunkte kann man in SCASM-Code umwandeln, was mich nicht wundert, denn wir haben seinerzeit bei der ersten boxed Version der "Rhein-Ruhr 2000" ähnlich gearbeitet.

Die Punkte sind Objekte, welche über PerspectiveCall --> RotatedCall mit dem Befehl Light erzeugt werden, z.B.

Light( m 4 261.56 10.00 187.83 1065353216 0.00 0.00 FF 240 181 255 0.00 0.00 1.00 )


Viele Grüße,
Michael

Ok also normaler Code.



Hatte eben einen längeren vermutlich für einige interessanten Text geschrieben. Speziel auch zu Horst seinen Äußerungen und der Interpretation von Landclass und Poly.

In Horst seinem Satz :

"Man kann exakte (realistische) Polygone auch mit Landclass darstellen," liegen zwei Interpretationsmöglichkeiten. Ich hatte auch ein Bild aus meiner Dok dazu angehangen. Dieses Bild hat mich aber den Beitrag gekostet.

Habe vorher nur auf die Byte Größe geschaut (die war OK) nicht aber auf das Pixelformat. Das war über der im Forum zulässigen Größe von 800 x 600.

Dumm gelaufen, Fehlermeldung das Bild zu groß, mit dem Nebeneffekt das der ganze Text weg ist.

Habe jetzt keine Lust mehr zum schreiben.

ok, ich hab gesagt ich schreib mal nichts mehr ... aber ich hab den ersten Teil von JOBIA's Mehrteiler auf BEV gepostet (und übersetzt) - hier die Antwort von Stephen (dem BEV-Designer) - diesmal ausführlicher:


You bring up a couple of very interesting points that I'd like to address.
1) BEV texture colors are a much closer match to the defaults than other scenery textures...in fact it was my original intension (back when I was creating these for myself) to have as natural of a blend as possible so that the default textures such as farmlands and textures outside the normal B and C sets would look natural. I've tried very hard to maintain that integriry throughout the development and although there are some notible differences, i.e. water and conifers...the majority of textures even blend in well with the world mask. Point is, you could purchase US\Canada and those textures that are found in other parts of the world will blend in very well.

2) None of the textures that aare included in the BEV textures are created from arial or satellite photos! That is a very important feature that everyone should know. I have observed several satelite and arial photos to get a real world perpective on how things should be laid out (especially city textures), but what you see are results of hand drawn textures that are then scanned into the computer and then hand colorized. I use several tools to include Photo Shop 7, Gimp, FXFoto, just to name the more prominent ones and through a long process (over 3 years) I've finally concieved a technique that works very well...and what you see are the results of that effort. I must also give credit to the members of the Beta Team as their insistence on better and better textures has increased the quality by at least 30 to 40 percent. Case in point are the new desert and dry textures...when I first handed them over to the team...the colors were all wrong...they looked fine as individual texture sets, but really didn't blend in well with each other or the previous created more temperate areas. The team's observations, and suggestions made a huge difference and you can see that difference in the screenshots posted in the forum and on the website. We have literally changed the face of desert\dry area within FS! To me, that is a huge accomplishment and has just raised the standard another notch.

3) With what I've explained above...the same technique will be used to create the other seasons. I have absolutely no intensions of taking the existing textures and add or subtract hue and saturation in order to get a unsatisfactory result. Again, many, many arieal photos as well as any sat photos will be used to get some ideas, but the results will be more so from the input of the Beta Team and interested members of the community who would like to add their comments to the forum.

4) Europe has a planned release date of near the first of the year and will probably begin with Spring textures. The hope that with the announcement of the commencement of developing European textures we'll get community members to give us their two pence worth...that is my hope, but more often the case members would prefer waiting for the end results and then add their two pence after the fact. As I said, hopefully this wont be the case and we can create the texutures based upon what people actually see and what they want it to look like in their simulator. I can't begin to tell you the impact the BTs have had on this project and thankfully we have many Europeans within the group. But anyone is welcomed to add their thoughts and comments and post pictures, etc. Just start a thread on the forum and I'm sure it will grow as the developing stage for Europe draws closer.

5) As far as seasonal textures...you're absolutely right that various parts of the world changes depending upon the temperate zone coded by MS. As I stated earlier, there shouldn't be any real issues with blending as we have done our best to ensure that doesn't happen. Along with the seasonal textures...it is (IMO) a bit silly to think that every virtual pilot does his\her flying only using the seasons according the actual calendar. I for one fly summer throughout the year (but that was primarily because any existing winter textures never looked all that real to me) and will probably continue to do so. I believe I'm not alone here as I'm sure there are literally hundreds if not thousands of vps who fly outside the calendar seasons. Let me also explain that the whole purpose of the BEV project is to make all of the seasons more enjoyable to fly in. To illustrate...I stayed away from desert areas simply because the textures lacked any interest. They were boring, leopard spotted textures that did absolutely no justice to the beautiful desert areas that I live in. With the creation of the BEV desert\dry textures...suddenly there is a whole new exciting world to explore. The same will apply to the seasonal textures as well...Fall will be absolutely stunning, winters will be a world of shimmering lights and shadows, and spring will be as colorful as spring in real life...you'll swear you're seeing flowers in those moutain meadows.


(Fortsetzung im nächsten Post)