Seite 3 von 5

Re: Zusi-Objektalbum

Verfasst: 08.10.2018 17:36:49
von Matthias H.
Hallo Holger,

an ein direktes Öffnen der Objektdatei im Editor hatte ich gar nicht gedacht ;)

In meinem Anwendungsfall habe ich im 3D-Editor eine Strecke mit Landschaft geöffnet und brauche die Objekt-Datei (den Pfad) nur in der Drag&Drop-Liste (Funktion "3D-Objekte aus einer Drag&Drop-Liste in die Landschaft importieren"), um von dort an die richtige Stelle schieben zu können. Zusätzlich müssen dort auch noch ein paar Parameter mitgegeben werden (Schreibgeschützt, direkt einbinden, Billboard...)


Gruß
Matthias

Re: Zusi-Objektalbum

Verfasst: 08.10.2018 17:44:09
von Holger Maaß
Hallo Matthias,

ich denke, diesen Weg werden wir auch weiter so beschreiten. Sind zwar zwei, drei Klicks mehr, aber mein Luxusweg funktioniert nicht. Ich wollte eine Datei sozusagen als virtuelle Zwischenablage "missbrauchen". Ich schlafe zwar noch mal drüber, aber zu 90% ist die Luxusvariante bereits gestrichen ;(

Gruß
Holger

Re: Zusi-Objektalbum

Verfasst: 08.10.2018 17:51:11
von F. Schn.
Wie genau hattest du das denn vor?
Und warum schließt du die Datei nicht einfach wieder? :P Oder willst du die Datei modifizieren?

Re: Zusi-Objektalbum

Verfasst: 08.10.2018 17:57:17
von Holger Maaß
Wenn der 3D-Editor die Datei kooperativ öffnen würde, könnte man folgendes machen:

- öffne die Datei in beiden Programmen, da zum Lesen, da zum Schreiben
- schreibe im Objektalbum den Pfad
- lese ihn im 3D-Editor

Vergiß es, geht aber nicht. Der Weg ist jetzt so: Rechtsklick auf ein Objekt in der Übersicht (oder auch Strg-C <-- das ist ein C, Herr Maaß) --> Dateipfad kopieren. Dann wechseln zum 3D-Editor und dort in der Importliste Strg-V.

Gruß
Holger

P.S.: ......................................................................................................................... noch geht das nicht ^^^^^, noch gilt Strg-V :(

Re: Zusi-Objektalbum

Verfasst: 08.10.2018 18:04:51
von F. Schn.
Welche Datei willst du denn öffnen? Die Kacheldatei? Du musst doch erst mal entscheiden, wohin ein Objekt importiert werden soll?

Re: Zusi-Objektalbum

Verfasst: 08.10.2018 18:08:49
von Holger Maaß
Nein, nein. Es geht um die Funktion "Landschaft erstellen" --> "Objektimport Drag&Drop". Dort kann man die zu importierenden Objekte aus einer Dateiliste laden. Um diese Datei geht - äh, korrigiere - ging es.

Noch mal 'ne Frage an Matthias, da du den Dateivorschlag gemacht hast. Ich habe für mich selbst das Handling mit Datei und Strg-C/Programmwechsel/Strg-V ausprobiert. Mein Eindruck ist, dass ich nur bei seeehr vielen Objekten ein Vorteil mit der Dateivariante habe. Immerhin muss ich sie da Öffnen/Neu Anlegen, dann füllen, dann Schließen und im 3D-Editor wieder öffnen. Ich habe den Eindruck, das Copy&Paste in die Importliste schneller geht. Was meinst du?

Gruß
Holger

Re: Zusi-Objektalbum

Verfasst: 08.10.2018 18:27:24
von F. Schn.
Ok, da hast du aber 1-2 OpenFileDialogs.
Wie genau stellst du dir da mit Strg-V vor? Ich sehe nicht, dass der Dialog den Shortcut unterstützt.
Ich glaube aber, ich nehme die Herausforderung an. ;)

Re: Zusi-Objektalbum

Verfasst: 08.10.2018 18:31:04
von Holger Maaß
Du hast gewonnen! Das gibts doch nicht, der nächste Tiefschlag. Also Matthias vergiß alles, es wird doch eine Datei geben ... Lalalalatüdeldetü

Zur Erklärung: ich war gerade mal zum Datei testen gekommen, da ich eigentlich nur abwechselnd i-mehls und PN's beantworte und Forumsbeiträge schreibe. Ist echt lustig heute, nee, wirklich.

Gruß
Holger

Re: Zusi-Objektalbum

Verfasst: 08.10.2018 18:32:38
von Matthias H.
Ja, copy + paste ist im Normalfall besser als über Datei!
Dachte nur, dass das „paste“ nur mit Anpassung des Editors gehen würde.

Datei wäre praktisch, wenn man sich erstmal eine Reihe Objekte raussuchen und sammeln will. Aber aus meiner Sicht nachrangig.

Edit: ok, dann ist es ja so wie ich dachte. Aber völlig ok und eine Riesenerleichterung gegenüber dem Durchhangeln durch x Verzeichnisebenen.

Re: Zusi-Objektalbum

Verfasst: 08.10.2018 20:00:53
von Roland Ziegler
Holger Maaß hat geschrieben:Auch hier kann XML überzeugen. Wenn ich z.B. ein Feld "Kategorie" habe, gebe ich die Werte als "enumeration" vor. Damit ist die Bedeutung des Wertes denke ich auf beiden Seiten (Objektautor vs. Datenauswerter) klar - vorausgesetzt, die Kategorien sind auch selbstredend
Das ginge aber über Freitext-Tags weit hinaus und näherte sich der klassischen Modellierung - und würde, eine XML-Implementation hier annehmend, recht folgenschwere Implikationen für die bestehenden Strukturen bedeuten, zweites, fremdes Modell innerhalb des ersten. Macht man eigentlich nicht.

Erneut weiter ausholend:

In der modellgetriebenen Architektur (Model Driven Architecture, MDA) unterscheiden wir zwischen plattformunabhängigem Modell (Platform Independent Model, PIM) und (Platform Specific Model, PSM). Ich wollte in meinen Beispielen nur den plattformunabhängigen Teil betrachten.

Wie man das Modell nachher implementiert, dass sollte man später entscheiden dürfen. Code-Generatoren gibt es für fast alles, ob XML, JSON, relationale Datenbanktabellen, IDL verschiedener Couleur oder auch schlichte C#-POCOs.

Bleiben wir also plattformunabhängig, abstrakt.

Im echten Tag-Ansatz definieren wir keine domänen-spezifischen Typen. (Domäne: die Zusi-Welt). Wir führen nur eine lineare Liste mit Freitext-Einträgen oder ein Schlüssel/Wert-Wörterbuch, ebenfalls Freitext/Freitext, bar jeder Semantik.

Diese Liste oder das Wörterbuch soll hier vom menschlichen Benutzer gefüllt werden. Der kann da reinschreiben, was immer er möchte. Der eine schreibt „Epoche=spätes 19. Jahrhundert“, der andere „Baujahr=1898“. So lief das bei OSM. Allerdings hatten sie bei OSM die Mittel, das mit viel Gehirnschmalz und Algorithmen der künstlicher Intelligenz im Nachhinein einigermaßen zusammenzuführen und zu vereinheitlichen. Diese Mittel haben wir bei Zusi wahrscheinlich nicht.

Ich würde übrigens die Metadaten in jedem Fall vom eigentlichen Objekt entkoppeln. Warum soll die Laufzeitumgebung von Zusi sich den Ballast aufbürden, das Meta jedes mal mit zu verarbeiten? Interessiert zur Laufzeit nicht. Es besteht doch nur eine Abhängigkeit Meta vom Objekt, nicht umgekehrt. Gerade, wenn man mit Datenmodellen für Meta experimentieren will, wird man sinnvollerweise die originären Zusi-Datenstrukturen damit nicht belasten. (Siehe auch das Konzept der Extension-Methods in C#, mächtig nur dank der Entkopplung). Der eigentliche Datenbestand darf bei externer Meta-Pflege unangetastet bleiben, read-only, ungefährdet.

Re: Zusi-Objektalbum

Verfasst: 08.10.2018 20:29:33
von Holger Maaß
Hallo Roland,

ja, ich würde den Benutzer hier schon ordentlich gängeln wollen. Ein richtiges Freitextfeld würde ich ihm lieber nicht anbieten. Ich weiß aus leidvoller Erfahrung, das so etwas a) zum "Rumspielen" verführt (mal sehen, was geht) oder b) zum Austesten, wie ich das Programm zum Absturz bringe. Ja, wir nähern uns hier der klassischen Modellierung: Ausfüllen von vorgegeben Formfeldern. Aber ich verstehe nicht, warum du das Ablegen von Metadaten, die ja zum Objekt gehören und ich daher nicht als "fremd" bezeichnen würde, als folgenschwere Implikation für das bestehende Modell ansiehst. Rein technisch und praktisch kommen sich die beiden Datenbereiche nicht ins Gehege. Hier konkret wäre Zusi ausschließlich an den 3D-Daten interessiert; das Objektalbum meinetwegen an den Metadaten. Eventuell falsche und/oder beschädigte Metadaten würden in beiden Programmen nicht zu einer fehlerhaften Darstellung des 3D-Modells führen.

