package core:encoding/hxa

Overview

Implementation of the HxA 3D asset format HxA is a interchangeable graphics asset format. Designed by Eskil Steenberg. @quelsolaar / eskil 'at' obsession 'dot' se / www.quelsolaar.com

Author of this Odin package: Ginger Bill

Following comment is copied from the original C-implementation --------- -Does the world need another Graphics file format?

Unfortunately, Yes. All existing formats are either too large and complicated to be implemented from
scratch, or don't have some basic features needed in modern computer graphics.

-Who is this format for?

For people who want a capable open Graphics format that can be implemented from scratch in
a few hours. It is ideal for graphics researchers, game developers or other people who
wants to build custom graphics pipelines. Given how easy it is to parse and write, it
should be easy to write utilities that process assets to preform tasks like: generating
normals, light-maps, tangent spaces, Error detection, GPU optimization, LOD generation,
and UV mapping.

-Why store images in the format when there are so many good image formats already?

Yes there are, but only for 2D RGB/RGBA images. A lot of computer graphics rendering rely
on 1D, 3D, cube, multilayer, multi channel, floating point bitmap buffers. There almost no
formats for this kind of data. Also 3D files that reference separate image files rely on
file paths, and this often creates issues when the assets are moved. By including the
texture data in the files directly the assets become self contained.

-Why doesn't the format support ?

Because the entire point is to make a format that can be implemented. Features like NURBSs,
Construction history, or BSP trees would make the format too large to serve its purpose.
The facilities of the formats to store meta data should make the format flexible enough
for most uses. Adding HxA support should be something anyone can do in a days work.

Structure: ---------- HxA is designed to be extremely simple to parse, and is therefore based around conventions. It has a few basic structures, and depending on how they are used they mean different things. This means that you can implement a tool that loads the entire file, modifies the parts it cares about and leaves the rest intact. It is also possible to write a tool that makes all data in the file editable without the need to understand its use. It is also possible for anyone to use the format to store data axillary data. Anyone who wants to store data not covered by a convention can submit a convention to extend the format. There should never be a convention for storing the same data in two differed ways. The data is story in a number of nodes that are stored in an array. Each node stores an array of meta data. Meta data can describe anything you want, and a lot of conventions will use meta data to store additional information, for things like transforms, lights, shaders and animation. Data for Vertices, Corners, Faces, and Pixels are stored in named layer stacks. Each stack consists of a number of named layers. All layers in the stack have the same number of elements. Each layer describes one property of the primitive. Each layer can have multiple channels and each layer can store data of a different type.

HaX stores 3 kinds of nodes

- Pixel data.
- Polygon geometry data.
- Meta data only.

Pixel Nodes stores pixels in a layer stack. A layer may store things like Albedo, Roughness, Reflectance, Light maps, Masks, Normal maps, and Displacement. Layers use the channels of the layers to store things like color. The length of the layer stack is determined by the type and dimensions stored in the

Geometry data is stored in 3 separate layer stacks for: vertex data, corner data and face data. The vertex data stores things like verities, blend shapes, weight maps, and vertex colors. The first layer in a vertex stack has to be a 3 channel layer named "position" describing the base position of the vertices. The corner stack describes data per corner or edge of the polygons. It can be used for things like UV, normals, and adjacency. The first layer in a corner stack has to be a 1 channel integer layer named "index" describing the vertices used to form polygons. The last value in each polygon has a negative - 1 index to indicate the end of the polygon.

Example:
A quad and a tri with the vertex index:
	[0, 1, 2, 3] [1, 4, 2]
is stored:
	[0, 1, 2, -4, 1, 4, -3]

The face stack stores values per face. the length of the face stack has to match the number of negative values in the index layer in the corner stack. The face stack can be used to store things like material index.

Storage ------- All data is stored in little endian byte order with no padding. The layout mirrors the structs defined below with a few exceptions. All names are stored as a 8-bit unsigned integer indicating the length of the name followed by that many characters. Termination is not stored in the file. Text strings stored in meta data are stored the same way as names, but instead of a 8-bit unsigned integer a 32-bit unsigned integer is used.

Types

File ¶

File :: struct {
	header:    Header,
	backing:   []u8,
	allocator: runtime.Allocator,
	nodes:     []Node,
}
Header :: struct #packed {
	magic_number:        u32le,
	version:             u32le,
	internal_node_count: u32le,
}

Image_Type ¶

Image_Type :: enum u8 {
	Image_Cube = 0, // 6 sided qube, in the order of: +x, -x, +y, -y, +z, -z.
	Image_1D   = 1, // One dimensional pixel data.
	Image_2D   = 2, // Two dimensional pixel data.
	Image_3D   = 3, // Three dimensional pixel data.
}
 

