#ifndef __SOMEFILE_H__
    #define __SOMEFILE_H__
    ... ... // 一些声明语句
    #endif

    方式二：

    #pragma once
    ... ... // 一些声明语句

    #ifndef的方式依赖于宏名字不能冲突，这不光可以保证同一个文件不会被包含多次，也能保证内容完全相同的两个文件不会被不小心同时包含。当然，缺点就是如果不同头文件的宏名不小心“撞车”，可能就会导致头文件明明存在，编译器却硬说找不到声明的状况

    #pragma once则由编译器提供保证：同一个文件不会被包含多次。注意这里所说的“同一个文件”是指物理上的一个文件，而不是指内容相同的两个文件。带来的好处是，你不必再费劲想个宏名了，当然也就不会出现宏名碰撞引发的奇怪问题。对应的缺点就是如果某个头文件有多份拷贝，本方法不能保证他们不被重复包含。当然，相比宏名碰撞引发的“找不到声明”的问题，重复包含更容易被发现并修正。

   方式一由语言支持所以移植性好，方式二 可以避免名字冲突。
一般可以这样处理：
#infndef XX
#define XX
    #if _MSC_VER > 1000 
      #pragma once 
    #endif
   .
   .
#endif
注意：   _MSC_VER 是出于版本兼容性考虑，定义
   Defines the compiler version. Defined as 1200 for Microsoft Visual C++ 6.0. Always defined.

