GradientViewport.dll im Pluginorder bei SU 6 verursachte nicht nur die Abstürze bei mir unter Vista,
sondern ist auch verantwortlich für ein ärgerliches Problem bei der Texturbearbeitung:

Sowohl unter Vista wie auch auf meinem Laptop mit XP /Ati-Radeon blieb beim Editieren einer Texturfläche diese selbst ohne Texturdarstellung, was die Ausrichtung derselben verständlicherweise fast unmöglich machte.

Tritt dieser Fehler auf, besteht auch ein zweiter: Der Arbeitshintergrund jeder Skp-Datei wird immer dunkler und stark schattiert dargestellt, jedes Umfärben ist nicht möglich.

Bei einem anderen Rechner unter XP sowie unter SU 5 zeigten sich diese Fehler nicht.

Wie ging es weiter ?

Die wirkliche Ursache des Problems lag in meinem Plugin-Ordner:

Die GradientViewport.dll (mit Gradient Hintergrund.rb unter /Diverses) erweist sich als inkompatibel. Nach deren Entfernung läuft alles rund, auch mit Original-Grafik-Treibern.

Die GradientViewport.dll ist ebenfalls Ursache für einen weiteren Fehler auch unter einigen XP-Konfigurationen. (Dazu eine eigene Überschrift ...)

Ergänzung:

Laut Vistas "Problemberichte und-lösungen" verursacht der NVIDIA-Grafiktreiber das Problem. Auch die Installation des neuesten NVIDIA-Treibers 175.19 erbrachte keine Besserung.

Ich habe daher alle NVIDIA-Treiber runtergeschmissen und statt dessen erst einmal den entsprechenden von
http://www.omegadrivers.net/
installiert. Respekt ! Da gibt es für Karten von Nvidia und Ati kostenfrei aktuelle Treiber, die die Originale ersetzen können. Wenn auch nicht so schnell, jedoch bislang ohne Fehler. Habe wohl den starfighter gegen die turboprop getauscht.

bin merkwürdig überrascht, welche Scheunentore Marktführer bei ihren Produkten offen stehen lassen und wie es möglich sein kann, parallel Ersatz bereit zu halten.

Wenn Du im Layer-Fenster das Minuszeichen verwendest, hast du die Möglichkeit, Layerinhalte auch komplett auf den aktuellen Layer zu verschieben. Dadurch kannst Du deine Layer leicht und gezielt zusammenfassen.

Der Vista-Anzeigetreiber nvlddmkm.sys stürzt ab, Vista ist Sekunden später wieder da, aber das Programm (eben auch SU) ist hängen geblieben. Ein ärgerlicher Bug und wenn man das Problem benennen kann, sieht man: das Internet ist voll von frustrierten Anwenderstimmen.

Hier ist offensichtlich etwas nicht ausgereift!

-- Welche Erfahrung habt Ihr ?

Soviel habe ich zusammengetragen: Ein Vista-Kompatibilitätsproblem, offensichtlich im Zusammenhang mit OpenGL - tritt unregelmäßig auf - in der Tendenz mehr bei 64Bit-Systemen, mehr bei viel Arbeitsspeicher, mehr bei NVidia-Grafikkarten, mehr bei SLI-Boards -- aber nicht nur. Die Grafikkartenhersteller loben Besserung, aber dass Problem ist seit 2 Jahren Thema.

Kann man die Gefahr durch Einstellungen im System verringern ? Die Hardwarebeschleunigung auszustellen ist ja nur ein Notnagel, keine Lösung.

SU Pro 6 auf Vista 64 / 8800 GT

Danke Nobert.

Ich habe unterdessen das Problem durch einen anderen Weg gelöst, den ein ebenso überraschter XP-Anender mit dem gleichen Problem für sich entdeckt hatte: Durch Installation von SU 5 (!) Pro. Da funktioniert es und und die Installationsroutine beseitigt das Problem in SU 6 gleich mit.

Sicherlich kein Königsweg ... aber doch zielführend.

Die Freude über meinen neuen Rechner (Quad, Nvidia 8800 GT, Vista x64) wird etwas getrübt:
Beim AVI-Exportieren aus SU 6 pro funktioniert die Optionseinstellung für den Codec bei mir nicht wie von xp gewohnt.

Die Codec-Einstellung springt immer zurück - auf den Uralt-Codec Cinepack von 1995 (Radius) - mit dementsprechend mäßigen Ergebnissen. Alle Versuche, einen anderen Codec auszuwählen, werden nur scheinbar angenommen - die neue Einstellung für die Codecauswahl wird nach Schließen des Optionsfensters nicht gespeichert - obwohl alle anderen Einstellungen im Optionsfenster akzeptiert werden. Keine Fehlermeldung, die alte Einstellung bleibt maßgebend. Neu installierte Codecs werden zwar angezeigt, aber nicht übernommen - immer der gleiche Fehler.
http://www.sketchucation.com/forums/scf/posting.php?mode=post&f=47&sid=08600e34a4cbfff7e4f42e65d9f3ae08#

Liegt die Ursache für diesen Bug bei SU oder Vista? Wer sieht eine Möglichkeit, aus dieser Falle herauszufinden?

Wolfram, mit WinXP klappt es.

Aber es wird doch andere Mac-User geben, die Gebäude mit Texturen hochladen können ?

[Ralph]

Wolfram,

ich kann Deine Probleme nicht nachvollziehen.