Pixel data is arranged in the following configurations

Layer ¶

Layer :: struct {
	name:       string,
	// name of the layer (maximum length is 255)
	components: u8,
	// 2 for uv, 3 for xyz/rgb, 4 for rgba
	data:       union {
		[]u8, 
		[]i32le, 
		[]f32le, 
		[]f64le, 
	},
}

Layer_Data_Type ¶

Layer_Data_Type :: enum u8 {
	Uint8  = 0, // 8-bit unsigned integer,
	Int32  = 1, // 32-bit little-endian signed integer
	Float  = 2, // 32-bit little-endian IEEE 754 floating point value
	Double = 3, // 64-bit little-endian IEEE 754 floating point value
}

Layer_Stack ¶

Layer_Stack :: distinct []Layer
 

Layers stacks are arrays of layers where all the layers have the same number of entries (polygons, edges, vertices or pixels)

Meta ¶

Meta :: struct {
	name:  string,
	// name of the meta data value (maximum length is 255)
	value: union {
		[]i64le, 
		[]f64le, 
		[]Node_Index, 
		string, 
		[]u8, 
		[]Meta, 
	},
}

Meta_Value_Type ¶

Meta_Value_Type :: enum u8 {
	Int64  = 0, 
	Double = 1, 
	Node   = 2, 
	Text   = 3, 
	Binary = 4, 
	Meta   = 5, 
}

Node ¶

Node :: struct {
	meta_data: []Meta,
	content:   union {
		Node_Geometry, 
		Node_Image, 
	},
}
 

A file consists of an array of nodes, All nodes have meta data. Geometry nodes have geometry, image nodes have pixels

Node_Geometry ¶

Node_Geometry :: struct {
	vertex_count:      u32le,
	// number of vertices
	vertex_stack:      Layer_Stack,
	// stack of vertex arrays. the first layer is always the vertex positions
	edge_corner_count: u32le,
	// number of corners
	corner_stack:      Layer_Stack,
	// stack of corner arrays, the first layer is always a reference array (see below)
	edge_stack:        Layer_Stack,
	// stack of edge arrays
	face_count:        u32le,
	// number of polygons
	face_stack:        Layer_Stack,
}

Node_Image ¶

Node_Image :: struct {
	type:        Image_Type,
	resolution:  [3]u32le,
	image_stack: Layer_Stack,
}

Node_Index ¶

Node_Index :: distinct u32le

Node_Type ¶

Node_Type :: enum u8 {
	Meta_Only = 0, // node only containing meta data.
	Geometry  = 1, // node containing a geometry mesh, and meta data.
	Image     = 2, // node containing a 1D, 2D, 3D, or Cube image, and meta data.
}

Read_Error ¶

Read_Error :: enum int {
	None, 
	Short_Read, 
	Invalid_Data, 
	Unable_To_Read_File, 
}

Write_Error ¶

Write_Error :: enum int {
	None, 
	Buffer_Too_Small, 
	Failed_File_Write, 
}

Constants

CONVENTION_HARD_BASE_CORNER_LAYER_COMPONENTS ¶

CONVENTION_HARD_BASE_CORNER_LAYER_COMPONENTS :: 1

CONVENTION_HARD_BASE_CORNER_LAYER_ID ¶

CONVENTION_HARD_BASE_CORNER_LAYER_ID :: 0

CONVENTION_HARD_BASE_CORNER_LAYER_NAME ¶

CONVENTION_HARD_BASE_CORNER_LAYER_NAME :: "reference"

CONVENTION_HARD_BASE_CORNER_LAYER_TYPE ¶

CONVENTION_HARD_BASE_CORNER_LAYER_TYPE :: Layer_Data_Type.Int32

CONVENTION_HARD_BASE_VERTEX_LAYER_COMPONENTS ¶

CONVENTION_HARD_BASE_VERTEX_LAYER_COMPONENTS :: 3

CONVENTION_HARD_BASE_VERTEX_LAYER_ID ¶

CONVENTION_HARD_BASE_VERTEX_LAYER_ID :: 0

CONVENTION_HARD_BASE_VERTEX_LAYER_NAME ¶

CONVENTION_HARD_BASE_VERTEX_LAYER_NAME :: "vertex"

CONVENTION_HARD_EDGE_NEIGHBOUR_LAYER_NAME ¶

CONVENTION_HARD_EDGE_NEIGHBOUR_LAYER_NAME :: "neighbour"