/C:在预处理输出中保留注释语句
/c:只编译，不连接，相当于在"Build"菜单下选择了"Compile"
/D:定义常量和宏，与源程序里的#define 有相同效果
/E:预处理C、C＋＋源文件，将源文件中所有的预编译指令及宏展开，将注释去掉，然后将预处理器的输出拷贝至标准输出设备输出，并且在每个文件的开头和末尾加入#line
/EH:指定编译器用何种异常处理模型
/EP:同/E,只是去掉了#line
/F:设置程序的堆栈大小
/FA:设置生成何种列表文件（汇编、汇编与机器码、汇编与源码、汇编与机器码以及源码）
/Fa:指定用/FA设置的列表文件的存放路径及（或）文件名
/FD:生成文件的相互依赖信息
/Fd:设置程序数据库文件（PDB）的存放路径及（或）文件名
/Fe:设置最终可执行文件的存放路径及（或）文件名
/FI:预处理指定的头文件，与源文件中的＃include有相同效果
/Fm:创建map文件
/Fo:设置编译后Obj文件的存放路径及（或）文件名
/Fp:设置预编译文件（pch）的存放路径及（或）文件名
/FR:生成浏览信息（sbr）文件
/Fr:同/FR,不同之处在于/Fr不包括局部变量信息
/G3:为80386处理器优化代码生成
/G4:为80486处理器优化代码生成
/G5:为Pentium处理器优化代码生成
/G6:为Pentium Pro处理器优化代码生成
/GA:为Windows应用程序作优化
/GB:为Pentium处理器优化代码生成，使用80386、80486、Pentium、Pentium Pro的混合指令集，是代码生成的默认选项（程序属性选项中Processor对应Blend）
/GD:为Windows动态库（dll）作优化，此开关在VC6中没有实现
/Gd:指定使用__cdecl的函数调用规则
/Ge:激活堆栈检测
/GF:消除程序中的重复的字符串，并将她放到只读的缓冲区中
/Gf:消除程序中的重复字符串
/Gh:在每个函数的开头调用钩子（hook）函数--penter
/Gi:允许渐进编译
/Gm:允许最小化rebuild
/GR:允许运行时类型信息(Run-Time Type Infomation)
/Gr:指定使用__fastcall的函数调用规则
/Gs:控制堆栈检测所用内存大小
/GT:支持用__declspec(thread)分配的数据的fier-safety
/GX:允许同步异常处理，与/EHsc开关等价
/Gy:允许编译器将每一个函数封装成COMDATs的形式，供连接器调用
/GZ:允许在Debug build 的时候捕捉Release build的错误
/Gz:指定使用__stdcall的函数调用规则
/H:限制外部名字的长度
/HELP:列出编译器的所有的命令开关
/I:指定头文件的搜索路径
/J:将char的缺省类型从signed char改成unsigned char
/LD:创建一个动态连接库
/LDd:创建一个Debug版本的动态链接库
/link:将指定的选项传给连接器
/MD:选择多线程、DLL版本的C Run－Time库
/MDd:选择多线程、DLL、Debug版本的C Run－Time库
/ML:选择单线程版本的C Run—Time库
/MLd:选择单线程、Debug版本的C Run—Time库
/MT:选择多线程版本的C Run-Time库
/MTd:选择多线程、Debug版本的C Run—Time库
/nologo:不显示程序的版权信息
/O1:优化使产生的可执行代码最小
/O2:优化使产生的可执行代码速度最快
/Oa:指示编译器程序里没有使用别名，可以提高程序的执行速度
/Ob:控制内联（inline）函数的展开
/Od:禁止代码优化
/Og:使用全局优化
/Oi:用内部函数去代替程序里的函数调用，可以使程序运行的更快，但程序的长度变长
/Op:提高浮点数比较运算的一致性
/Os:产生尽可能小的可执行代码
/Ot:产生尽可能块的可执行代码
/Ow:指示编译器在函数体内部没有使用别名
/Ox:组合了几个优化开关，达到尽可能多的优化
/Oy:阻止调用堆栈里创建帧指针
/Q1f:对核心级的设备驱动程序生成单独的调试信息
/QI0f:对Pentium 0x0f错误指令作修正
/Qifdiv:对Pentium FDIV错误指令作修正
/P:将预处理输出写到指定文件里，文件的后缀名为I
/TC:将命令行上的所有文件都当作C源程序编译，不管后缀名是否为.c
/Tc:将指定的文件当作C源程序编译，不管后缀名是否为.c
/TP:将命令行上的所有文件都当作C＋＋源程序编译，不管后缀名是否为.cpp
/Tp:将指定文件当作C＋＋源程序编译，不管后缀名是否为.cpp
/U:去掉一个指定的前面定义的符号或常量
/u:去掉所有前面定义的符号或常量
/V:在编译的obj文件里嵌入版本号
/vd:禁止/允许构造函数置换
/vmb:选择指针的表示方法，使用这个开关，在声明指向某个类的成员的指针之前，必须先定义这个类
/vmg:选择指针的表示方法，使用这个开关，在声明指向某个类的成员的指针之前，不必先定义这个类，但要首先指定这个类是使用何种继承方法
/vmm:设置指针的表示方法为Single Inheritance and Multiple Inheritance
/vms:设置指针的表示方法为Single Inheritance
/vmv:设置指针的表示方法为Any class
/W:设置警告等级
/w:禁止所有警告
/X:阻止编译器搜索标准的include 目录
/Yc:创建预编译头文件（pch）
/Yd:在所有的obj文件里写上完全的调试信息
/Yu:在build过程中使用指定的预编译头文件
/YX:指示编译器若预编译头文件存在，则使用它，若不存在，则创建一个
/Z7:生成MSC7.0兼容的调试信息
/Za:禁止语言扩展(Microsoft Extensions to C)
/Zd:调试信息只包含外部和全局的符号信息以及行号信息
/Ze:允许语言扩展(Microsoft Extensions to C)
/Zg:为源文件里面定义的每个函数生成函数原型
/ZI:生成程序库文件（Pdb）并支持Edit and Continue调试特性
/Zi:生成程序库文件（pdb），包含类型信息和符号调试信息
/ZL:从obj文件里去掉缺省的库文件名
/Zm:设置编译器的内存分配xianzhi
/Zn:禁止浏览信息文件里面的封装
/Zp:设置结构成员在内存里面的封装格式
/Zs:快速检查语法错误
－－－－－－－－－－－－－－－－－－－－－－－－－－
vc所支持的文件类型

