Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Special dummy nodes (Empties in Blender) are used to indicate special location to the engine. Some of them need to set directly in the model file (mdl), other in the walkmesh files (dwk or pwk). The naming conventions need to be followed in order for them to be recognized by the game. These naming conventions differ depending on the model type (doors, placeables, creatures) and whether they belong to the model file itself or the corresponding walkmesh file.

Table of Contents
maxLevel2


Placeable Model

The dummies in the placeable models are mostly for spell targeting purposes and VFX location.

In 1.69 They are all optional, if not present the center (=location) of the placeable is used. It appears in EE this is buggy/fixed/something and doesn't default to the center of the model.

Warning
titleNaming Convention

Crop the first four characters of the model name and append the appropriate suffix (this typically removes "plc_")

Suffixes

The table below contains a list of valid suffixes. These suffixes differ from the ones used in door models.

NameSuffixPurpose
Ground_groundLocation for certain spell effect, e.g. raising particles from Protection from the Elements spell.
Hand_handSpell casting origin.
Head Hit_head_hit

Location for spell effects, e.g. beams and VFX bubbles from the Protection from Alignment spell.

Also determines the height at which the floating text bubble appears above the placeable when highlighted in game.

Impact_impactImpact location for spells and missile attacks.

Examples

This tables contains a list of valid impact nodes for different placeable names.

Model nameNode name
plc_a01a01_impact
automobilemobile_impact
px_qwertwert_impact
abcdefef_impact



Placeable Walkmesh

The only dummy in placeable walkmeshes are use nodes. They determine where a character will walk to, when given a use command. Up to two use nodes can be specified, the character will walk to the closest one. They are optional, if not present the character will attempt to walk to the center of the model. This may fail, especially for large placeables, in this case the placeable becomes unusable.

Warning
titleNaming Convention

Four arbitrarily chosen characters followed by the suffix. 

Suffixes

The table below contains a list of valid suffixes. These suffixes do NOT have a leading underscore and are case sensitive - they must be all lower case.

NameTypeSuffix
Use Dummy 1Dummypwk_use01
Use Dummy 2Dummypwk_use02

Examples

This tables contains a list of valid use nodes nodes. As you can see the prefixes are completely random, the only important thing is that they are four characters long. The preferred name is wtf_pwk_use01.

Model nameExample Node name
plc_a01a01_pwk_use01
automobilewtf_pwk_use01
pcs_x99roflpwk_use01
abcdeflalapwk_use01



Placeable Transparency via .txi

It is possible to create a placeable that uses a texture which calls a texture information file (.txi) while maintaining the proper transparency of all meshes and how they interact with characters.  This requires the use of a special node ending in "a" inserted between the aurorabase and the mesh using the .txi, as well as ensuring that the extra node and subordinate text are the last occurring in the .mdl file.  The most common use case for this is water.

Warning
titleNaming Convention

The model name followed by the letter "a" with no space or underscore.

Examples

This tables contains a list of valid animation (.txi) nodes. As you can see the prefixes all match the model name and there is no space or underscore between that name and the "a."

Model nameNode name
plc_a01plc_a01a
automobileautomobilea
pcs_x99pcs_x99a
abcdefabcdefa


This method is complex enough to warrant further information, which can be found on the Placeable Model TXI Transparency page.


Door Model

The dummies in the door models are mostly for spell targeting purposes and VFX location. They are all optional, if not present the center (=location) of the door is used.

Warning
titleNaming Convention

Model name appended with the appropriate suffix. Note the lack of underscore.

Suffixes

The table below contains a list of valid suffixes. These suffixes differ from the ones used in placeable models. Note the lack of underscore as well.

NameSuffixPurpuse
GroundgrndLocation for certain spell effect, e.g. raising particles from Protection from the Elements spell.
Head Hithhit

Location for spell effects, e.g. beams and VFX bubbles from the Protection from Alignment spell.

Also determines the height at which the floating text bubble appears above the placeable when highlighted in game.

