Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Computational Solid Geometry (CSG) Library#672

a-day-old-bagel started this conversation inIdeas
Discussion options

CSG enables fast level-editing workflows and in-game editor capabilities. Quake's BSP tree-based levels, and all the games subsequently derived from Quake's approach (source engine games, etc.) all relied on CSG in the form of brush-based level creation, for example.

Currently, we have zmesh, which includes some tools for operating on triangle meshes, but I don't see any libraries in zig-gamedev specifically designed for CSG.

In my own project, I've tried several such libraries. One that stands out isManifold. Manifold is quickly gaining popularity, and is being considered for inclusion in notable projects such as Godot and Blender. It's already being used by recognized names in the engineering/cad space.

I had previously hoped to bringa smaller library up to speed, fix its bugs, and suggest it be included in zig-gamedev, but I'm finding myself spending too much time bugfixing with this one, and so I'd tend to suggest Manifold instead now.

Anyway, I don't know if there's been any discussion so far about CSG or including CSG capabilities in zig-gamedev. Naturally, modern CSG offers quite a bit more utility and usability than the BSP tree engines of old could offer, so to be clear, CSG can serve as a useful tool for level editors or other in-game editors even without the users game engine being tailored around it. Triangle meshes can be an output, for example, to mesh with the rest of the zig-gamedev tools.

Personally, for me, the conventional asset creation pipeline used by most of the game industry, where you have big fat 3D modeling and art asset creation tools requiring special training or expertise to use, and where the process of using them eats up the bulk of the budget (and time) you have to make a game, is unappealing.

I'm including CSG as a big part of my own project, regardless of whether we're interested in including it in zig-gamedev, but I wanted to bring it up for discussion.

EDIT: Oh, I should add: I'm happy to create and maintain the "zmanifold" or whatever zig-gamedev sub-library we'd have, if we chose to include it, following existing patterns in here.

You must be logged in to vote

Replies: 1 comment

Comment options

One other thing I might mention: Manifold already has C bindings, so zig bindings aren't large or complicated.

I already suggested to the Manifold creator that I could add zig bindings into Manifold's own bindings directory alongside the C bindings, but they said they'd prefer zig bindings to stay in a separate repo (they'd never even heard of zig, so I understand - Java bindings were also relegated to a separate repo anyawy).

Given that, I'll be making the equivalent of a zmanifold repo somewhere no matter what, so I'll probably start making it under my own account name, and if we want it here, it can be moved.

EDIT: Here is the in-progress zmanifold repo:https://github.com/a-day-old-bagel/zmanifold

You must be logged in to vote
0 replies
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Category
Ideas
Labels
None yet
1 participant
@a-day-old-bagel

[8]ページ先頭

©2009-2025 Movatter.jp