1. Den Grund für Deinen "Schatten-bug" habe ich bereits erläutert unter "Nachtschattenproblem" http://www.sketchucation.com/scf/viewtopic.php?f=14&t=1622

Dort beschreibe ich, das wie dies durch wechselnde Anwendung von SU-free und SU-pro entsteht, verbunden mit einem eingestellten Standort außerhalb der USA. Die Datei, nicht das Programm musst Du verändern.

2. Bei der Übertragung von skp auf kmz musst Du auf zwei Dinge achtgeben : In einer KMZ wird alles, was deutsche Sonderzeichen ä,ö, usw. enthält, nicht angezeigt. Schon der Name der verwendeten jpg zB. darf diese Zeichen nicht enthalten. Und wenn du das File bereits selber vor dem Hochladen über export/3dmodell testen willst: darauf achten, dass GoogleEarth4.kmz ausgewählt ist - Ohne die 4 keine Texturen.
   Eine so erstellte KMZ ist identisch mit denen, die man aus dem 3Dwarehouse lädt und startet korrekt mit Doppelklick auf die Datei die Prozedur in GE.

[Ralph]

Fein.

Aktuelle Version ist jetzt 6.0.1099.

Und die erste positive Überraschung: Der Konflikt der Sandbox mit vielen PlugIns, den ich nie ausräumen konnte, ist offenbar Vergangenheit. Sie erscheint brav an ihrem Platz, als ob nie etwas gewesen wäre...

[Ralph]

Während SU keine Probleme mit deutschen Umlauten in den Bezeichnungen zeigt, ist Google Earth da intolerant:

Ein kleines ü im internen Texturnamen, den SU aus dem Dateinamen der verwendeten jpg abgeleitet hatte, ließ alle von ihr belegten Flächen jeweils in einer anderen bunten Spektralfarbe erscheinen und konnte erst nach einer zeitraubenden Fehlersuche aufgespürt werden.

[Ralph]

Leider funktioniert bei mir der Zugang nicht in der beschriebenen Weise.

Mit :80 heißt es bei mir "Der angegebene Ordner ist ungültig. ..."

Und ohne fragt mich http://www.su.porta.ca zwar nach Benutzer und Passwort, doch nach Eingaben mit guest wird dies nur stoisch wiederholt.

Win xp mit SP2

[Ralph]

Ein Problem hat man selten alleine ...
Und weil ich ihn noch nirgends dokumentiert gefunden habe, hier die Beschreibung eines speziellen Bugs:

Nach Aufruf einer Szene oder zuweilen auch schon beim Öffnen einer Datei zeigt sich das Modell als dunkle oder schwarze Silhouette, bestenfalls in ungewohnter Abendstimmung. Die Tageszeitvorgabe zeigt nächtliche Uhrzeiten, mit Glück springt die falsche Zeit bei Anklicken der Tages- oder Jahreszeitregler in die gewohnte Position, - nicht immer. Eine Speicherung einer helleren Tageszeit in der Szene gelingt nur kurze Zeit, nach erneuten Öffnen der Datei steht man wieder vor dem gleichen Problem.

Nach meiner Erkenntnis liegt dem folgende Ursache zugrunde:

Die Datei wurde zum Teil in SU pro (welches eine Ortsvorgabe zulässt) und SU free ( keine Standortwahl auf dem Globus möglich) bearbeitet, insbesondere die Abspeicherung der Szenen/Seiten scheint hier zum Problem zu werden. Die sich so merkwürdig überlagernden Einstellungen von europäischer und amerikanischer Zeit lassen sich in SU free nicht mehr heilen, mir hilft nur eine Rückkonvertierung in SU 5 pro und erneutes Abspeichern der Zeitvorgabe und des geografischen Standorts.

http://lh4.google.de/58Ralph/RqiS2qU5REI/AAAAAAAAAAs/r7zrXkmc7MI/nachtschatten.jpg?imgmax=720

nachtschatten.skp

[Ralph]

Eine Komponente, die sich gleichzeitig in 2 oder mehr Flächen schneidet gibt es in SU wohl nicht.

Dies ist ja nicht nur an der Ecke, sondern auch auf der Wandinnenseite ein Problem, wenn man die Wand als Körper, also auch mit Innenfläche, modellieren will.

Einen ähnlichen Fall habe ich für mich so gelöst:

Ich verzichte auf das automatische Aufschneiden. Aber ich baue in das Fenster, welches eine komplette Komponente bleibt, eine unsichtbaren Hilfskörper (Hidden Geometrie) ein, den ich zum Schneiden der Rohbauöffnung benutze. Der Hilfskörper sollte nach außen und innen überstehen. Beim Schneiden muss dann die verdeckte Geometrie angestellt sein. Wenn man den Hilfskörper auf einen eigenen Layer legt, kann man derweil das übrige Fenster auch ausstellen.

Die Prozedur hat sich für eine Serie von Fenstern ganz gut bewährt.

--- ok. - zugegebenermaßen nicht ganz so elegant, als wenn das Loch gleich beim Einsetzen der Fenster in die Wand kommt. Aber dies kann dann nicht passieren : Bezieht man eine Wand mit den automatisch eingeschnittenen Fenstern mal eben schnell in eine Gruppe ein und denkt nicht dran auch wirklich alle Fenster mit einzusammeln, dann geht da das Rollo herunter - und nicht so schnell wieder auf.

[Ralph]

Danke für den Raum hier, Coen!
-Ralph

[Ralph]