CONVENTION_HARD_EDGE_NEIGHBOUR_LAYER_TYPE ¶

CONVENTION_HARD_EDGE_NEIGHBOUR_LAYER_TYPE :: Layer_Data_Type.Int32

CONVENTION_SOFT_ALBEDO ¶

CONVENTION_SOFT_ALBEDO :: "albedo"

CONVENTION_SOFT_AMBIENT_OCCLUSION ¶

CONVENTION_SOFT_AMBIENT_OCCLUSION :: "ambient_occlusion"

CONVENTION_SOFT_DISPLACEMENT ¶

CONVENTION_SOFT_DISPLACEMENT :: "displacement"

CONVENTION_SOFT_DISTORTION ¶

CONVENTION_SOFT_DISTORTION :: "distortion"

CONVENTION_SOFT_LAYER_ADD_BLENDSHAPE ¶

CONVENTION_SOFT_LAYER_ADD_BLENDSHAPE :: "addblendshape"

CONVENTION_SOFT_LAYER_BINORMAL ¶

CONVENTION_SOFT_LAYER_BINORMAL :: "binormal"

CONVENTION_SOFT_LAYER_BLENDSHAPE ¶

CONVENTION_SOFT_LAYER_BLENDSHAPE :: "blendshape"

CONVENTION_SOFT_LAYER_COLOR ¶

CONVENTION_SOFT_LAYER_COLOR :: "color"

CONVENTION_SOFT_LAYER_CREASES ¶

CONVENTION_SOFT_LAYER_CREASES :: "creases"

CONVENTION_SOFT_LAYER_MATERIAL_ID ¶

CONVENTION_SOFT_LAYER_MATERIAL_ID :: "material"

CONVENTION_SOFT_LAYER_NAME_UV0 ¶

CONVENTION_SOFT_LAYER_NAME_UV0 :: "uv"

CONVENTION_SOFT_LAYER_NORMALS ¶

CONVENTION_SOFT_LAYER_NORMALS :: "normal"

CONVENTION_SOFT_LAYER_SELECTION ¶

CONVENTION_SOFT_LAYER_SELECTION :: "select"

CONVENTION_SOFT_LAYER_SEQUENCE0 ¶

CONVENTION_SOFT_LAYER_SEQUENCE0 :: "sequence"

CONVENTION_SOFT_LAYER_SKIN_REFERENCE ¶

CONVENTION_SOFT_LAYER_SKIN_REFERENCE :: "skining_reference"

CONVENTION_SOFT_LAYER_SKIN_WEIGHT ¶

CONVENTION_SOFT_LAYER_SKIN_WEIGHT :: "skining_weight"

CONVENTION_SOFT_LAYER_TANGENT ¶

CONVENTION_SOFT_LAYER_TANGENT :: "tangent"

CONVENTION_SOFT_LIGHT ¶

CONVENTION_SOFT_LIGHT :: "light"

CONVENTION_SOFT_NAME ¶

CONVENTION_SOFT_NAME :: "name"

CONVENTION_SOFT_TRANSFORM ¶

CONVENTION_SOFT_TRANSFORM :: "transform"

LATEST_VERSION ¶

LATEST_VERSION :: 3

MAGIC_NUMBER ¶

MAGIC_NUMBER :: 'H' << 0 | 'x' << 8 | 'A' << 16 | '\x00' << 24

VERSION_API ¶

VERSION_API :: "0.3"

Variables

This section is empty.

Procedures

file_destroy ¶

file_destroy :: proc "odin" (file: File) {…}

meta_destroy ¶

meta_destroy :: proc "odin" (meta: Meta, allocator := context.allocator) {…}

nodes_destroy ¶

nodes_destroy :: proc "odin" (nodes: []Node, allocator := context.allocator) {…}

read ¶

read :: proc "odin" (data: []u8, filename: string = "", print_error: bool = false, allocator := context.allocator) -> (file: File, err: Read_Error) {…}

read_from_file ¶

read_from_file :: proc "odin" (filename: string, print_error: bool = false, allocator := context.allocator) -> (file: File, err: Read_Error) {…}

required_write_size ¶

required_write_size :: proc "odin" (file: File) -> (n: int) {…}

write ¶

write :: proc "odin" (buf: []u8, file: File) -> (n: int, err: Write_Error) {…}

write_to_file ¶

write_to_file :: proc "odin" (filepath: string, file: File) -> (err: Write_Error) {…}

Procedure Groups

This section is empty.

Source Files

Generation Information

Generated with odin version dev-2022-10 (vendor "odin") Windows_amd64 @ 2022-10-05 21:11:47.320548600 +0000 UTC