Dear Friends of Realtime 3D Graphics

In the “Glossary of the SrrTrains Project” (https://simulrr.sourceforge.net/concepts/001_Glossary.pdf), in appendix A.2, I had published a few assumptions about SMUOS.

Here, in this Blog posting, I am feeling free to highlight those assumptions that COULD be relevant for relativistic software.

[…]A.2. Basic Assumptions about a Possibly Suggested X3D Component “SMUOS”
———————————————————————–
1. SMUOS will follow the enhanced model/module/frame paradigm (eMMF paradigm)
2. Basic assumptions about SMS models (*M*MF)
2.1. SMS models are represented using declarative 3D principles
2.2. Models can be rendered (they are visible, audible, sensible, …)
2.3. Models are rendered relative to a module
2.4. If models are not attached to a module, then they cannot be rendered
2.5. SMS models contain MIDAS objects to become multiuser capable
2.6. MIDAS objects depend on the SMUOS component. They are specialized to
distinct use cases (binary switch, carousel drive, …)
2.7. MIDAS objects cannot be rendered. They make only sense together with
a model or module
3. Basic assumptions about SMS modules (M*M*F)
3.1. An SMS module is NOT a tile
3.2. SMS modules are represented using declarative 3D principles
3.3. A module renders a (small) part of a virtual universe
3.4. A module spans a (pseudo) euclidean space time, where models and/or
avatars can meet
3.5. The relation of a module’s coordinate system to the world coordinate
system of the Web3D browser is “for further study” (ffs.)
3.6. Modules can contain “intrinsic” models. “Intrinsic” models are imple-
mented directly as a part of a module
3.7. Modules can contain “bound” models. “Bound” models are implemented
separately from modules, so that they can be used by many modules.
3.8. Modules can contain “unbound” models. “Unbound” models can be loaded
or unloaded independent of all modules. If created, an unbound model can
be “assigned” to a module. Changing the assignment from one module to
another is called “handover”
3.9. Each SMS module contains an instance of the “SMS module coordinator”.
The SMS module coordinator is a node defined by the SMUOS component.
The SMS module coordinator cannot be rendered, but it coordinates all
MIDAS objects of all models that are attached to its module
4. Basic assumptions about the SMS frame (MM*F*)
4.1. The frame integrates one or more SMS modules into a VR/AR platform
4.2. The frame is responsible to register, load or unload top level modules
4.3. SMS models cannot be contained directly in the frame. A module must be
in between
4.4. If the scene shall be multiuser capable, then the frame
4.4.1. is responsible to initialize the used MU system and to provide a
“sessionId” to the SMUOS component
4.4.2. must provide a network connection to the SMUOS component
4.5. The SMS frame contains an instance of the “Simple Scene Controller”,
which is a node defined by the SMUOS component.
The “Simple Scene Controller” cannot be rendered, but it controls the
SMS module coordinators of all SMS modules and hence it controls the
complete SMUOS component within a scene instance
5. Basic assumptions about “classic avatars”
5.1. Classic avatars have N instances, where one instance – the so-called
“pilot” – is part of the scene instance that is used by the user, who
is represented by the avatar, and the other N – 1 instances – the
so-called “drones” – just follow the pilot
5.2. With the help of the special MIDAS object “Avatar Container”, we can
5.2.1. assign avatars to the frame (world coordinate system)
5.2.2. assign avatars to some module (module coordinate system)
5.2.3. assign avatars to some model
5.3. Please be aware: SMS models can NOT be rendered relative to the world
coordinate system. SMS models can NOT be rendered relative to SMS models
5.4. Hence classical avatars are NOT SMS models
6. Basic assumptions about “UM avatars” (unbound model avatars)
6.1. UM avatars are unbound SMS models
6.2. UM avatars are models that represent a virtual identity
7. Basic assumptions about moving modules
7.1. There will be a special MIDAS object, let’s call it “Module Container”,
that will allow to instantiate SMS modules as parts of an SMS model
7.2. Hence the “basic MMF paradigm”
frame – 1:n – module – 1:n – model
will become the “enhanced MMF paradigm”
frame – 1:n – module – 1:n – model -1:n – module – 1:n – model ad. inf.[…]

Have a nice week

Yours CP/V