you are viewing a single comment's thread
view the rest of the comments
[–] 1 point 2 weeks ago (1 child)

You might consider vertex color support at-least for part color and at-most for face color (/face loops).

Yeah, kindof my guiding principle for what features I want it to support is "support whatever GLTF supports", and GLTF has something called "COLOR_0" which is basically vertex colors. So, yeah. It's on the roadmap. How high up the priority list? No clue at this point. Lol. (Right now I'm tweaking the OpenGL 3d viewer built into it, and I think probably one of the next things I'll tackle is per-vertex normals. But yeah.) If folks want per-face colors, I'll probably just make users split vertices as necessary. Like, if they have something like the following:

     *
    / \
   /   \
  / Red \
 /       \
*---------*
 \  Blue /
  \     /
   \   /
    \ /
     *

And they want the whole top face to be red and the whole bottom face to be blue (or, say, if they want a hard crease normals-wise at the junction there rather than a smooth transition), they'll just have to have 6 separate vertices (though some of them will share the same location in space.) If that makes any sense.

I’m not sure if ‘modelgen’ is a good name, it sounds AI-related.

Yeah, that's good feedback to have, and you're not wrong. I don't know. I haven't thought of a better name yet. Heh.

It has what I've heard called a "Swiss Army knife" CLI. If you think of how Git works, for instance, where you have "git log", "git commit", "git revert", "git show", "git diff", etc, that's a "Swiss Army knife" pattern. So I want the executable to have an easy short version. I was thinking "mg" for "Modelgen". (And it would have "mg run" for running a script and "mg shell" for an interactive REPL and "mg help" for usage information (all three of these preceding examples already exist and work) and "mg transpile" for transpiling a script to Go (when transpilation to Go is supported in the future) etc.) So I kindof want that to be a consideration of the name. If I renamed it to "Enmodelerator" or whatever, it'd be harder to come up with a short version for that. Heh.

Anyway! I'm rambling. But I do want to avoid any appearance of it being connected to anything GenAI. (And I do specifically intend for it never to include any LLM-generated code or anything.)

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 2 weeks ago* (1 child)

    if folks want per-face colors, I’ll probably just make users split vertices as necessary
    they’ll just have to have 6 separate vertices
    If that makes any sense.

    Sure, this is the approach I believe was used for Mt. Crumpit in the VC skybox in the PS1 Grinch game (see the image in my post). Basically cut-and-paste into new mesh ('separate>selection' in Blender*), then paint. Perfectly fine for final assets, but can complicate mesh changes.

    Another trick is to instead just add edge loops to contain the transition, so not exactly a hard edge but pretty close with a small enough face (this was Spyro's trick for mountains/clouds/celestial-bodies etc in its VC skyboxes, also Homeworld 2 see explanation).

    Technically gltf does support face corner domain (as called by Blender* color attribute), though I can understand the multiple reasons you might not go that route especially early on. Basic VC does cover a lot of use-cases, and I'm not sure if your modelling method will have that sort of work-flow where it's simple+common to work with faces/topology directly like that (like for character design).

    When you do get to textures/UV stuff you can also go that route for color via a palette as well. Assigning the entire UV map of a part onto the middle of a single pixel would also be the easiest first step to code, and a palette would make a lot of sense for this type of tool.

    * I also am not so comfortable with Blender. It's not impossible for the low-poly stuff that I do, but I'm not a master with shortcuts and the modifiers bother me with errors or I-should-not-have-done-that moments.

  • source
  • parent
  • hideshow 2 child comments