Hi all,
Happy I am now in a situation to be allowed to publish the basic idea about how it could be possible to use group calls in a R’4 GSM-R network to define a “Mixed Reality Theatre” for display at some “VR Equipment”.
This is the paper (GPL): MixedRealityGroupCall-Valentin-v1.0.pdf
Have a nice week
Yours Christoph
Hi,
In my latest postings, see
I told you that I am actually thinking about how to proceed now.
The concepts are getting clearer and clearer, but I have not yet thought about how we should proceed, if we had the “Mixed Reality Mode” (MR Mode) one day in a future far far away from now.
What, if we connected the virtual railroad with *real* 3D printers and 3D scanners, generally spoken, real replicators (RR)?
I think, we would have to split the process of creation of a vehicle (aka UBO) into two phases:
The 1. Definition Phase – where the *real* replicator did his job – could last very long, many seconds, even minutes or hours.
The outcome were an “Object Type” (OT), identified by an “Object Type ID” (OTI) and a URL, where the Web3D Browser could load the model (aka UBO) from.
At the end of the definition phase, we had
In the implementation I’m currently thinking about I would skip the Definition Phase (because I have no MR Mode and I will be using pre-defined OTs).
Now, in the 2. Creation Phase, the SMS would load the UBO from the URL in all scene instances and finally the global state of the UBO would be initialized to the “initial state” (in the multiuser scene and in the RLO).
Sounds reasonable, doesn’t it?
Have a nice week
Yours Christoph
Hi all,
The more detailed I think about the concepts for SrrTrains Rail Vehicles, the clearer it gets to me: yes, this is the right direction. These are concepts for centuries.
Now I have updated chapter 4 of the “Facility Loader” document.
If you like to dig into the concepts in a very detailed way, you can do this at:
https://github.com/christoph-v/spark/blob/devel_arimathea/3rd-party-input/SrrTrains-v0.01/HibernationReports/hr009-facility-loader-v4.0.pdf
Have a nice week
Yours Christoph
Now, when the version “Pieta” has been finally released and when I have reported that my “professional goals” of the project were reached, it is the correct time to answer the question to myself:
Will I still continue – or better resume – the project or will I lack the motivation to consume leisure time for something that is perceived as being a burden rather than a pleasure.
Well, the tricky thing is to never do any commitment to anybody.
It’s done, when it’s done.
So I have updated my little paper about “Unbound Objects (UBOs)” and I have translated it to English language.
This paper is a kind of manifesto for the next steps of the SrrTrains project and sketches the requirements for the support of UBOs and Handover:
However, never ever this paper contains any commitment regarding a timing of the project.
It’s done, when it’s done.
Have a nice week
Yours Christoph
P.S.: if you are interested in the “professional goals”, and in how far they have been reached, feel free to contact me via e-mail
Now, when I have released the la(te)st version of the SrrTrains v0.01 software (please see here: https://areasharpa.wordpress.com/2018/06/09/spark17-a-bugfix-for-the-pieta/), and when I have bothered my readers with so many detailed information, I would nevertheless like to give a SHORT SUMMARY about the WHY of this project.
The reason for this project is the SUPPORT OF THE IDEA OF A NETWORK SENSOR.
When I started to implement a multiuser virtual model railroad based on VRML/X3D (still not finished!), then I asked at the x3d-public mailing list, whether there was some STANDARDS for multiuser communication.
Those times (I think it was around 2009), two standards were proposed – DIS and the Network Sensor – and I selected one of both for my hobby project.
Those times I thought the Network Sensor was more general and so I went for it.
Maybe I was wrong.
However, I found three standard use cases of the Network Sensor and I invented a fourth use case of the Network Sensor.
Most of the SrrTrains project is about this fourth use case (to examplify it, to try around with it and to become sure, whether I should recommend it for the community).
These results are now nailed down in the SP-ARK project.
Please refer to the power point at https://github.com/christoph-v/spark/blob/master/3rd-party-input/SrrTrains-v0.01/TechnicalSummary/Sms3DWeb_20180610.pdf.
Also refer to an overview of the SP-ARK project at https://areasharpa.wordpress.com/spark/.
So far, I am still not sure, whether it would have been better to go for DIS, however, these are my results and they can be used by anybody.
Have fun with Web3D
Yours Christoph
Hi all,
The la(te)st release of the SrrTrains v0.01 software was the “Pieta” release from May 2017 (with the version 0033.10bf2).
Now I have done a few minor corrections and improvements (see the list below) and a new release 0033.10bf3 by 2018-06-09.
The files can be downloaded directly from sourceforge:
https://sourceforge.net/projects/simulrr/files/
Please be aware: the project is “CLOSED” and “WAITING FOR 3RD PARTY INTEREST”.
Have fun with Web3D
Yours Christoph
P.S.: what’s new?
released: 2018-06-09, SVN revision: 333
– Interface Changes:
– release 0033.10bf3 (SVN333)
– small renaming activity (SVN332)
– update Concepts’ Descriptions 100 – 999 (SVN331)
– update Concepts’ Descriptions 000 – 099 (SVN330)
– necessary adaptations for SrrSwitchB (SVN329)
– moving MoosSwitchB -> SrrSwitchB (just moving!) – (SVN328)
– Registration of Object Types (SVN 327)
– Initialization and Activation of UBO Loader (SVN 326)
– new SSC Activation Controller (SVN 326)
– new naming rules (SVN 325)
– locality of console parameters is set at the dispatcher stub now (SVN 321)
– now any console parameter can be a local parameter (SVN 321)
– Default gravity in McBase is 0 -9.81 0 instead of 0 0 0 (SVN 319)
– SmsModuleLoader separated from SscBase (SVN 318)
– Other Changes:
– implemented the “SMS Dispatcher Feature” (SVN 321)
– new field “isBound” of key container (SVN 320)
– minor improvements of SmsLoader (SVN 318)
Although the SrrTrains v0.01 project has been closed, and although the project is waiting for “3rd party interest”, I felt free
to update the Concepts’ Descriptions.
I already had done it for the papers 000 – 099 (SPARK#15),
Now I have done it for papers 100 – 999.
Please find here the Overview about the SRR Framework (which is paper 100, which contains links to all papers)
and – for completeness – the SYNOPSIS Paper (even more general).
The software (0033.10bf3) will be released soon (but only minor changes, so sorry).
Have fun
Christoph
Although the SrrTrains v0.01 project has been CLOSED, and is now waiting for “3rd party interest”,
I felt free to update the Concepts’ Descriptions, to be inline with the upcoming “bugfix 3” release of the 0033.10 “Pieta”.
The papers 100 – 999 will follow soon (detailed descriptions)
Have a nice week
Yours Christoph
Now, when we can be confident that the PS-ARK project might go well, it’s time to write a little view back on 9 years of SrrTrains.
All started with the “third child” DIGITS, which was inspired in autumn 2000.
It’s not important to explain DIGITS, it will follow automagically, when the “SMS Biotope” will have evolved based on the definition of the SMUOS component, which is an outcome of SrrTrains v0.01.
However, SrrTrains was the idea to take X3D multiuser scenes for the implementation of railway multiuser games. And it worked quite well. Only problem, nobody could be convinced to help, it was all a “one-man-show”.
No need to be angry. That’s mankind. We need not worry about. Things will never change. Everything green.
Says
Yours Christoph
The “Hibernation Reports of the SrrTrains v0.01 Project” have been translated to English language and stored at the repository of the SP-ARK Project.
https://github.com/christoph-v/spark
This was the last activity of the SrrTrains v0.01 project – now it is in “CLOSED” state – but can be “RE-OPENED” by 3rd party interest.
Btw 1: still active “little burning candle” PS-ARK Project
Btw 2: still in state “ignition” SP-ARK Project
Have a nice Easter Sunday on April 1st
Yours Christoph
Area 1.0 