ImpactimpcImpact location for spells and  missile attacks.

Examples

This tables contains a list of valid impact nodes for different placeable names.

Model nameNode name
door_001door_001impc
automobileautomobileimpc
px_qwertpx_qwertimpc
abcdefabcdimpc



Door Walkmesh

 The dummy in dwk files determine where a character will walk to when interacting with a door. Doors may have up to three states. A closed state and two open states, as NWN doors may swing open to both sides. That means there may be up to may be up to six dummies - two for each state. As with placeables a character will walk to the closest dummy, when interacting with a door - depending on the state the door is currently in (open1, open2, closed)

Warning
titleNaming Convention

Two arbitrary alphanumeric characters followed by an underscore followed by a suffix.

Suffixes

The table below contains a list of valid suffixes. These are case sensitive, the DWK has to upper case, everything else is lower case. Doors may swing open to both sides, that means there may be two open states, each state having two dummies.

NameSuffixPurpose
Closed Dummy 1DWK_dp_closed01Closed state Use dummy 1
Closed Dummy 2DWK_dp_closed02Closed state Use dummy 2
Open State 1 Dummy 1DWK_dp_open1_01Open state 1 Use dummy 1
Open State 1 Dummy 2DWK_dp_open1_02Open state 1 Use dummy 2
Open State 2 Dummy 1DWK_dp_open2_01Open state 2 Use dummy 1
Open State 2 Dummy 2DWK_dp_open2_02Open state 2 Use dummy 2

Examples

This tables contains a list of example Closed Dummy 1 nodes for different door names. The two leading characters are completely arbitrary alphanumeric characters, they HAVE to be followed by an underscore, followed by the suffix.

Model nameNode name
t_door0101_DWK_dp_closed01
dwc_gate0404_DWK_dp_closed01
ddd_x99la_DWK_dp_closed01
abcdefXY_DWK_dp_closed01



Creatures

These creature nodes are used for combat targets, animation purposes (e.g. equipped item positions), and floaty (floating) name.

Warning
titleNaming Convention

Nodes have to be given the exact name from the table below. Creature nodes don't use suffixes or prefixes.

Names

The table below contains a list of VFX special node names.  These two nodes should always be directly linked to the model base. They should have an orientation of 0 0 0 0.

NameParts ("P")Full ("F")Limited ("L")Simple ("S")Purpose
headconjureYesYesYesYes

Casting animations for "Head" where the VFX appears, see Animations and spells.2da.

It also helps determine the height of floating name seen when you press the Tab key (see Hierarchy below). This is not exactly the same location but is a little off, a bit lower than you'd think.

If not set the bubble just appears at 2.1M off the ground which is ok for most medium sized or smaller creatures.

handconjureYesYesYesYesCasting animations for "Hand" where the VFX appears, see Animations and spells.2da.


The table below contains a list of other special node names. Depending on creature type (parts, full, simple, limited - which is simple plus some other limited animations) not all of these nodes are available.  These nodes should always be linked to the corresponding mesh part and usually are a dummy type. They are all optional (if not there it might default to root or just not show the relevant mdl/effect/whatever).

NameParts ("P")Full ("F")Limited ("L")Simple ("S")Purpose
rootYesYesYesYes

