Engine: Model Viewer & Converter
Model Viewer
The model viewer highlights several custom engine tools and features surrounding the conversion and importation of rigid (non-animated) 3D models. Additionally, the model viewer demonstrates proper camera functionality in conjunction with culling capabilities. All 3D models featured in the demo originated as .fbx files, and subsequently converted into a custom runtime file format (.azul). To accomplish this, a model converter engine tool was developed to extract the required information from the existing .fbx file(s).
Each rigid model also contains an associated collision sphere to represent their respective bounding volumes. These collision spheres are represented in the demo; shaded green when in view of the primary camera. The white outline in the demo represents the frustrum of the primary camera. When outside this frustrum, the collision sphere of a rigid 3D model is shaded red. This is done to demonstrate not only the culling capability present within the engine, but also proper camera tracking.
Data Reduction
The model viewer serves as a tool to properly verify converted data within the engine. Specifically, it focuses on increasing performance by demonstrating culling functionality during real-time. Upon being loaded into the engine, each converted model has an associated Ritter sphere, conceptually representing the bounding volume. Using easy-out radius tests of the sphere, a potential collision with the origin camera is determined each frame. If a collision occurs, the color of the bounding volume is turned green. This indicates that the given object requires rendering. Conversely, if the model’s bounding volume does not collide with the origin camera, the engine may choose to forgo rendering that object. This is a incredibly useful, if not necessary, optimization to perform when working within any real-time application with graphical elements.
OpenGL functions are used to render the rigid models to the screen. The following is a code sample of the Graphics Object used to render a standard model using a flat texture shader:
Whereas functionality exists to easily render using pure vertex arrays, the custom Azul engine utilizes tri-lists and indexing to define triangle positions. This allows for the elimination of redundant vertex data, and therefore increases the performance of the engine during the rendering stage. This reduction is done entirely offline in the model converter (see next section), making the converted data available upon importation into the engine. The following demo showcases side by side unreduced and reduced pyramid models using this method:
Note how there are nearly 3X the number of vertices contained in the unreduced version, yet the model appears identical. In this instance, at 32 bytes per polygon, the reduction saves almost 1.5MB in memory at runtime. This may seem trivial in a singular scenario, but applied engine-wide, this reduction produces enormous savings; a fact especially true when dealing with more complex models.
The above shows the results of the reduction after converting each model, as well as a general display of the custom file's archived contents.
ModelConverter.exe
The model converter Tool was developed in order to convert existing .fbx files into a custom .azul runtime file format. The converter is a wholly separate executable, utilizing command line prompts to simplify the conversion process for the user.
The first command-line parameters simply require the name of the .fbx file to be converted along with the name of the resulting .azul file to be outputted. For example:
The next step is the most important. The user of the converter must specify one of two primary output types: “Model” or “Animation”:
Specifying “Model” upon using the converter will ensure that all of the data used to render the 3D rigid model is extracted; this includes the vertices, normals, and uvs (texture coordinates). Furthermore, if there is an associated .tga texture present with the .fbx file, the user may specify an additional option “-includeTexture”. This will directly package the texture into the archived file to be automatically imported and associated with the model upon engine initialization:
Regarding rigid models, the bounding volume calculation is also performed (based on Ritter’s algorithm) and exported within the conversion process. This is to decrease the strain on engine initialization, and ensure that each imported model uniformly includes this data. (See “Model Viewer” for more information)
Specifying “Animation” lends itself to even more potential scenarios within the converter. Unlike the “Model” specification, converting an animated .fbx file will not automatically extract the vertices, normals and uvs of the model. Specifying “Animation” will only ensure the exportation of animation clips and their associated keyframe data. This data has the potential to be extensive, seeing as it contains unique positional information for each skeletal bone in the animation hierarchy at every frame.
Using the option “-includeHierarchy” leads to the greatest extraction of data. Specifying this option will ensure that not only are the animation clips exported, but also the information necessary to render the fully skinned and animated model. This includes not only the aforementioned vertices, normals and uvs, but also the inverse bind pose matrix, the weight influences and corresponding indices, and the hierarchy table used to calculate skinning. This option is present to ensure that the hierarchy, or skeleton, of the animated model is reused within the engine. By only extracting the animation data by default, we can ensure redundant data is not exported. Furthermore, when only exporting the animation data there is an additional option available to the user to attach the associated hierarchy name. For example:
This will signal anim_model_clips.azul to associate all exported clips to the hierarchy located in the new_anim_model.azul file.
Lastly, there exists a final option available when exporting animations: enabling compression. When using the option “-compress” in conjunction with animated data, the converter will compress all associated animations to a pre-set degree. If the resulting loss of fidelity is unacceptable, the user may specify a number after the “-compress” flag. The following shows how to apply the above options:
(For more information on compression see Engine: Compression & Blending)
The resulting .azul files serve as archived storage, containing “chunks” of data tagged with custom headers unique to the engine. These Azul Engine tools were built to specifically utilize data-driven principles. Upon initialization of the engine, a custom file iterator automatically imports all of the .azul files present in the working directory. The engine then appropriately deconstructs these archived files, organizing and placing the resulting objects in their respective managers.
