Ideen zu haben – Der Inhalt

September 4, 2014

Liebe Leserinnen und Leser

Jetzt hatte ich Euch ja berichtet, dass ich mit meinem Hobby – Projekt SrrTrains v0.01 tatsächlich aufgehört hatte und dass ich auch die zugehörigen Blogs gelöscht hatte.

Weiters hatte ich hier versprochen, dass ich weitere Artikel zur technischen Fragestellung des Projektes schreiben werde.

Was hiermit geschieht.

Jetzt haben wir festgestellt, dass das Protokoll zwischen Client und Server standardisiert werden sollte, um jedem User zu ermöglichen, seinen Lieblings-Client zu verwenden.

Aber das ist nicht genug.

Das Internet-Protokoll TCP/IP wäre auch nur eine halbe Sache gewesen, wenn man nicht auch das Socket Interface dazu definiert hätte.

Somit ist die Idee eigentlich eine zweifache und ich würde sie als „SMUOS/C3P“ bezeichnen, das bedeutet:

  1. einerseits das „Netzwerk Interface“ für Simple Multiuser Szenen (SMUOS = „Simple Multiuser Online Scenes“)
  2. andererseits das „Netzwerk Protokoll“ für Simple Multiuser Szenen (C3P = „Collaborative 3D Profile“)

Für das Interface gibt es bereits den Ansatz

  • des „Network Sensor“ bzw.
  • des „Event Stream Sensor“

Was das Protokoll betrifft, ist soviel ich weiß noch nichts definiert.

Das SrrTrains v0.01 Projekt hat sich hauptsächlich mit einer „Verfeinerung“ des „Network Interface“ (insbes. des „Event Stream Sensor“) beschäftigt, indem man gewisse spezialisierende Annahmen über den Inhalt der Szene trifft:

  1. Eine Szene besteht in SrrTrains aus Modulen, die wiederum Modelle enthalten, die wiederum sogenannte MIDAS Objekte enthalten
  2. Die MIDAS Objekte sind spezialisierte „Netzwerk Interfaces“, die auf dem generellen „Event Stream Sensor“ basieren
  3. Die Szene wird nicht nur in Modelle zerlegt, sondern auch in Module, die erst die Modelle enthalten
  4. Dies liegt daran, dass man – analog zur Modulbauweise in der Modellbahntechnik – davon ausgeht, dass eine Anlage aus Teilen von verschiedenen Autoren zusammengesetzt werden soll

Man verfolgt damit folgende Ziele:

  1. SrrTrains MIDAS Objekte sollen in allen SrrTrains Modellen verwendbar sein
  2. SrrTrains Modelle sollen in allen SrrTrains Modulen verwendbar sein
  3. SrrTrains Module sollen in allen SrrTrains Anlagen verwendbar sein
  4. SrrTrains soll weitestgehend auf dem ISO Standard X3D aufbauen und auf Netzwerk Protokollen, die noch in der IETF standardisiert werden müssten
  5. Lg

    Christoph


Das Weltkoordinatensystem

August 6, 2014

Wenn ich mir einen Begriff „denke“, dann „hänge ich ihn innerhalb meines Weltbildes auf“.

Dazu benötige ich ein „Weltkoordinatensystem“, nämlich „mein persönliches Weltkoordinatensystem“.

Es gibt soviele „theories of everything“, wie es Menschen gibt, denn jeder von uns trägt so eine Theorie mit sich herum.

Was jetzt aber, wenn ich das Universum in einer Datenbank abspeichern möchte, also wenn ich es sozusagen „objektivieren“ möchte.

Auf welches Koordinatensystem soll ich die gespeicherte Welt beziehen?

WGS84 bietet sich an, weil auch GPS dieses Koordinatensystem verwendet.

Aber was ist, wenn ich nicht nur die Welt, sondern gleich das ganze Universum abspeichern möchte?

Ein relativistischer Ansatz muss her.

Aber wie?

Meint
Euer Christoph


Läuten VR-Technologien ein neues Biedermeier ein

Mai 9, 2014

Ist z.B. Oculus Rift nur ein „Rückzug aus der Realität in die Virtualität“ oder „bringen uns solche Technologien die entfernte Wirklichkeit näher“?

Fragen über Fragen
Meint
Euer Christoph


Btw: UCAV Flying Formation

April 15, 2014

Weil wir gerade darüber geredet haben……

http://www.aviationweek.com/Blogs.aspx?plckController=Blog&plckScript=blogScript&plckElementId=blogDest&plckBlogPage=BlogViewPost&plckPostId=Blog%3A27ec4a53-dcc8-42d0-bd3a-01329aef79a7Post%3A483bfc46-b673-4819-af70-790d6cd93b12


