A domain-specific language for doing 3d modelling. As in, you write code, and it spits out a 3d model.
If you want to make 3d stuff, there's "CAD" (Computer-Aided Design) software for making machinable, functional parts (like gears or brackets or cases or adapters) and then there's software for making art for game assets or animated shorts or whatever.
Another way to divide the space: there's software where you make the result directly using a pointing device (think "MS Paint" or something where you can "freehand" stuff), and then there's software for making 3d shapes by writing code.
(This is entirely a tangent, but I think of the "pointing-device" way of doing things as the "potter paradigm" which connects your fingers as much as possible to the digital space that is your medium so you can manipulate the thing you're making. And the latter is the "dark factory paradigm" named after "dark factories" -- manufacturing facilities populated only by robots doing manufacturing where they don't even need to keep the lights or HVAC on because the robots don't need them. In the "dark factory paradigm", you externalize a portion of your brain in the form of a program/script and it acts on your behalf on the digital medium. And these paradigms aren't limited to just making 3d files. Graphviz is another good example of something in the more "dark factory" way of doing things. And the project I'm working on now isn't the first one I've undertaken to expand availability of "dark factory" pattern asset creation tools available. I really feel like the world needs a lot more of that. Not to say the "dark factory" pattern is "superior" per se, but it's a lot better for the way my brain works and I'd like for way more of such tools to exist. So I guess I'm being the change I want to see in the world.)
Just some examples of software for making 3d models sorted on those two axes:
| CAD | Artistic 3d Modeling
---------+-------------+----------------------
Pointing | FreeCAD | Blender
Device | TinkerCAD | Autodesk Maya
---------+-------------+----------------------
Writing | OpenSCAD |
Code | ImplicitCAD |
Notice that bottom-right box is empty? I'm working to fix that.
The working name for what I'm working on now is "Modelgen". Not 100% sure that'll be the final name, but it works for now.
(And to be fair, I think some of the tools in the top box may have built-in tools for doing things by writing code, but I want something where the writing-code way of doing things is the "bones" of the project, not something kindof tacked on after the fact as an afterthought.)
Just to tease it in some slightly more concrete terms, following is kindof a "hello world" sort of program that will display (pop up a window with an OpenGL viewer in it) a low-poly sphere. (The sphere in this example will consist of 8 times 16 equals 128 faces, some square/rectangular ones with 4 vertices, some triangular with 3.)
import "mg/prim"
import "mg/util"
sphere := prim.Sphere(8, 16)
util.Display(sphere)
The result looks like this:
Outputting that sphere to a file (in GLTF format) instead of just displaying it looks like this:
import "mg/prim"
import "mg/format/gltf"
sphere := prim.Sphere(8, 16)
gltf.Encode(@{
Filename: "sphere.gltf",
VertexSets: [@{
Vertices: sphere,
}],
})
For a much more complex example, here's a desk fan I modeled with my language just to test it out and provide an example to users:
And the corresponding source code can be found here. (It was too big to paste into a Lemmy comment.)
Everything I've showed here is actual. Like, not potential future state stuff, but works today on my computer. (I haven't published it anywhere yet, but that's coming... sometime. Heh. It'll be FOSS when I do. AGPL license.)
Right now, it only supports vertices and faces, and has some helpers for doing some helpful geometry-generation kind of manipulations. It doesn't yet support textures, normals, normal maps, armatures, morph targets, animations, etc but all of that is planned to happen at some point. It's still early on. (It's nearly 25,000 lines of Go code (plus a little HTML/JS/CSS that tips the total over 25,000 according to cloc) and I've been working on it for many months (not sure exactly how long) and I'm calling it "early on". Lol.)
Just some miscellaneous stuff:
- It has a functional "playground". As in, a webpage where you can go (or where you'll be able to go once I put it out there somewhere), write Modelgen code in a text box, hit the "run" button, and it will run that Modelgen code in your browser. (Not on the server. Actually in your browser using WASM and WebGL for the displayer.) Think Go's Playground or something like JSFiddle, only for Modelgen.
- Right now, it's an interpreted language, but I'm planning to support automated transpilation from Modelgen to Go as well. Picture this. You're writing a game, right. A largely procedurally-generated game maybe similar, let's say, to Spore. Your game needs to generate creatures on the fly at runtime. So you build a function in Modelgen that takes some parameters -- maybe biome kind of stuff like aridity that might affect how reptilian the creature is and maybe gravity level that would affect how "stocky" the creature was or whatever -- you transpile that Modelgen function into Go, you write your game in Go and include that function in the code, and when your game needs a new creature, it just calls the function, which uses the parameters and maybe some PRNG and gets a fully functional model complete with textures and animations. (I probably won't bother making facilities for transpiling to other languages other than Go, but it'll be FOSS. If someone contributes code for transpiling to C or JavaSript or whatever, I'd probably be open to adopting it into Modelgen if they wanted that.)
- It only supports two file formats so far: STL and GLTF. And it only supports outputting to those file formats, not importing. But I definitely plan to support as many formats as possible and to support importing from files.
- It is written in a way such that Modelgen can be used just as a Go library without involving the DSL. And I plan for that to continue to be the case moving forward.
- Modelgen supports faces with any number of vertices more than 3. But the displayer and many of the functions that output to files require 3-vertex faces. But there's stuff built into Modelgen to split more-than-three-vertex faces into three-vertex faces automatically.
Ok. I think I've said enough at this point. Lol.