Inspired by this Lobsters thread, and some of the great comments within it, I would like to ask if anybody is doing some hobby programming this weekend?

  • e0qdk@reddthat.com
    0·
    1 month ago

    I’m not sure I quite get it, but if I’m following correctly, you’re using the numbers to indicate a sequence of vertices for a triangle fan here (with @ indicating the central vertex), right? If so, the vertices are used in more than one triangle; (0, 1, 2) and (0, 2, 3) are triangles that reuse vertex 0 (@) and vertex 2.

    If that’s what’s going on then it should be fairly straightforward to turn shapes defined like this into extrusions; for the simplest case you duplicate and offset the triangle fan for the other end and then generate quads/pairs of triangles for the extruded faces of the prism – and for more complicated cases you can repeat that (with planar alignment if needed) following a curve in small increments.

    I might not be following though since I don’t know what you mean by color index face hints.

    • insomniac_lemon@lemmy.cafeEnglish
      0·
      1 month ago

      You are right about a few things, though the key is that Raylib is what’s creating the polygon (after I parse the text file into a sequence) and ideally I don’t handle face/mesh creation myself (at low-level). Maybe eventually.

      what you mean by color index face hints

      For additional context on where faces are.

      I’ve mentioned vertex color (ideal as face colors), but I probably do want to handle a 3-digit-hex color palette with object-library-wide management.

      here's what I was thinking with verts no longer numbered (instead E for external, C for corner. even-odd might work better in some cases), index numbers as hints and for color

      Each arm would be its own color

      #values: matrix_xres matrix_yres target_size vert_num
#IDEA, fails with heart as there is only 1 corner vertex
32
32
160.0
11
                                
               E                
               1                
                                
                                
                                
                                
                                
                                
                                
                                
E2         C       C         3E 
                                
                                
               1                
              2@3               
              4 5               
         C           C          
                                
                                
                                
               C                
                                
                                
                                
                                
                                
                                
                                
     4                    5     
    E                      E

      The reason I’m thinking about this is that it would be better to have one way to define verts. triangle_strip can generally do more (shapes with no central point) than triangle_fan, though I think the star here is the sort-of-thing that a single triangle_strip cannot do. That, and with numbering it only allows 62 verts (0…9, a…z, A…Z), and is a bit clunky to iterate on. Numbering, especially with a strip, is also a lot more complex as you get more verts. If I got to the point of making my own editor*, I might abstract this away so the user only works with points.

      Use-in-code-wise I may have already solved fan-vs-strip with a function that just compares the values of the first few points to choose draw type, though I wasn’t confident in that as it’d require a lot more testing. Might be better to store that in an enum as well.

      * I wasn’t quite sure of using what I already made for anything more than a simple arcade-like game, so that sort of kills motivation, needing to do even more technical work just to get visible results.