Extensible Parameters (ExP)

Developed By:

• Rob Whisenant, 2002, 2006
• DAZ Productions (www.daz3d.com), 2006

Developed For:

• Poser® Format Content

Authored By: Rob Whisenant, © 2006 DAZ Productions

• See FAQ : Extensible Parameters (ExP)

This technology does the following:

• Removes the reliance on a limited predefined list of channels as a means of supplemental content distribution
• Addresses the probability of conflicting products due to attempts to occupy common/shared channels
• Maintains compatibility with legacy products by continuing to provide predefined channels

• Reduces overall space consumed on the hard disk by reducing redundant data

• Provides a mechanism for extending a figure's capabilities through supplemental files and a small command-line utility

• Each of the solid arrows in the above diagram represent a readScript call
• Each of the dashed arrows in the above diagram represents a consolidation of the information into a single file
• Each content developer provides the Secondary level files that define their product
• A command-line utility automatically generates the Primary level files (based on the contents of the actor named subdirectories)

• Each actor in the cr2 contains two separate readScript calls
  • One for declaring the product's parameter group hierarchies (groupNode, parmNode, etc.), for that actor; located within the groups clause of a given actor
  • One for declaring the product's channels (valueParm, targetGeom, etc.), for that actor; located in the channels clause, following the groups clause
• The cr2 contains a single readScript call for a Primary Enhanced Remote Control (ERC) pose
  • This call is made just above the figure clause; due to the fact that the actors and channels being referenced by Enhanced Remote Control (ERC) declarations in the pose must exist prior to making those declarations
• The cr2 contains a single readScript call for a Primary LinkParms pose
  • This call is made within the figure clause in the standard location for in-line data; immediately preceding the weld statements

• Each readScript'ed file must be uniquely named to prevent Poser from loading the wrong file¹⁾
  • Primary level file names must be unique to prevent loading files for another figure; DAZ uses an abbreviated representation for the figure²⁾
  • Secondary level file names must be unique to prevent loading files for another actor of the same figure; DAZ uses an actor index from within the cr2³⁾
  • Secondary level file names must be unique by product; DAZ uses the product code from the online store⁴⁾

• The Primary Grps file is in-line formatted and is used to consolidate the contents of Secondary Grps files; this is done to work around the destructive nature of group declarations in Poser
• The Secondary _Grps files are in-line formatted and are used to establish parameter group hierarchies for channels

• The Primary Chnnls file is in-line formatted and is used to call the Secondary Chnnls files
• The Secondary _Chnnls files are in-line formatted and are used to establish the channels of an actor

• The Primary Enhanced Remote Control (ERC) file is in-line formatted and is used to call the Secondary ERC files
• The Secondary _ERC files are pose formatted and are used to establish ERC linkages between channels

• The Primary LnkParms file is in-line formatted and is used to call the Secondary LnkParms files
• The Secondary _LnkParms files are in-line formatted and are used to establish 1 to 1 linkages between channels

• At the very least, all support files consist of the version clause

Example:

{
version
	{
	number 6
	}
}

• These files consist of only the pertinent information; notice the lack of fully defined actor, channels and groups clauses

Example:

{
version
	{
	number 6
	}
 
			groupNode My Morph Group
				{
				groupNode My Morph SubGroup
					{
					parmNode myChannel
					parmNode myOtherChannel
					}
				}
}

• These files are formatted after complete pose files, whereby the complete statement/clause hierarchy up to the pertinent information is declared explicitly

Example:

{
version
	{
	number 6
	}
 
actor myActor:1
	{
	channels
		{
		valueParm myChannel
			{
			valueOpDeltaAdd
				ControlFigure
				ControlActor
				ControlChannel
			deltaAddDelta 1.000000
			}
		}
		targetGeom myOtherChannel
			{
			valueOpDeltaAdd
				ControlFigure
				ControlActor
				ControlChannel
			deltaAddDelta 1.000000
			}
		}
	}
}

• The utility resides in the ”/Runtime/libraries/!DAZ” directory
• Batch files (PC) or shell scripts (Mac) reside in the ”/Runtime/libraries/!DAZ” directory for each figure the technology is used in
  • Syntax: DzCreateExPFiles ”figureDirectory” ”figurePrefix” ⁵⁾
• This utility automates the creation/update of the Primary files based on the contents of each actor sub-directory; excluding only the “Deltas” sub-directory which is reserved for companion delta injection/removal files
• Only actor level sub-directories are processed; any further nesting of directories is ignored
• Only files bearing these predefined suffixes are processed: “_Grps”, “_Chnnls”, “_ERC”, “_LnkPrms”
• The order of sorting in the Primary files generated is dependent on the last modified timestamp; reverse chronologically, so as to place the last edited files first, rather than have developers compete for the top position by using special characters in the filename
  • Files should follow the naming structure: #-productCode_type.pz2
    • Files that do not follow the naming structure are placed last in the list
• Files with the “_DAZ” pre-suffix ⁶⁾ are placed at the top of the sorted order; chronologically; this should only be used for CORE products, even at DAZ