🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Designing the interface to the renderer for rigged mesh.

Started by
0 comments, last by Nagle 2 years, 9 months ago

I've been using Rend3→WGPU→Vulkan→Rust to build a Second Life client. Rigid objects are rendering fine. Now it's time to think about rigged meshes, something the Rend3 and WGPU levels don't yet implement. It's on their roadmap.

Rend3 is basically a reasonably friendly interface to Vulkan. (WGPU is a layer to make Metal, OpenGL, WebGL, etc. work sort of like Vulkan, cross-platform.) You create objects called Mesh, Object, Material, and Texture, and send them to the renderer. The renderer then displays the scene in an endless loop, while, from other threads, you make changes to the scene. It's a pure retained-mode rendering system. All the GPU allocation is handled for you, and it's safe in the Rust sense.

Rend3 currently lacks rigged mesh / character support, and it's time to plan that. So, here's what I'm thinking needs to be added, for minimal support of rigged mesh.

RiggedMesh:
Like Mesh (the current rigid mesh type), but has N rows of weights, one element per vertex.

SkeletonTransforms:
Array of M transforms.

RiggedObject:
Like Object (creating an Object makes something appear in the scene), but instead of having a single transform, has the handle of a SkeletonTransforms object and a table which maps the row indices of its RiggedMesh to the indices of the SkeletonTransforms. So one set of SkeletonTransforms serves all the RiggedObjects of the body.

With this, changing the SkeletonTransforms moves all the parts of the rigged object. That's how animation works, so updating SkeletonTransforms happens frequently. RiggedMeshes don't change much. On sizing, N is small, <= 4 for Second Life. M is usually 20..50.

This is general enough to be used by different game engines, I think. It's reasonably close to what the GPU can do. It means Rend3 doesn't have to know much about skeletons; they're just an array of transforms. Creating those transforms is the job of higher level software. So that seems to be a good place to cut the problem and define an interface.

I don't think the Bevy people, who are building a game engine, got this far yet.. Here's their draft: https://github.com/bevyengine/bevy/pull/1429​ . So there's no Rust de-facto standard for this. (Rust-based 3D game development is still rather bleeding-edge. Things are going well, but important pieces are not built yet.)

Here's what Second Life's internal data for a rigged mesh object looks like, for reference.

http://wiki.secondlife.com/wiki/Mesh/Mesh_Asset_Format#Vertex_Weight_Encoding

That has roughly the same data model.
Comments?

This topic is closed to new replies.

Advertisement