sokol_shape: A proposal

[iboB]

I saw that you're working on a shapes utility for simple functional meshes and I have a proposal which changes the library a lot, so if you end up being interested, it would be better to reflect it before the release.

Flexible vertex format.

I don't mean the retro DirectX FVF, but a way to allow more vertex customization and optional fields.

Instead of relying on a fixed vertex structure sshape_vertex_t, why not create a more flexible struct:

struct sshape_vertex_desc {
    void* position_buf;
    size_t position_stride;
    void* normal_buf;
    size_t normal_stride;
    // ... etc
}

If a pointer is not null, sokol_shape fills it with data. If it is null, it's left it alone. There can be "easy mode" utility functions which create a description for sshape_vertex_t.

This allows the following features

• The user can decide which attributes they want
• Different attributes can potentially go in different vertex buffers
• There can be multiple attributes for the same thing from which the user can choose (for example allow both uint icolor and vec4 fcolor)
• This is future proof. For example it can be reused in a hypothetical future library sokol_mesh_load, which loads obj, or gltf or fbx, which can potentially not hold some attributes. Also adding new attributes to the library (say tangents and bitangents) will be much easier

... which brings be to the second part of the poposal: I don't know if you've already planned this, but I really think tangent and bitangent generation is very important. I suppose a lot of use-cases for sokol are small graphics demos and normal space is probably very important for most of them.

Thanks for the awesome work!

[floooh]

I've been considering a more flexible feature set because the original ShapeBuilder/MeshBuilder code where I'm copying the builder-code from had a similar feature, it basically allowed you to provide a vertex layout as input to the builder which defines what vertex components you're interested in and their formats. I left this out in sokol_shapes.h for now, because in Oryol I hardly used this feature.

I'll think about it though because once the actual builder code is implemented and tested it's probably not that much work to add. I'll probably not use the pointer-per-vertex-component-idea though.

There are also much more flexible and powerful shape generators out there, like https://prideout.net/shapes.

sokol_shape.h shouldn't replace those more powerful headers, but instead provide a simpler 'plug-and-play' alternative with a simple API and direct connection to sokol_gfx.h functions.

I've also been thinking about writing a glue header for par_shapes.h, which would just contain some structs and functions to make it easier creating sokol_gfx.h resources from the data generated by par_shapes.h, this might still be an option for later.

[iboB]

Cool np. I'm just putting it out there :)

Btw I see that par_shapes also doesn't generate tangents.

Are you considering proper tangent/bitangent generation for sokol_shape?

[floooh]

PS: At least the initial version probably won't have tangent/bitangent generation, I see the point though, once there are there are texture coordinates, tangent/bitangent makes sense too. However, currently I see the header more useful for rendering simple debug shapes, not for "serious" asset generation stuff...

[MikeHart66]

Kinda on topic as this change seems like it effects Sokol in a bigger way. Is there a roadmap for Sokol? Because I am considering implementing Sokol as a new render backend for an existing Game Programming language and it kinda feels like a moving target atm.

[floooh]

@MikeHart66 Since sokol is a hobby project I don't want to commit to a roadmap, I also don't want to get into a "stasis" where breaking changes are no longer possible because too many projects depend on a stable API. Another reason for not having a roadmap is that quite a few recent changes had been "unpredictable" and were the result of "outsider" requests and PRs (all changes in sokol_app.h that happened this year where based on such suggestions for instance).

Having said all that, I still try to avoid too frequent breaking changes in the public APIs of the core headers (everything in the top-level directory), and instead try to batch such changes and bundle them with bigger architectural changes which would break compatibility anyway. This is quite rare though, seems to happen about once per year per header at most. It's more likely in "fresh" headers of course, but at least sokol_app.h and sokol_gfx.h are fairly stable now.

The optional headers in the util directory are a bit more "fluid", but breaking changes are rare as well (again, more likely in new headers than in old headers).

[MikeHart66]

@floooh thank you for your honest answer. Much appreciated.

[ylluminate]

Hey @floooh is adding 2D support to _shape also intended? There's been some discussion about using _shape instead of _gl for additional performance gains and so forth for another library being based on _gl and this seems as though it would be really great to have a cohesive 2+3D primitives library.