Das Psi und so……

Oktober 19, 2013

Gleich zu Beginn der Hinweis: es geht mal wieder um mein Hobby, nämlich um die virtuelle Modelleisenbahn.

Diese hat jetzt ja einen neuen Namen bekommen („SMUOS“) und ist eigentlich keine Eisenbahn mehr, sondern ein generelles offenes Konzept für 3D Multiuser Szenen.

In dem Dokument, das auf http://smuos.wordpress.com/2011/03/01/smuos-and-the-ietf/ verfügbar ist, habe ich ja bereits im März 2011 eine Architektur vorgeschlagen, an der ich jetzt immer noch feile.

Zuletzt habe ich die Szeneninstanzen (SI) auf persönliche Szeneninstanzen (PSI) „umgetauft“, was schöne Assoziationen ermöglicht.

Hier also das Übersichtsbild (nicht erschrecken, schaut furchtbar kompliziert aus, ist aber nicht einmal so kompliziert wie ein modernes Telefonnetz 😉 )

smuos_sysarch_13

Jetzt haben wir also folgende Ansätze (und ich bitte um fruchtbare Weiterassoziationen).

  • PSI = personal scene instance
  • ITR = interface to reality, enthält das „Modell der Wirklichkeit“
  • WWW-Serv. = WWW Server, enthält das „statische Modell“
  • SCSI = Server/Controller scene instance, enthält das „dynamische Modell“
  • POI = Sensoren und Aktoren, um Wirklichkeit und dynamisches Modell abzugleichen
  • Sensor = point of interest, Aktor = point of interaction

User „bewohnen“ PSIs.

z.B.: User 1 „bewohnt“ PSI 1, User 2 „bewohnt“ PSI 2 und so weiter.

User können mehr als eine PSI bewohnen, sie können auch die „Reality“ bewohnen.

User, die nur die „Reality“ bewohnen, sind aus der Sicht dieses Modells keine „eigentlichen“ User, sondern „kollaterale Entitäten“, die die „virtuelle Wirklichkeit“ nur indirekt beeinflussen können.

Eine PSI stellt nur ein „Bild“ der Wirklichkeit dar aber der User ist trotzdem „mit der Wirklichkeit verbunden“, wenn er nicht „an den Bildern haften bleibt“.

Das „statische Modell“ im ITR ist von einem „Autor“ erstellt worden.

Das POI „ist“ nicht die Wirklichkeit, es ist nur ein „Tor zur Wirklichkeit“.

usw.

Meint
Euer Christoph


Ich gebe es auf

Mai 27, 2013

Zuallererst die Frage: Was meine ich mit „aufgeben“?

„Aufgeben“ im Sinne von engl. „to abandon“ oder „aufgeben“ im Sinne von engl. „to hand in“?

Nun gut, diese Frage möchte ich bewußt offenlassen.

Aber was ist „es“?

„Es“ ist in erster Linie eine Reihe von Ideen, die alle im Laufe der Zeit entstanden sind, und die alle mehr oder weniger veröffentlicht worden sind (jeweils auf einem meiner 5 Blogs oder in einem meiner beiden Sourceforge Projekte).

Warum ich diese Ideen alle veröffentlicht habe und nicht für mich behalte, liegt letzten Endes daran, dass ich für mich persönlich keine Chance gesehen habe, damit Geld zu verdienen, dass mein jeweiliger Arbeitgeber daran nicht interessiert war, und dass ich dann letzten Endes aus einem schlechten Gewissen gegenüber der Menschheit mir immer die Arbeit angetan habe, es zu veröffentlichen.

Ein gewisser Exhibitionismus mag auch dazu beigetragen haben.

Und die Tatsache, dass eine Veröffentlichung letzten Endes der einzige Beweis dafür ist, dass ich diese Idee gehabt habe (als erster oder nicht, ist hier nebensächlich).

Das meiste davon ist nicht neu, aber es ergibt in Summe einen ganz schönen Überblick darüber, was dabei zwangsläufig herauskommen muß, wenn sich ein Mensch aus der Sparte Telekom in seiner Freizeit mit den Möglichkeiten von 3D-Graphik beschäftigt, insbesondere mit Web3D Technologien, insbesondere mit dem Netzwerksensor-Interface.

A) Der persönliche Urknall

Noch bevor ich wußte, was Google Earth ist, war da eine „Inspiration“, die im Wesentlichen auf dasselbe hinausläuft.

Bloß, dass ich von Anfang an von einer verteilten Datenbank geträumt habe, die Server in aller Welt (und von verschiedenen Eigentümern) durch ein Internetprotokoll miteinander verbindet und 3D-Szenen aufgrund eines primary Key zusammensetzt, den ich als „VRA“ (Virtual Roaming Area) bezeichnet habe – ein geschlossenes oder offenes Polygon.