Ein entsprechend programmierter XML-Reader würde sich - die richtige Struktur vorausgesetzt - nicht für Knoten interessieren, für die er keine Verwendung hat. Alle meine Datenreader, die ich je programmiert habe, haben aktiv nach "ihren" Daten im Datengewühl gesucht. Was sie nicht interessiert hat, haben sie stillschweigend überlesen. Als großen Ballast würde ich das so daher nicht ansehen.

Das Trennen von Nutz- und Metadaten oder das Zusammenhalten: beides hat Vor- und Nachteile. Der Vorteil ist natürlich, das ich zwei saubere Bereiche habe. Ein Fehler in dem einen Bereich kann dem Anderen nichts anhaben - solange das Schlüsselfeld intakt ist. Ich sehe hier als Nachteil, das sich ein hypotetischer späterer Dritter, der sich mal mit der Datenpflege befasst, es einfacher hat, einen Bezug zwischen Nutz- und Metadaten herzustellen, wenn sie zusammen liegen. Das Trennen setzt eine Ia-Dokumentation voraus, damit dieser ominöse Dritte nicht scheitert. Und da habe ich so meine Sorgen.

Aber, wie bereits angedeutet: schauen wird doch mal, was Carsten überhaupt dazu meint.

Gruß
Holger

Re: Zusi-Objektalbum

