Dynamic Variable Naming Standard

Other languages:

Proposal by 3x1t_5tyl3 on the 19th of November 2020.

Technical Spec-sheet for the NeosVR Global World-color Standard

As people have realized putting another space directly on root is probably a bad idea. As such putting a new field underneath the users allows for higher flexibility. The examples have mentioned "Data" as a name for it which I tend to find proper.

Player A is now abbreviated as "P-A"

Player B - "P-B"

Examples:

Player A is at the bar. As such The hierarchy looks like:

└── Root
   └── Users
       ├── Lounge
       │   └── P-A
       ├── Bar
       │   └── P-B
       ├── Dance-Hall
       └── Outside

In this case "P-A" would be getting the Data off of "Lounge".

If "P-A" Would move under "Bar" it'd inherit the Data of the "Bar". As such it'd inherit the color that "Bar" implements.

└── Root
   └── Users
       ├── Lounge
       ├── Bar
       │   ├── P-A
       │   └── P-B
       ├── Dance-Hall
       └── Outside

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~

Fallback system (on avatar!) If the secondary doesn't exist

fallback to primary
- fallback to avatar's own color if primary doesn't exist either.

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~

Defined-Color: Colors should only facilitate color.

Defined-Intensity: Intensity should only facilitate how *strong* that color is.

As such the float value should not exceed 3 and not go below 0.

This makes the system more accessible to users who have some form of photo sensitivity. As the Values can be locally set to 0 for intensity to make sure people with photosensitivity can have a part in a world too.

With this in mind my proposal for the Naming would be: DynamicVariableSpace: Data

Direct binding enabled.
This is all that you should name it. For every Slot a user is under. With no dynamic spaces in between.

The Variables should follow a pattern as follows: The beginning marks the Use-case. -So for this case "World" says that the color comes from the world. The middle marks the Type. -Color for color, intensity for a float value that is a multiplier to color. The number (should only be 1 & 2) marks different colors. - Example would be primary and secondary colors. I *personally* don't see a reason for a tertiary number. -- Example: World main color is red and secondary is black. As such an avatar could contain itself in that way as well. -- Example2: World main color is dark green and secondary is white. Same as above just different. Allowing more customization with just one more input node. See "Fallback system" for info on fallback.

If secondary exists but not primary: -> Fallback to the avatar color. (Ignore world color) Secondary never exists alone. Use primary if only one color is given. Not secondary.

My suggestion for naming them:

Data/WorldColor1
- Data/WorldColor2
Data/WorldIntensity1
- Data/WorldIntensity2

So for implantation it'd look like:

WorldColor1 x WorldIntensity1 -> Apply to avatar for effect.

R: 1, G: 0, B: 0.2 x 1.5 --> R: 1.5, G: 0, B: 0.3

Example use case:

└── Root
   └── Users
       ├── Lounge (Set to Red, mid intensity)
       ├── Bar (Set to Blue high intensity)
       │   ├── P-A
       │   └── P-B
       ├── Dance-Hall (Changing color to the music with intensity as-well)
       └── Outside (Color set to a low creme with low intensity)

This means that the player has to be parented for this work in the way mentioned above.

Proposal by Gabriel192 on the 7th of January 2022.

An extension of the system can be done in the following way

Data/WorldColorDrive1

Data/WorldColorDrive2

These variables would be driven by the world itself using Data/WorldIntensity1 and Data/WorldColor1 / Data/WorldColor2.

The perks of this is that it gives simplicity to add audio reactivity to a Avatar/Item by only using a single component.

The next thing is that it makes sure every audio reactive Avatar/Item is gonna work decent in any world you enter since we tend to change the settings on the volumemeter connected to Data/WorldIntensity1.

This would severely reduce possible overly bright emissive effects on anyone to aid with photosensitivity in addition to removing redundant instances of audio reactivity LogiX.

Proposal by CoffeeKei on the 30th of July 2022

An extension of the Data world space for audio FFT implementation.

Each FFT bin is assigned its own float variable as the following:

Data/AudioFFT1
Data/AudioFFT2
Data/AudioFFT3 ...and so on

It is recommended to stick to 16 bins for float variables as scaling will offset each bin; and any need for more than 16 is an edge case that will require a proprietary system.

FFT audio reactive items and avatars should default to Data/WorldIntensity1 if FFT steams are not present to support the more widely used and performant systems using the naming conventions proposed by 3x1t_5tyl3 and Gabriel192.

Proposal by CoffeeKei on the 30th of July 2022

An extension of the Data world space for song metadata to display title, artist, and album cover.

Parsed metadata would be assigned its own variable following similar naming convention to 3x1t_5tyl3 and Gabriel192 as shown:

Data/AudioMetadata1
Data/AudioMetadata2 ...and so on

This allows for multiple audio streams with metadata to exist and display in a world. Item and avatar systems displaying this metadata should interact with the parenting system as originally proposed by 3x1t_5tyl3.

If metadata is not present, the variable will return "null". This can be used to display a message and/or image on the receiving display to notify the user that there is no data, or to disable the display entirely.

When the variable begins receiving data, the value will no longer be "null" and display normally.

Dynamic Variable Naming Standard

Navigation menu

Search