Home 🔶 NNA Core Spec 🔶 NNA Component Types 🔶 Roadmap
NNA is a system to store data in a 3d models node-hierarchy.
For simpler definitions, information can be encoded into a node name directly. These are called 'Name Definitions'.
More complex definitions can be stored as a JSON object. These are called 'JSON Components'. An array of JSON components is called the 'JSON Definition' for a specific node.
A file with NNA definitions must have .nna in its name before its file format suffix.
An FBX file with NNA definitions would be named for example Superawesomemodel.nna.fbx.
On import into a game-engine with an NNA implementation, these definitions will be parsed into the game-engines own constructs.
The following characters are reserved for NNA and can not be used in regular node-names:
$, &, ,, :, ;
Name definitions must fit inside a single node-name. The limit for name length in Blender is 63 bytes. This should be the maximum for interoperability reasons.
Their format is different for each definition but follows the following general syntax:
Syntax: Actual Node Name ($) $ NNA Processor Name Optional Parameters Optional Side Suffix
Example: UpperLeg$TwistHips,0.5.R
UpperLeg is the actual node name.
$Twist is the NNA type name. It always starts with a $ character.
Hips is a parameter for the definition.
, is a separator for different parameters.
0.5 is a parameter for the definition.
.R is the side suffix.
The combination of the 'actual node name' and the optional side suffix must be unique. This will form the ID of the definition. In this example the ID would become UpperLeg.R.
If a name definition starts with two $ characters, then the definition will be removed from the name on import after processing. The node can be referenced by other nodes with this cleaned name.
Json definitions are of arbitrary length, as they are spread over multiple nodes.
They are an JSON array of JSON objects. All objects (Components) must have a t property. It specifies the 'type' of the component, based upon which it will be processed.
As node-names can be only 63 bytes long in Blender, the Json array gets split into 'lines'. That’s an array of nodes. The lines must start with $, a line-number, and another $. A line does contain raw Json text and does not have to parse into valid Json, only the total combined string.
Since many tools, including Blender, require for node-names to be unique, the line-number can have an optional 'salt'. Before the second $ add a . followed by a number, in order to make the node-name unique.
In order to not clutter the main model’s hierarchy with Json 'lines', they can be contained in a 'targeting-node' which is parented to a node named $nna, which is parented to the root. The targeting-node’s name must start with $target: followed by the unique name of the targeted node. The root of the hierarchy can be targeted with $root.
Example:
$nna
→ $target:Hair01
→ → $0$[{"t":"ava.secondary_motion","id":"0","intensity":0.4},{"t
→ → $1$":"vrc.physbone", "overrides":["0"],"pull":0.15,"spring":0
→ → $2$.3,"limit_type":"angle","max_angle":60}]
Json components can have optional id and overrides properties.
An id is a string that must be unique within the model, and can be used to reference other components.
overrides is an array of ID’s. The overridden components will not be processed.
On import into a game-engine, NNA Json definitions will be removed from the hierarchy by default.
In order to specify meta information about the file, like i.e. the author or a link to a documentation, a special $meta object can be added to the $nna node.
The meta-data is a JSON object consisting of 8 specified, but optional properties, and arbitrary additional ones. The JSON object is to be parsed the exact same way as the JSON component array.