DSW:全称是Developer Studio Workspace，最高级别的配置文件，记录了整个工作空间的配置信息，她是一个纯文本的文件，在vc创建新项目的时候自动生成
DSP:全称是Developer Studio Project，也是一个配置文件，不过她记录的是一个项目的所有配置信息，纯文本文件
OPT：与DSW、DSP配合使用的配置文件，她记录了与机器硬件有关的信息，同一个项目在不同的机器上的opt文件内容是不同的
CLW：记录了跟ClassWizard相关的信息，如果丢失了clw文件，那么在Class View面板里就没有类信息
PLG：实际上是一个超文本文件，可以用Internet Explorer打开，记录了Build的过程，是一个日志型文件
RC：资源描述文件，记录了所有的资源信息，在资源编辑器里作的修改，实际上都是对RC文件的修改
RC2：附加的资源描述文件，不能直接资源编辑器修改，只能手工添加，可以用来添加额外的资源
RES：经过资源编辑器编译之后的资源文件，以二进制方式存放
SBR：编译器生成的浏览信息文件，在代码导航的时候非常有用，她需要在编译时指定/FR或者/Fr开关
BSC：BSCMAKE.EXE将所有的SBR文件作为输入，经过处理之后输出一个BSC文件，在代码导航的时候实际用到的是BSC文件
ILK：当选定渐增型编译连接时，连接器自动生成ILK文件，记录连接信息
PDB：全称是Program DataBase，即程序数据库文件，用来记录调试信息，是一个相当重要的文件，没有他，程序无法正常调试
LIB：如果项目输出是Dll的话，一般会输出一个跟项目同名的Lib文件，记录输出的函数信息
EXP：同Lib，是跟Dll一起生成的输出文件
PCH：全称是PreCompiled Header，就是预先编译好的头文件，在编译时指定/Yu开关时编译器自动生成

被误解的C++——优化variant实现

int F1(int N);
int F2(int N);
int MyF(int (*pF)(int), int);

void main()
{
 cout<<"函数指针调用F1，此时的结果为："<<MyF(F1, 4)<<endl;
 cout<<"函数指针调用F2，此时的结果为："<<MyF(F2, 4)<<endl;
}

//函数F1、F2、pF的定义
int F1(int N)
{
 return N*N;
}

int F2(int N)
{
 return N+N;
}

int MyF(int (*pF)(int), int N)
{
 return pF(N);
}

Overview: This lab will work through the process of creating a simple “Exporter” MAX Plug-in. The goal of the lab will be to familiarize the developer with the basics of creating a MAX plug-in, and the basics of exporting 3ds max scene data.

This lab is composed of 5 phases. At the beginning of each phase you will find a link to a .zip file that contains source code for the exporter that is relevant to the topic of that phase. Phase 0 provides the basic Microsoft Visual C++ v6 project skeleton. Each phase builds upon what was discussed in the previous ones, so simply replace and add the files in the source of the current phase to the previous ones.

Table of Contents

PHASE 0: STARTING OUT

PHASE 1 : GEOMETRY

PHASE 2 : TEXTURES AND LIGHTING

PHASE 3: ANIMATION AND MODIFIERS

PHASE 4: CUSTOM DATA

OTHER STRATEGIES, FUTURE DIRECTIONS

Legend

In order to help in identifying the various entries in this document the following legend will be applied:

MaxSDK Classes are in this format: IDerivedObject

MaxSDK Methods are in this format: DoExport()

Filenames are in this format: export.cpp

Source code that is only relevant to this tutorial are in this format: PerFaceData

PHASE 0: STARTING OUT

Source code for Phase 0: phase0.zip