Ich habe das als DIGITS bezeichnet („Distributed Internet Geographic Information Transmission Service“).

Ich nehme an, zur Entwicklung dieser Sache hat man meine Ideen nicht gebraucht, dennoch habe ich sie sicherheitshalber als Unterverzeichnis im Source Code meines ersten Open Source Projektes veröffentlicht: http://simulrr.sourceforge.net

B) Eisenbahn-Simulation

Kann man Web3D verwenden um Eisenbahnen zu simulieren?

Natürlich!

Es gab auch bereits einige nette Beispiele im Web, dennoch fehlte mir noch der Multiuser-Mode.

Ich fragte auf der X3D-public Mailing Liste, ob es hier bereits standardisierte Lösungen für den Multiuser-Mode gab.

Ja, sagte man mir, einerseits gab es da die DIS Komponente (Distributed Interactive Simulation), die bereits fertig standardisiert war – jedoch nur von einem Web3D Browser unterstützt -, andererseits gab es den Netzwerksensor, welcher ein sehr viel generelleres Interface darstellte, aber es gab immerhin zwei Web3D Browser, mit denen man Versuche anstellen konnte.

Ich entschied mich für den Netzwerksensor, obwohl natürlich die Verwendung eines generellen Interfaces für komplizierte Anwendungen (also z.B. für eine Eisenbahn-Simulation) prinzipiell höhere Aufwände bedeutet.

Im Gegenzug war man nicht von einem einzigen Browserhersteller abhängig (theoretisch, zumindest) und man konnte die Funktion des Interfaces auf die eigenen Wünsche „hinbiegen“.

Diese Idee verfolgte ich auf dem Blog http://simulrr.wordpress.com
und im Sourceforge Projekt http://simulrr.sourceforge.net

C) Simple Multiuser Szenen

Idee B) führte dazu, dass ich begann, einen Satz von X3D Prototypen experimentell zu entwickeln. Ich bezeichnete diese Prototypen als „SRR Framework“, wobei der Begriff „Framework“ eher das bezeichnete, was einmal daraus werden sollte, als das, was es tatsächlich schon war.

Da das „SRR Framework“ mittlerweile recht komplex geworden war, beschloss ich, es in einen Basisanteil (das sogenannte „base module“) und spezifische Anteile (sogenannte „extension modules“) zu zerlegen. So könnte der Basisanteil für beliebige „Simple Multiuser Online Scenes“ (SMUOS) und die spezifischen Anteile für verschiedene Anwendungen (Eisenbahnsimulation, Autosimulation, Flugzeugsimulation, Bürozusammenarbeit (Collaboration), etc.) verwendet werden.

Aufgrund mehrerer Ursachen bildete sich daraus

D) Die Idee SMUOS/C3P

Das „Base Module“ des „SRR Frameworks“ läßt sich bereits jetzt für einfache Multiuser-Szenen benützen, hat aber aus Sicht eines Mitarbeiters der Telekom Branche den entscheidenden Nachteil, dass für die Kommunikation mit dem Collaboration Server ein proprietäres Protokoll verwendet wird.

Dieses Protokoll sollte man also definieren.

Weiters wäre es im Sinne einer Standardisierung sinnvoll, das „Base Module“ des „SRR Frameworks“ „tieferzulegen“, also eine X3D Komponente zu definieren, welche im Wesentlichen die API bietet, die im SRR Framework experimentell entwickelt worden ist.

Diese Idee SMUOS/C3P beschreibe ich auf dem Blog http://smuos.wordpress.com
und im (ungestarteten) Sourceforge Projekt http://smuos.sourceforge.net

Ein weiterer Aspekt – der auf eine Mail auf der X3D-public zurückgeht und von dort „inspiriert“ war – ist die Idee, die „Wirklichkeit“ als (N+1)-te Szeneninstanz in die Multiuser-Session einzubinden.

Diese Idee ist in einem Paper zusammengefasst, welches ich am 1.März 2011 veröffentlicht und zuletzt am 18.Jänner 2012 geändert habe. Dieses Paper findet sich unter anderem hier: http://smuos.wordpress.com/2011/03/01/smuos-and-the-ietf/.

So, das war „es“.

Jetzt liegt es an Dir, lieber Leser, zu entscheiden, ob ich mit „aufgeben“ „to abandon“ gemeint habe, oder „to hand in“.

Oder, ein bisschen direkter formuliert, sozusagen mit den Worten der letzten Hornbach-Werbung: „Und jetzt Du.“

Meint
Euer Christoph