.LWO File Format

Introduction

LWO3 is the form type that LightWave 3D 2015 and later put in the objects it saves. A file looks like an LWO2 file with a different form type, and this site reads it by the LWO2 rules.

NewTek has not published a description of LWO3 where this site could read one, so this page does not list what it adds. The one open reader consulted, the LWO importer of Assimp (BSD licence), handles LWO3 with the LWO2 code plus one change, described below. It labels LWO3 “LightWave 2018 and later”; this site has also said 2015, and neither start version is confirmed.

Structure

An LWO3 file is an IFF file: one big-endian FORM chunk whose form type is LWO3 (4C 57 4F 33 at offset 8), holding chunks, each a four-letter ID, a 4-byte length, the data and a pad byte when the length is odd. Everything else that the LWO2 chunk reference says about data types, sub-chunks, layers, points, vertex maps, polygons, tags, envelopes, clips and surfaces is what the viewer applies to it.

00000000  46 4F 52 4D 00 00 00 A8 4C 57 4F 33 54 41 47 53  FORM....LWO3TAGS

What the viewer here does

• The form type LWO3 chooses this variant, so a file is told from LWO2 by reading offset 8, not by its name.
• Every chunk it knows from LWO2 is decoded in full: layers, points, vertex maps (UV maps among them), polygons, tags, bounding boxes, envelopes, clips and surfaces with their texture blocks. The pictures show the layers and the UV maps.
• A chunk or sub-chunk the LWO2 description does not define is skipped by its length and shown as bytes in the tree, and the overview lists its ID under “Chunks not in the reference”.

This is unchecked against real LWO3 files: neither this machine nor Assimp’s test set (36 LWO2 files, 5 LWOB and 2 Modo LXOB files) holds a file with the form type LWO3. It was tested on files built to the LWO2 rules with the form type changed, and on built files that follow Assimp’s LWO3 reading. Where LWO3 changed the meaning of a field that LWO2 already has, this reader would show it the LWO2 way.

Sub-chunk lengths

The one difference Assimp makes for LWO3 is in the contents of SURF, CLIP and ENVL: it reads them as chunks with 4-byte lengths (and lets a FORM appear among them), where LWO2 has sub-chunks with 2-byte lengths. Its checks of the sizes follow: TYPE 4 bytes, PRE and POST 4, KEY 10. This is unconfirmed by a real LWO3 file. The viewer here tries both: it reads those chunks with 2-byte lengths if they fit the chunk exactly, and with 4-byte lengths if only those do.

Modo’s LXOB form, which has the LWO2 chunks and an extra 4 bytes after an envelope’s index, is a different format with its own extension (.lxo) and is not read here.

In this reference

• LWO2 data types and chunks – the layout this form shares, with a worked example
• Envelopes and clips, Surface parameters and Surface blocks

Not described

Almost everything about LWO3 beyond its framing is not described here.

• Reference: every chunk, field and value that LWO3 adds or changes; the version of LightWave that introduced it (2015 or 2018); whether nested FORM chunks occur and what they hold. The 4-byte sub-chunk lengths come from Assimp’s reading and no real LWO3 file confirms them.
• Viewer: reads LWO3 by the LWO2 rules, choosing 2-byte or 4-byte sub-chunk lengths by which fits. A nested FORM is shown as an unknown chunk of bytes. Chunks it does not know are listed and shown as bytes; textures, envelopes and shaders are not applied, as for LWO2.
• Verification: only built files; no real LWO3 file was found.

Variants

• LightWave object (LWOB) – the original form, written by LightWave 5 and earlier
• LightWave object (LWO2) – the form from LightWave 6 on, with layers, vertex maps and surface blocks
• LightWave object (LWO3) – the form from LightWave 2015 on, read by the LWO2 rules

Links