We’ll start with the process of creating our own “skeleton” plug-in from scratch.

In general, when creating plug-ins, I try the following steps in the following order:

1. If a skeleton for the plug-in types exists, I start with that
2. If not, I use the AppWizard, if the wizard supports the plug-in type
3. Otherwise, I do the following

Create a new Win32 DLL project in MSDEV. I usually put the plug-in project under the MAXSDK directory.

I setup the project configs to build the plugin DLL, with the appropriate extension, into the MAXSDK\PLUGIN directory. I use relative paths and add ..\include to the include path and ..\lib to the lib path. I setup the C Runtime settings as appropriate (Debug Multithreaded DLL for Debug and Multithreaded DLL for Release), and create the Hybrid project configuration (by copying the Debug config, but setting the C Runtime to release-mode Multithreaded DLL)

I usually add 2 CPPs ([PLUGINNAME].CPP and DLLENTRY.CPP), the former will hold the various implementation code for the actual plugin-type derived class(es), the latter will hold the requirement C-style plugin DLL exports. Likewise, I usually add a PLUGINNAME.H that has the class definitions of the plugin-type derived class(es).

I add the appropriate [PLUGINNAME].DEF file, with the appropriate 3ds max DLL exports. The def file looks something like:

LIBRARY MyPlugIn
EXPORTS
LibDescription		@1
LibNumberClasses	@2
LibClassDesc		@3
LibVersion		@4
SECTIONS
.data READ WRITE

I add a string table to the resources, along with a version resource. If the plug-in has a dialog, I add one. For this simple exporter lab, there is no additional dialog (well, there’s the about box, which doesn’t really count).

Plug-in Requirements

I then proceed to add the basic classes that all plug-ins need. I start with coding the DLL exports, which are more or less boilerplate, into DLLENTRY.CPP. This in turn (via LibClassDesc) leads directly to the creation of the required plug-in ClassDesc.

The DLL exports are fairly self-explanatory. DLLMain (not an export per se) initializes some custom controls. LibDescription will return the localized string that describes the plugin. LibNumberClasses returns the number of plug-in type classes the plug-in DLL provides (for this example, we only provide 1). LibClassDesc returns the ClassDesc for 3ds max to use to identify and create plug-in type objects. LibVersion returns the version of MAX the plug-in works with, which is always defined in the 3ds max headers as VERSION_3DSMAX.

LibClassDesc often just returns the address of a single static ClassDesc. For this tutorial, I derived from ClassDesc2. In general, for those familiar with this process, I recommend working with ClassDesc2 and ParamBlock2 instead of their predecessors. In general, the previous versions will be phased out in the future.

As discussed earlier, the ClassDesc acts mainly as a class factory for the main derived plug-in class. In this case, the main plug-in class we will derive from SceneExport. In our plugin we declare derivations of both ClassDesc2 and SceneExport. Typically, a single static instance of the derived ClassDesc is created and returned by LibClassDesc. The derivation also returns category, class ID, and name information about our derivation of SceneExport. The SDK has a tool (GENCID.EXE) that provides an easy way to create unique Class Ids.

This brings us to the plug-in type object derivation. We provide a derivation for SceneExport in our header (MyExporter). The basic required overrides for SceneExport are briefly explained as follows:

int ExtCount() : Returns the number of file extensions that the exporter provides (for our example, we provide 1, which I arbitrarily decided would be “MEP”).
const TCHAR * Ext(int n) : Returns the 3-letter file extension string for the given extension index (0-based).
const TCHAR * LongDesc() : Provides the “long” description of the file export format.
const TCHAR * ShortDesc() : Provides the “short” description of the file export format, shown in the file export dialog drop-down.
const TCHAR * AuthorName() : Provides the string that describes the author and/or company of the exporter plugin.
const TCHAR * CopyrightMessage() : Provides the string that shows the copyright for the given exporter and/or exporter format.
const TCHAR * OtherMessage1() : not used
const TCHAR * OtherMessage2() : not used
unsigned int Version() : Somewhat redundant, but returns a version number for the exporter.
void ShowAbout() : Shows an about box, accessible by the user from the main MAX export dialog.
int DoExport() : The actual export method. BOOL SupportsOptions() : Returns TRUE if the exporter supports some custom export options. Currently, only one option (export selected versus export entire scene) exists.

