Standardising geometry extraction & processing

[snake-biscuits]

Some parts of the current geo testing system are large & make more sense as part of an extension (extensions aren't as actively maintained; they're also specialised, but can work with multiple branches)

I'd also like to move some geo operations to bsp2gltf

Quickly generating small chunk of geo is still handy for small investigations, so I don't want to remove the methods Tho I would like to separate out the generation of filetypes (.obj, .gltf etc.)

Node-tree traversing methods pair well with these functions, so we should aim to export geo for all formats (eventually) I don't really want it to be a development focus Although, visualisation can really inform reversing.

5th Jan 2024: created utils.geometry for standardising geo method output

Related Issues

• https://github.com/snake-biscuits/bsp2gltf/issues/9

Geo Methods

• id_software.quake.as_lightmapped_obj
• [x] id_software.quake.vertices_of_model -> model
  • [x] id_software.quake.vertices_of_face -> face_mesh
  • [x] respawn.titanfall.shadow_meshes_as_obj -> shadow_mesh
  • [x] respawn.titanfall.occlusion_mesh_as_obj -> occlusion_mesh
  • [x] respawn.titanfall.vertices_of_model -> model
  • [x] respawn.titanfall.vertices_of_mesh -> mesh
  • [x] respawn.apex_legends.mesh (different material name lookup)
• [x] respawn.titanfall.vertices_of_tricoll_header -> tricoll_model
• [x] valve.source.model
  • [x] valve.source.vertices_of_displacement -> displacement_mesh
    • [x] valve.source.vertices_of_face -> face_mesh

[snake-biscuits]

import bsp_tool
all_branches = (*bsp_tool.branches.quake_based, *bsp_tool.branches.source_based)
methods = {(m.__module__, m.__name__)
           for b in all_branches
           for m in b.methods.values()
           if "vert" in m.__name__}

{print(f"{a}.{b}") for a, b in sorted(methods)}

[snake-biscuits]

Might make more sense to just look at what geo related methods we have & standardise in place extensions.geometry can still handle conversion to model formats A triangles_of_* series might make some sense though, as we need to mix triangle fans, soups & strips Not to mention Source Engine Primitives

Replicating Displacement triangle strips would be a good way to explore DisplacementNeighbours

Related Issues

• 75

[snake-biscuits]

Keeping track of which branches have geo methods would also be handy for bsp2gltf completeness

[snake-biscuits]

Bulk geo conversions are really slow in Python, so they'd be better suited to C++ (bsp2gltf) Prototyping w/ branch methods is still pretty handy though

It's just in some cases you need full context to visualise things

[snake-biscuits]

A small geo export option for Source Engine maps to identify locations dense with t-junctions would be neat (single out faces where primitives.count != 0)

[snake-biscuits]

While doing the extensions.lightmaps refactor (https://github.com/snake-biscuits/bsp_tool/commit/b371f3dca0fbac52844e73ad68b08ef4f7fbcde1) I remembered lightmap uvs We can't extract lightmaps from quake, quake2 or source without parsing geometry So some amount of geometry code will have to stay tied to branches

Centralising lightmap data -> image code in extensions.lightmaps still makes sense tho Especially when working with external formats (and 3rd party modules like Pillow)

extensions.geometry could just be for conversion to .gltfetc.

[snake-biscuits]

per-branch methods are still useful for exploring data, but geo is better suited to visualisation more than an extension, we need standardisation

[snake-biscuits]

As of https://github.com/snake-biscuits/bsp_tool/commit/2f597f2544c0fa5132080bf75494c1d7257130c0 core types have been moved to utils.geometry

Geometry related branch methods should use these types to keep things standardised extensions.geometry will be for storing these types in model formats (.gltf, .obj etc.)

[snake-biscuits]

This refactor went really well, helped clean up a lot of poorly maintained code too Should also greatly simplify tests

I can see some areas where we could improve though:

• geometry.Vertex should convert types (quake.Vertex -> vector.vec3 etc.)
• extensions.geometry exporters should take a dict so models can be named