Verfasst: 08.10.2018 21:10:25
von Holger Maaß
Das soll es dann für heute sein: die v0.2.1 mit diesen Änderungen:

- die Dateipfade der einzelnen Objekte können in eine Datei exportiert werden, die im 3D-Editor zum Importieren von Objekten via Drag&Drop genutzt werden kann
- die Kopiertastenkombination ist Strg-C (ich habe endlich meine richtige Brille wieder gefunden und kann nun ein C und ein V auseinander halten)
- das Handbuch steckt nun auch in der "portable" Version (keiner hat geschimpft, dass es gar nicht da war)

Noch ein Wort zum Kopieren der Dateipfade:

Das Exportieren ist im Handbuch - ich denke - recht ausführlich beschrieben. Solange der Export aktiv ist, kannst du mit Strg-C nichts in die Zwischenablage hieven. Das geht nur bei inaktivem Export. Allerdings funktioniert ein Strg-V drüben im 3D-Editor in der Objektimportliste so und so nicht.

Dann mal Gute Nacht,
Holger

Re: Zusi-Objektalbum

Verfasst: 08.10.2018 23:38:12
von Carsten Hölscher
Verwendungszeitraum und Kategorie gibt es ja schon in den Headerdaten, auch mit einer "erzwungenen" Auswahl.
Weitere Felder wären da möglich, wenn nötig. Mir fehlt etwas der Überblick, was man als Bastler alles an Auswahlkriterien braucht.

Carsten

Re: Zusi-Objektalbum

Verfasst: 08.10.2018 23:40:12
von Matthias H.
Meine letzten 10 Cent zum Thema Datenmodell:

Vergesst bitte bei aller wissenschaftlicher Betrachtung den Objektersteller nicht. Als solcher möchte ich mich auf den Objektbau konzentrieren und weder ein weiteres komplexes Tool für die Erfassung von ein paar Daten (die nichts mehr tun als die Suche nach Objekten zu erleichtern) bedienen, noch ein Studium für das Verstehen des Datenmodells absolvieren müssen.

Gefühlsmäßig bin ich da eher bei Holger. Auch der Ansatz, die Daten zusammenzuhalten gefällt mir besser. (falls die ls3 Dateien nicht aufgebohrt werden sollen, wäre ja z.B. auch wie bei den Texturen eine Zusatz-xml zur eigentlichen Objektdatei denkbar)

Gute Nacht!

Re: Zusi-Objektalbum

Verfasst: 09.10.2018 09:52:10
von Roland Ziegler
Man verzeihe mir meine abstrakte Sichtweise, da bin ich halt vorgeschädigt, die Denkweise des Systemarchitekten. ;)

Ich möchte die Analogie Buch und Bibliothekskatalog anführen, im alten Stil, so richtig auf Papier gedruckt, zum Anfassen, und mit Karteikarten in Schubladen. Das Buch ist eine abgeschlossene Sache. Es bekommt einen Aufkleber (den Schlüssel), bleibt aber ansonsten unverändert. Es hat keine Ahnung davon, dass irgendwo auf der Welt eine Bibliothek das Werk katalogisiert, nach Kriterien, die weder Autor noch Verlag kennen müssen, die von den Bibliothekaren sogar nicht einmal konsultiert werden müssen.