The default ground "dummy node" which defines the root. Every position in a model is based off this (thus it's usually the feet for creatures). It's generated automatically on the basis of the dummy node created first in the model (which has no positional data).

Cloak attachment point.

Where conjuration/casting ground VFX appear (ie at the creatures feet) (defined in spells.2da as ConjGrndVisual)

headYesYesYesYes

Casting animations, corresponds to Head Hit in placeables and doors

handconjureYesYesYesYesWhere conjuration/casting spell VFX appear (ie in front of where hands of the creature would be)  (defined in spells.2da as ConjHandVisual and/or CastHandVisual)
headconjureYesYesYesYesWhere conjuration/casting spell VFX appear (ie above the head of the creature) (defined in spells.2da as ConjHeadVisual and/or CastHeadVisual)
impactYesYesYesYesCombat and spell target (typically linked to torso)
rhandYesYesOptionalNoWeapon position in right hand for parts ("P"), full ("F") and limited ("L") creatures. Exmaple L model with just right hand: c_devil.mdl (Balor)
lhandYesYesOptionalNoWeapon position left hand for parts ("P"), full ("F") and limited ("L") creatures. Example L model with both weapons: c_driderchf.mdl (Drider Chief)
lforearmYesYesOptionalNo

Shield position for parts ("P"), full ("F") and limited ("L") creatures. Example L model with both weapons and a shield point: Formian Worker: c_frmwrk.mdl

Special: Heads




Default: head_gYesYes (optional)Yes (optional)Yes (optional)

This is set by using the HEAD_NAME column in appearance.2da for the node that will be looking at things, and be looked at (eye contact).

Almost every model that uses it will define it within the appearance.2da file, but if not present such as blanked, it will be defaulted to head_g

Phenotype Geometry



This is what armor/helmet parts swap in/out
head_gYesOptionalOptionalOptional

Head node for phenotypes (ie the model node geometry name - replaced by helmet models and is where monk glowing eyes goes)

Also the node used for head turning (at least it's set to head_g in appearance.2da and defaults to it if not present).

neck_gYesOptionalOptionalOptionalNeck position for phenotype-based models
torsoYesOptionalOptionalOptionalTorso position for phenotype-based models
beltYesOptionalOptionalOptional
pelvisYesOptionalOptionalOptional
lshoulderYesOptionalOptionalOptional
lbicepYesOptionalOptionalOptional

lhand

YesOptionalOptionalOptional
lthighYesOptionalOptionalOptional
lshinYesOptionalOptionalOptional
lfootYesOptionalOptionalOptional
rshoulderYesOptionalOptionalOptional
rbicepYesOptionalOptionalOptional
rforearmYesOptionalOptionalOptional
rhandYesOptionalOptionalOptional
rthighYesOptionalOptionalOptional
rshinYesOptionalOptionalOptional
rfootYesOptionalOptionalOptional
tailYesOptionalOptionalOptionalTail attachment point, usually on the lower back
wingsYesOptionalOptionalOptionalWing attachment point, usually on the middle of the back
monsterNOptionalOptionalOptionalOptionalwith N in [0,9] e.g. monster1, monster5. Can be used for Beam Visual effects, see BODY_NODES page on nwnlexicon

Hierarchy

Nodes should be children to the mesh part on which they apply the effect so that the applied effect follows the body part during animations.  The exception to this is headconjure, which should be children of (linked to) the model base, or aurorabase.  The z position (height) of headconjure is used to position the floating text that displays the creature name over the origin (0,0) of the creature model.  Omission or incorrect linking of the headconjure node makes the floating name text default to a set height of about 1m above the origin. The handconjure node, however, does not follow this rule and can be linked to a node if you wish for casting VFX to follow its movements.


Common Node Summary

Cross reference table in case you are changing, say, a placeable to a creature (eg a mimic!) or a door to a placeable or whatever.

Note that placeables and doors do not "conjure" or "cast" spells (it does so essentially instantly) so anything related to that isn't used.

If a particular node doesn't exist it should default to the "root" node (ie the "ground").

Node TypeCreaturePlaceable (plc_a01)Door (door_001)Description and Notes
Beam Nodes (source of beam)



BODY_NODE_CHESTimpacta01_impactdoor_001impc
BODY_NODE_HANDhandconjurea01_handdoor_001impc
BODY_NODE_MONSTER_0 - 9monsterNa01_grounddoor_001grnd
Default Root Noderoota01_grounddoor_001grnd
VFX Target nodes



VFX Impact Nodeimpacta01_impactdoor001impcvisualeffects.2da entry with, for instance, "Imp_Impact_Node" set, ie; their body (usually)
VFX Head Nodeheada01_head_hitdoor001hhitvisualeffects.2da entry with, for instance, "Imp_HeadCon_Node" set, ie; their head
VFX Root Noderoota01_grounddoor_001grndvisualeffects.2da entry with, for instance, "Imp_Root_S_Node" set, ie; their feet
Other



Looking Target Node

HEAD_NAME in appearance

Default: head_g

a01_headdoor001impcAnything else defaults to the root node location, eg if a trigger is talking or something equally silly.

(Table needs finishing)

Shields

These creature nodes are used for combat targets - ie where arrows hit.

Warning
titleNaming Convention

Nodes have to be given the exact name from the table below. Creature nodes don't use suffixes or prefixes.

Names

These two nodes should always be directly linked to the shields dummy base.

NamePurpose
imp_shield_1

Shield attach point 1 for arrows

imp_shield_2Shield attach point 2 for arrows


Tiles

These special nodes are for the main and source lights selectable in the area properties for each tile.

See the Area File PDF for more info for now.

The suggestions in the PDF of the node name having to be CAPITALLETTERSsl1 needs testing.

NamePurpose
modelnamesl1

Source Light 1 node (torch)

Should be a node of type "lightdummy" which has all the standard light things applieda position on the tile. The "color" field of the VFX "fx_flame01.mdl" will be replaced by the module area settings for this tile.

----

From the PDF:

A sourcelight is a point on a tile where the graphics engine can attach the model of a flaming light source.

Not all tiles have sourcelights. To determine if a sourcelight is present, the application must inspect the tile's model file. There should be a dummy node whose name is the tile model's ResRef in all-caps with "sl1" or "sl2" appended to the end.

To create a sourcelight in the graphics engine, spawn "fx_flame01.mdl" at the position of the tile's "sl1" or "sl2" dummy node and play the animation whose name matches the value of the appropriate Tile_SrcLight Field.

Example: if the tile model as specified by the TileSet and Tile_ID is ttz_a01_01.mdl, and Tile_SrcLight2 is 14, then spawn fx_flame01.mdl at the "TTZ_A01_01sl2" dummy node in the tile and set it to play the animation named "14".

To get a rough visual representation of the source light color associated with a given number, take the Tile_SrcLight value, multiply it by 2, and use it as an index into lightcolor.2da, which contains the RGB values. Note however, that editing lightcolor.2da will have no effect on the colors shown in the graphics engine; the colors are entirely determined by the animations embedded in fx_flame01.mdl. In other words, lightcolor.2da should match up with the model, not the other way around.

----

It seems some standard settings for these are:

  • ambientonly 1
  • shadow 0
  • nDynamicType (isdynamic) 0
  • affectdynamic 0
  • lightpriority 5
  • fadingLight 0
  • flareradius 0
  • radius

    -

    low values eg 7.5

  • multiplier 1
  • modelnamesl2

    Source Light 2 node (torch)

    As sl1, single dummy node. You can have two at most per tile.

    modelnameml1

    Main Light 1 node (generic lighting)

    Should be a node of type "light" which has all the standard light things applied. The "color" field will be replaced by the module area settings.

    ----

    From the PDF (needs double checking):

    A mainlight is an overall colored lighting effect that can be applied to a tile.

    To determine if a tile has a mainlight, the application must inspect its model file. There should be a light node whose name is the tile model's ResRef in all-caps with "ml1" or "ml2" appended to the end.

    For example, if the tile model is tts_a01_01.mdl, then mainlight 1 on that tile would be a light node called "TTZ_A01_01ml1".

    If a light node does not exist, then the toolset does disables the controls to set the light's value.

    ----

    It seems some standard settings for these are:

    • ambientonly 0
    • shadow 0
      • Don't project shadows from it
    • nDynamicType (isdynamic) set to 0
    • affectdynamic set to 1
    • fadingLight 1
    • lightpriority 5
      • The lowest priority
    • fadingLight 1
    • flareradius 0
    • radius at small values (eg: 5, 14)
    • multiplier 1
    modelnameml2

    Main Light 2 node (generic lighting)

    As ml1


    ...