Most of the methods are basic returns of localized strings from the string table, or constants/defines. The real “meat” of an exporter plugin is the DoExport method, which we’ll expand in the next sections. This example is simple and therefore has no custom exporter options. You may want to take a look at the exporter samples, and the skeleton exporter, for a simple way to provide a special “before export” dialog that has exporter-specific options.

I added some protected methods (DoHeader, DoNodes, DoTailer) in my basic plan of exporting scene-global information, followed by per-node information, followed by any “end delimiter” file information (if nececssary). I also added some cached pointer member variables, and a cached FILE pointer to open/write to during the actual export.

• Note: Some of the above can be read about in more detail in a section of the SDK helpfile titled “Creating a New Plug-In Project”.
• Note 2: You may note that in the SDK samples, many different styles of code organization are used. Feel free to use the style you feel most comfortable with.

Try it

1. Create a sub-directory off your MAXSDK directory called “Exporter”
2. Un-zip / Copy Phase0 project/source files into Exporter directory
3. Start MSDEV, and open Exporter project
4. Examine the Project and Build settings. Notice the extra Hybrid Build configuration. Notice the relative lib paths and the added MAX libraries, the output destination, and the C-Runtime type (Multithreaded DLL or Debug Multithreaded DLL)
5. Examine the project files. First, look at the EXPORTER.DEF file and notice the four DLL exports
6. Look at the DLLENTRY.CPP file, and examine each of the DLL exports closely, including the DLLMain. This CPP is complete, and we will not need to modify it for the remainder of the session
7. Look at EXPORTER.H. Notice the #define MYEXP_CLASSID , and the MyExporter declaration.
8. Look at EXPORTER.CPP. Notice the MyExporterClassDesc declaration and implementation. Notice the (mostly empty at this point) implementation of MyExporter.
9. Examine the Project resources, which at this point include a generic About Box Dialog resource, a generic Version resource, and a String Table resource.
10. If you have the compiler and 3ds max handy, feel free to go ahead and compile the plugin (suggested you use Hybrid Build Configuration at this point) and try using it. In 3ds max, you can either doa File->Export orFile->Export Selected (if there are objects selected), and get the File Export Dialog. In that dialog, if the plug-in is properly loaded, you should find the “*.MEP” MyExporter format. Naturally, at this point, if you export to this format, you’ll get an empty file.

PHASE 1 : GEOMETRY

Source code for Phase 1: phase1.zip

For the first actual 3ds max scene contents we export, we’ll concentrate on just the geometry of geometric scene objects.

To facilitate working with nodes in the 3ds max scene, we first need to create a node enumerator method that walks over and processes the nodes in the MAX scene. There are various ways to do this: provide our own method that walks the scene manually, or utilize IScene and TreeEnum callbacks via ExpInterface. For this example, we’ll code our own enumerator from scratch.

For some brief backgrounder information on 3ds max's Scene hierarchy, the basic layout is of a scene tree, with a single “root” Node, whose children are all the nodes in the scene. If a node has a heirarchy (via a 3ds max “link”, or perhaps based on the layout of the object, e.g. bones), this will be represented in the “tree” as well. The Schematic view gives a pretty good visual idea of what this more or less looks like.

The Root node is somewhat special, and can be accessed via the Interface::GetRootNode utility method. The Root node doesn’t represent any actual geometry or the like.

For our node walker, the basic pseudo-code looks something like:

