I render using my custom render script. I wrote it because I want the ability export pivot data for each frame along with the sprite image. Pivots are used to create layered sprites, with node-like functionality. There are no discreet layers, just animation sequences attached to each other called SpriteSequences. The green boxes are the sprite sequences, the orange dot is the origin, and the red dots are the pivots. Each sequence has an origin that attaches to a pivot of another sequence, or is attached to nothing which is the case for the top-level sequence that renders at the sprite origin. You can't see any of the limb sequence origins(orange) because they're under the pivots (in red). Each pivot has a layer number for the order in which the attached sequence will render.
At the moment, these layer numbers are relative because when they render, each sequence renders the sequences that are attached to it's pivots. So a sequence renders the pivots' sequences that are negative before it renders itself and positive afterward. In the second image, I want the left arm to render behind the legs, but with relative layers there are conflicts. My solution to this is to have the Sprite class sort it's active sequences by their layer (absolute), and call their render function directly. I guess I had it the other way because I didn't want the Sprite class to get complicated too soon. I just wanted it to serve as a manager for the SpriteSequences and not do their rendering calls for them, just call the top sequence. Absolute layers seem necessary to avoid layer overlapping issues.
Here are my steps:
First I create the model and animate.
Then I separate the geometry that would go into it's own sequence into their own (Max) layers. The torso in one layer, the legs in another, etc...
Then I attach custom "pivot points" to the objects where the other layers are attached.
Pivot points are really just special dummy objects (represented by green wire boxes).
The pivot's coordinates are projected into screen-space when rendered, and stored in frame coordinates for each frame. For rendering the limbs you can establish the frame's origin position by using the button named "<>" and selecting the object.
Then I set the options for rendering, and render each sequence in the order I want for the sheet. When I'm satisfied with the sprite sheet, I can save the sequence render settings in a text file so I never have to render each sequence individually again. If I need to I can edit this settings list by hand easily.
Now I save the image, and the pivot and origin data in a text file. I now have the option to save a depthmap of the sheet if I want to make a normal map for the sprite too.
The script also packs the sprites into the sheet as efficiently as possible, with an option to pad the borders with transparent pixels. Padding is useful because the in-game sprite renders using float texture coords, and its difficult for me to get an exact "cut" between the frames.
That's everything needed to create a functional, layered sprite.
Other concerns are aesthetic things like, "should I render a sprite that's evenly lit on all sides because when it has a normal map it looks better, or should I leave shadows or contrast in the diffuse map in case the player doesn't have shaders?" There are many decisions to be made about lighting, or shaders, or sprite pixel density.
Now to get the sprite we just created into the game, it has to be included into an Entity. An Entity can have a collision model and/or a sprite, along with attribute value pairs. More on entities later.