So sehe ich das auch hier. Der Autor des Zusi-Objektes darf außen vor bleiben. Er muss sich nicht um die Katalogisierung kümmern. Auch das Zusi-Objekt selbst bleibt unverändert (das bereits gedruckte Buch). Die Katalogisierung erfolgt allein in der Bibliothek, mit externen bibliotheks-eigenen virtuellen Karteikarten, deren einziger Zweck die zielgerichtete Suche im Bestand ist. Die Entwicklung geeigneter Indizierung und anderer Kriterien ist Sache des Bibliothekars hier und seiner freiwilligen Helfer.

Re: Zusi-Objektalbum

Verfasst: 09.10.2018 11:32:49
von Carsten Hölscher
So ganz passt der Vergleich aber nicht. Bücher stehen in vielen Bibliotheken, Haushalten, Instituten usw. und da kann der Autor des Buches gar nicht wissen, wie er die Daten gestalten müßte.
Bei uns baut jeder für den einen, genau bekannten Datenbestand und kann daher auch als Autor die Infos direkt in die Datei einbauen, um so eine aufwendige Doppelstruktur zu ersparen.

Carsten

Re: Zusi-Objektalbum

Verfasst: 09.10.2018 12:02:31
von Roland Ziegler
Carsten Hölscher hat geschrieben:Und da kann der Autor des Buches gar nicht wissen, wie er die Daten gestalten müßte.
Woher soll der Autor hier wissen, nach welchen Kriterien in Zukunft mal jemand suchen möchte?

Unterschätze nicht die Komplexität eines Datenmodells für die Meta-Suche. Solange dies vom Werk selbst entkoppelt bleibt, ist ein eigenständiger Entwicklungs- und Erweiterungsprozess möglich. Eine Einbettung in bestehende Datenstrukturen würde es in ein Korsett zwängen, das aufgrund des dort herrschenden und notwendigen Turn-Around-Zyklus kreatives Schaffen sehr beschränkt, Scheitern und Datenschrott eingeschlossen.

Das eigentliche Werk und seine Katalogisierung sind und bleiben zwei verschiedene Dinge, die sich zumindest meiner nicht gerade zufälligen Auffassung nach nicht unnötig gegenseitig behindern sollten.

Re: Zusi-Objektalbum

Verfasst: 09.10.2018 13:39:42
von F. Schn.
Holger: Was brauchst du denn? Den Zur-Liste-Hinzufügen-Button, sonnst noch etwas? Vielleicht das getten der Tabelle, auswählen einer Zeile und den Löschen-Button?

Zu Metadaten: Die Anforderungen an die Datenbank sind aber schon etwas speziell.
Es soll ja a) offline sein, b) müssen die Experten, die Jahrenlang in mehreren verschiedenen privaten Datenbeständen Objekte führen, auch irgendwie ihre eigenen, bislang privaten Daten wiederfinden können, die Daten also eintragen können, und c) muss das dann wenn es offline ist, mit der Zusi-AddOn-Update-Funktion harmonieren, sprich es darf nicht eine einzelne Datei sein.
Sicherlich lösbar, aber zu bedenken würde ich es trotzdem mal geben.

Re: Zusi-Objektalbum

Verfasst: 09.10.2018 15:55:35
von Carsten Hölscher
Theoretisch ist das ja sicher nicht verkehrt mit einer Datenbank. Es muss halt alles auch leistbar sein. Seit Anfang an hab ich versucht, dass zumindest die Kategorie in den Dateien vermerkt wird. Man kann ja mal schauen, wie intensiv diese Option genutzt wird - und das sind nur wenige Klicks (Antwort: ein 3D-Objekt im gesamten Datenbestand hat einen Eintrag). Also die erste Frage wäre: Wer erstellt die Infrastruktur und wer füttert sie erstmalig und dann auch fortlaufend mit Daten - bei jeder Änderung im Dateibestand muss diese Datenbank ja immer nachgezogen werden?

Die Bibliothek beschäftigt dafür hauptamtliche Angestellte.

Carsten

Re: Zusi-Objektalbum

Verfasst: 09.10.2018 20:27:38
von F. Schn.
Holger: Hat etwas gebraucht, bis ich die Thematik wieder im Kopf hatte, jetzt aber: https://pkeus.de/~philipp/Zusi/3/Zusatz ... .0.0.1.zip" target="_blank

Probleme bereiten die FileOpen&SaveDialoge auch mir. Das was ich geschrieben habe, funktioniert auf Windows 7. Wenn es ganz dumm läuft, muss man sich jedes OS einzeln ansehen...