Fangame How-to:SonicGDK/Configuring 3D computer graphics software

From Sonic Retro

(Original guide by Andrew75)

A guide about how to configure properly some programs used to create 3D models and import them into SonicGDK.


I have been assisting a few teams using SonicGDK as a sort of technical advisor, as it seems many people are experiencing the same issues over and over again. The main issue that I've been seeing occurs when you guys make custom models for UDK (be it in 3ds Max, Maya or Blender) and Sonic doesn't stick to the meshes properly, he seems to hop for a few moments as he runs.

Some of the issues that cause this occurs when people import undersized models and then scale them up in UDK by a certain percentage. A workaround would be to select Build from the UDK editor toolbar and Build All. It could also be related to the file you're exporting, using an outdated FBX exporter from your modeling program (this relates to the version of UDK that you're using), so make sure to update the FBX format to the latest version for your program.

Someone asked me for advise on how to fix the hopping issues, but both the "Build All" and FBX compatibility problem were not the root of the issue. It turns out that we needed to export the model with the true scale from the modeling package (not scale up in UDK). The best habit would be to make game assets in the true scale that will be used in the game, or rescale the asset in the modeling package before exporting the poor thing. What are the correct scales for Sonic and his assets? I've put together a little tutorial to help get you guys started.


First thing you will need to know is that 3ds Max and Blender share the same exact scale for models being exported from both programs using the default scale setting of UDK. An interesting note: in 3ds Max, 1 generic Max unit, cm, meter, or whatever scale you have default units set to, they will all export to the same sized model in UDK (1 unit of any type of measurement is equal to 1 UDK unit).

Figure 1

SonicGDK has double sized scale requirements, due to Sonic being programmed at a larger scale for his jump height and run speeds, vs UDK units, 3ds Max units, Blender units or even classic Sonic pixels. We need to match SonicGDK scales, not UDK scales, so choose between:

  1. Model in grid space setting of 2 (may be confusing for some people).
  2. Set the spacing to 1 and than rescale after the model is finished but before exportation.

Myself? I prefer the second option, since it's easier to keep track of units of 1 rather than multiples of 2.

Figure 2

When rescaling a mesh and you want to export it to the game... please use Reset Xform! Otherwise you "may or may not" get some issues in the future. What reset Xform does is reset all transforms, rotations and scales and set new defaults. It's also recommended to apply reset Xform in any and all situations including just before skinning a character mesh.

Figure 3
Here we see Sonic's UDK scale compared to UDK grid scale of 1. Notice how 1 pixel is equal to 2x2 udk grid units.

Figure 4

SGDK's Sonic model may look shorter when standing next to the classic sonic 1 sprite's height but the programmed units match the sprite more than the model (at least I think so), these scales I'm going into are more useful for making environments, than Sonic's actual model scale. Sonic is 39 pixels tall in classic games, which is 39 units tall in modeling package (rescaled by 200% = 78 units tall for SonicGDK). The maximum jump height so that Sonic can land on platforms and environmental pieces would be 100 units in the modeling package (rescaled by 200% = 200 units high).

Figure 5