nodeEnum(Node ptr)
If the ptr isn’t valid, exit
If the ptr isn’t selected, and we’re exporting only selected nodes, exit
If the user canceled (usually via ESC), exit
Otherwise
Evaluate the object, determine what type of object it is, and call
a specific helper method that exports that type of object
For each child of the current ptr Node
nodeEnum(child)

The code that will call the “nodeEnum” will be in MyExporter::DoNodes, and look something like:

Get a count of the children of the Root Node
For each child of the Root Node
Check for cancel and break if cancelled
nodeEnum(child)

Try it

1. Based on the above pseudo-code, write the given portions of code. You’ll need to look at INode ( ::Selected(), ::NumberOfChildren(), ::GetChildNode(), ::EvalWorldState()), Interface ( ::GetRootNode(), ::GetCancel()) and possibly ObjectState and Object (::SuperClassID()) in the SDK docs
2. Compare your code with the code snippet from Phase 1 exporter-nodeenum.cpp

ObjectState and Node::EvalWorldState are probably worth a bit more explanation. As you may already know, the 3ds max geometry pipeline maintains a “Object” that flows up the pipeline, and can essentially be represented by different, animated states, starting with a “Base” object, then possibly into a “Derived” object with a modifier, and so on.

EvalWorldState tells the node to take it’s Object “stack” and effectively make a collapsed copy, such that the resulting ObjectState contains the final end-result of the stack. This is also what is effectively used at Render time.

• Note: I also added some code to MyExporter::DoHeader that exports some basic header file information (date/time created, title string, etc). Feel free to examine.

Meshes

3ds max Meshes are triangle polygonal meshes. Every geometric (renderable) object in a 3ds max scene must be able to convert itself to a triangle mesh. Anything in the scene collapsed to a editable mesh will already be in tri-mesh form, however primitives (modified or not) may not be. To get the triangle mesh, we use the Object::ConvertToType API and request a TRIOBJ_CLASS_ID.

When calling ConvertToType, it’s important to check the returned result pointer, and see if it’s the same as the original Object pointer. If so, this implies the Object didn’t generate any new stuff, and thus we shouldn’t delete the result. Otherwise, the Object did generate a new mesh, and we, the caller, are responsible for freeing the mesh.

Once we have a mesh, we extract and dump out the number of vertices and number of faces. This information is available as APIs off the Mesh class.

As the mesh data is in Object Space, we need to get the Node Transform Matrix (for the current frame). We export this first in generic row-major format.

We then export the world-space point of each mesh vertex, multiplying the vertices by the object TM.

We then export the faces, described by three indices into the vertex array. The vertices, taken in counter-clockwise order, describe the “front” (positive normal) of the face. We also export the “edge visibility”, which describes, for a given edgeA->B, if 3ds max draws a highlight line in the viewport or not, and also if in edit-mesh-edge mode, if the edge can be selected. Finally, we export the smoothing group for each face, which could be used with the vertex normals (which we don’t export for now, left as an exercise) to smooth the mesh via Phong or other shading method.

For this phase, we do not export any mesh material or UV information. This will be done in Phase 2.

Try it

1. In the last part, we had nodeEnum call a utility method to export GeomObjects (in the code sample this is MyExporter::ExportGeomObject). Try implementing ExportGeomObject to export the Node Transform Matrix, and if the Node can convert itself to a TriObject, try exporting the Mesh information. You’ll need to look at Inode::GetNodeTM() and the Matrix3/Point3 classes in the SDK docs for getting the matrix information. You’ll need to look at the Object::ConvertToType() and TriObject and Mesh class in the docs for exporting the mesh information.
2. Compare the code with the code fragment exporter-geom.cpp. The code fragment has both the mesh and the patch (next) exporter code – the mesh exporter code is the second “chunk” in ExportGeomObject.

Patches

For patches, we provide an additional code path in ExportGeomObject that looks for PATCHOBJ_CLASS_ID and exports the patch i