Area 1.0

Hi all,

As you might know, I have been bothering you with mini and micro news about the SrrTrains v0.01 project since the year 2009, i.e. for almost ten years.

But now the shape of the project gets sharper and sharper and the “New Concept Paper of SrrTrains v0.01” has been finished.

That does not mean the project is already finished, it just means there are no big things to be invented any more, just the work has to be done.

Please find version 4.3 of the new concept paper here:
https://github.com/christoph-v/spark/blob/master/3rd-party-input/SrrTrains-v0.01/HobbyReports/hr007-new-concept-paper-v4.3.pdf

1. Hobby Report No. 007
2. published on 2018-12-23
3. 66 Pages
4. 13 Chapters
5. 7 appendices

The child project SP-ARK (Simple Playground to Achieve Required Knowledge) is in place at the preliminary home page https://areasharpa.wordpress.com/spark and it is waiting for supporters.

If you have a promising use case, or if you are just interested in Multiuser X3D Scenes please take the time and seize the holiday season for a short look. If the texts inspire you, then please do not hesitate to write a comment here at wordpress, so that other people can be sure this topic is actually an interesting topic and I am not just a singular event.

So, what is it about?

1. It’s all about “Simple Multiuser Scenes” (SMS) – a term, which I try to position
2. It’s about Multiuser Railway Simulation Based on X3D
3. It’s not restricted to Railway Simulation – it’s extensible
4. It’s about the Network Sensor and its definition
5. It’s about VR and it’s about MR (proxy configuration), currently no AR envisioned (this may change)
6. and it’s about some things that I cannot publish

Merry Christmas

Yours Christoph

Hi all,

As you might know, I am still doing some small updates to the SrrTrains v0.01 project, although THE PROJECT IS IN A CLOSED STATE and I AM WAITING FOR 3rd PARTY INTEREST.

Well, I have done some updates to the “Hobby Reports” (former “Hibernation Reports”), which had been granted to the SP-ARK project at GitHub. Now they are available in Version 4.3:

1. HR 001 Pieta / Rebase to MIB Core
   some minor updates
2. HR 005 SRR Objects
   major changes regarding vehicles/trains
3. HR 007 New Concept Paper of SrrTrains v0.01
   a few small but essential updates
4. HR 009 SMS Facility Loaders
   a new chapter about unbound objects (UBOs)

All the Hobby Reports can be found at the master branch here at this link.

The README is here.

Merry Christmas
Yours Christoph

Hi all,

I have frozen Release 3 of the documentational “Hibernation Reports”:

Only bugfixes will be done any more: Hibernation Reports (3.x) – Frozen

On the other hand, I have merged and deleted the branch “devel_arimathea”.

Now the Release 4 of the documentational “Hibernation Reports” will be developed at master:

Development: Hibernation Reports (4.x) – Open

Have a nice week

Yours Christoph

Hi all,

This is the final planning for the SrrTrains v0.01 project (nothing new so far):

I added the key words *TODO11*, *TODO12* and *TODO* into the Concepts’ Descriptions to have a feeling of

1. What has already been done – no tagging
2. What is planned for step 0033.11 – tagged by *TODO11*
3. What is planned for step 0033.12 – tagged by *TODO12*
4. What has not been planned yet – tagged by *TODO*

Please find the updated Concepts’ Descriptions here:

001_Glossary…*TODO12*………overview of the concepts and some terms
011_NamingRules……………..using names in an SMS; the MMF paradigm
012_FrameAndModules………….the frame and the modules
013_ModelsAndObjects…………astral, bound and unbound objects
014_ConsoleInterface…………influencing an SMS from a Command Line Interface
051_Extensibility……………extending the software (e.g. for road vehicles)
052_UnboundModels.*TODO11*……creating and deleting models at runtime
053_Handover.*TODO11*………..unbound models changing modules dynamically
054_MovingModules.*TODO11*……including modules as parts of a model (eMMF)
099_PerformanceConsiderations…is performance an issue?

The Overall Planning (i.e. Prophecy)

STEP0033.11 / architectural features

unbound models, handover, moving modules with experimental vehicles (v=const)
not before 2020

STEP0033.12 / railway kinetics (v not equal const)

with basic vehicles
not before 2021

LATER

1. Rebase to some “SMS”/”DIGITS” environment
2. additional railway features
   1. coupling and collisions
   2. 1900’s Interlocking

Have a nice week
Yours Christoph

Hi all,

As you might know, the SrrTrains v0.01 project has been CLOSED and is now waiting for “3rd party interest”.

However this fact should not prevent me from continuing on a “hobby level”.

In my latest posting (The “Regway”) I introduced the experimental vehicle that will be implemented by the release 0033.11 “Arimathea” (not before January 2019).

This week I’d like to publish an overview of all features of the SRR Framework.

In red font: the “bleeding wounds” of SrrTrains. Things that are being awfully missed currently.

In case of questions or comments please feel free to use the commantary function any time. Your mail address will never be published.

Yours
Christoph

Hi all,

I have started to design the what-I-call Regway.

It’s a kind of “R-Segway” (a Segway for railways) and it will be the first vehicle of the new SrrTrains software (after the redesign, which has been lasting since 2010).

I am expecting the new software “Arimathea” (0033.11) not before January 2019.

You can download the current software (0033.10bf3 “Pieta”) at http://simulrr.sourceforge.net

Have a nice week

Yours Christoph

Hi all,

I have done a check and some small improvements on the SrrTrains Web Pages:

1. Die Projekte (German language) – Overview
2. SrrTrains v0.01 – the first project (closed)
3. Simple Playground – future option for SrrTrains v1.0
4. Packet Switched ARK – something different

Have a nice week
Yours Christoph

The “Concepts for Rail Vehicles” turn out to be a “neverending story”.

Doing baby steps – little baby steps – but the direction is correct (hopefully).

Updated chapter 4 of “Hibernation Report 009” again – now version 4.1:

https://github.com/christoph-v/spark/blob/devel_arimathea/3rd-party-input/SrrTrains-v0.01/HibernationReports/hr009-facility-loader-v4.1.pdf

Have a nice week
Yours Christoph

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

• here: SrrTrains – Reduced to a pure hobby project and
• here: SrrTrains – Concepts for vehicles clearer

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:

1. The Definition Phase
2. The Creation Phase

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

• a Real Life Object (RLO),
• being situated within a real replicator,
• ready to receive an “initial state” from the multiuser scene

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